Never knew such a thing existed :) Thanks for heads up, will check it out.

My pleasure. Let me know if you need any help with it. If you want I can also tell you my favourite settings. Depending on model complexity and final pixel resolution a good bake might take 20 to 40 minutes, but if you have a more modern computer it might take even lesser :salute:

So, finally, where does the glitch I'm experiencing come from ? Only a difference in the order of vertices between main and AO objects ?

I don't have Blender installed, and don't know how to use it.

:up:

Yes, at this point we can conclude that this is the main, and probably the one problem :yep:

I think no one knew how to use Blender before installing it and starting to mess with it :O:

At the beginning the learning curve can be step, but on the internet there are a lot of guides and video-tutorials covering even the most advanced of its functionalities. I myself am still learning them. I think I will stick to Wings3D as my main modelling tool because I feel more proficient with it, but there are a lot of cool things you simply can't do in Wings and you can do in Blender. Why giving them up? :03:

Yes. And there is a VERY easy way to see this in Wings3D, Blender, 3DS Max, or any other 3D program.

Copy the Faces section in the AO obj file.
(Obj files are just text files!)

Paste that over the faces section of the main obj file then open it!

If it looks like garbage? It is Garbage!

For GR2 strict import? We need to sort the faces and texture coords.
For SH3/4? The faces and textures are stored in a different TMAP section!

So, in short, it's impossible to realise (unless checking everything with your trick) that AO objects are incorrect before seeing it in game... because S3D only checks if there are the same number of vertices between main and AO obj...

I was sure you were about to say something like that... :DL

Correct!
But you can just look at the first few lines of verts in each file and see that you have a problem.

Hahahah, I am predictable and you know me well. My point still stands though :03: :salute:

I had to do some research but I'll explain how a 3D model is stored in a dat file.
I'd figured this out long ago but just some details I had forgotten.

I have a Template for 010 that I'd forgotten about so I used it to refresh my memory. I guess I'm getting old!
:o
Anyway! Here's how a dat stores the information and how I figured it out.

All verts are stored in a chunk of information easy to follow with my Template.
As are Faces and texture coords. And here's where it gets tricky!
Any extra texture coords, for say the AO mapping, get stored right along with the Main objects coords in one chunk of data.

That's where the TMAP sections come in! They point to the Verts and the texture coords in the main chunk of data! So they are nothing more then faces calling the proper lines from the main chunk of data.

S3D just puts out a proper obj file on export then on import?
Just stacks everything in it's proper place.

How I do it is to export a 3D model as a rawchunk with S3D then run my Template. It takes a few minutes to look at things and see that texture coords are GREATER then the same obj files exported by S3D.

Should anyone want to see the Template and the files I worked with let me know.

SH5 does it a bit differently.

Now! back to the dat information!

There's one more small bit of information to know on reading the textures in hex!

Say I have this in the obj file.....
vt 2.548912764 0.04277324677

But my Template shows this!
float U_coord 2.548913
float V_coord 0.9572268

Don't make sense? yes it does! Subtract the float V_coord from 1!

I'll have to edit my Template to get the proper read out.
:/\\!!

I also have to Credit my Friend Anvart (Alex) for most of the Template.

Like I said before. I'd forgotten more then most even know.
Going over the information in a dat file I remembered even more!
I'm working on fixing the Template to show EXACTLY what you'd see when exported with S3D.

One area is the faces and how they are stored in a dat file.
One needs to read the first part then read the second.

It's kind of crazy but here's what you see.
We read 3 Verts THEN read the 3 Textures!
So if a Face is 3/1 2/3 5/4?
You will read 3 2 5 in Hex THEN 1 3 4!

Now I know most don't give a crap about that kind of stuff. But I do for a reason!
I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game!
There is NOTHING that does that!

that would be awesome:salute:

Amazing, thank you Jeff-Groves :salute::up::yeah:

That would be nice :up:

Indeed, one can arrange model parts in their desired position by manually adding/subtracting node translation/rotation values, but performing this task on model of a certain complexity is a PITA because nested objects inherit position/rotation from their parent objects :doh: