Project Bento Feedback Thread

[Vir Linden]

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.

[Vir Linden]

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

[Gael Streeter]

I identified yesterday the cause of the problem : it was the avatar_lad.xml of the viewer version 5_0_0_313150.
Indeed in the id="772" name="EyeBone_Head_Elongate" section, some bones were missing and some existing ones had weird values.I noticed also some missing bones for the Inner Corner Eye and the Eye Spacing sliders...

I have just installed the new version of the viewer, 5_0_0_313876, and all these problems seem to have been fixed in the new avatar_lad.xml. That is great ! :-)

I will now continue my tests and notably try to also animate my mesh heads...

[Vir Linden]

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.

[Vir Linden]

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?

[Teager]

The mouse isn't precisely necessary to the experiment; it's just an avatar on which I know pre-bento joint positions are set, and which is small enough to easily spot a difference in size when joint positions switch to default. The key thing to note is not the avatar itself but the flip-flopping of joint positions when combined with pre-bento content which sets joint positions on the full pre-bento avatar. If you'd like to test with that same avatar, it's the Orange Nova Luddi Lamb avatar - https://marketplace.secondlife.com/p/Orange-Nova-Luddi-Lamb-White/4494231

 

I've already confirmed that the file with only partial bones exported did set only partial joint positions. The fact that it renders as a big jumble is more or less why I sent it your way - I don't understand why the partial joint offset mesh should render any differently than the full joint offset mesh.

 

mHindLimbsRoot is not rigged, but shouldn't need to be. Its position is set and the bone is included in the export... Unless the answer to my earlier question was not the answer I surmised.

How is the mesh importer determining a partial set of bones, exactly? Is it setting joint positions for all bones that are present in the dae, rigged or not, or is it setting locations only on bones with weights?

[Gaia Clary]

I made a few experiments with partial Skeleton exports. And i found a partial export imports fine together with joint positions when the mPelvis bone is included in the exported Rig like in this example:

http://blog.machinimatrix.org/wp-content/uploads/2016/04/bento_testboots_1_rootbone.dae



 

Here is another file which does not include the mPelvis bone and which does not import correct to Aditi when joint positions are enabled:

http://blog.machinimatrix.org/wp-content/uploads/2016/04/bento_testboots_2_rootbones.dae



 

When you look into the skeleton hierarchy (in the Collada file) you see this skeleton has 2 roots mKneeRight and mKneeLeft which might be the cause of the problem. In fact when you look at the image you see that the right leg is correct, while the left leg gets totally wrong. Does this mean that the SL Importer expects to get only one Root bone? So is this an error in the Collada file or is this an Error in the SL Importer?

If this is an issue with the SL Importer, then here are 2 ideas how this could be fixed:

Import joint positions only for weighted bones

In this case the SL Importer needs to examine each imported mesh to find out which weight maps are populated with weights. Then the user can simply export the entire skeleton while the importer only uploads joint positions for the weighted bones.

In this case my first example above also works perfect because although it contains the mPelvis bone, no joint position will be imported for mPelvis because the mesh is not weighted to the mPelvis.

Add an artificial "Root" bone

In this case the Exporter needs to define a "Root" bone identical to the mPelvis bone except for the bone name. The SL Importer knows that no joint position shall be imported for the artificial "Root" and all is well.

I personally prefer the first fix, because this automatically optimises the imported meshes (does only import necessary information) and allows us to use the normal Collada exporter and always get a clean Rig.

[Gael Streeter]

I have made more tests with the facial sliders and the animations with the last viewer version (5_0_0_313150) and these tests have unfortunately confirmed what I feared : The facial animations and sliders can not work well together as they are implemented today !

For my tests I took a very basic but fundamental example of animation : a blink animation (an animation closing the eye).

They are today two available ways to design this animation : with rotations or with translations. (It is possible to use also both techniques at the same time but this does not change anything to the problems.)

1. Rotations Animations

For this first test, I design the blink animation with only rotations of the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones. I import it in SL and test it on my Mesh head rigged on the Bento bones.

When I first use the animation with the same shape as the one used to design the animation and to rig the head, with an Eye Opening set to 37, the animations works well : The eye is correctly closed as wanted.



Then, I set the Eye Opening slider to 70. When I play the blink animation again, it works no more well : the eye is no more closed completely but only partially.



