Technically based stuff

[Jeff-Groves]

gap and I have exchanged ideas and thoughts for years now.
As have many others. Instead of going off topic in many threads as We have been? I figure a new thread is needed to keep things in a sorted way.
I don't mean how you complete a Mission or stuff like that!

[Aktungbby]

Gap and I have exchanged ideas and thoughts for years now, as have many others. Instead of going off topic in many threads as we have been, I figure a new thread is needed to keep things in a sorted way.
I don't mean how you complete a Mission or stuff like that! ^FIXED! TO INCLUDE WHOLE SENTENCES! :O: NATURALLY, I PREFER A THREAD WITH ''THINGS IN A SORDID WAY''... BUT WE'VE WOLFERZ'S "THE BILGE" FOR THAT ALREADY!
:Kaleun_Cheers:

[Jeff-Groves]

Gap is NOT his user name. It's gap.
Get it? Got it? Good!
:smug:

[Jeff-Groves]

One thing gap (NOT Gap) and I have talked about is TDW's Editor.
I'd like anyone using it to discuss issues in this thread.
Details such as which version and so on. There is no real easy to find information on which version you should use to do different things.
I'd like to see if we can compile that data.

[Aktungbby]

Gap is NOT his user name. It's gap.
Get it? Got it? Good!
:smug: GOOD gOD YOU'RE RIGHT! I'LL INFORM THE SWEATSHIRT MANUFACTURER IMMEDIATELY!:timeout: https://i.ebayimg.com/thumbs/images/g/~T0AAOSwzcNcCDX1/s-l225.jpg

[Jeff-Groves]

:o
:/\\!!
:haha:

[propbeanie]

Already he is working on his "Funniest Post of 2019" award... :har: :O:

[Jeff-Groves]

Well he is being technical with his stuff.
Not sure how that goes over with Mrs. Aktungbby and I ain't gonna ask!
:doh:

[gap]

Say we have 50 verts with their 50 normals.
But it has only 30 vts. (texture coords)
Faces don't matter as those are stored in a separate area.

GR2 stores with vt, vn, and vt in a structure.
So we run out of vt's!
TDW did some crazy stuff which does account for that but increases file size in a wild way.

So all you need to do is add to the vt count to have a balanced file.
They can be zero coords or re-use already used coords. It don't matter!
Now Exported meshes from a GR2 HAVE this extra info!
Once imported into say 3D Max? Max DUMPS the redundant stuff!
So an export with NO modifications to the file WILL NOT have the extra info.

That forces you to use TDW's strange import function and the result is a file MUCH larger then it needs to be.
I believe there's a 'clean' import or something? That sees the file as proper for import and no extra processing is needed.
Thus smaller file sizes.

Somewhere in the Exporter thread or else where I PROVED this and gave the answer!
I'll see if I still have objsort code and add to it to adjust for this.

Okay that starts making sense to me but...

If a closed mesh gets unwrapped, I would expect some its edges to be split and its vertex number to be bigger than before. In other words, vt should be always more or equal in number than v and vn, not the contrary. Does that make sense?

Are you sure that that's the only problem we have?
I assume that for the two obj files composing a main-model / AO-model pair to be imported correctly, their vertices and faces must be identical and in the exact same orde, right?
Now suppose that we want two or more objects that have already been unwrapped and textured for the diffuse texture (very common case with models we import from SHIII or with free models available on the web) to share the same AO map and to be baked together (as a ship hull, superstructure, funnels, masts, lifeboats, etc). The easiest way to accomplish that, would be by combining all the meshes into one big object, then one should auto-remap (or resize/re-sort) the UV map of the combined object so that the unwrapped faces will cover the whole UV space without overlapping with each other, bake the AO map and finally separate the combined object and recombine the resulting meshes so to recompose the original models that we had combined. Now what I wonder is, are we sure that after the combining-separation-recombining of the original models, all their faces and vertices are exactly in the same order as before?

