Polymath Snuggler

You need to complely disassociate the skeletal heirarchy for upload but still preserve local rotational values at zero. This has the downside of making "export with joint positions" completely non-functional. But with a non-directly-parented skeleton you can twist any of the parts around any which way to make a "bind pose" and the as long as the joint rotations are all still locally zeroed, your file will produce an intact result. I haven't tested the "twist" case though. But my code is currently under some rather heavy revision~ so I don't really have the means of doing so. It should also be noted that the "twist" case is topologically a NIGHTMARE and should never be used. There are some solutions you don't want to have work ~ and that's one of them. Because the forearm topology and UV's will be a distorted twirl of a mess.

This project adds stuff to the existing ~ completely invisible, avatar skeleton. It does not change anything for anyone unless you are a content creator that "makes rigged mesh". For everyone else, if you have purchased something that "uses Bento" you will need the new viewer to see your new content properly ( much like you you would need a mesh enabled viewer to see mesh content ) Other than that nothing has changed, there are no new options for you to worry about except for a few new "attachment points" to wear stuff on. That's all! Enjoy!

Are those sliders position based? ~ Are your animations that are playing there adjusting the position of the bones? If so ~ it's been publicly stated over and over again that translation ( position ) based animations will negate the effects of any translation based slider control. If these animations don't use translation then this might well be a bug. Edit: Reset skeleton is something done locally on each viewer. One person pressing "Reset Skeleton" does NOT reset the skeleton for everyone else viewing that avatar. Therefore it cannot be "scripted" into your Animations. 2nd Edit: Here is a list of bones that are partially or completely affected by sliders that move their position, and therefore may have those slider values overridden by translation animations that also affect position as well: https://wiki.secondlife.com/wiki/Project_Bento_Skeleton_Guide#Bones_Currently_Affected_By_Positional_Sliders

Beq and AndryK seem to have ironed out the problems with the fix, which is awesome news, and the fix itself was actually fairly simple~ I feel compelled to mention however, that the bug itself was incredibly bizarre. As it was rooted in the methodology of the piggybacking of mesh display behavior on top of prim base types. Bugs that are simple to locate don't last 5 years~ nor do the bugs that are simple to solve. This particular one was insanely difficult to locate, but simple to solve. The vast majority of the rest of the LOD problems sadly fall under the "simple to locate, but nearly impossible to solve." umbrella. That being said, while there are a LOT of bugs with the LOD system, it's still 'passibly functional' as it presently stands. Remember: The Lindens operate as a business should. Cost benefit analysis. Which means solving really convoluted pain-in-the-ass problems that have no drastic impact on the world really isn't high on their to-do list. The majority of the problems come from the way the upload system presently is incentiveizing uneducated creators to create content with single-triangle Low LOD's. And while I do hold the Lindens partially accountable for not doing more to at least clarify in the uploader what was "good" and "bad" for SL. At the end of the day, there's no amount of enforcement that can stop a unskilled creator from creating bad content, without limiting the creative freedom of a good content creator to create something impressive. That being said~ SL documentation, especially on mesh has been abysmally lacking. As for actually fixing things ~ I've actually submitted a number of random LOD related bug reports to LL ~ and they've seemed very receptive to at least trying to figure out a solution. After looking through the JIRAs of the last 5-7 years, I can say with reasonable confidence, a lot of longstanding bugs of SL predominantly exist because no one has filed a report that reliably points to "this specific thing is broke." ~ Most of it is "when I go here, and do this thing, half the time this other strange thing happens that I didn't expect." While that's helpful ~ as someone who's recently taken up trying to write code junk~ I can tell you it's not always quite good enough. Things seem to be heading in the right direction though! Even if it's a bit painfully on the slow side.

I noticed that too ~ while staring at the LAD file, but I figured it's always been like that~ since it wasn't "Bento" I didn't see fit to mention it. I figured everything that's worn on an attachment point has always been adjusted to that node position.

Awesome Cathy!~ !! That is a very long~ and in depth explanation of what I've been trying to describe in my posts so far ~ Obligatory ~ "Yes I made it work in 3ds max too" post: 3ds Max Joint flexy flex. In World flexy fist ~~ Note: I'm aware the hand doesn't move, But that's because I haven't made a rigged hand yet.