Indeed, the Eye Opening slider moved the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones along the Z axis, the rotations of the animation stayed the same and are applied above the moved bones : when the bones are upper and lower the rotations angles are no more sufficient to close the eye.



So it is not possible to design a blink animation with rotations which works correctly with any eyes shape adjustment !
And this is also true for a large variety of other animations using rotations...

2. Translations Animations

For this second test, I design the blink animation with only translations of the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones along the Z axis. I import it in SL and test it on my Mesh head rigged on the Bento bones.

When I first use the animation with the same shape as the one used to design the animation and to rig the head, with an Eye Spacing set to 50, the animations works well : The eye is correctly closed as wanted and at the right place.



Then, I set the Eye Spacing slider to 100. When I play the blink animation again, it works no more well : the eye is correctly closed but is not placed at the right place (it is moved closer to the nose).



Indeed, the Eye Spacing slider moved the mFaceEyeLidUpperRight and mFaceEyeLidLowerRight bones on the side of the head, the translations animation also moved the same bones and overwrote totally the moves made by the slider : when the animation is played the bones are moved on the side as they are with an Eye Spacing of 50 and no more as they should be with an Eye Spacing of 100.



So it is not possible to design a blink animation with translations which keeps the eyes shape adjustments made !
And this is also true for a large variety of other animations using translations...

 

All this is terribly frustrating !

Indeed, the Bento project had two main aims concerning the mesh heads :

• To allow to deeply animate the mesh heads
• To allow to deeply adjust the shape of the mesh heads

And these technical issues completely counteract these aims !

Today, I personnaly do not know how I can use at best the new Bento possibilities : How explain to my customers that they can either change the shape of their mesh head or have nice animations for it but not both ?

And I do not see today how the Bento implementation can be improved technically in order to solve these big issues...

I really hope Linden Lab or the community will find a solution !

 

[stefandetoifrench75 Janus]

Gael,

A huge thank you for this great topic, you summed up the problem with a very detailed explanation ... I found the same problems as you... and I'm very worried.

Indeed, it is extremely frustrating, initially I thought to an error or forgotten in the development of this project to simultaneously work on the sliders and facial animations, and I was just thinking that having the opportunity to work on rotations and translations bones would solve this problem ...

And now I perceive myself that this is not a bug or forgotten, but the sliders and animations do not work together but I would say even worse, they are conflicting and make the result very rough and unsightly.

I think this problem has never been identified and explored before, since most new bones on the face, which was supposed to bring a great improvement and innovation creators and users to mesh heads.

I hope and pray very hard to make this HUGE problem to be considered by the team, because in the current state, it is impossible to exploit this new project, which was promising, I think if it is not improved, all users will reject the blame on the designers and will never understand this problem resolutely very technical and difficult to explain.

Another big thank you Gael to spend time and work for all mesh head designers. I hope they will be more likely to support your efforts to find solutions.

Also thank you to Gaia for your investment and your innovative jewelery "Avastar" which greatly improves our lives. As well as other creators involved in identifying the problem project.

Hopefully Linden invest as much as you, with the aim of improving the problem of THEIR platform.

<3

[Kitsune Shan]

I had mention this before and even proposed some solutions that could help to solve this. This isnt something related to mesh head only, it will happen with everything really even more on things using custom joints. Im sure people though my comment wasnt interesting or accurate and people choosed to ignore it or maybe they werent even able to draw on their mind this kind of problems. Im glad to see that Im not the only one that sees some serious issues here. All we can hope its for a fix before they release something broken like happend with fitted mesh .

[Vir Linden]

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.

[Gaia Clary]

---

Kitsune Shan wrote:

I had mention this before and even proposed some solutions that could help to solve this.

---

Can you please add some links to your proposals ? Although i recall you had mentioned a few ideas over the past months, i am not able to find your posts related to animation issues and possible fixes.

I admit that i am not good with using the forum search :matte-motes-frown: 

[Krystal Silverweb]

---

Gael Streeter wrote:

 

Today, I personnaly do not know how I can use at best the new Bento possibilities : How explain to my customers that they can either change the shape of their mesh head or have nice animations for it but not both ?

And I do not see today how the Bento implementation can be improved technically in order to solve these big issues...

I really hope Linden Lab or the community will find a solution !

 

---

 

