And that's the downside of the enterprise, one supposes.  3D meshes fit to a particular figure are made to fit and be accentuated by a particular figure - but may go awry when fit differently.  As an example, my plugin for Poser->Cinema 4D has rather sophisticated master-slave dial support (FBM, PBM, ERC, JCM, etc. - the only outside of Poser and DAZ|Studio afaik), but it is nowhere near fully Poser-compliant to support constructs concocted by VM for complex mathematical control and manipulation of channels (dials).  This is both a limitation of my knowledge of how the developers of Poser implemented these controls and that of the system into which I construct the 'simulated' dials.  The ignorance, time, and effort demand a compromise - something that works in most situations but not in specific, specially-tailored ones.

WW works to do its best with what PhilC/Kamliche know about clothing and figures.  Sometimes even that is not enough to cover the complexity and variability of the situation (which is highly complex as we know).  Hopefully one day, conforming clothing will be completely replaced by dynamic cloth simulation - which is far superior when done correctly - but it is still a very expensive and complex solution which costs money, power, and time.

Textures are always a burden. One would think remapping a flat, planar, 2D image would be so much simpler than, say, matching 3D morphs or conforming clothing.  But actually, it is a very complex process.  It is more akin to morphing than mapping (which are related) because you are taking one space and mapping it onto another.  The problem arises in generality - which doesn't exist.  There must always be a 'mapping algorithm' from one mapping to another.  Think of Poser's FaceRoom.  You take a photo and map it to a head.  This requires that you specify particular points as relationships for the mapping procedure.  The same is true for UVmapping conversions.  UTC does this statically by only supporting 'known' mappings and providing the engine to make the conversion between them.  To do this generally would not be possible without intelligent agency directing the process (FaceRoom or RealViz ImageModeller point matching, for instance).

To get to the point about texture remappings, the problem really resides in the fact that textures are digital (whereas morphs and conforming clothing are mainly analog - floating point).  You are not remapping a procedural texture (which is easy comparatively) but a pixel x pixel digital representation.  Most of the work is in extrapolating and interpolating the digital information into a form that is maleable and then cementing that information back into digital form.  Think about the fact that a texture is 1024x1024 pixels and let's say that it is being mapped to some arbitrary 640x256 pixel mapping which is not a one-one relationship in pixel positions/orientations.  When remapped, these pixels must be stretched and aliased and transformed and so on in a way that preserves the original digital image but conforms to a new set of shapes.  As I have found, this is not very easy - there are textbooks and papers and APIs all geared just to explaining and implementing this seemingly simple task!  The reason is that, unlike 'analog' data, digital data doesn't stretch and expand as easily without showing signs of the process (sample error, aliasing, overcompression, etc.).    Take a 1024x1024 JPG and compress it to 64x64 and you see the inevitable loss of information - even without the remapping!  One day these things will be ubiquitous - for now, we must live with the limitations.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone