:rotfl2:

Sorry for the misunderstanding guys, I wasn't aware that Mister_M had already sent his own version of kapuhy's steamer to Jeff :oops:

Okay, that explains the huge difference in vt coordinate count between the two files. It also proves that I was wrong in thinking that GR2 editor does not read UV face information from the AO object file. If it didn't, the unbalance/different order of vt lines between the two files would have meant a bad secondary UV map, but this is obviously not the case :up:

I am sorry to say that this is a huge problem. One of the prerequisites of my spreadsheet is vertices in the main and in the UV2/AO objects to be in the same order. I could identify and sort vertices according to their coordinates. This method would work for simple objects, but I could not easily discern vertices with the same coordinates, a rather common occurrence with edge-split models. In theory I could discern overlapping vertices by checking which faces they are part of, but that would be an overly complicated method; before I come up with a semi-decent routine, you could redo ten times your changes on kapuhy's model :yep:

My suggestion is to switch to Blender for final model editing. This program supports object multi-mapping, i.e. the assignation of multiple UV maps on the same object. You can even import an UV map from one object to another identical object, so whatever changes you do to the model, you are sure that the two exported obj files will be identical in vertex/face structure.
Else, if you want to stick to Wings3D, be more careful. You want to ungroup the main model? Immediately after, ungroup the AO model too. You want to regroup a group of sub models? Make sure that you regroup exactly the same objects for both models. Your actions on each model should be specular and you should perform them exactly in the same order for having a chance of success. :yep:


It all makes sense :up:

I have checked the original Hull1.obj and Hull1_AO.obj of Kapuhy's model.

- in main model = vt = 2102
- in AO model : vt = 13772

- v lines are identical and in the exact same order

No glitch in game.

Good news! That means that texture coordinates' count/ordering is not critical for UV2 import neither in granny models nor in .dat ones :up:

Wow. I might look for another way to make AO texture bake in future :)

Through in SH5 Goblin editor, it shows Armora having 69k verts and 28 k tris total while (comparable in size) stock N3SA1 is 27k verts and 11 k tris, so i'd say proportion is similar.

EDIT: btw, Mister_M, if you'd like to make some changes to model in Blender I can send you .blend files so there's less importing/exporting.

Why don't you bake your AO textures in Mod Tools (i.e. the free version of Autodesk Softimage)?
I started using that program after Jeff's advise. Its texture baking utility features a lot of useful options for customizing the output. They can be a bit confusing at the beginning, but imo they are worth the effort of learning them.
On medium settings, my bakes never missed a single texel even on very minute parts, but I must add that I always unwrap my models manually.

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: