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

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.

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

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.

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

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

...erm... wait - I think I understand what you' talking about re: scaling....

Let's say that you have a square (polygon) and the UVs go from 0.0 on the left edge to 1.0 on the right edge... when rendered, the texture will be rendered once, from edge to edge on the polygon, using the entire texture.

Now if we take that same polygon and make the UVs go from 0.0 on the left edge to 4.0 on the right edge... when rendered, the texture will be rendered (tiled) 4 times, from edge to edge across the polygon, so it will be shrunk by a factor of 4, to fit in the same space 4 times - you're absolutely correct.

I was only thinking about the case where you would (using the example above) move the left edge to 3.0 and the right edge to 4.0.... that would be the same as from 0.0 to 1.0.  Sorry for the confusion.

I'm not quite sure how to respond to your scaling issue (at least without looking into it with respect to Poser's interpretation), but from my past experience, a 1.0 value and a 4.0 value should produce the exact same results.  If it's not, then it may be something specific to Poser.

re: out-of-bounds...

Yeah, UVMapper does bring up that dialog when it senses values outside the 0.0 -> 1.0 range, but you can just cancel that dialog and it's perfectly happy to deal with (display) them as expected.  I often use 'tiling' to (for example) move the Head UVs out a tile, to separate them from the Body UVs (and Transmap UVs and Mouth/Teeth UVs, etc. - each get moved out into thier own tiled space), so they aren't all piled up on top of each other (visually).  If you do that, Poser (and other apps) still work(s) fine.

Sure thing.  The negative values also wrap, btw... a value of -0.2 would be the same as 0.8 (for example).  Note that this wrapping (tiled texturing) is a function of the application in question - Poser in this case, but most other 3D apps as well - but in most UV-editing utilities/apps (UVMapper, BodyPaint, etc), you'll see the UV polygon outlines drawn outside of the 0.0 -> 1.0 space.

Quote - Here's an update for the chain maker script.

Excellent work Cage (and others) - cool script!

Quote - ...I had to extend their UV's beyond 1.0 on v.  I'm sure this is probably frowned upon, but it does texture stretching, giving a final result with the correct proportions.

You may or may not know this, but any UV value beyond 1.0 will "wrap" back to the other side (tiling, not really stretching).  So for example a value of "1.2" would effectively texture the same as a value of "0.2".  This form of UV-mapping is particularly effective with 'tiled' (seamless) textures.

...one more tip, related to multiple passes... As the script is processing, you'll see the status area at the bottom updating...

Running Pass: X Repetition: Y...

...as it goes through each itteration (or Repetition).  For very loose Threshold values, the Repetition count may only go up to 20 - 40 or so and for tighter Threshold values, the count may go up to 100+ (or more - lots of variables determine how high, including how badly the mesh is mangled to start with).

"Generally", you might get the best results if that count drops down to the single-digits (or something approaching the Steps value), for a given Threshold value.  My suggestion is to experiment with the Passes value - run 3 or 10 passes at the same Threshold and see if that's better or worse than one pass.  It might start counting up to 100 or more on the first pass, then drop to 74, then 52, then 30, etc... in other words, each pass should (normally) affect (fine tune) fewer and fewer vertices. 

[The above comments are mostly related to small / dense polygon areas, using a small Threshold - remember that large polygons will move more and more towards the base shape with each pass]

With the new default Threshold value (0.000031), it will still move those polys in the back of V3's mesh towards the head-neck connection, but it won't smooth it out very well.  At that setting, it maintains almost all of the total 'height' of the skull - the polygons on the top of the head are ever-so-slightly larger and so aren't affected (as much).  However if you increase the Threshold to 0.000032 then you start affecting those.

With that in mind...

• in order to really clean them up and affect all of them, the Threshold would need to be more like 0.000045 or something.
• Values smaller than that will only affect smaller and smaller polygons, as you decrease the Threshold value.
• It turns out that that same default value of 0.000031 is a good starting point for the V4 mesh as well.
• It's probably too small to start with when working with less-dense meshes like Antonia or V1 (it might affect the smaller polygons more than you want)... I'd start at something like 0.000045 and work down from there.

...so, given the above, my recommendation would be to just start with the default settings, run the script and see what you get... - if you see large polygons that look like they didn't get cleaned up, increase the Threashold value until you narrow in on the ones you want affected.

• if you see large polygons moving too much (deforming back towards the base shape), then decrease the Threshold value until they are no longer affected.
• if you see small (and/or tiny) polygons that still need more adjusting, decrease the threshold (once you get down past the larger-poly threshold size, they won't move anymore, so you can concentrate on the smaller ones).
• there really is no bottom-end Threshold for polys as small as the ones you see in V3's lips (for example), but a value of 0.0000131 is a good practical limit (just insert a 1 in front of the 3 that's there in the default setting).

...note that you can also run multiple passes... this can sometimes help smooth out the existing topology (ie. once the polygons look like they are shaped correctly, but may still be a bit 'bumpy').  Just keep in mind that multiple passes on relatively large polygons/threshold may cause additional distortion (erm... more towards the base mesh shape).

The general issue / rule of thumb is... large polygons (or polygon areas) are more likely to move back towards the base shape, since there's relatively fewer of them defining the shape within that area.  If an area is made up of tiny V3 lip-size polys, then you can get away with pretty tight tolerances and/or more additional passes before you start losing the shape.

