Quote - > Quote - Perfect example: if your NURBS-capable modeller has a "drape" function - try it out... in pure NURBS, it's damned fast... add a bit of constraint on half-edge lengths (so it didn't distort down to the floor), and it would be a golden example of what dynamic clothing could be.

One frame of any highly constrained and limited sim is always fast. Can you 'drape' with wind or self collision or in multiple directions in your NURBS modeller ? Can you get your cloth to be cut or react to cloth weight and weave ? Can you adjust it's shear and stretch resistance ?

I don't see why not - the sim I pointed at is only to display one limited function, but with lots of other aspects tied onto it at the same time. Whether it scales up and would survive within Poser's environment I do not know fully - I've only experimented with it lightly against D|S' SDK-exposed functions - even there it would take a bit of internals modification to use that particular rig, but it scaled up fairly well. I wouldn't use it however due to IP issues. > Quote - Your idea, though cool, is founded on your assumption that the 'speed' you are seeing in drape is because of NURBS. While it is actually from the fact that 'drape' is to cloth sims what a 'pose' in poser is to a muscle system.

Not necessarily. While I do believe that the increased speed is due to not having to calculate for each and every vertex, I don't believe that simply being a NURB is the reason why. What I do believe is that if you can reduce the effective number of edges and control points to calculate against, you get a faster response. NURBs is just one of a handful of different methods. > Quote - Polys are basically a network of connected points, which you can simply map to the springs.

Oy... that would slow things down considerably... first off, tying a spring to a pair of half-edges, okay... I can grok the idea you're getting at (and everything is already nice and delineated right down to the very now-predictable initial vectors of those springs, which makes it attractive at first). OTOH, if you take a typical 5,000 poly mesh (say, a knee-length ruffled skirt for V3), you're liable to have roughly 10,000 or so springs (prolly more) to deal with (depending on the # and distribution of tris, quads, and n-polys in the mesh, etc). Calculating collision detection on each vertex against the world is going to eat CPU as it is - now you want retention/stretch info tied in to each and every edge-pair? With an .obj file that has morphing info and possibly joint/quat rotation info tacked onto the top of that? I dunno about you, but these things take forever to read-in to Poser as it is... > Quote - Sure it can, and is in advanced cloth sims like syflex. Which BTW costs 10x what poser itself does. And incidently, syflex a pure poly cloth sim. Tells you something doesn't it.

It does... it tells me that they've either figured out one hell of a nice algorithm, use sub-D and very low-poly mesh, don't use an ASCII format for the file, or that they break it all down internally into something else entirely for calculation (or, possibly that the mesh file being read-in for this is a binary file already chock full of octrees and other sim-friendly structures, or...). I'm not sure what they are using, but I am willing to wager that it wouldn't natively accept anything like a .cr2/.obj pair. I'm not saying it ain't possible, but I am saying that doing that to a traditional Poser-friendly .obj file in typical mesh densities (and scaling... ugh), simply ain't gonna cut the mustard. /P