You'll have to come up with your own solution to the problem. I don't have a magic one for you. I was merely pointing out why you are having the problem you are having so you can start solving it. I know Cathy Foil sells MayaStar ~ which I would assume (but I don't really know!! ) deals with these issues~ and many others.

If you're doing the equivelent of that in Maya. That's EXACTLY why it's not working. That's what I've been saying this entire time. Do see the similarity between these two??? 

Yes ~ that is what I described in my post above yours. As for fixing the problem~ recall what I said about moving the bones making the connection nodes in Maya move and what looks like a visual representation of the bone nodes rotating occur, but not actually rotating the bone the way it looks?? Here's a visual representation of what you're doing (done in 3ds max rather than Maya) : http://i.imgur.com/n0fMFbj.gif Notice how the connective bars move ( which makes the bone look like it was rotated ) but the bone itself is still sticking out way off in a strange angle. Hopefully this might help explain where you're going wrong. EDIT FOR CLARITY : I'm reproducing what you're doing wrong, in an attempt to show you what you're doing wrong. Edit:: Ty Whirly and VistaAnimations for posting the hands video. I didn't think there was anything wrong with the rig as-is ~but I've been listening to people complaining about the bone setup in the hands for awhile now~~ so much so that my confidence in my rig was beginning to get shaken. It's good to see they're working as intended in an actual product demo~ rather than in my little "make sure it's not broke" tests.

The male skeleton is more than just joint positions ~ it's also bone-scale, which is why you're getting bunching and wierdness. I'm getting near having a max male skeleton soon~ just been having some difficulties working through the details.

I'm not sure what exactly is going wrong in this case, but I do know that Maya "draws" it's bones based on their connection, rather than their rotation. ( I'm referring to the line that you see being a representation of where a node is relative to it's parent and it's child ~ rather than the direction that node itself is pointed in ) Meaning in theory ~ you can have a bone rotated in a direction, but in the Maya Viewport ~ since it's drawing "connections" but not "rotations" it looks visually like it's pointing in another~ I sadly don't know Maya skeletons that well ~ as I mostly work in 3ds max ~ but that would be my best guess here. As for other reasons ~ well..... Converting from SL to Maya and then back to SL again provides a bit of an odd situation. I can't really think of a way to explain this without getting into the math of it ~ so here goes, as simple as I can manage. All joints in SL ~ when the skeleton is in the "T-pose" rest position are rotated to euler 0 0 0 world coordinates. Which means it's Z-axis is pointed straight up to the sky. This does not make Autodesk software happy ( both Maya and 3ds Max ) ~ as it tends to like it's bones tracked by their actual rotations~ That means bones are positioned with their Z axis pointed down the length of the bone. Converting between the two systems gets a bit hairy and confusing ~ and a lot of things can go wrong since there's a lot of work-arounds and funkiness that we have to kind of do to compensate.

@Vir. I ran into some odd slider entries in the LAD file. I haven't quite worked out what how driven: sliderName~ ( node#, min1, max1 , min2, max2 ) Entries affect their child-nodes that they refer to. However. One such child node has a lot of zeros in it for affected bones :  I'm unable to tell if these zeros actually do something. Are they redundant? Ignorable? Do they serve a purpose? Or did I find a rounding error of some sort? EDIT ~ I did a little more digging and : The following bones have slider entries that are either zero vectors for both scale and position, or just have single entries for scale or position that are zero, with no entry at all for the other field. "SliderName: Male_Skeleton || mWingsRoot HAS ALL ZERO DATA" "SliderName: Height || mCollarLeft HAS ALL ZERO DATA" "SliderName: Height || mCollarRight HAS ALL ZERO DATA" "SliderName: Height || mWing1Left HAS ALL ZERO DATA" "SliderName: Height || mWing1Right HAS ALL ZERO DATA" "SliderName: Frown_Mouth || mFaceLipUpperLeft HAS ALL ZERO DATA" "SliderName: Frown_Mouth || mFaceLipUpperCenter HAS ALL ZERO DATA" "SliderName: Frown_Mouth || mFaceLipUpperRight HAS ALL ZERO DATA" "SliderName: Ears_Out || mFaceEar1Left HAS ALL ZERO DATA" "SliderName: Ears_Out || mFaceEar1Right HAS ALL ZERO DATA" "SliderName: Wide_Eyes || mFaceEyeAltLeft HAS ALL ZERO DATA" "SliderName: Wide_Eyes || mFaceEyeAltRight HAS ALL ZERO DATA" "SliderName: Square_Head || mFaceRoot HAS ALL ZERO DATA" "SliderName: Egg_Head || mFaceLipLowerRight HAS ALL ZERO DATA" "SliderName: Egg_Head || mFaceLipLowerCenter HAS ALL ZERO DATA" "SliderName: Egg_Head || mFaceLipLowerLeft HAS ALL ZERO DATA" "SliderName: Egg_Head || mFaceTongueBase HAS ALL ZERO DATA" "SliderName: Arced_Eyebrows || mFaceEyebrowOuterRight HAS ALL ZERO DATA" "SliderName: Arced_Eyebrows || mFaceEyebrowOuterLeft HAS ALL ZERO DATA" "SliderName: Pointy_Eyebrows || mFaceEyebrowOuterRight HAS ALL ZERO DATA" "SliderName: Pointy_Eyebrows || mFaceEyebrowOuterLeft HAS ALL ZERO DATA"

Ty for fixing the image postings ~ As for the actual problem... Is this what happens when you upload the file without "Use Joint Positions" checked? It's interesting to see the bone nodes are highlighted red ~ which I've sort of assumed at this point ( with no real confirmation mind you ~ besides fiddling with it ) ~~means they're using some sort of custom orienteation/ position. I can't speak for the accuracy of the Maya import of the rig. People have been murmuring about "wierdness in the hands" for almost a month now and I've been unable to reproduce the problem personally. ~ That being said, I may not be doing the correct tests.

The two images look identical?~ I'm confused.

Vir ~ the more I think about this particular feature the more important it starts to become. For example : I strongly advocated that the mHindLeg bones scale with the front ones ~ otherwise they'd be rather useless as quadruped bones. I still stand by that ~ Primary use case should always come first. However~~ if this scale lock feature is implemented on a mesh-by-mesh basis it would make the mHindLegs the most ideal go-to bones for people who are striving to create animated shoulder pets as they are the least likely to be in use by other attachments ~etc etc ~ in which case their slider control would be annoying at best, a show-stopper ( for their animated shoulder pet project ) at worst. The locking feature definitely will contribute to the overall diversity of things that can be created with Bento.

As someone who hardly uses gestures at all ~ and has a microphone that makes me apparently sound like a robot having an aneurysm I don't have much to contribute to this conversation at all. However~ "The newbie experience" and keeping things in a way that offers the maximum ease of use should always be the goal !!

My Volume bones may be incorrect for that part of the body. ~ I'm working on updates still presently.

Uh... IK joints are part of what you call a "control rig" You create and append a control rig TO bones. They're not part of the skeleton, they're what you, the creator append to the skeleton to make it move... Or ~ you know, buy Avastar, because they do all that for you.

Anytime someone puts the word "Scaling" in a sentence I start to get fits. Bone scaling happens with avatar slider use ONLY. You cannot upload animations that change the scaling of ANYTHING anywhere. Bento just got an RC viewer! Bento is functional on the main grid ( Agni )

The dummy nodes are on the correct side, you forget the bones are crossed for the corners of the mouth. Thier controller nodes are rotated incorrectly though. Which is why I'll replace the incorrect controller node files soonish~ as soon as I get the the SL Sliders workin on the rig. Remember dummy node hierarchy visually appears to be different from actual bone hierarchy ( though they both function identically as actual bones ). With "Show Links" on the ( selectable ) link portion of the node leading to the bone does not visually relate the bone's influence, rather it's a conection indicator ~ it shows "what it's attached to". There is no visual representation for the actual extent of the bone influence. That's why I prefer bone nodes personally, but there were requests for a dummy only skeleton.

Scale based animations will not work in SL. The bone scale issue is only relevant towards getting an accurate slider system that replicates the SL slider system.

I made the decision to share my skeleton files because of the number of people who were struggling with understanding the joint orientations~ as well as the people who were dealing with import issues into 3ds max. The skeleton files posted on the wiki should be okay to rig to~ for a decent sized test project, but not okay to use with a large animation project just yet. To answer your question: The skeleton files that are presently posted, scaling the root will make the entire rig follow suit ~ but since I posted my original response and now.... I've reworked the skeleton ( yet again ) for slider support~ something which I had not originally planned on doing. Putting in slider support means that each of the bones have to be set to scale independently ( because that's what sliders do ) which means scaling the token may not be a 'thing' ~ on the newer rig I have. I'll see if I can puzzle out a scripted solution to that problem. So the skeleton I have now is parented differently than the one that is publicly available presently. ( Read that, don't do any terribly complex animations just yet ~ the animation exporter won't be able to actually export anything you do right now ~ however if you're good with import / export with animations, you can probably retarget whatever you work on presently to the new rig setup ) That being said ~ ( in theory!! )~ Working on a rig that is scaled up will work ~ as long as you don't track scale keyframes into your animation.

