may i get these clothes pressed?

1. Darien Caldwell 2.16.12 / 10am

   NIce! Can’t wait to see the new version in action. 🙂
2. Niran’s Viewer 12.3.5 and more: daring to be experimental | Living in the Modem World 2.16.12 / 12pm

   […] Releases 1.24 (Feb 14th) and 1.25 (Feb 15th – gives you some idea of the speed of updates!), have given me cause to play a little bit of catch-up. Release 1.24 was itself essentially a series of fixes and tweaks to the 1.23.5 release (also made on the 14th February), while version 1.25 adds version 0.2 of Qarl’s Parametric Deformer to the Viewer and includes some graphics related tweaks. You can therefore take this review as more-or-less a n outline of the key elements from all three of these releases (1.23.5 through 1.25). […]
3. Chalice Yao 2.16.12 / 2pm

   Hey, Qarl?

   ‘if ((skin->mDeform) || (1))’

   😀
4. qarl 2.16.12 / 2pm

   crap.
5. Chalice Yao 2.17.12 / 5am

   oh, Qarl?

   Even with it set to if(skin->mDeform != FALSE) it won’t work.

   Solution:

   Change mDeform from BOOL to bool, and all FALSE assignments to ‘false’ in the modelpreview and other files.

   BOOL is a..bad, bad thing, and actually an int. It works if mDeform is a bool and gets assigned false or the .asBoolean returns.

   a if(skin->mDeform != false) does the job in lldrawpoolavatar then. Just tested it with an upload :3
6. Rygel Ryba 2.29.12 / 1am

   Hopefully this is the place for this…

   Was playing with the Mesh Deformer a bit with a friend yesterday and I’m not sure exactly how the data is stored in things but this option came to mind as we were looking at things…

   One of the issues you have mentioned is some sort of a toggle to say “Yes do deform this” or “No, this is rigid”. I found that as we were playing with things though that wearing a few meshes like a jacket over a long sleeved shirt, creates a bit of bulk in the arms that isn’t particularly desirable.But if I could hide the shirt arms with a texture so they are invisible, then the jacket arms could be smaller. Trick here is that the deformer still knows about the shirt sleeves even though they are hidden.

   So, while I’m not sure about the practicality, here is my suggestion: Individual modifier shape data. This might actually use less resources at run-time than then deformer, too.

   Individual Modifier Data Per Mesh Attachment

   Imagine it as a separate shape file for each mesh item. It starts with no data (rigid) but then you can add a shape to it. You can copy your avatar’s shape data as a starting point and then, to use my example above) use the slider that makes your arms skinnier JUST on the jacket. It’s a different value from your avatar shape. Once you are done you “save” the modification and it’s stored in the object file itself.

   This way, you save the need of calculating everything at the time the mesh is worn. All the offset data is figured out and stored at the time you edit your appearance. So this would save a lot of load when items are worn and taken off. The downside, of course, is that you can’t have 2 different shapes and wear the same jacket object. But we have that same limitation with regular prim attachments, too – change shape and that attachment is going to need to be adjusted or you just wear a pre-adjusted copy.

   Another advantage here is that all the collision math doesn’t need to be as precise. If there is a slight bit of arm poke-through and I have a no mod shape, my mesh “shape” data IS modifyable so I can just bring up the arm thickness a notch or two and poof – fixed. Save your jacket and you never have to worry about poke through again.

   I could also, for example, have a prim/sculpted “belt” on my jeans and add just a hint of “love handles” or whatever to my jacket to make it expand outside that belt without affecting my whole waist.

   I think this would be a great feature, would (possibly, if my guess on how all this works at runtime is correct) reduce some run-time server load at least when the mesh is first attached and possibly as it moves, too, and generally add a lot of flexibility to the combinations of things that users can wear – especially combinations of prims and meshes that the original mesh creator didn’t design specifically to accomodate.
7. Henri Beauchamp 3.20.12 / 4pm

   Hello Qarl

   There are two problems with the current implementation of mesh deformers:
   1.- it causes some avatars wearing rigged meshes to “jump” up and down annoyingly every 10 frames or so, even when their mesh is not deformed.

   2.- it causes huge ‘hiccups’ (frame freezing) when many avatars wearing deformed mesh rez (for example, after a TP with avatar wearing defomed meshes.

   Problem #1 is in fact in the current viewer mesh code that causes the “jump” sometimes, when rebuildRiggedAttachments() is executed. Since your code adds such a call to LLVOAvatar::updateVisualParams() and since the latter function is called periodically for each avatar, the jumps happen for any avatar wearing rigged meshes with a non-zero offset.
   I implemented a workaround for the Cool VL Viewer (it will be in the upcoming v1.26.4.5 release), which only calls rebuildRiggedAttachments() from updateVisualParams() if the avatar is actually wearing a deformed rigged mesh, but the true solution would be to call rebuildRiggedAttachments() only if an actual change happened in the visual parameters.

   For problem #2, you could perhaps throttle the deformer tables creation to one every few frames (which would cause deformed mesh to “fully rez” (be tailored) progressively). Another solution is to optimize the code (perhaps would it be possible to use SSE2 ?…).

copyright qarl.

entries RSS comments RSS