[WIP] Almagest. Strict Import for SH5.

[Mister_M]

Originally Posted by Jeff-Groves

Well. In the dat file format you CAN HAVE different counts on that information!
But the VERTS MUST BE EXACTLY THE SAME!

I'd suspect Wings re-ordered the Verts placement in the exported obj file thus faces and textures are screwed.

And You are the one that used Wings. It didn't to it by itself!
LOL!

I don't create garbage by myself...

[Jeff-Groves]

Just playing with you Mate.


It is strange to many that somethings do not work as expected with programs like S3D or TDW's program for SH5.

Both missed things and based their codes on false assumptions.
Sometimes that was a Ego thing on their parts to NOT listen to suggestions.
Sometimes it was a lack of understanding EXACTLY how the import target is constructed!

S3D used ALOT of information from the Grey Wolves in it's construction.
TDW's program aslo credits a Grey Wolf as soon as you open it!
(Guess WHO privateer is!)

[Mister_M]

Originally Posted by Jeff-Groves

Just playing with you Mate.

Originally Posted by Jeff-Groves

Guess WHO privateer is!

YOU

 

Sorry...

[Jeff-Groves]

I may be the LAST Wizard left here at SubSim.


I look at the files in a way that others do not.
With nothing but 010 Hex editor? I opened and changed the Bunker so one can walk all around!

I'm probably the ONLY one left active that can change things and create a better future for other Modders.
I am in debt to the ones that taught me.

[gap]

Originally Posted by Jeff-Groves

Well that was easy.
I compared the main obj and the AO obj in 010.
Your vertices do not match between the Main Hull and AO Hull.

If you are talking about my puffer model vertices in the main model do match vertices in the AO model, confirmed by WimMerge comparison and by the fact that my spreadsheet (which supposes an exact match in vertex order) generates a correct output

I think you meant texture vertices. Didn't you?

Originally Posted by Jeff-Groves

IF number counts are the same for the vertices? It ignores what those are in the AO object and only imports the faces and texture coords!

So basically S3D IS importing garbage you created.
That is the flaw AND the opening in S3D that I am working to fix!

in an obj file 3D faces are denoted by the vertices composing them. So in a triangulated model you need three numbers to denote a face, e.g. 3 31 15 (this is: vertices # 3, 31 and 15 in the list of vertices are connected to compose a face).

This is for non-UV-mapped objects. For UV-mapped objects you must add three more numbers. Following the previous example: 3/10 31/7 15/25.
This line tells us that vertices #3, #31 and #15 in the vertex list are connected to compose a face in the 3D space, and that vertices #10, #7 and #25 in the texture vertex list compose a face in the UV space, where vt #10 corresponds to v #3, vt #7 to v #31 and vt #25 to v #15.

The errors I and Mister_M have been experiencing lead me to think - but this is only my guessing - that face definitions are written in dat/gr2 files only once, that secondary texture coordinates are stored in the same order as main UV coordinates, and that neither S3d nor GR2E read all the information stored in secondary obj file's face definitions in order to sort texture coordinates appropriately.

[gap]

Originally Posted by Mister_M

Hull1.obj :
2018 f
868 vt

Hull1-uv2.obj :
2018 f
2729 vt

It already seems problematic...

Oh my

I was expecting some unbalance in vt count between the two files, but such a huge unbalance was really unexpected.

Did you mess with secondary UV map? I mean: cutting edges which were originally joined or vice-versa?

And since you are at it, can you check that vertices (v lines) are sorted in the same order in the UV2 obj file as in the main obj file? That's a quick comparison in WinMerge

[kapuhy]

Originally Posted by gap

Oh my

I was expecting some unbalance in vt count between the two files, but such a huge unbalance was really unexpected.

If its my tramp steamer MisterM was writing about, 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.

[Mister_M]

Originally Posted by gap

Oh my

I was expecting some unbalance in vt count between the two files, but such a huge unbalance was really unexpected.

Originally Posted by gap

Did you mess with secondary UV map? I mean: cutting edges which were originally joined or vice-versa?

No

Originally Posted by gap

And since you are at it, can you check that vertices (v lines) are sorted in the same order in the UV2 obj file as in the main obj file? That's a quick comparison in WinMerge

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

Originally Posted by kapuhy

If its my tramp steamer MisterM was writing about

Yes

[Jeff-Groves]

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


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.

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!

Send me the ORIGINAL files.

[Mister_M]

Originally Posted by Jeff-Groves

Send me the ORIGINAL files.

Well, Kapuhy sent me the obj files of his nice tramp steamer. If Kapuhy doesn't mind, I can send you his D/L link.

If not imported/exported via Wings3D, it seems that there isn't any glitch with AO-map in game.

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