^FIXED! TO INCLUDE WHOLE SENTENCES! :O: NATURALLY, I PREFER A THREAD WITH ''THINGS IN A SORDID WAY''... BUT WE'VE WOLFERZ'S "THE BILGE" FOR THAT ALREADY!
:Kaleun_Cheers:

One thing gap (NOT Gap) and I have talked about is TDW's Editor.
I'd like anyone using it to discuss issues in this thread.
Details such as which version and so on. There is no real easy to find information on which version you should use to do different things.
I'd like to see if we can compile that data.

GOOD gOD YOU'RE RIGHT! I'LL INFORM THE SWEATSHIRT MANUFACTURER IMMEDIATELY!:timeout: https://i.ebayimg.com/thumbs/images/g/~T0AAOSwzcNcCDX1/s-l225.jpg

Already he is working on his "Funniest Post of 2019" award... :har: :O:

Well he is being technical with his stuff.
Not sure how that goes over with Mrs. Aktungbby and I ain't gonna ask!
:doh:

LOL, I don't want to sound too technical, but I confirm, I am gap. That's actually the acronyme of my full name, but without dots and with all lower case letters. I like it more like this, but I take no offense if someone wants to capitalize it lol :03:

[Jeff-Groves]

VT can be lower.
I have an obj file open now with 28566 vertices but has 1520 texture coordinates.
To make it GR2 compatible we would need to add texture coords.
Those can be a repeat or just 0. That should allow TDW's program to import as a 'clean'. I think that's his term.

[Jeff-Groves]

You can combine meshes into one obj file. They are still separate meshes If done right.

Then Bake. You only need the UV's (VT) for each mesh. Faces should not change.
Don't know if Wings3D or other programs can export UV's only or if you can have more then one texture channel in them.

Now. UV's are a quick way to change texture coords (VT) in Max. I burn AO in a different program, save the UV's, then import to Max.

To do the same if your program does not export just the texture information? Export the burned obj and copy paste the VT's when needed.
And before anyone asks? I can decode 3D Max UV's to vt's.

Read up on how the obj file handles faces. It's really simple once you fully understand it.
3 verts make a face. The f tells you what v gets what vt
f v1/t1 v2/t2 ....

[gap]

VT can be lower.
I have an obj file open now with 28566 vertices but has 1520 texture coordinates.
To make it GR2 compatible we would need to add texture coords.
Those can be a repeat or just 0. That should allow TDW's program to import as a 'clean'. I think that's his term.

I wonder how this is technically possible in a manifold space. :hmmm:

Let's take a simple primitive like a cube. In the XYZ space it has indubitably eight vertices. Unwrapped as in the figure below, it will have fourteen UV vertices, you can count then:

https://i.imgur.com/D7WZifx.png

By stitching all the UV edges together, we can reduce vt number to eight (i.e. the number of XYZ vertices), but I don't see how we could make it smaller than the main vertex count.

https://i.imgur.com/28xT8iW.png

You can combine meshes into one obj file. They are still separate meshes If done right.

Then Bake. You only need the UV's (VT) for each mesh. Faces should not change.

Sure, but when we separate an object into the single contiguous meshes composing it, and/or when we combine several objects into a bigger objects, vertices get re-numbered/re-sorted as a consequence of the separation and/or combination. Are we sure that when we recombine/re-separare them, to re-build the original objects, their vertices will be again in the exact same order?


Don't know if Wings3D or other programs can export UV's only or if you can have more then one texture channel in them.

I know that Max supports multiple UV coordinates, I that's what you mean. Unfortunately that's an useful feature missing from Wings3d (dunno about Blender).

[Jeff-Groves]

You can fold that box to 4 to get a lower vt count.
faces will remain the same and just use the same vt in places.

[Jeff-Groves]

On putting multiple meshes in an obj? Don't weld the verts and they will remain a separate mesh! Burn your AO, then export ONLY that one mesh.
All things should be fine! Now in Max I have a script the will export all the meshes to separate obj files so it's simple. Maybe Wings has scripting abilities?

