![]() |
SUBSIM: The Web's #1 resource for all submarine & naval simulations since 1997 |
|
![]() |
#1 |
CTD - it's not just a job
|
![]()
Already he is working on his "Funniest Post of 2019" award...
![]() ![]()
__________________
"...and bollocks to the naysayers" - Jimbuna |
![]() |
![]() |
![]() |
#2 |
GLOBAL MODDING TERRORIST
|
![]()
Well he is being technical with his stuff.
Not sure how that goes over with Mrs. Aktungbby and I ain't gonna ask! ![]() |
![]() |
![]() |
![]() |
#3 | ||||||
Navy Seal
![]() Join Date: Jan 2011
Location: CJ8937
Posts: 8,215
Downloads: 793
Uploads: 10
|
![]() Quote:
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? Quote:
Quote:
Quote:
Quote:
Quote:
![]() |
||||||
![]() |
![]() |
![]() |
#4 |
GLOBAL MODDING TERRORIST
|
![]()
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. |
![]() |
![]() |
![]() |
#5 |
GLOBAL MODDING TERRORIST
|
![]()
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 .... Last edited by Jeff-Groves; 02-04-19 at 06:30 PM. |
![]() |
![]() |
![]() |
#6 | ||
Navy Seal
![]() Join Date: Jan 2011
Location: CJ8937
Posts: 8,215
Downloads: 793
Uploads: 10
|
![]() Quote:
![]() 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: ![]() 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. ![]() Quote:
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). |
||
![]() |
![]() |
![]() |
#7 |
GLOBAL MODDING TERRORIST
|
![]()
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. |
![]() |
![]() |
![]() |
#8 | |
Navy Seal
![]() Join Date: Jan 2011
Location: CJ8937
Posts: 8,215
Downloads: 793
Uploads: 10
|
![]() Quote:
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... Last edited by gap; 02-05-19 at 06:13 AM. |
|
![]() |
![]() |
![]() |
#9 | |||
Navy Seal
![]() Join Date: Jan 2011
Location: CJ8937
Posts: 8,215
Downloads: 793
Uploads: 10
|
![]() Quote:
![]() Quote:
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... Quote:
![]() Last edited by gap; 02-04-19 at 07:24 PM. |
|||
![]() |
![]() |
![]() |
|
|