may i get these clothes pressed?
i’m headed out on vacation next week but i want to get another release of the deformer code out for testing.
it has a fix for the problem of “crumpling.” (thanks to Elie Spot for helping me debug the problem.) it turns out that looking at the closest vertex isn’t enough – we need to find the closest point on the closest triangle – and determine what mixture of three corners makes it. deforming is now a much smoother effect.
it also contains the on/off switch, settable at upload time. (it’s next to the “Upload skins” checkbox.)
7 thoughts on “may i get these clothes pressed?”
Leave a Reply Cancel reply
You must be logged in to post a comment.
Filed under: second life - @ 13 February 2012 3:16 pm
NIce! Can’t wait to see the new version in action. 🙂
Hey, Qarl?
‘if ((skin->mDeform) || (1))’
😀
crap.
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
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.
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 ?…).