Project Bento Feedback Thread

[Gaia Clary]

The Joint position section is here:

 

• Ensure your Rig is in Edit mode
• In the Avastar Rigging panel ensure that the
  Config Subsection is displayed

Regarding the Jaw position:

There is a trick to avoid moving the joint in edit mode:

Note: It is important to do the following Before you Bind your mesh to the Avastar Rig:

 

• Select the Avastar Rig
• Open the Appearance Slider section
• Open the Chin slider section
• Move the "Jaw Angle" Slider to a value of 80 (or whatever suits best for your purpose):



You see how the joint position of the Jaw changes dramatically with the slider settings.

Now bind your mesh to the Rig. Of course you need to tell your customers
to keep the Jaw angle at 80 or at least close to that value "to get optimal results".

But also note the jaw bone position depends on a couple of sliders:

 

• Jaw Jut
• Jaw Angle
• Chin Depth
• Head Stretch
• Egg Head

So this may work in some case but not in others.

[Gaia Clary]

---

Gael Streeter wrote:

I do not understand why the mFaceTeethLower is not parented to the mFaceJaw but to the mFaceRoot.

Is there is a reason for this ?

---

It is related to how the jaw is used together with the Shape Sliders.

Please make this experiment either within Avastar or by using your Bento Viewer (there is a show bones option somewhere in the Advanced section or in the Developer section of the viewer):

 

• Select the rig in pose mode (show bones in the viewer)
• Make the face bones visible
• Open the appearance slider section (Chin)
• Move the Chin Depth Slider and check how the chin moves in relation to the mouth

• Open the Mouth slider section
• Now move the Shift Mouth slider and again check how the mouth moves relative to the Jaw

I guess this makes it clear why the lower teeth have not been parented to the Jaw bone. Yes you have to animate the teeth and the jaw in parallel in that case. And yes, its not perfect.

 

[Anne Cloud]

The tail of that bone might well move based on the shape of the avatar, however it is crucial that the head joint of that bone be fixed as per Siddean's suggestion, since anatomically, it is so close to center and it would be unlikely itself to shift much due to shape change. It might not matter much to those of us who do use offsets, but in the situation where doing so negatively affects the face when sliders are used, I can understand why it would be of great importance to ensure an anatomically correct baseline.

[Vir Linden]

Hi Gael,

Yes, that is the expected behavior when playing animations with a translation component. I don't know the history of that decision and I'm not sure it's ideal - certainly your idea of the position resetting after the animation finishes is a reasonable thing to expect. However, since we've had this behavior all along, we couldn't really change it now without breaking existing content; for example, some people intentionally use animations as a way to reset the avatar's bone state.

I think one popular way to get things to reset after an animation completes is to have a lower priority idle animation, so that it will take over when the higher priority animation goes away. Perhaps folks with more content creation experience will have other ideas.

[Vir Linden]

If anyone has a dae that consistently shows this problem, please file a bug report and attach the model. We can take a look at it.

[Vir Linden]

Hi Pirschjaeger,

If you are still seeing the height flickering, could you help us track down the problem? If you either attach the relevant model files to https://jira.secondlife.com/browse/BUG-18245 or send me a copy of your objects in-world, we can take a look. Thanks!

[Pamela Galli]

Just want to say, as a non animator, seeing animators and Lindens working publicly as a team on this project is heartening and inspiring to the rest of the content creator / merchant community. I don't recall seeing anything quite like it.

[Teager]

As Vir said, one common way to fix it is to have a lower priority idle animation or background animation playing constantly which has your bones in their correct position, with translations.

 

Another way is to use the last frame of your animation (after the end of the loop) to move your bones back to their starting place, so they fix themselves every time your animation ends.

[Gael Streeter]

If the animations to stop use translations, a "background low priority animation" can not solve the problem because this low priority animation will also lock the bones positions (even if it is in the default positions) and that is not what we want here : we want something that release completely the bones used...

From my point of view, this problem will be extremely annoying for the end users : they will wear mesh parts including Bento translations animations that will lock their bones at a position and the effect will continue, deforming their shape, even after detaching the mesh parts...

If they use the Reset Skeleton, will this not compromise the operation of the other mesh parts (using Bento translatons too) they may still wear ?

[Vir Linden]

Hi Pirschjaeger,

I can see the problem using the test model you sent. Thanks for sending that!

Symptoms are a bit different than the previous bug, so I think it may be something new. We've added it to the bug list for bento.

[Krystal Silverweb]

---

Vir Linden wrote:

If anyone has a dae that consistently shows this problem, please file a bug report and attach the model. We can take a look at it.

---

Ok I made this bug report on it:

https://jira.secondlife.com/browse/BUG-20019

[Krystal Silverweb]

---

Gael Streeter wrote:

I made an animation using Bento bones translations and I am very surprised to see that

when I stop the animation, the bones stay at the last place given by the animation and do not come back to where they were before the animation was played...

Why is it so ? Did I miss something ? So how do we reset these bones positions ?

I tried the Reset Skeleton feature. It works well.

But this resets ALL the bones and not only those I would like.

This can not be used when wearing several objects moving different Bento bones and want to reset only a part.

So how to reset just a part of the skeleton ?

---

Wouldn't the original SL animations have to be updated to include the extended bones in them? Then the extended bones we animate would go "back to default" after we stop our animations made with them.

 

[Gael Streeter]

Thank you for your answer Gaia.

Regarding the Jaw position, that is exactly what I did.
I have adapted the bone position with the shape sliders in order to have it at the place I want before binding my mesh.
That is why, I am not sure we can say that the bone is not at the right place as it moves a lot according to the shape used...

Regarding the Avastar features you described, I think I do not have the same version of Avastar as you because I have none of them.
I use the last public version : 2.0.10.

Here is what I have in the Collada and Rigging panels :



[Gaia Clary]

The newest version is:

avastar-2.0-alpha_blender-2-77.zip

When you install this you should see the new export options and Avastar's product version number 2.0-11.

But beware... We have some trouble at the moment to get the joint position editor to work properly together with the shape slider system. The goal is to let you edit the skeleton completely independent from the Shape that you use.

The problem is that the shape sliders move the bones. So when you edit the skeleton while you have loaded an arbitrary Shape, then the tool needs to find out where the edited bones would be located when the skeleton is in the Second Life restpose. Then the tool can calculate the "true" joint position offset.

Actually this is already working for almost all mBones. But for some funny reason the jaw bone and its children misbehave here. I bet this is somewhat related to the issues on the lower lips and the chin that have been reported by Medhue.

[Vir Linden]

Hi Gael,

Reset Skeleton will re-apply any joint positions defined by the meshes you are wearing, so it should be compatible with whatever attachments you have on at the time. If you run into cases where it seems to be behaving incorrectly please let us know.

Reset Skeleton applies joint changes in this order:

1. joints get initialized based on the starting values defined in the skeleton file.
2. sliders are applied based on the shape and other wearables. This can change the scale and position (translation) of joints.
3. attached meshes apply any joint positions that they define (if "joint positions" was checked when the mesh was uploaded). So this means that positions defined by sliders may be overridden by attached meshes.
4. then after Reset Skeleton completes, effects from running animations are applied, so for example if you were running an animation that changed the position of a joint, that would supercede the position set in the previous steps.

[Vir Linden]

Thanks for filing that, Krystal! We'll take a look.

[Gael Streeter]

Thank you Gaia. I will get this version... :-)

I noticed also a little "shift" between Avastar and SL regarding the jaw elements.

[Gael Streeter]

Thank you Vir for these details !

Indeed, as it is done, this will not alter the other meshes worn as the offsets (by meshes or animations) will be reapplied.
In any case, if I notice something, I let you know.

[Vir Linden]

We've had a couple of issues reported recently where the symptoms were caused by using alpha flipping to simulate eye blinks. Just wanted to make sure everyone was aware that we now have eyelid bones in the bento skeleton. These bones should enable eye blinks to be animated using a mesh skinned to the eyelid bones; this should also give considerably better performance.

If there are concerns about using skinning for blinks, please let us know what problems you have encountered.

[Anne Cloud]

First off, let me say that I've noticed the eyeblink issue relating to texture offsets appears to be fixed from what I can tell (Thanks!). I have not yet tried alpha flipping. 

With that said, My concern is not specifically focused upon eyeblinks, and here's why:

Not everyone will be creating things which have the flexibility of using up human face bones for non-human attachments (my own wyvern case is an example).

Additionally, If we point to eyelid bones and say 'you can use those', don't we ignore the issue that creators may wish to use alpha flipping for *any* reason not otherwise handled by Bento bones? 

Granted, with what I have on my plate right now, I don't currently have something that would test this, however I think it is in our best interests that potential buggy areas be future-proofed as much as possible. 

[Tornleaf]

I used to have the mesh jitter/jumping with my puppy avatar's blinks. I think we solved it by making sure only one weighted mesh out of the group of weighted meshes (if you happen to be wearing more than one) had joint positions. Though I plan to toss it with an update. With the eye bones being available, you'd have to drag me back to that alpha swapping mess kicking and screaming.

[Anne Cloud]

Don't get me wrong - If you can make the switch you definitely should.

But i'm not even really talking about just eyeblinks here. Say for example if someone makes a steampunky avatar that has multiple interchangable parts, one of which has a door, knob or switch that makes use of alpha switching to flip back and forth? The content creator would be limited not through any fault of their own but by the inherent issues associated with updating rigged, joint offset meshes.

[Pirschjaeger Fassbinder]

I attempted to rig the mesh to the eyelid bones, but it just did not work for me. I might try a little more, but I think the problem may lie in bigness of the eyes and the relatively small eyelids. I am unable to get the upper eyelids to completely close without eyelid mesh going into the eye meshes. I even made a somewhat lame lower lid rigged to the lower eyelid bone that rotates upward. I also tried fiddling with the position of the upper eyelid bone in the animation, but I could not get it close without overlapping. I also tried moving the bone position in general. I could be missing something. Does mFaceEyecornerInner suppose to serve any purpose in blinking?

Otherwise, I do prefer to use the bones as opposed to alpha flipping. Just the eyelids of my avatar will use the alpha flipping. I just do not think it works for some specific instances.

I did try what you suggested, only making one of the meshes of the head have joint positions and uploading the rest without them. When I linked them and attached them, it worked fine without the jumping. So, problem solved for at least myself.

[Medhue Simoni]

---

Pirschjaeger Fassbinder wrote:

I attempted to rig the mesh to the eyelid bones, but it just did not work for me.

I might try a little more, but I think the problem may lie in bigness of the eyes and the relatively small eyelids.

 I am unable to get the upper eyelids to completely close without eyelid mesh going into the eye meshes. I even made a somewhat lame lower lid rigged to the lower eyelid bone that rotates upward. I also tried fiddling with the position of the upper eyelid bone in the animation, but I could not get it close without overlapping. I also tried moving the bone position in general. I could be missing something. Does mFaceEyecornerInner suppose to serve any purpose in blinking?

 

---

It's probably best to try playing with the eyelid weights while the eyelids are in the closed position. It's probably also good to pull the eyelids slightly away from the eye in the closing animation.

[Tapple Gao]

Here's an idea that would make it possible for animations to reliably set a bone's position back to default, but it would require a change in the .anim file format. I propose we add a new flag to the anim file format to specify that translation channels are relative, rather than absolute.

What does that mean? currently, <0,0,0>m in an anim file (32766,32766,32766 internally), means the bone is at the same location as it’s parent. I'll call this absolute positioning. It could be changed so that <0,0,0>m means the bone is in the default location from calculating shape and joint offsets. That would mean an undeformer, for any shape, would just be an animation with all translations set to 0. Translations to mPelvis are already treated this way (0 means, the offset above ground that was calculated as proper based on leg length and such)

For backward compatability, a flag would be needed to specify old or new behavior (relative or absolute). I propose that the field named "looping" be changed from a boolean field to a bitmask field. Now, looping would remain the lowest bit in this bitmask. relative translations could be the next lowest order bit. 0 means old, absolute translations, 1 means new, relative translations. This field would have no effect on mPelvis translations

This would enable a few niceties besides just reliable undeforming. It would also mean that translations work better between different avatars. Say you have two face meshes. one is long, the other is short. You make a translating nose wiggle animation for the short face. it works nice on that face, but if you play it on the long face, your nose will be moved to the location it should be on the short face, causing deformation. If translations were relative, this animation would work on both these face meshes, and any other, regardless of where they decide the nose goes.

What would be the impact? This is a viewer-only change, so only the viewer needs updating. And, assuming no animations were uploaded with the looping flag set to something other than 0 or 1, this will not break any existing content, or any re-uploaded content. No tools like avastar immediately break, but they can be updated at the creator's leisure to support this new animation style. The bvh importer could immediately take advantage of this flag by just presenting a checkbox in the upload, next to the looping checkbox.

I also posted this as a feature request jira: https://jira.secondlife.com/browse/BUG-20027