Technically based stuff
 

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:

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

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/...DX1/s-l225.jpg

:o
:/\\!!
:haha:

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:

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?

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:

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.

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

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

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?

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

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.

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?

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