Vir Linden

I think the stats you're looking for now are: MAX_CONSTRAINTS = 10 (unchanged) LL_CHARACTER_MAX_ANIMATED_JOINTS = 192 The latter is equal to the count of bones plus the count of attachment points, rounded up a bit to allow for a couple of other factors.

Hi Teager, We actually had the alt eyes as children of the face root for a while during Bento development. The problem there was that the alt eyes no longer worked as drop-in equivalents for the original eyes under sliders and such, since their parenting was different. Unfortunately, as you suggest, there probably isn't a perfect solution. At this point, we will likely keep the skeleton as-is. If you have any thoughts on what turns out to be the best alternative method for working with the eyes on models like the horse, it would be a great thing to add to the best practices documentation.

The Bento project viewer has been updated. This latest build contains the recent work on supporting multi-root skeletons and partial joint offsets, and also has a couple of slider-related fixes. Details in the release notes.

Gael, Unfortunately we can't do the check at import time without changing the mesh format, which is outside the bento scope/schedule at this point. I'm currently testing this with a tolerance of 0.1 mm and everything seems to work with a suitably defined model. We have some flexibility in picking a threshold, as long as it's within the scope of floating point precision, and hopefully small enough to not produce a visible change in the model - that would mean that someone could "lock" a joint by making an invisibly small tweak to the joint position.

Currently joint offsets have an "all-or-none" property. If you select joint offsets on import, then all the joints that the model is skinned to will be uploaded with a corresponding joint offset. But what if you don't actually want to override the position for all those joints? It may be that you only wanted to change the location for a few and are happy to have the rest left at the default location, to potentially be moved by sliders or overriden by other attachments. Ideally we would like to be able to specify which joints the joint offsets would apply to. However, we are not looking to change the mesh format for bento (schedule!) so we would need a way to control the behavior per-joint without actually changing the mesh import UI or the mesh format. One possibility would be to look at the joint positions on a mesh when it's loaded by the viewer. If it claims to have a joint offset for a joint, but the position is unchanged from the default location, we could ignore that joint offset and just leave the joint unmodified. If you wanted to force a joint offset for a joint, you would need to make a small change to the joint position to override this behavior. So the question is, would this be useful? And would it break existing content? It looks like in many cases the meshes already out there do have slight joint position changes added by the modeling tools, in which case they would not be affected by this change. And if they were affected, in most cases it would not make any difference - remember the joint winds up in the same position either way. A case where appearance might change would be if there were two meshes trying to set the joint position to different locations, and the mesh that happened to be chosen as the winner was the one that set it to the default location. If that location was considered "right" and the location requested by the other mesh was considered "wrong", then the position would have changed from the "right" location to the "wrong" location. But this seems like a bit of a corner case; if two meshes are fighting over the same joint, the user has no control over which one is chosen as the winner, so mixing such meshes inherently gives unpredictable results anyway. If we don't identify any major concerns with this approach of ignoring joint offsets for unchanged joints, it will become the behavior in the next bento project viewer. Please let us know what you think.

Gaia is correct that extensive slider support for Bento was not something we had originally planned to do. We would like it to be as useful as possible, though, so we have the question of what the best practices are, and whether there is anything else we can do in the viewer to make it work better. If anyone wants to discuss these issues live I've added the topic to the Bento User Group meeting for this week.

Thanks for the details on that issue, and the test models. I turns out that the mesh importer currently expects there to be a single "skeleton" node, and expects all the joints to be children of that node. So in the two-root model, the first skeleton (right leg) gets picked up, and the corresponding left-leg joint info gets dropped. We have a candidate fix that looks good so far; if all goes well it will be in the next project viewer, and multiple-root models should import correctly.

