Hey Phantom,

Related to the TDMT scripts, I think the split-seams that he's speaking of are the UV-seams, not splits in the geometry/vertices.  Take a head mapping, for example... with a cylindrical style UV-mapping, there's a UV-seam on the back of the skull and the head mapping is flattened out, with the face in the center and an ear and half the skin behind there (up to the rear-center of the skull) on each side.

The entire head/face makes up an 'island' of UVs, with a seam on every edge (split down the back, split at the neck, one or more splits along the top of the head, potentially splits at the ears/lips/eyesockets, etc.).

The 'problem' that the code has currently, is determining 'which' island (and in the case of things like the head example, which 'side' of that island) each UV-polygon / vertex belongs to.

The code basically keeps track of mapping info the determines how one mesh (it's vertices) maps / correlates to another (the vertices of one mesh map to one or (more likely) several vertices of the other mesh, along with a weight value for each of those vertices).  This mapping was originally for use in transfering shapes/morphs between disimilar meshes... the same info can also be used to transfer the UVs from one mesh to another, but in it's current form is hit-or-miss at any UV-seams.

Each vertex can have many corresponding UV values, depending on where the seams are, so it's a 50/50 chance of getting it right if there are only 2 answers, but there are cases where it's a 1-in-4 shot as well (where a vertex happens to be at both a vertical and horizontal split, like maybe the back of the skull seam, where it also meets the neck split).

Ok, I went ahead and installed Vue 6 PLE so I could test this and as far as I can tell, it IS a bug in Vue - sorry. I will do some more testing tomorrow (erm... later today), but so far, I haven't found any rhyme or reason to how Vue is computing the center ("Position") of an imported mesh - it's just nonsensical.

Just to clarify a few points for future reference:

• There is no axis/pivot information in a .obj file - so the fact that Vue is putting it somewhere other than 0/0 is entirely based on some internal calculation of it's own doing - you would think that it would put it at the 'center' of the vertices that make up the mesh, but apparently that's not the case.
• Vertex-order has nothing to do with it (or at least "preserving" vertex order - preserving it assumes that you had some correct/working order to start with, but doesn't have any meaning for a newly created mesh.  And, just for the record, Riptide always 'preserves' the vertex order anyway :) ).

...I know that you've said that models from other apps are importing correctly, but the ('correct') example you sent me is also 'off' (not at 0/0).  It's almost like the program is using integer (or possibly low-precision fixed-point) math and converting that back to floats instead of floating-point in some cases (ie. it's "almost" correct), but in other cases, it's offset by many meters.

[If anyone has a sample .obj file from Hexagon or some other app that Imports correctly, I'd love to get a look at it]

My advice at this point would be to do what Shawn is doing - If you need to do some precise positioning of objects (that can't be accomplished by dragging the objects around in Vue), you should just set them up in C4D and then export them all together (already positioned how you want them).

Yeah, after thinking about this more, I thought that maybe it was computing the center as the "average" of all the vertices instead of the average of 8 vertices that make up a bounding box around the mesh (which would tend to skew the center to a side with more vertices), but it doesn't appear to be doing that either.

Shawn, are you looking at the "Pivot" or "Position" values?

Ok, I finally (mostly) figured out what Vue is doing (which I consider 'wrong')...

• When Importing, Vue generates a Vertex-per-UVvert... so a cube would normally have 8 vertices, but since there are 6 faces, with (potentially) 4 separate UV values for each face, you end up with 24 vertices.  If this wasn't bad enough, somehow Vue comes up with 28 vertices for a simple cube (some not used for polygons).
• After the above vertex-expansion, it then does in fact do a averaging of ALL the vertices to find the center of the mesh - when it should be calculating an average of the 8 vertices that make up a bounding box of the mesh.

...I added code to one of my plugins to confirm the above and came up with the exact values that Vue comes up with (at least in some cases).  I did not check all cases (when no UVs exist, for example) and apparently the 28-vert cube example above may only use 24 of those (or something) to compute the center with, but a uv-mapped 3000+ vertex model I ran through testing came up with the exact same values Vue did.

Short story - this "bug" has nothing to do with how any app or plugin exports .obj files - it's a bug/feature of how Vue is determining the center of an imported mesh.

BTW, you know that those magnets are essentially acting the same way JCMs do.. right?  In other words, they are being adjusted, as the joints rotate.  So the strength / distance / pull / effect of those magnets is not 'constant'.

Quote - Wings3D likes to load the groups as separate objects, as well, but one can prevent that by explicitly defining an object at the start of the .obj file, that is, by just adding a line that says something like 'o body'. I don't know if the same trick would work in Hexagon, but it might be worth a try.

Just to expand on this a bit... "o xxxxx" is an "object" record in a .obj file and is separate from a "g xxxxxx" - "group" record.

Group records tell the program groups/selections/sets of related polygons, whereas Object records are typically used to deliniate both sets of points/vertices as well as polygons.

Based on the fact that both exist, it makes sense to me that any "object" within a .obj file can have multiple "groups" defined as part of that object (and in fact, they are laid out that way, hierarchically within the file).  Unfortunately, many 3D apps make no distinction between Objects and Groups - they will just split either/both into multiple separate meshes.

With the above in mind, it sounds like what odf is saying is that if there IS an Object record in the .obj file, Wings (at least) starts making that distinction and leaves all the Groups in the same Object.  I have no idea if Hexagon does this though.

As for Cinema 4D, the default (built-in) .obj file - in addition to re-ordering the vertices - Import will split any Groups or Objects into separate meshes.  The default Export loses all Group information entirely.  Because of these (and many other) issues, I wrote my Riptide (and later Riptide Pro) plugins for Cinema 4D. 

That sounds like a good plan for those not-so-Poser-friendly apps, odf.  My personal experiance is mostly with Cinema 4D + my Riptide Pro plugin... in which case, all vertex-ordering and grouping and material zone assignment is maintained, so (just for C4D users,)you simply Export from Poser, Import into C4D, make your adjustments and re-Export.  In fact, my plugin even preserves UVMapper's "Region" selections (just another means of categorizing polygon selections.. I typically use them to specify uv-mapped islands (sets of polygons that wil be using the same texture file)).

Hi mathman,

The files are created using the TDMT "Compare" script(s). And then there's a separate "Transfer" script to transfer morphs and shapes between figures, based on those .vmf files.  This particular thread is related to a script that helps you clean-up shape transfers, either after the fact, or as an interim step in fine-tuning the shapes for the "Compare" script.

The best place to look is at the "TDMT_Morph_Transfer" link in Cage's signature (just look for his post(s) above)  - he drove the development of the process and has all the various scripts (and many others) linked there, along with links to various threads about the process.

Cheers,

Keith

Timberwolf,

I have written a plugin for Cinema 4D specifically for use / assistance in making JCMs. The plugin is called MorphMill and has an 'Undeform' tool, along with some other goodies.  It basically lets you pose a figure, freeze the mesh, edit the frozen/deformed mesh, then the plugin can remove the rotation/deformation, giving you the mesh you need to apply as a 'morph' to the original, undeformed mesh.

It's kind of hard to explain, but/so be sure to check out the mini-tut in the Online Documentation.  The plugin has a 30-day free trial period, so you can download it and give it a try.

Cheers,

Keith

Attached Link: tdmt_pyd.zip

Thanks for the comments... the file was missing, but I just replaced it (see link above).

Cheers,

Keith

Hi Cage,

I don't personally have any (immediate) use for these scripts, but I just wanted to pop in and tell you how impressed I am at your tenacity in figuring this stuff out - nice work!

Cheers,

Keith

tenacious / obsessive... whatever works :).

Quote - Would you like a VSS sRGB skin shader? I could set publish one pretty easily.

Hey BB,

Did you ever publish the sRGB version of your VSS skin shader?  and/or your Hair Shader?

It doesn't look like you updated the files/links on the VS homepage. Would love to get those when you get a chance - thanks.

Quote - ...could it be that the dll does not support 64 bit OS?

Simple answer... yes (32bit only).