I think this kind of issue always comes up when we want something to be able to do everything--as a creator I understand. The more possibilities and customizablity the better! However, there are some roadblocks hit along the way and this seems to be one of them. You can't make translate work-because it saves the location of the bone you set. So that bone will always go back to that location. And rotation would have to be increased or decreased based on your new shape-and possibly the bone translated a little, so it could never be perfect if that shape is changed using the same animation. Perhaps if a new rotation is calculated based on the adjustment of a slider, but who knows if that's possible and it still would have issues(bone being translated).

I was actually surprised when I found out there would be slider support in addition to having new animation possibilites! I think as a creator, we have to just state to our users that these animations work with the shape/mesh provided, and may not look good with others. We could provide a few different shapes that look good, and different animation sets to go along with that shape as a solution. Yeah, more work as always....but just look at the mess with all the mesh bodies and clothing sizes needed to be provided, ugh x.x

For mesh heads with "expressions" already, they could be rigged and the new shapes would work. So, looks like 1 of 2 options for mesh heads...tons of head attachments creating lag, or make predefinied shapes and different animation sets to go along

Even with the basic SL avatar skin/shapes out there, sometimes if you would alter a shape the skin would look bad with it, so if you think about it... it's not a ton different than that, just not all the flexibility that's wished for

[Gaia Clary]

Hiu, Gael;

I got inspired by your post to add a new chapter to the Bento article on our Website. Please feel free to check it out:

    http://blog.machinimatrix.org/2015/12/17/avastar-2/#transrot

Feedback and ideas for improvement are welcome (either here or on our website)

[Gaia Clary]

---

Gael Streeter wrote:

Indeed, the Bento project had two main aims concerning the mesh heads :

• To allow to
  deeply animate
  the mesh heads
• To allow to
  deeply adjust the shape
  of the mesh heads

And these technical issues completely counteract these aims !

---

I believe the support for Appearance Sliders was never planned. It was added only a couple of weeks ago as an additional goody. And i believe everybody knew right from the begin that appearance sliders and Animations do not work nicely together in all cases.

However we have shown a few areas where shape sliders and animations indeed work nicely together provided you only use rotation animation. So maybe it is frustrating that we can not have everything. But at least we got a lot more than nothing by now :matte-motes-sunglasses-3:

 

[Vir Linden]

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.

[Medhue Simoni]

---

Gaia Clary wrote:

---

Gael Streeter wrote:

Indeed, the Bento project had two main aims concerning the mesh heads :

• To allow to
  deeply animate
  the mesh heads
• To allow to
  deeply adjust the shape
  of the mesh heads

And these technical issues completely counteract these aims !

---

I believe the support for Appearance Sliders was never planned. It was added only a couple of weeks ago as an additional goody. And i believe everybody knew right from the begin that appearance sliders and Animations do not work nicely together in all cases.

However we have shown a few areas where shape sliders and animations indeed work nicely together provided you only use rotation animation. So maybe it is frustrating that we can not have

everything

. But at least we got

a lot more than nothing

by now :matte-motes-sunglasses-3:

 

---

I thought about this issue with sliders and animations, and it seems to me that we can have both the sliders and animation work together, if we added a child bone to the bones we want to animate with sliders.

Here is an example. Let's say we want the Ear Tips slider to work by offsetting the FaceEar2 bones, and still be able to animate FaceEar2 bones. The way to accomplish this would be to add a child bone to FaceEar2, maybe calling it FaceEar2slider, and the slider offsets that bone, instead of FaceEar2 bones. The creator of the mesh avatar would need to weight the ear tip of the mesh to FaceEar2Leftslider, instead of FaceEar2Left. With this set up tho, both the slider and animation on FaceEar2Left will work. The animator would also need to never move the FaceEar2slider bones.

Here's another example, using the same concept, but different set up. Eye Spacing is a good 1 for this. Here, the Slider bone would need to be the parent of the Eyebones, and Eyelid bones. So, the slider here gets applied to the EyeSlider bones, and the Eye bones, and Eyelid bones can still be animated while not affecting the EyeSlider bones.

[kayla Mekanic]

Which means even more bones added to the already complicated skeleton update... :matte-motes-dont-cry:

[Cathy Foil]

Interesting idea Medhue but I know we can't add anymore bones to the skeleton.

Here's an idea.  How about adding an Attachment Point for each of the new face bones in the avatatar_lad.xml?
We could make it so that these new attachment points you can not attach prims or mesh to like the traditional attachment points like the left or right hand attachment points but make it possible to weight mesh to and use these new attachment points so they can be animated.

