Yeah, yeah.  It's simple - the matching body parts of the figures are put together.  But that's only if you are a good boy (or girl) and used the exact JPs of the target figure (maybe with the adjusted weighting zones).  I've seen plenty of conforming figures where things really didn't match up (because of scaling or joints nowhere near the target figure's or in different orientations or etc.), and yet Poser still manages to get them conformed properly.

My conforming algorithms are pretty good, but very complicated and tweaky.  And they still fail on a percentage of figures - especially shoes/boots.  For instance, the image shows a before and after - with color-coded bones to illustrate the mismatch.  This is Miki with the left Yulan Boot, unconformed on the left, conformed on the right (not tweaked).

Of course, this is my own limited-understanding implementation of how this might be done.  There is definitely something missing in my understanding that allows conforming to occur in Poser even in some brutal circumstances and fail with these odd cases with my algorithm.  And it would be nice to remove the oft-times required user tweaking and be able to get it right programmatically.

Thank you very much,

Robert

Quote - I've seen plenty of conforming figures where things really didn't match up (because of scaling or joints nowhere near the target figure's or in different orientations or etc.), and yet Poser still manages to get them conformed properly.

Fogive me if I am stating the obvious, but I suppose you know that Poser seems to use the 'initValue' in the conformer when it first conforms the item, NOT the "k" line values which don't affect the initial conforming. If you try to conform Posette to another Posette it doesn't work, if you zero her translations and rotatins it still doesn't work, but if you zero her translations and rotatins, then 'Memorize Figure' it does work. After the Memorize, you can pose her any way and she still conforms. Then again, on the other hand there is the strange case of the P4 Thin Strap Dress: actor chest:3 [blah blah] channels { [blah blah] rotateZ zrot { name GetStringRes(1028,3)

                        hidden 0
                        forceLimits 0
                        min -35
                        max 35
                        trackingScale 1
                        keys
                                {
                                static  0
                                
                                }
                        interpStyleLocked 0
                        }

Both the "k" value and the initValue are "26", and it still conforms ok. Black magic? If I set 'initValue 26' for zRot in the chest my conforming Posette, then Memorize, it won't conform properly. The thin Strap Dress destroys all my theories and refutes everything I thought I knew (not much) about conforming.

My code actually zeroes both figures (the target and the conformer) before performing the conforming process so that rotations have no effect.  There is no IK yet to worry about (but soon enough).

The disparity, in the image for Miki and her Yulan boots for instance, is not in rotations, but in the JPs themselves.  The Orientation, Origin, and Joint Order are the same, but the EndPoint is different between them.  And this is the only varied factor that allows the two matching body parts to be aligned properly when conformed.  In other cases, I've seen differences in the Orientation, Origin, EndPoint, or all three!

For properly done conforming items, those that used the base geometry for instance and where the default body part geometry is already placed properly, there is no need for any 'tweaking'.  But in cases like this, the geometry is actually rotated during the conforming process - this is not  via the rotation dials, though there is a slight change in these (still unknown why) it is not enough to account for the rotational alignment.

The simple answer is that the EndPoints are made to coincide.  But this doesn't always work either.

I think initValue has nothing to do with the conforming algorithms.  The figures' rotations are literally zeroed.

Thanks,

Rober