Teager, I'm trying to look into whether combining partial joint overrides is working as designed. I saw you sent some centaur meshes - thanks for those. It looks like the "partial avatar bones exported" does have only a subset of joint positions defined (but also renders as a big jumble), and the "all avatar bones exported" looks a bit better but clearly not right. I don't have a copy of the mouse avatar. If it's something available in the marketplace, my suspicion is that it's setting most or all of the original non-bento joints, so the mouse and the the "all avatar bones exported" centaur wind up fighting over the human torso bones. If you can send me a copy on aditi or a marketplace pointer to the mouse or one of the other meshes you've been using I can take a look. One other thing I noticed about the hind limbs is that it doesn't look like you're doing anything with the mHindLimbsRoot, which is the parent of both of the hind limbs (like a 2nd pelvis). Possibly some of the problems might be related to that?

If you log in with the previous project viewer, or visit the alternate viewers page, you should get the update. As noted above, this has the final planned skeleton and set of supported sliders.

The next project viewer is currently going through QA. This is a bit more extensive process than some of our past builds because this build includes what we're planning to be the final skeleton definitions, including the set of bones, set of attachment points, and slider support. So for example all the sliders need to be checked, which takes a while.The main changes you will see from the previous build are: One new bone, for the chin Two new attachment points, for the hind feet Many sliders are now supported for suitably weighted meshes (big thanks to Matrice, Gaia and Cathy for pushing this much farther than we originally thought would be possible) Various bug fixes including one for some annoying graphics glitches in the mesh upload preview We'll let you know when the build is released. If you want to discuss the latest changes, or anything else Bento-related, feel free to join us for today's meeting of the Bento User Group. Details at http://wiki.secondlife.com/wiki/Bento_User_Group

