TODO:-Change rip triangle/quad button behaviour (disable if not any available)-Limit those annoying MessageBox'es.-Fix triangles UV calc.-Auto texture size resolve after open-Better MTL generation/ to make this faster-Button for loop thru all models-Throw away this message box in extended mode

An "extract all to one .obj" function which gives you one already merged .obj would be the best since some stage seems to have more than 20 fragments..and merging them one by one can be pain in the ass (but if it takes too much time no problem )

Yep. Checked that. 3DS Max hates meshes, that have too much vertex info. I'll tell you why this is happening:

There's Entry point for model.

At first it says how much vertex are there in this one segment. Then there's X Y Z data for each vertex. After vertex data, so after 6*number of vertex there's 4 byte padding + MODULO from absolute position, but this is not important. After this there's count for triangles and count for quads. Not always triangle part of this model uses all of vertices. So in triangle part of model there's vertex data for both triangle+quad, but only data for triangle connection. That makes 3DS Max furious. Other softwares should get over it. Currently, I can't solve this problem, however... there's a small chance I'd like to write below.

I took a closer look how does a OBJ file with many objects stitched together look like... You won't believe. It's just one model after another. O_O It's like copying one model data to another's and it works! I though I wouldn't be able to figure a way to do this because of every model needs to use it's own vertex, vt and face info, and today I've just seen this. So a magical button for one way convert to ready, stitched model is just a matter of time.

Still can't find a problem with triangle VT. I didn't test this in 3DS Max yet. I'll do like I did with quads. I'll manually repair the texture, and see what result should I get from my file. This worked for quads, should work for triangles.

I did make some major changes. Made it faster now to rip models. No need to generate MTL, click on resolve texture or etc. Just select model and RIP. That's all.

I'll post the software updated to TOOLS category here. I'll edit this one to post a link for this.

However, I just found a logic bug. It caused in some rare cases to throw away an exception.

Yep, a problem you posted was fixed in 0.95, available to download in topic in TOOLS. This error was appearing when TPage resolving was trying to use UV translation bigger than the texture itself. I just had to break the loop one index earlier. Clearly my bad.

Keep me updated with any other bugs you'll encounter. Thanks.

Kaspar01, really? Well, I wasn't expecting that. I corrected only that loop that added one bad face indice due to breaking loop after doing instructions instead of checking condition before calculating.

Kaspar01, really? Well, I wasn't expecting that. I corrected only that loop that added one bad face indice due to breaking loop after doing instructions instead of checking condition before calculating.

Yep! I already tested it on many stages but never got that error again

The triangles uv problem is weird.. it looks like each triangle take the right piece of texture but it's shown "reversed"..

Maybe I'm wrong but it looks like the UV "positions" of each triangle are correct but they're not correctly assigned to their own vertex..

if I am not mistaken that is the bridge in dollet connecting to the communication mountain.

You're probably right.