With the above in mind, you'll need to keep a close watch when working with V1 / Antonia type meshes, because the smallest polygons are not as far apart in size from the largest ones (like they are in V3 or V4).

Interface / Options:

Omit Split Edges -

For the most part, you want to leave this Enabled.

Omit Zero Deltas -

There are 3 'general' usages of this script... 1. You set the desired morph(s) on the Figure and then run the script - the resulting morphs will only contain the corrections.

1. You zero all morphs on the figure and select some morph(s) from the list in the script's interface - the resulting morph will contain the selected morph(s), along with the adjustments/corrections.
2. A combination of the above... the resulting morph will contain any morph(s) selected from the list, along with corrections based on those morphs, as well as the current (morphed) state of the figure, but will not contain the morph(s) set on the figure, themselves.

...the Omit Zero Deltas option is ONLY related to morphs set on the figure - only those vertices (contained in morphs active on the base figure) will be processed.

Omit Non-Morphed Verts -

This option is ONLY related to the morphs selected in the list - only those vertices (contained in morphs selected from the list) will be processed.  NOTE: Setting this option overrides the Omit Zero Deltas option.

Mesh Density Screening -

The enables/disables the option described in the top part of this post.  When this option is disabled, the complete list of polygons/vertices (not already screened out by some other option) will be processed, regardless of the Threshold setting.

Max Repetitions -

With this script, the only time you're likely to need this setting is if you set the Steps value very high, combined with tight Threshold values on a dense mesh :) (I had it kick in once when doing 100+ Step value with a small tolerance on V3).  Generally, you can just leave it alone.

Threshold -

How close you want the vertices to resemble thier original Relationships (relative to each other, in the base mesh).  See the top of this post for additional discussion.

Steps -

Determines how far the script moves vertices towards thier target / goal locations, for any given itteration.  Higher step values can sometime produce smoother results, with less shrinkage /deformation, but the affect is not as drastic as the early versions of this script - you can generally just leave this at the default value.

Passes -

As mentioned above, you might want to run multiple passes at the same Threshold value... you can now do that without having to run the script multiple times.

Have fun!

Quote - Possibly silly question: is anything forcing you to use the same threshold in all areas of the mesh, or is it conceivable to make it depend on the mesh density in the neighborhood of the current point?

Not silly at all... it's what I had started playing around with, actually.  The current script will 'lock down' verts (stop moving them) as they get closer to where the script thinks they need to be (based on the threshold value).  It does this by filling in a matchlist[] array with a 1 for verts that should no longer be moved.

The large polygons don't really need tight threshold/tolerance values as the smaller ones... My current thinking is to determine an approximate "mesh density" value for each vertex, based on the shortest distance to a neighboring vertex. The script would then use this density value to 'lock down' the sparse areas earlier (higher threshold) in the process.  I had some success with some crude hard-coded values earlier, but hadn't yet come up with the best way to compute the right values to use, for any given mesh (in other words, values I was using for V1 or Antonia didn't work well on V4 and values I used for V4 didn't work well on V3).

The early testing code is in there (along with my related comments), it's just commented out right now.

Anyway, for anyone still interested, here is the sample image I was preparing related to the earlier posts...

On the left is a 'messy' (his labeling, not mine) morph that Cage sent me, applied to V3.  The right image shows the mesh after 2 passes of the latest RR script, using the current defaults (Steps = 4, Threshold = 0.000025, Omit Welds and Split Edges both checked).

As you can see from the image, the top and top-rear of the head lost some volume and this will happen to sparse mesh areas (large polygons) when using tight tolerances.  However, areas like that are easy enough to edjust with a few magnets if you really want to get that shape back and that side-effect also brought the rear of the skull back in line with V3's neck joint.

The denser areas of the mesh (lots of tiny polygons) still held the shaping, while cleaning up the messy vertices (note the nostrils and lips).

So, in general...

• the sparser the mesh (or larger the polygons in some area), the more they will tend to move back to the original mesh shape (V3, n this case), as you use smaller and smaller Threshold values.
• the denser the mesh (tiny polygons), the smaller the threshold value needs to be, in order to clean the mesh more, but because they are tiny, they retain the 'shaping' of the morph better than large poygons.

..this is a bit of a catch-22 with a mesh like V3's (depending on how messy the mesh is)... you need to use tight tolerances to clean up the tiny poygons, but tighter tolerances (or multiple runs of the script) cause more 'shrinkage' on the large polygons.  At some point, I might get interested in working on this issue again, but in the meantime, it's not a huge problem, because: - as mentioned, if you really want to get some of that volume back, you're just a few magnets away.

• If you're just trying to clean the mesh up as a better candidate for the Correlation script, you'll still get decent correlations.
• the 'sparsest' areas of typical Poser meshes are in areas like the top/back of the head - which is typically covered by hair anyway :).

Anyway, as I mentioned in my earlier post, the Restore Relations script is not meant to replace the Restore Details script.  My advice is to try both and use the one that works best for you in your particular situation (as mentioned earlier, one of the best corrections I got on the above situation was actually to run RD once first, then RR).

I'll monitor the thread and answer any questions directed at me, but otherwise, I'm off...

Have fun!