[WIP] Almagest. Strict Import for SH5.

[gap]

Originally Posted by Jeff-Groves

I guess I'm gonna need some crayons to explain things.

Originally Posted by kapuhy

If its my tramp steamer MisterM was writing about

Originally Posted by Jeff-Groves

We ARE talking about dat file import of the files Mister_M sent me.
I have not seen the ORIGINAL FILES! Just what I got today.

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

Originally Posted by kapuhy

this might also be my "fault" for using "lightmap pack" function for smaller faces to avoid problem I had where small and long faces like ropes and railings were omitted in AO baking. Lightmap pack uv-maps faces as separate rectangles in 2d space so there would be many more edge cuts in ao uvmap than in diffuse uv map.

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

Originally Posted by Mister_M

I guess I have to copy/paste all the lines into 2 .txt files ?
EDIT : So, order is different, a long block (nearly the first 1/3) has been put at the end...

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

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.

Originally Posted by Jeff-Groves

In a DAT file? number of texture coords and faces does NOT matter!
Unlike SH5 where it DOES matter! (Thus the addition of false info to balance a strict import)

In Dat files, like GR2 files, ALL verts in ALL files MUST MATCH!

The files I have show that the COUNT of verts is fine but the placement does not match between the main and AO obj files.
Thus the Faces are off! Hell! For S3D and TDW's Tool? You could zero every Vert in the AO and as long as counts match? It will import!
Because they DO NOT read and save the verts in the AO obj!

It all makes sense

[Mister_M]

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.

[gap]

Originally Posted by Mister_M

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

[kapuhy]

Originally Posted by Mister_M

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

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.

[gap]

Originally Posted by kapuhy

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

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.

[kapuhy]

Originally Posted by gap

Why don't you bake your AO textures in Mod Tools (i.e. the free version of Autodesk Softimage)?

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

[gap]

Originally Posted by kapuhy

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

[Mister_M]

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

Originally Posted by kapuhy

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.

Originally Posted by gap

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.

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

Originally Posted by gap

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.

[gap]

Originally Posted by Mister_M

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

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

Originally Posted by Mister_M

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

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

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?

[Jeff-Groves]

Originally Posted by Mister_M

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

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!

[Mister_M]

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

Originally Posted by gap

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

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

[Jeff-Groves]

Originally Posted by Mister_M

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

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

[gap]

Originally Posted by Mister_M

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

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