[FF8] .x battle fields

[kaspar01]

I did some test too and I had same problem "invalid vertex index" when importing (had to open obj whith noesis and re-export again to fix that).

I'm using 3ds max 2014 anyway.

Known bugs:
-Bad UV calculation for triangles

Yeah.. probably there is something flipped somehow.. don't know if my screen can help to understand what's wrong but here's it 

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  )

BTW> 700 lines of code... (not counting designer code) Phew, I'm tired.

Have some rest .. you really deserved it 




P.S.

This is amazing.. thanks Maki.. you made my day..really 




Update:

There is something weird whith stage 30 and 31..


it looks like there is one or more missing piece..I'm sure there must be some "border" filling the gap between the flat combat ground and lava.

[Maki]

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.

EDIT: Or wait a sec. I'll add that one model option

UPDATE: Nope. It didn't work. ;/

[kaspar01]

Thanks for explanation!

Indeed that 3ds max error is not a big deal (it can be solved using noesis in 2 secs)

I'm more worried about "missing pieces".

The "magical button" news sounds great!!! 


P.S.

I don't know if anyone already made a check but.. any chance that some stage are "hidden" in ff8.exe file? (so many stuff hidden there.. it would not surprise me  )

[Maki]

The "magical button" news sounds great!!! 

Ye. But I failed. Need more time.

Made a topic in TOOLS:
http://forums.qhimm.com/index.php?topic=16017.msg225783#msg225783

[kaspar01]

Ye. But I failed. Need more time.

Not a problem! that button would just make the process faster (I'd like it but I can live 1 or 2 day whithout it I guess )

The new version already speed up the process and that's already nice..I'm gonna test it in the next hours!


Update: I tested the new version and I don't know what you changed but I don't get anymore the error on 3ds max!

[Softtm17]

EDIT:
Sorry i didn't see the others post (Kaspar's problem, it's the same) XD so it's almost useless this post I have to try your update.

Anyway here my info:

- Net framework 4.5.1
- 3dsmax Ver. 2015 x64
- Stage a0stg100.x (Edea's room)
- Search model (strict) 9216 for example    (Vertices offset 0x2406 - Triangles // - Quads 0x248C)
And when i try to import it from the menù (and not with a drag and drop) , i got that error.
Meanwhile with a classic and fast drag and drop, nothing happens & nothing import.

Here the main file and the obj (9216) extracted (without any mtl, doesn't matter in this moment)
Link -> www.mediafire.com/download/l4t6rrm8ab7av9w/Model.rar

Oh and sometimes when i try to extract some quads model (in the same file you can try the 9720)  i got an error from the program, here the log:


<sup>Le informazioni su come richiamare il debug JIT (Just-In-Time) anziché questa finestra
sono riportate in fondo al messaggio.

************** Testo dell'eccezione **************
System.FormatException: Formato della stringa di input non corretto.
   in System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   in System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   in System.Byte.Parse(String s, NumberStyles style, NumberFormatInfo info)
   in FF8_StageModel_ToObj.Form1.button5_Click(Object sender, EventArgs e)
   in System.Windows.Forms.Control.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   in System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   in System.Windows.Forms.Control.WndProc(Message& m)
   in System.Windows.Forms.ButtonBase.WndProc(Message& m)
   in System.Windows.Forms.Button.WndProc(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Assembly caricati **************
mscorlib
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18444 built by: FX451RTMGDR
    Base di codice: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
Final Fantasy VIII Battle stage model to OBJ
    Versione assembly: 0.8.0.0
    Versione Win32: 0.8.0.0
    Base di codice: file:///C:/Users/Administrator/Desktop/FF8%20.X%20to%20OBJ.exe
----------------------------------------
System.Windows.Forms
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.34238 built by: FX452RTMGDR
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
mscorlib.resources
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_it_b77a5c561934e089/mscorlib.resources.dll
----------------------------------------
System.Windows.Forms.resources
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_it_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------

************** Debug JIT **************
Per abilitare il debug JIT, è necessario impostare il valore
jitDebugging nella sezione system.windows.forms del file di configurazione
dell'applicazione o del computer (machine.config).
L'applicazione inoltre deve essere compilata con il debug
abilitato.

Ad esempio:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Quando il debug JIT è abilitato, tutte le eccezioni non gestite
vengono inviate al debugger JIT registrato nel computer,
anziché essere gestite da questa finestra di dialogo.</sup>

Sorry for some parts on the log in italian languages (I'm italian )

[Maki]

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]

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..

[Maki]

Converter has been updated to 1.1. Fixed the triangles, added magic button.
http://forums.qhimm.com/index.php?topic=16017.new#new

Thanks kaspar01 for providing screens before and after fixing UV.

[Zervox]

a0stg001.x  Whinhill Village? 

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

[kaspar01]

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 )

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

[Mcindus]

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 )

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.

[Maki]

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 09
Changing image data after header, CLUT and core info should work.

[kaspar01]

Use TIM Viewer.
TIM texture is the last segment in .x file and is starting with header 01 00 00 00 09
Changing 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

[Maki]

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) :C
Even 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.

Candy for you:

[kaspar01]

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 

[Maki]

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 

Oh, could you upload this? I'd use that too.

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.

[kaspar01]

Oh, could you upload this? I'd use that too.

Can't find that script right now since I'm not at home but you could try this (should work as well or even better ) :

http://www.scriptspot.com/3ds-max/scripts/batch-exportimport

When I'll get back home I'll post the one I'm using

Edit:

Here's the one I'm currently using:

http://www.scriptspot.com/3ds-max/scripts/batch-merge

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).

[Halfer]

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?

[kaspar01]

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?

That could be an interesting point!

edit:

looks like battle/mag87 files contain environment textures for selphie's limit "the end".

[Softtm17]

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 MakiPL
If 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".

[Maki]

Edit:
IMPORTANT MakiPL
If 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.


@Mag999_a.dat contains only AKAO sequences (this is: sounds info).
Mag184 is Shiva.

EDIT3: In .EXE, at 0x9b7db8 is ASCII hard-coded "mag150.TIM". I though about ASCII rip using Jaeder Naub , see what I get.

[dheen]

Yes Odin GF invocation.

Hum no. Let me search definitely remind me something

Hum seems like bahamut. The only zone with moon on it ....

[Yagami Light]

That moon is from Rinoas limit break called Invincible moon

[Maki]

That moon is from Rinoas limit break called Invincible moon

Yep. Thanks. https://youtu.be/5zfvk6SfLZQ?t=1m48s

So, it's just a plane with a moving clouds. That's probably it. Need to find better model. (other magic file)