[gap]

Read up on how the obj file handles faces. It's really simple once you fully understand it.
3 verts make a face. The f tells you what v gets what vt
f v1/t1 v2/t2 ....

You are right, if v's order was messed up during the recombining of an object (needed for baking its AO map), I could always grab the v coordinates of the main obj file (the one with diffuse UV map stored) and paste them in the AO obj file. The problem comes with face definitions. Keeping on your example, let's say that these are the face definitions of the main obj file:

f v1/t1 v2/t2 v3/t3

and these are the face definitions of the AO obj file (with messed up vertex order)

f v1(ao)/t1(ao) v2(ao)/t2(ao) v3(ao)/t3(ao)

The faces of the fixed AO obj file should look like this:

f v1/t1(ao) v2/t2(ao) v3/t3(ao)

I could do that file merger in excel indeed, but unless I find a way to create an 'intelligent' generic spreadsheet that works with obj files of any length, setting up a 'specific' spreadsheet every time, is going to be a time-expensive exercise...

[gap]

You can fold that box to 4 to get a lower vt count.
faces will remain the same and just use the same vt in places.

I am sorry but I don't get it. Of course I could overlap all the UV vertices so that they look just one vertex, but to my understanding the different number of vertices in the UV map than in the 3D geometry is only determined by the un-welding of some faces (more unwelding = more edges and more vertices). The only way to reduce again this number is by welding again the un-welded faces, but we can't weld UV faces that are not welded in the 3D geometry. Can we? :doh:

On putting multiple meshes in an obj? Don't weld the verts and they will remain a separate mesh! Burn your AO, then export ONLY that one mesh.

Yes, indeed but that's not what I was talking about.

Let's say that I have one object composed by two meshes let's call them a and b. the vertex sequence in that object is

v a1
v a2
v a3
v a...
v b1
v b2
v b3
v b...

Now let's say that we want to bake our object together with another object. After the creation of a new UV map (for the AO channel) and the AO baking we separate the combined object into the single meshes composing it, and then we re-compose the original objects. As long as we didn't alter the geometry of any single mesh, vertex order within them should not have changed. But what if the order of the meshes within the re-combined object has changed as a consequence of its separation and re-combination? We would find ourselves with an object so composed

v b1
v b2
v b3
v b...
v a1
v a2
v a3
v a...

Apparently the original object and the re-combined object will only differ in their UV mapping, but to GR2 Editor would be two different objects...

I hope I made myself clearer this time...


All things should be fine! Now in Max I have a script the will export all the meshes to separate obj files so it's simple. Maybe Wings has scripting abilities?

I don't think so :hmmm:

[Jeff-Groves]

I think I know what you mean but I'm not positive.
Can you send me example obj files and which version of the GR2 editor you have a problem with?

[gap]

I think I know what you mean but I'm not positive.
Can you send me example obj files and which version of the GR2 editor you have a problem with?

For the moment I have not good examples that I can send to you. No doubt I will, in case I face problems the next times that I will need to import some objects with their secondary UV map into a GR2 file.

I am not saying that the problem I tried to describe below will necessarily happen, or that all the problems we faced in the past were coming from there, but we should at least agree on the fact that this is something that can happen, and if it happens it can scramble the UV-map import.

[Jeff-Groves]

we agree on the fact that this is something that can happen, and if it happens it can scramble the UV-map import.
I believe We saw this problem with the new wooden boats or the barrage balloon way back didn't we?
That issue may have been fixed with later releases of TDW's Exporter/Importer?
:hmmm:

[gap]

I believe We saw this problem with the new wooden boats or the barrage balloon way back didn't we?
That issue may have been fixed with later releases of TDW's Exporter/Importer?
:hmmm:

Hopefully yes. I remember having had some AO-import problems even using the last release, but I am not 100% sure and I can't say exactly on which model.

As I said, let's face problems as they come. I hope we will import many AO-mapped models in the next months, so we will have plenty of case studies :)