Exactly Halfer, vertex is 6 bytes. I pointed it out on XeNTaX forum, but forgot to do it here.
Thanks to you, we know it's standard X Y Z.
Sometimes the stages has some weird parameters. For a0st105 it's plain square, but, and that's interesting:
-Even if set the vertex to be higher than 00, it does is covered by the forest model, and player/enemy. It's hard to describe, but let's say we just CAN'T make the ground get higher, so example Squall would have to run thru ground to attack the enemy. Why? Because of the rendering options. The other example of rendering is the example of ground highering you made a test on. The ground mesh is combined with some high points in the background, so the rendering option is set to be normal 3D model, not some "weird one".
A few problems are still appearing:
1. Is X Y Z of vertex reverse-bytes? example 00 05 is higher than 05 00?
2. Still finding the UV and face indices. shakotay2 on XeNTaX made a face test with the data he found, and also rejected my idea. However, the test failed, here's his screenshot:
3. Where are the length bytes? Really. For a0stg105 probably, there're 152 vertices, so 152*6 bytes, still can't find that number, yet. How does the game know for how long it needs to read next bytes.
So, the vertices data is after header 01 00 00 08, and for a0stg105 is as I remember ~152. So After:
01 00 00 00 08 00 00 00 01 00 01 00, after this 152*6 bytes is whole ground vertices data.
If you find the data portion, where the texture is going crazy, and it's before .TIM, then you'll find UV, that could be useful also.
Also, a0stg160 looks great for reversing. It's a cube with UV layout + sky. So only two objects, low res texture, less data portion. I'll take a look there by HEX reversing, see if I could find the UV map, and see if I can find the entry point where vertices does start, and when it does end, to see if there's something characteristic. If so, then possibility of writing a software to rip this stages raise drastically.
Also, I cut from the file all three objects, from 01 00 00 00 08... to another this pattern, so I could test only one mesh, and less data I had to look at.
I'll take a closer look at a0stg101, and try using this HEX2OBJ software, to get the vertices of this ground, and see if it fits. I'm at school ATM, so I don't have that exact file, I'll do it at home.
We're making a nice progress here.
maybe we can alter camera
Camera starts from 0x5da (a0stg105.x with header like 02 00 08 00 20 00...). Camera is dynamic, has pre-keyed prologue animation, miss animation, and camera locations for various enemies. It's hard to reverse camera data, if I have to work on random events. Oh...