Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Afrotronics on 2003-11-10 16:16:11
-
Yo er'body. I was chillin at my computer last night and I was messin' around with the data files from FFVIII, specifically the model files (.mch). In my programming classes (I got to Eastern Michigan University BTW) I'm learning how to read from different file type and finding algortihms and that good stuff. So I decided to challenge myself. I wanted to see if I could figure out the structure of an FFVIII model file. After tens of minutes of hex editing and consulting with my friend Mo (who is an excellent 3d and AI Programmer BTW) I notice some patterns that may be vertex data. Looking through the file you'll come across lines that have -D and %D in an obvious pattern. A majority of the time the -D or %D (it's usually %D) will have six characters before it. I think these characters may be the x, y, and z coordinates (but where is w?). Before and after each instance of the 6char+%D there is (in hex) 0000 0100. I think this may be the defining space container for each vertex. There were some other patterns I found but I can't remember them right now (I'm in the computer lab at school so no FFVIII data is accessable). But the thing I'm forgetting is pretty important if I recall. My friend Moe pointed it out to me. I'll post it when I get home tonight. I don't know if I'm even remotely on to something ...shoot I could be looking at the wrong files...If I am, I'm definitely going to start writing a file reader for this file type. But I hope this is useful to y'all. Off topic--You know how you can hexedit a lot of programs and plain english will turn up in a file? Am I not seeing any English in these files (except for the .cnf files and the grp file) because the game was programmed in japanese or is there just no human readable data in any of the files? Anyways, I gots to get back to programmin' my stupid/hard e-commerce recommendation system project for my java programming II class.
-
Vertex data and texture (including mappings) can be read through an old editor I once wrote... so those values you've seen is probably the vertex coordinate data, yes. :) I never quite figured out where the skeletal layout/animation is stored however, I think it's in the individual scene files where they're used...
-
Oh yeah....I was also hexediting the FFVIII executable and there are craploads of Direct 3d calls in there. I have no clue what they all do cuz I don't know directX programming all that good stuff very well. I'm assuming (not a good idea, eh :wink: ) that somewhere there's a call for getting model data.
-Just for clarification this ISN'T the pattern that I forgot the details (because this isn't a pattern at all, it's just an observation). Yo, if you have any extra info and whatnot pllllllleeeeeeeeeeeeaaaaaaaase post!
-
:( :erm: Sorry bout the double post I wasn't quite sure which topic it would go under. I would've thought that it fits Tech-related more because tech related includes programming and inner-workings, but I wasn't sure because I saw subjects like mine in the Programming feedback topic. I hope people follow the link in the other one to get to this one because I think it would be really cool if we could get out hands on that there FFVIII Model data and make it useful :D
-
First Qhimm mentioned he has an old program for doing this
Second yes it would have a lot of Direct 3d calls in it. Of course this must mean you are talking about the PC version.
I'm still in the process of wadding through the PSX version of FF7's data :)
For the PSX version of anything beyond FF7 well Square decided to PACK everything tightly so no one could easily access or read the data (I guess they didn't like people ripping data from there games :) ).
Qhimm-
FF8 PC version does it have higher polygon count models for it?
or is it the same as the PSX in terms of model data?
does it have improved textures?
Do you have the 'prolog' information for the model data on the PC?
Cybie
-
I tried to rip ff8 data apart, but i didnt succeeded yet. I was able to extract only model textures ... no polygon / vertex data yet. I was trying .dat and .c?? files IIRC ... but im not sure about that. I thought that monster polygon / vertex data are stored in those files aswell, because in each there are textures for one monster and lots of other data i dont understand.
-
were you looking in the .mch files?
-
me not sure about that ... maybe ...
could you guys post info that you found ?
-
From what I've seen, the model data in FF8 PC is identical to the PSX version in terms of quality.
-
Ahh.. ok that means they are have similiar data..
Not that it's terribly informative.
However.. here is what I've found about the PSX models in FF7.
There is ALWAYS a TIM section in them and it's ALWAYS the last section in the file. If FF8 data is stored the same as FF7 then finding one of the characters TIM data location that's stretched on them, will find also there model data. It's backwards admitedly however I think it has potential to work better than anything else I have at least (hehehe). Are the background images the same format.. I wonder. They are all uncompressed too as I understand it. More exploring I guess :)
Cyb
-
yes they are ... i found out that there are usually 11 parts in the file, i think file is like this: (i dont have proper info on this cpu, so its unprecise)
first there is 4bytes(long integer) - number of file parts. Then for each part there is its offset (4bytes). I know that part 11 (and higher) are TIM textures (model texture, i found some buildings textures, so i think that scenes are stored like this aswell) ... i can extract model textures, it is implemented in biturn, but nothing more ... i hasn't been able to decode model info..
i'll post more proper info when i get it.
-
Oh... That's good news.
FF7's file format for models is much more varied and have a lot more parts to the objects.
The only exception in FF7 about the TIM at the end is HICLOUD.LZS this has it as Item 96 of 113. It's actually a 8 bit texture (instead of the 4 bit ones used on all the other ones).
Normally if the model doesn't use a texture it has a 64 byte TIM that's appears to be TV color bar colors. 16 pixels in all.
I assume all FF7 objects have colored vertices and use Guarad shading save for the few with actual textures?
I'm still working on the PSX model data.. darn hard to figure out.
Cyb
-
I've done some work with the FF7-format. Yes, the last section is always a 4-bit TIM with no pixel data (only palette) when the model has no texture. I know also about the vertex/color data and the offsets that pointing to them. FF7 model files contains also lines and quads. it seems there are also the hierachy and skeleton data in the files but i haven't decoded them 100%.
-
Which section has all the directive information for the file?
Is it section 1 or 2? I haven't pulled my hair out looking for it, but I've thought about it, back to adding my search function to my TV tool. (Originally Tim View. Now it views TIM's LZS compressed TIMs .DAT (partially resolved still needs more work) MIM <DITTO> and dumps BSX files. and of Course Battle Models).
Anyhow I can partially decode MIM files at least to see all the blocks that consist of the actual image.
Is it me or would all the character models be cramed in with each BSX or DAT file? I think that's where all the data for the cutscenes is.
Cyb
-
Yo, I'm thinkin' that none of the model data is actually stored where the textures are. The mag20383xx... files are just the texture and motion files. I'm thinkin that all of the model data is stored in the .mch files. Wouldn't it make sense to keep the model data separate from animation and textures to cut down on size. If each scene had to store an individual model then the game would be so much larger. Seeing as that the models themsleves are pretty much static throughout the game you could just keep them in a separate file. For a model to be the actual model it needs to well, stay as the model that it is. It would really suck for the programmers to have to reference a different model for each seen instead saying "We have this model that we're going to put in this scene and in this scene the model will be doing this (which is the motion data) and will use this(these) texture(s)". This is only a guess. But I'd have no other explaination what the .mch files are in a directory called "model" and everybody is having such a crazy hard time figuring out where exactly the vertex data is in the other file.
-
Well, i guess I was kinda wrong. I just found that the .mch files contain texture data at the very begining. it looks like after that though, there is vertex data or mapping data. It seems as though that the main character each have their own .mch file.
-
Pretty much all of the main characters have their own .mch files which are referenced in the actual field data files (rather than having to include the entire model in each field it's used). Other character models reside in the chara.one files found in the field files. Also, all animation data resides in the chara.one files, even for main character models. The animation data (found in the beginning of each model block in the chara.one files) is pretty much the only part of the model format that still eludes me; I have decoded the vertex data, face data, skeleton data and texture mapping data. Once I've understood the format of the animation data, I might compile a document on it, or write a small program to read the models. (just pleeease don't bug me about it ;) )
Until then, here's a basic layout on the .mch files:
- Index block, 64 DWORDs. Contains the offsets of each texture in the file, then a 0xFFFFFFFF, then the offset of the model data.
- Texture data. Standard TIM format.
- Model data header, 8+8 DWORDs. Contains counts and offsets of different types of model data (skeletal joints, vertices, unknown, faces, unknown, vertex-to-bone links, 3 x unknown).
- Skeletal joint data. 64-byte blocks of mostly zeros, contains a 1-based parent index and a bone length value. Probably a bunch of skeletal deformation data used in-game, but whose values are initially stored as zeros.
- Vertices. Blocks of 4 shorts, the first three being x-, y- and z-coordinates and the fourth unused.
- Faces. Huge blocks containing vertex indices, color data (unused), edge data (I think), texture mapping data and texture ID. Faces can be 3-point or 4-point polygons, decided by the first DWORD (actually it's a PSX GPU command ID).
- Vertex groups, or "limbs". These decide which vertices are connected to which skeletal node. Groups of 4 shorts, with the index of the first vertex, the number of vertices and the bone ID (1-based) to which they belong.[/list:u](http://www.qhimm.com/squall.jpg)
Teaser image of a decapitated Squall
Side notes: The animation data somehow stores the internal rotations for the model's skeletal nodes using 4 bytes per node. I'm speculating that the format would be one which a PSX could handle, in line with the lazy programmers theorem. Any ideas?
Also, the battle model format is vastly different from the normal field model format. I haven't even been able to find any vertex data in it, I'm almost suspecting it's compressed or something.
-
WooooooHOOOOOOOOOO!!!!!!! Qhimm you so totally rock! Thank you to everybody that helped in this effort. I love seeing collections of knowledge be put to work! Oh yeah, I was checkin' out some of the field data. I forgot which file it was exactly BUT it looks like the texture and model data for the vattle scences. The texture for battle scenes are 256x256 and for some reason or another each line of texture is separated by a line of a solid color. Just thought I'd throw in another two cents.
-
in .mch files:
7F 7F 7F 00 7F 7F 7F 00 7F 7F 7F 00 7F 7F 7F 00
<data>
7F 7F 7F 00 7F 7F 7F 00 7F 7F 7F 00 7F 7F 7F 00
is this some sort of container of some sort?
-
Nope, that looks like the vertex colors actually.
-
Using d001.mch I tried the whole 4shorts for the x,y,z coordinates and when I put the verteces in to a 3d space it looks like a vase or something kinda shaped like a vase, or a guy crouching. Is it supposed to look like a vase?
-
Side notes: The animation data somehow stores the internal rotations for the model's skeletal nodes using 4 bytes per node. I'm speculating that the format would be one which a PSX could handle, in line with the lazy programmers theorem. Any ideas?
Also, the battle model format is vastly different from the normal field model format. I haven't even been able to find any vertex data in it, I'm almost suspecting it's compressed or something.
Qhimm I've analyzed the PSX FF8 data for a bit, it's identical to the PC data you have provided thus far. I suppose one can conclude they are the same surprisingly. Unlike FF7... For FF9 they used yet another format.. sigh at least we know :)
Cyb
-
wow Qhimm great work.
-
Hey i finally found a way how to read something of those ff8 .mch's ... model with textures and skeleton to be exact. No animations yet.
And battle models are still giving me headaches, so its only bad-looking models up-to-date.
Here are some pics i dumped:
http://mypage.sk/BIN/ff8f_1.jpg
http://mypage.sk/BIN/ff8f_2.jpg
http://mypage.sk/BIN/ff8f_3.jpg
http://mypage.sk/BIN/ff8f_4.jpg
(http://mypage.sk/BIN/ff8f_5.jpg)
http://mypage.sk/BIN/ff8f_6.jpg
-
And here is how are ff8 battle models (.dat's) stored:
Final fantasy 8 battle dat format
At the start of file there is 'file data table'.
- file data table -
long number_of_file_parts
number_of_file_parts * long offset to file part
long end_of_file_offset
Some file data have 'file data table' or 'data sub table' at their start if they
contain more items, textures for example. 'data sub table' is similar to 'file data table',
except it does not have end_of_file_offset. All offsets are relative to table start offset.
- data sub table -
long number_of_file_parts
number_of_file_parts * long offset to file part
File data table shows that file consists of 11 parts usually for monster battle files.
Of these i know that 1st is bone model, 2nd is model geometry and 11th are textures,
3rd is probably model animation, 7th might be monster information.
I haven't decrypted whats in other parts, but i think there are animations, maybe monster
info (i saw monster name there somewhere).
- bone model -
header is 16 bytes long
2 byte short number_of_bones
14 bytes unknown
each bone info is 30h (48 dec) bytes long
2 byte short bone parent
2 byte short bone length, negative
44 bytes sometimes zeroes, sometimes not
- geometry -
There is 'data sub table' at the start of data. Shows number of objects and
offsets to their data.
After table there are vertices. each is 3 * short = 6 bytes;
there ain't no number of vertices, but vertex data are 16 bytes padded, and
last 8 bytes are zeroes. before that there are numbers of 3polys and 4polys.
After that data are padded with zeroes to 16 bytes from start of vertex data.
then polygons follow
- texures -
There is table like 'file data table' at the start, from which you can see how many
textures are there, what are their offsets and sizes. They are FF8 tim's, 8bit paletized,
usually with sizes 128x128, so their size is 16,928 bytes. Data of these texture files
start with these bytes: '10 00 00 00 09 00 00 00 0C 02 00 00'
-
I'm really sorry to revive this old topic, but I'm currently trying to work on that FF8 formats based on this topic, however, I've got a problem... :D
After table there are vertices. each is 3 * short = 6 bytes;
there ain't no number of vertices, but vertex data are 16 bytes padded, and
last 8 bytes are zeroes. before that there are numbers of 3polys and 4polys.
After that data are padded with zeroes to 16 bytes from start of vertex data.
Well, I don't want to criticize your english, since mine isn't better, however ... I don't have any idea what you're talking about... :-?
Could you, or somebody else who understood it, tell me, what you mean?
Oh, BTW: Yes, part 7 is monster information. Right at the beginning there is a 24 bytes length string telling you the name, you will just have to add 2 to every single char...
Thanx!
- Alhexx
- edit -
Oh, and how does that polygon data look like?
-
I have to say I can't read DAT files properly. Vertex data look
quite promising, but polygon data look absolutely wrong.
I could not find vertices count anywhere, so I though that verts
end when vert coords are zero. But looks like its not it.
Here are structs and code I use:
struct s_FF8_dat_3poly {
short vi[3]; //vertex indexes
char texcoords1[4];
short u1;
char texcoords2[2];
short aa;
} poly3;
struct s_FF8_dat_4poly {
short vi[4]; //vertex indexes
char texcoords1[2];
short u1;
char texcoords2[2];
short aa;
char texcoords3[4];
} poly4;
for( i=0; i<polys3_count; i++ ) {
cfin->Read( 16, &poly3 );
ula[ 0 ] = poly3.vi[ 0 ] &= 0x7FFF;
ula[ 1 ] = poly3.vi[ 1 ];
ula[ 2 ] = poly3.vi[ 2 ];
StorePolygon( 3, ula );
SetPolygonMaterial( polygons_count-1, 0 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 0 ),
(double) poly3.texcoords1[ 0 ] / 127, (double) poly3.texcoords1[ 1 ] / 127 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 1 ),
(double) poly3.texcoords2[ 0 ] / 127, (double) poly3.texcoords2[ 1 ] / 127 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 2 ),
(double) poly3.texcoords2[ 2 ] / 127, (double) poly3.texcoords2[ 3 ] / 127 );
}
for( i=0; i<polys4_count; i++ ) {
cfin->Read( 20, &poly4 );
ula[ 0 ] = poly4.vi[ 0 ] &= 0x7FFF;
ula[ 1 ] = poly4.vi[ 1 ];
ula[ 2 ] = poly4.vi[ 2 ];
ula[ 3 ] = poly4.vi[ 3 ];
StorePolygon( 4, ula );
SetPolygonMaterial( polygons_count-1, 0 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 0 ),
(double) poly4.texcoords1[ 0 ] / 127, (double) poly4.texcoords1[ 1 ] / 127 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 1 ),
(double) poly4.texcoords2[ 0 ] / 127, (double) poly4.texcoords2[ 1 ] / 127 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 2 ),
(double) poly4.texcoords3[ 0 ] / 127, (double) poly4.texcoords3[ 1 ] / 127 );
SetPointTexCoords( GetPolygonPoint( polygons_count-1, 3 ),
(double) poly4.texcoords3[ 2 ] / 127, (double) poly4.texcoords3[ 3 ] / 127 );
}
If you want to read MCH files I can put here some code too.
-
Okay, thanks. I'll see if can use that stuff in my work.
However, something I haven't been posting for a while: :D
(http://www.alhexx.com/tankyou.jpg)
- Alhexx
-
Its amazing how quickly you guys figure this stuff out... I really need to learn how to do this stuff some time.
-
I have to say I can't read DAT files properly. Vertex data look
quite promising, but polygon data look absolutely wrong.
I could not find vertices count anywhere, so I though that verts
end when vert coords are zero. But looks like its not it.
Here are structs and code I use:
...
If you want to read MCH files I can put here some code too.
10:27 5/10/2004
Thanks for sharing..hmmmmm I wonder if this is anything like the PSX version data time to look!
Cyb
15:20 5/10/2004
Ok after abusing the FACE information some I find it rather perplexing.
First none of the verticies are grouped as far as I can tell at least. I'm a little puzzled about the edge information I'm 3d ignorant, why are there 2 sets of vertex data? All the information that doesn't make sense in the faces .. actually don't seem to do anything for moi. (IE they are invariant).
IE I have
1 2 0
0 1 2
for one triangle polygon.
What does the second set of numbers do?
The verticies are my other problem as I said they don't appear grouped.
Or is this what the edge data is for? IE
Vertex 1 2 0 define this polygon and the remaining data does something else (useful perhaps?) I've drawn all the faces at once and it merely gives a jumbled pile of trinagles looks funny actually but seriously ...
I think this is why I'm having trouble with FF7 polygon data as well (hmmm). Or at least finding how the skeleton information is applied at the very least.
-
Ok after abusing the FACE information some I find it rather perplexing.
First none of the verticies are grouped as far as I can tell at least. I'm a little puzzled about the edge information I'm 3d ignorant, why are there 2 sets of vertex data? All the information that doesn't make sense in the faces .. actually don't seem to do anything for moi. (IE they are invariant).
IE I have
1 2 0
0 1 2
for one triangle polygon.
What does the second set of numbers do?
please to which FACE information are you reffering to ?
sometimes 2nd set of vertex indexes is set to array texture coords, or colours.
In ff7 p files polygons there were first vertex indexes, then normal indexes and last were some edge indexes. (according to doc http://mirex.mypage.sk/FILES/pformat.txt ) I was using only vertex indexes btw.
-
<SNIP>
please to which FACE information are you reffering to ?
sometimes 2nd set of vertex indexes is set to array texture coords, or colours.
In ff7 p files polygons there were first vertex indexes, then normal indexes and last were some edge indexes. (according to doc http://mirex.mypage.sk/FILES/pformat.txt ) I was using only vertex indexes btw.
FF8 PSX
The first 3 faces plus face 12 to see what a Quad looks like, of a small Squall model have this data
// FACE 0
// 25010607
// Polygon Flat Tri w Tex Opaque No Light
// 0001 0002 0000 0000
// 0000 0001 0002 0000
// 00,01 08,04 13,02 0E,00
// FACE 1
// 25010607
// Polygon Flat Tri w Tex Opaque No Light
// 0001 000A 0007 0000
// 0000 0003 0004 0000
// 68,1D 5F,1D 65,1A 00,00
// FACE 2
// 25010607
// Polygon Flat Tri w Tex Opaque No Light
// 000A 0001 0004 0000
// 0003 0000 0005 0000
// 68,1D 71,2A 68,27 00,00
// FACE 12
// 2D010709
// Polygon Flat Quad w Tex Opaque No Light
// 000A 0009 0007 0008
// 0003 0009 0004 000A
// 68,1D 71,2A 6D,1D 00,00
There are models with multiple tims that appear to have higher resolution in terms of polygons and textures. However this is the structure information I am using. I can't acertain the size of the remaining data in the model or what it's for.
Actual structure information I'm using.
typedef struct
{
UINT32 REFS[64];
}
PSX_FF8_MDL_HDR;
typedef struct
{
UINT32 SKJ;
UINT32 Vert;
UINT32 ZZ0;
UINT32 Face;
UINT32 ZZ1;
UINT32 V2B;
UINT32 ZZ2[10];
}
PSX_FF8_MDL_HDR2;
typedef struct
{
UINT16 Parent;
INT16 Length;//??
UINT16 ZZ0[2];
UINT16 FLAGS;//??
UINT16 ZZ1[27];
}
PSX_FF8_SKJ;
typedef struct
{
UINT8 U;
UINT8 V;
}
PSX_FF8_UV;
typedef struct
{
PSX_FF8_UV UV[4]; // 8
UINT32 ZZ0; // 4
UINT16 ZZ1[4]; // 8
UINT32 Type; // 4
UINT32 ZZ2[2]; // 8
UINT16 Edge[8]; // 16
PSX_FF7_CLR Colors[4];// 16
}
PSX_FF8_FACE;
They provide 8 edge spaces but only 6 are used for triangles and 8 for quads.
I've not bothered with the UV data yet as I just want the actual 'frame' to show first. I'm wondering if the coordinates are relative to each other in FF8.
The Skeleton Joint information seems mostly empty it has a few things and that's about it.
I'm baffled over the edge information and how to use it at this time.
I think the second set of Index values is how the polygons are jamed together, but I can't be sure as I have no idea what I'm looking at :)
Cyb
-
They provide 8 edge spaces but only 6 are used for triangles and 8 for quads.
I've not bothered with the UV data yet as I just want the actual 'frame' to show first. I'm wondering if the coordinates are relative to each other in FF8.
The Skeleton Joint information seems mostly empty it has a few things and that's about it.
I'm baffled over the edge information and how to use it at this time.
I think the second set of Index values is how the polygons are jamed together, but I can't be sure as I have no idea what I'm looking at :)
Cyb
Oh no I've gone crosseyed :z
-
Oh no I've gone crosseyed :z
You qouted part of a long post and said you went cross eyed. I donno.. are you just posting for the heck of it?
Cyb
-
Myeah, I was having on of those days, sorry.
-
Any progress? I'd really like to be able to have the ff8 character models in Milkshape 3D or 3DS Max someday.
-
Can be done, as you see few pics in my posts ... I just have to make new release of Biturn.
-
Have you updated Biturn yet. Sorry for bugging, however, I live, eat and sleep ff8 :)
-
not yet. I'll put a reminder to upload it.
-- edit --
ok here is some raw alpha version, its buggy but it should be able to see FF8 field files with extensions .MCH. There are two mch's included in archive.
http://bin.mypage.sk/FILES/Biturn_086alpha1.rar
-
Hey, thanks man. Unfortunately, I'm stuck at my cousins house for the week with a comuter that was made like 6 years ago and it can't do anything big without crashing... So I'll have to get it sometime this weekend.
-
i cant even find files with those extensions lol.... i wish i payed more attention to learning this kinda stuf... ive been too busy modeling :P
-
i cant even find files with those extensions lol.... i wish i payed more attention to learning this kinda stuf... ive been too busy modeling :P
As in playing with 3d models or the other kind of modeling? :D
As for FF8 models etc.
I should be getting to speed on fixing the myriad of bugs in TV so as odd as this sounds, I'll be visiting FF8 data after I rewrite FF7s stuff.
I have decided the sanest way to handle everything is to have an intermediary object system to handle the rendering instead of using the original data. This will do the following:
[list=1]
- Eliminate the current chicken egg texturing problem and insure the textures are initialized correctly.
- Insures the Object data doesn't need any goofy special handling and each object is treated the same.
- Removes the need to have seperate rendering segments for each file type (IE FF7 character FF7 background FF7 field character FF7 field NPC FF7 battle scene FF8 character etc etc)
- Reduce the over all clumsy code and make a more universal approach to generating other object formats fot output instead of dumping things to a big text object.
[/list:o]
Cyb
-
http://www.uglypeople.com/uploaded/11711/0067.jpg
you decide which kind of modeling :P
naw, ive been busy working on a few ff7 characters, check the general section of this forum for a wallpaper i made of one of them.
also, if were on about cracking model data, would it be safe to assume, that in theory, once this is done, i could put a different character model into ff8 in place of another? i understand i would need that characters skeleton, and to rig them to it n all (worlds crappyest job appart from skinmapping)
-
Creative Inc: have you tried it ? Did it work ?
Almighty_gir: you have to unpack those big .fi .fl files, inside there are field .mch files.
-
ahhh mirex forever my saviour. unfortunately my ff8 disks were involved in an accident recently, and i dont believe in cracks...so im trying to find somewhere that still sells it >_<
-
ahhh mirex forever my saviour. unfortunately my ff8 disks were involved in an accident recently, and i dont believe in cracks...so im trying to find somewhere that still sells it >_<
Very commendable...I know more than a few people who would instantaneously go and download a crack from the net should that happen.
-
well...if i owned the cd's and didnt want to use them, thats one thing, but in this instance it would mean downloading the full game, so....i think thats wrong....
anyway, on topic, if anyone could send me the model for squall, and seifer, in 3ds format, that would be awsome :D
-
well...if i owned the cd's and didnt want to use them, thats one thing, but in this instance it would mean downloading the full game, so....i think thats wrong....
anyway, on topic, if anyone could send me the model for squall, and seifer, in 3ds format, that would be awsome :D
If you are at 56K that's a pain. 256K it's less. However it's a gray area, I don't think I want to go there personally. :)
Nope wish I did though. I suppose as soon as I finish the base model changes om TV I will start looking at export options for the models. Right now I just have to make bone and joint objects and then create the skeleton object. It sounds complicated, but that's because it is. There is no easy way to do it, that seems to be my conclusion.
Cyb
-
@Mirex: I'll let you know in the next 10 minutes. Just got back from my cousins house.
EDIT: Hey! whaddua know! It works. great job man.
-
At least you know where your FF8 CDs are. Mine disappered.
Wahhh!
BTW, I think you can get the publisher to replace CDs for a fee.
-
anyway, on topic, if anyone could send me the model for squall, and seifer, in 3ds format, that would be awsome
Duh people dont even try. I dont know if they are the ones, because i haven't played ff8 so far, but there are two of the main guys models, in that archive ! Convert them by the exe which is also in archive and there they are. But i think they will look ugly, because 3DS is old format and it does not handle proper point coords texturing.
ok here is some raw alpha version, its buggy but it should be able to see FF8 field files with extensions .MCH. There are two mch's included in archive.
http://bin.mypage.sk/FILES/Biturn_086alpha1.rar
-
its not that i dont try, its that i lost my cd's and formatted my pc, and refuse to illegally download the game.