SUBSIM Radio Room Forums



SUBSIM: The Web's #1 resource for all submarine & naval simulations since 1997

Go Back   SUBSIM Radio Room Forums > Silent Hunter 3 - 4 - 5 > SH5 Mods Workshop
Forget password? Reset here

Reply
 
Thread Tools Display Modes
Old 01-18-22, 02:29 PM   #91
Mister_M
Grey Wolf
 
Join Date: Feb 2021
Posts: 778
Downloads: 26
Uploads: 0


Default

Quote:
Originally Posted by Jeff-Groves View Post
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...
Mister_M is offline   Reply With Quote
Old 01-18-22, 02:37 PM   #92
Jeff-Groves
Village Idiot
 
Jeff-Groves's Avatar
 
Join Date: Sep 2014
Posts: 5,299
Downloads: 130
Uploads: 0


Default

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!)
__________________
I don't do Stupid. So don't ask.
Jeff-Groves is offline   Reply With Quote
Old 01-18-22, 02:52 PM   #93
Mister_M
Grey Wolf
 
Join Date: Feb 2021
Posts: 778
Downloads: 26
Uploads: 0


Icon12

Quote:
Originally Posted by Jeff-Groves View Post
Just playing with you Mate.


Quote:
Originally Posted by Jeff-Groves View Post
Guess WHO privateer is!
YOU





 
Sorry...
Mister_M is offline   Reply With Quote
Old 01-18-22, 03:06 PM   #94
Jeff-Groves
Village Idiot
 
Jeff-Groves's Avatar
 
Join Date: Sep 2014
Posts: 5,299
Downloads: 130
Uploads: 0


Default

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.
__________________
I don't do Stupid. So don't ask.
Jeff-Groves is offline   Reply With Quote
Old 01-18-22, 03:30 PM   #95
gap
Navy Seal
 
Join Date: Jan 2011
Location: CJ8937
Posts: 8,214
Downloads: 793
Uploads: 10
Default

Quote:
Originally Posted by Jeff-Groves View Post
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?

Quote:
Originally Posted by Jeff-Groves View Post
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.
__________________
_____________________
|May the Force be with you!|
...\/
gap is offline   Reply With Quote
Old 01-18-22, 03:44 PM   #96
gap
Navy Seal
 
Join Date: Jan 2011
Location: CJ8937
Posts: 8,214
Downloads: 793
Uploads: 10
Default

Quote:
Originally Posted by Mister_M View Post
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
__________________
_____________________
|May the Force be with you!|
...\/
gap is offline   Reply With Quote
Old 01-18-22, 04:04 PM   #97
kapuhy
Grey Wolf
 
Join Date: Oct 2010
Location: Poland
Posts: 873
Downloads: 72
Uploads: 3
Default

Quote:
Originally Posted by gap View Post
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.
kapuhy is offline   Reply With Quote
Old 01-18-22, 04:10 PM   #98
Mister_M
Grey Wolf
 
Join Date: Feb 2021
Posts: 778
Downloads: 26
Uploads: 0


Default

Quote:
Originally Posted by gap View Post
Oh my

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


Quote:
Originally Posted by gap View Post
Did you mess with secondary UV map? I mean: cutting edges which were originally joined or vice-versa?
No

Quote:
Originally Posted by gap View Post
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...

Quote:
Originally Posted by kapuhy View Post
If its my tramp steamer MisterM was writing about
Yes

Last edited by Mister_M; 01-18-22 at 04:22 PM.
Mister_M is offline   Reply With Quote
Old 01-18-22, 05:22 PM   #99
Jeff-Groves
Village Idiot
 
Jeff-Groves's Avatar
 
Join Date: Sep 2014
Posts: 5,299
Downloads: 130
Uploads: 0


Default

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.
__________________
I don't do Stupid. So don't ask.

Last edited by Jeff-Groves; 01-18-22 at 05:42 PM.
Jeff-Groves is offline   Reply With Quote
Old 01-18-22, 05:46 PM   #100
Mister_M
Grey Wolf
 
Join Date: Feb 2021
Posts: 778
Downloads: 26
Uploads: 0


Default

Quote:
Originally Posted by Jeff-Groves View Post
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.
Mister_M is offline   Reply With Quote
Old 01-18-22, 07:00 PM   #101
gap
Navy Seal
 
Join Date: Jan 2011
Location: CJ8937
Posts: 8,214
Downloads: 793
Uploads: 10
Default

Quote:
Originally Posted by Jeff-Groves View Post
I guess I'm gonna need some crayons to explain things.


Quote:
Originally Posted by kapuhy View Post
If its my tramp steamer MisterM was writing about
Quote:
Originally Posted by Jeff-Groves View Post
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

Quote:
Originally Posted by kapuhy View Post
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

Quote:
Originally Posted by Mister_M View Post
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.


Quote:
Originally Posted by Jeff-Groves View Post
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
__________________
_____________________
|May the Force be with you!|
...\/

Last edited by gap; 01-18-22 at 07:27 PM.
gap is offline   Reply With Quote
Old 01-19-22, 05:13 AM   #102
Mister_M
Grey Wolf
 
Join Date: Feb 2021
Posts: 778
Downloads: 26
Uploads: 0


Default

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.
Mister_M is offline   Reply With Quote
Old 01-19-22, 05:38 AM   #103
gap
Navy Seal
 
Join Date: Jan 2011
Location: CJ8937
Posts: 8,214
Downloads: 793
Uploads: 10
Default

Quote:
Originally Posted by Mister_M View Post
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
__________________
_____________________
|May the Force be with you!|
...\/
gap is offline   Reply With Quote
Old 01-19-22, 05:40 AM   #104
kapuhy
Grey Wolf
 
Join Date: Oct 2010
Location: Poland
Posts: 873
Downloads: 72
Uploads: 3
Default

Quote:
Originally Posted by Mister_M View Post
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.
kapuhy is offline   Reply With Quote
Old 01-19-22, 06:29 AM   #105
gap
Navy Seal
 
Join Date: Jan 2011
Location: CJ8937
Posts: 8,214
Downloads: 793
Uploads: 10
Default

Quote:
Originally Posted by kapuhy View Post
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.
__________________
_____________________
|May the Force be with you!|
...\/
gap is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 02:02 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 1995- 2024 Subsim®
"Subsim" is a registered trademark, all rights reserved.