If you're in 3ds max ~ work in Ortho instead of Persp if you're having cam-clipping issues. Alternatively ( or in addition ) you can always uniformly scale the root token up~ that's what it's there for, just scale it back down before export. The rig has to be scaled correctly at the start or it won't export correctly ~ That's just how this works. No matter what it has to have the correct dimensions in meters. I made those example 2012 rig files~ they're the output of my script. However there's a couple issues with the dummy node files that I'm going to be fixing. ( The control nodes aren't oriented correctly in the file~ whoops! ) As well as a potential reparenting of the entire rig setup to accommodate the SL slider setup inside 'max ~~ no promises on that though. ( This will only affect the files with additonal nodes in them ~ not the "basic" ones ~ those are just fine as is )

The wiki is locked but if you leave Vir Linden a message in world with a link to the files you wish attached to the Wiki, I've found they appear there in fairly short order.

Importing the DAE file back into blender directly with default settings does yeild a very strange looking skeleton. I tested / confirmed that awhile ago. Most people are using Avastar or similar such tools to create their skeleton rigs rather than importing the DAE files. The DAE file itself seems sound ( as it pulls into 3ds max correctly ) but something to do with the way that the standard Blender Importer functions yeilds a deformed skeleton, at least for people ( like me ) who don't really know how to use Blender, and are just using default importer settings. That's not to say that there's no way of doing it correctly, just that my knowledge of blender isn't quite good enough to get it to work right for me.