There's been some discussion recently about partial joint overrides and what the requirements are for these. I'll try to clarify a little bit what the terms mean, and how the best practices have shifted over time. Joint Offsets is the standard term for mesh fields that redefine the desired position for some of the bones. This is the term historically used in the viewer codebase and in uploaded meshes. Unfortunately this is a misleading term because they don't define an offset, that is, something added to the original position. What they really are is position overrides that cause the original position to be completely replaced by the "offset" value. An uploaded mesh is allowed to define a position override for some or all of its joints. The old behavior was that upload of joint offsets was only allowed if offsets were defined for a large fraction of all the bones. So to satisfy that requirement, a lot of older mesh content defines offsets for all the joints, even if the offset value is identical to the original non-offset value. The problems with this approach arise when multiple meshes want to define offsets for the same joints. There's really no way decide which mesh should "win" in such a scenario, so the viewer has to pick one effectively at random (it actually uses the UUID of the mesh to pick a winner, which gives a consistent result but is not something that's under user control). For Bento, the requirement that offsets must be defined for most or all joints has been removed. This should make it easier to create meshes that have different areas of responsibility, so for example a head mesh might define offsets only for face joints, and it should be compatible with a centaur body mesh that only defines offsets for the legs and spine. Since the requirement has been changed only recently and only in Bento viewers, a lot of existing content probably still defines more offsets than necessary, and may have compatibility issues with other meshes. Add-on tools liike Avastar will also need to be updated if they were previously enforcing constraints on how many offsets must be defined. Note also that these changes are recent and haven't been tested a lot, so it's possible that there are issues still to fix with such mix-and-match mesh models. Mesh skinning also depends on the uploaded model to specify which joints the model is weighted to. We can handle content most efficiently if the list of skinned joints is limited to the joints that the uploaded mesh actually has weights defined for, but it's largely up to the content creator to enforce this. Note that the set of which joints are used for skinning is not necessarily the same as the set of joints for which position overrides are defined.

Teager - I believe the current version of the bento viewer supports partial joint position changes, so if you have two meshes that do not fight over what joints they want to reposition, they should be able to work together. It's possible that's not working as intended, or there could be some joints that the meshes are both trying to override. If you could send me a copy of the test objects you're using I can take a look. With the hind limb positioning issues, do you see the problem when you're wearing a single mesh? Or only with multiple meshes?

That house fly is both impressive and somewhat terrifying.

Thanks, Gaia, we'll look at adding those to the next build.

Thanks, we'll take a look at those.

Whirly - thanks for checking. I updated the links on the bento testing page to point to copies that are hopefully public. Please let me know if it's still giving you problems.

There's a new build out for the Bento Project Viewer. You should get it automatically if you run a previous version of the project viewer. This build includes additions and a few changes to the face bones, and increases the hind limbs to 4 joints each instead of the previous 3. Along with the skeleton updates, there is a lot of work in progress on support for the sliders. For example, if you do edit shape on a suitably rigged mesh avatar, you can now tweak settings such as nose length or width, or eye spacing and tilt. Along with the viewer update, we have also changed the bone definitions on the aditi simulators, so uploaded meshes and animations will now be updated against the same set of bones. There are two mesh models available that can be used with the sliders - see http://wiki.secondlife.com/wiki/Project_Bento_Testing for current information on supported models. This should put us at the end of significant skeleton changes. There might still be minor tweaks to support additional slider work, or to address reported bugs that may be related to the spine joints. The reason we've been having this test period on aditi is to help make sure we have the right skeleton before we go live on the main grid. Please help us by making models that exercise the new joints! I'm not sure if there has been any content creator testing so far for the spine joints or the new hind limbs - we would encourage anyone interested in those areas to try them out and let us know how it goes. We will have a Bento User Group meeting tomorrow at the usual time - please feel free to come by and ask questions, or show off your work!

Henri, re: avatar_lad bugs: Agreed, and well spotted. Those will also be fixed in the next project viewer build.

Re: attaching hind legs to flexible spine: The intent is that the limb root will allow the new limbs to be relocated wherever on the spine they would be most useful, and we are also adding additional joints along the original spine to increase flexibility. So a couple of possible scenarios would be to move the new limbs up to the mTorso joint and have them be front limbs for a centaur-type model, or move them partway down the tail and use some of the tail joints as intermediate spine joints. If we attach the hind limbs to a fixed point along the spine, it would simplify usage a bit (no need to relocate the limb root), but would reduce flexibility to use them in different ways. Another possibility for using the limb roots is to make rigged pets, drones, or other animated objects that aren't even visually attached to the avatar. We'll be interested to see if such uses come up in practice.

I can see the extra joint would help with modeling that type of "digitigrade" legs. Another obstacle is the IK code, used to keep the legs configured with respect to the ground when walking or sitting. It only applies to the original limbs anyway, and does not extend to the toe bones. Trying to add another link to the IK chain and tweak the behavior so regular human walking and sitting still works right would be a significant project and we would not have time to look into it for this release. How useful are the extra joints without IK changes?

We've moved today's meeting half an hour later due to a conflicting company meeting, so 1:30 SLT.

Henri, re: avatar_skeleton_spine_joints.xml: Any extra avatar_skeleton or avatar_lad files are for use during development - I had added that one to make it easier to test with and without spine joints when trying to fix an associated rendering bug. We'll remove the extra files before release - in the meantime, they won't affect the behavior of the viewer unless they are copied in place of the standard files.

Re: alt eye issues: I think the parenting of the alt eyes may have changed from the original eyes. Maybe also an issue with the sliders? Either could cause some discrepancies potentially.

Re: the spine joints, what I think we ideally would want to do is add one joint each between mPelvis->mTorso, mTorso->mChest, and one for the neck. The reason we're adding joints in pairs elsewhere in the spine is because we're using a kind of odd scheme where the two spine joints in their default positions cancel each other out, allowing us to leave the position of the original bones (mPelvis, mTorso, etc) unchanged. If we can avoid doing the same thing with the neck, that saves us two joints. So the intent isn't to slight the neck, it's more that we're overbuilding the rest of the spine. Happy to discuss more at the user group meeting today.

The Bento project viewer is now updated with the new skeleton, and back-end enforcement on most regions of Aditi is being updated to match. As before, you can upload any bones in the BentoExperimental1 region.