This way all the mFace bones are used by the sliders but the animations only affect the new attachments.  The attachments are basically the child bones you are talking about.  Of course this might get shot down if adding attachment points causes the same lag as regular bones which we are already at our limit.

I am not 100% sure this would solve all our problems.

[Medhue Simoni]

I was just throwing out what came to mind, thinking about sliders and animation. What gets done about it is out of my hands.

 

I did have some thoughts about joint positions too. Why can't the uploader just choose which joints to offset by whether those bones have weights? If I'm not weighting anything to a bone, then I obviously don't really care if it's offset. Right?

[Gaia Clary]

---

Medhue Simoni wrote:

Why can't the uploader just choose which joints to offset by whether those bones have weights? If I'm not weighting anything to a bone, then I obviously don't really care if it's offset. Right?

---

Hi, Medhue;

The Bento Importer allows to import partial Rigs and so it only affects the bones that it finds in the collada file and keeps all other bones untouched. So you can get what you propose above as follows:

Blender-2.64 or newer:

 

 

• Disable the deform option for all bones which you do not want to export
• Then export with "only deform bones"

Avastar-2.0-10:

 

 

• Always exports only the bones which are weighted to at least one of the exported meshes

Avastar-2.0-11 (coming soon):

 

 

• You can decide if all bones get exported or only the weighted bones (via exporter option)

 

[Medhue Simoni]

I tested out your idea of the alternative bones to animate with, and I made a video on it for Blender users.

 

[Cathy Foil]

Awesome video Medhue!

Did you export out a .anim animation of the trunk to SL's Beta Test Grid Aditi to see if it all worked?

I would think it would if the Bento bones you were using for the trunk got keyframed.

I would also like to mention to make sure that people using this technique that their animations have to contain translations as well as rotations if the Bento bones rotate.

The translations using this technique are 100% mandatory or the disconnected Bento bones will not move together like they are connected together.

In Maya we can constrain to a bone's rotation or translation or scales.  So doing this technique in Maya you would want to constrain your Bento bones to the custom skeleton bones to both rotation and translation.

Unfortunately right now Maya users can not export animations with translations of all the bones.

There is a wonderful person right now working on it, not me, but I won't say their name because I don't know if they want everyone to know they are working on it.

If anyone knows a work around like a free FBX converter that can convert FBX files to .anim files compatible with SL please let us know.

I would also like to let people know that if they are moving the face bones around and using them in unique ways, like Medhue is for his trunk, it must be made clear that the facial sliders in the Appearance Editor must be at their default neutral position.

If someone were to move the nose slider to be bigger I suspect it make the Elephant look like it accidentally inhaled an aardvark that got stuck. I think I saw that in a Pink Panther cartoon once. LOL

[Medhue Simoni]

---

Cathy Foil wrote:

Did you export out a .anim animation of the trunk to SL's Beta Test Grid Aditi to see if it all worked?

 

---

Yes, I did export an anim, and it all worked beautifully, even with the head being influenced by the mouse IK in SL. Everything held together well.

 

---

Cathy Foil wrote:

 

Unfortunately right now Maya users can not export animations with translations of all the bones.

There is a wonderful person right now working on it, not me, but I won't say their name because I don't know if they want everyone to know they are working on it.

 

 

---

Ah well, I think the cat is out of the bag, as Nalates recorded your convo about the topic after the last Bento meeting. The afterhours video is on Youtube.

 

---

Cathy Foil wrote:

 

I would also like to let people know that if they are moving the face bones around and using them in unique ways, like Medhue is for his trunk, it must be made clear that the facial sliders in the Appearance Editor must be at their default neutral position.

 

If someone were to move the nose slider to be bigger I suspect it make the Elephant look like it accidentally inhaled an aardvark that got stuck. I think I saw that in a Pink Panther cartoon once. LOL

---

Yes, I tried to keep most of the other bones in the right place. So, the elephant will still have some customizable facial features. I'm also thinking of using the top lip bones to allow the user to customize the length of their tusks.

[Ikey Ilex]

To be clear, there's no way to make the new bones use physics similar to flxiprims, is there?

It seems to me like having to hard-animated the physics for something like a ponytail in hair or a floppy hat or something is a bit dumb... Surely there's a way to make the ew bones actually respond to gravity/wind/etc if desired?