I made that list before MakiPL released the tool just looking at the first clut of the corresponding TIM texture so.. there are probably many errors (when you find at leas a "?" it's because I was not sure about it )

I made that list before MakiPL released the tool just looking at the first clut of the corresponding TIM texture so.. there are probably many errors (when you find at leas a "?" it's because I was not sure about it )

Thanks for your correction! later I'll edit the list.

Is there a way to rip just the TIM the .x file is calling? This would be very handy for texture modders.

Use TIM Viewer. TIM texture is the last segment in .x file and is starting with header 01 00 00 00 09Changing image data after header, CLUT and core info should work.

These days I'm manually fixing some textures extracted from tim files to create proper material in 3ds max (whith alpha map) but it's not always an easy task to guess the right color palette for each texture piece..so I wonder... there is any info about how the game "knows" which one is the right one?How does it pick the right colors from the tim file?I tried to read something about .tim format but it looks like those info are not contained in the texture files..(this would be an explanation about why there is actually no tool able to extract the correct and complete texture automatically).

The problem is that for battle stage the "palette sections" have different dimensions and they apparently do not follow any logic order..(unlike world map textures which are placed on a square grid whith subsequential order).

I'm not asking to work on it..I just wonder if anyone already looked at this stuff

These days I'm manually fixing some textures extracted from tim files to create proper material in 3ds max (with alpha map) so I wonder... there is any info about how the game "knows" which one is the right one?How does it pick the right colours from the tim file?

There are two PSOne GPU related instructions: 12's byte and 15's first byte digit (quad) [and that's probably this]. Changing those produced for example inverted colours. However, FFVIII engine uses texture colourization, so it's real-time colourized - 21's, 22's and 23's byte (it's generally used to imitate the fake lightning in VIII).I found no way to use it though. (colourization) :CEven if I could manage, to get values for pallete used (CLUT, not colourization) I still couldn't make any use of it. For generic .OBJ uses I'd have to colourize the texture itself, and it's out of my reach. Sorry. :C

I'm started to work on producing one .OBJ file. This would need, to convert quads to triangles by myself. Should not be a big deal. Mixing quads and triangle objects messes up texture coords and face indices of the others. Triangulating quads and stitching all should work, probably.

Actually the only thing I could guess is that each polygon or group or uv group is assigned somehow to the right color clut..Something like multi-material in 3ds max but whith color cluts ID instead of material ID.. (I could be totally wrong anyway )

If I'm right then there is probably no way to automatically extract the "correct puzzle" from a TIM..

we at best could make a check to see if we're making it right

For the single .obj is a good thing even if I actually solved the importing time whith a useful script I found that allow me "multi import" .obj files in few secs

P.S.

I was wondering about some GF stuffs.. for example if you look at that sort of "cemetery ground" (or whatever it is) that GF Cerberus came out from during its summoning animation..What's that? it looks like a sort of battle stage but it's animated (gate opens..)I didn't find clues of where that environment could be located till now.. same thing for Alexander mountain and other GF animation "accessory 3d models".. maybe they have their own file format

Same here. I'll run a software on FF8.EXE and see what will happen. UPDATE: No. There's no .X files in EXE, nor 01 00 01 00 objects compatible with .X format.

That worth the try anyway

I think that probably there is some file format for "animation models" that could be similar to .dat combat model (like GF ones but probably not the same) that is used for stuffs like that like Shiva's "ice shards" or Ifrit's "magma ball" and so on..There is a chance that same format is used for normal magic animation which actually spawn a 3d model (blizzard, blizzara, blizzaga..etc).

I may be completely wrong but why don't you give a shot to mag999_a.dat file. Its size and name could mean that it includes something special, maybe all the ground models for GF animations?

I've already check it but i don't know how read/extract the data/models from over there.If you hex edit that file, you can see this header in every "data blocks".

"XX XX XX XX 00 00 00 00 00 11 00 00 00 00 10 00 00 90 06"Always the same but not the first 4, maybe are some kind of pointers i don't know.Anyway the header it's always the same dimension 06 90 (is this the header.....i think xD)

We've tried some old Py scripts from this thread http://forums.qhimm.com/index.php?topic=15056.0 but are not the same "Kind" of model...so are totally useless...If you can give a check...maybe MakiPL, you can understand something for make a new script/tool for make readable these "Blocks".

Edit:IMPORTANT MakiPLIf you check this file "mag087_b.1r1" the structure is very similar to a battlestage...so let me know if there is something like the "the end" stage. If yes i'll give you other file with this type of "models".

Edit:IMPORTANT MakiPLIf you check this file "mag087_b.1r1" the structure is very similar to a battlestage...so let me know if there is something like the "the end" stage. If yes i'll give you other file with this type of "models".

Indeed. Typical Quad info starts at 0x88c. However visualisation of this produces bad mesh.There's texture in 1t0 and 1t1. The file is divided on parts. At the moment I can tell:

.1p0 file is UNKNOWN (p stands for... particle?).1r0 is start file, that the first unsigned int is size of the first pattern. Visualizing of vertices from this part produced this cloud: . Moreover 2240 MODULO 6 != 0, so it's not Short type X Y Z vertices. After this another pattern appears. Finally, a 8670 byte of this strange pattern. 8670 is dividable by 1,2,3,5,6,10,15,17,30 and 34. Never seen anything sized like that. .1r1 is the same as above, but the pattern is almost the same like the stage. Starting from 0x8bc till the least 2c EOF byte, there's 5712 bytes, and this number is dividable by 24. Max face index is 545, this means I need at least 545*6 = 3270 Bytes of data for vertices. I found, that there's a pattern for either 4 or 8 bytes. 4 bytes of data, and four next bytes are 00 00 00 00. .1s0 looks like the camera (has the same header as stage - but it's only a speculation).1t0 and .1t1 - divide parts of this texture:

Hm... I have an idea. Please, could you find a mag file that's responsible for some magic/GF that has objects in it? I could then real-time memory edit this to find out what will happen. OR, someone tell me if he/she recognise a spell/magic/anything that this texture may apply.