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!

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.

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.

Aki, I'm not sure if it's currently documented anywhere. Hopefully we can add it at some point. The list (source code in LLAvatarAppearance::computeBodySize()) is: mSkull mHead mNeck mChest mTorso mHipLeft mKneeLeft mAnkleLeft mFootLeft Changes to position or scale can affect the calculation, although it doesn't get recomputed extremely often - mostly changes to attachments or appearance updates (triggered by outfit/slider changes) would trigger an update. I don't think that just animating those joints is going to cause a lot of problems in normal practice, but it is something to be aware of.

Another area where we've had some discussion recently is the desire to override slider behavior. Depending on what kind of avatar or accessory you are making, the sliders based on mostly-human shapes with bones in the default locations may or may not make sense. We can partially override sliders by using joint positions - any bone that has a position defined by an attached mesh will not have its position altered by sliders. However, this is only a partial solution, because sliders can also affect joint scales, and there is currently no way to prevent those effects. So a proposed solution is to allow a mesh to include "joint scales" along with "joint positions" - whenever a scale was defined, it would override the scale effects from sliders. This would make it easier to model avatars that are not shaped enough like a default human for the human-oriented sliders to work well, and would also make it easier to repurpose some bones for other things. We've done some proof-of-concept testing to show that it is feasible to do scale overrides in the viewer. The main open question is how these would be implemented in the imported collada files. There would need to be a way for tools like Blender and Maya to add the appropriate scale information when the model is being created, as well as support for this mechanism in any add-ons based on those tools. We'll continue looking into this, and in the meantime please let us know if you have any ideas on the best way to add this sort of support to collada files.

No, that's not expected. My suspicion is that the model you're starting with may already have some position changes for the bones, so you're getting offsets applied even where you didn't make any intentional changes.

Hi folks, As noted in the user group page (http://wiki.secondlife.com/wiki/Bento_User_Group), there is no user group meeting today. Wanted to give you a brief summary of where we are on Bento development. There should be a Bento project viewer update coming in the next few days. Changes to look for in this update are: Fix for a case where some meshes, when rendered with hardware skinning on some machines, would display a spike shooting across the region. Fix for a longstanding issue where some sliders caused the right breast volume to move in the wrong direction. Fix for the avatar height glitch on blink (this could manifest under other circumstances too). Generally we're trying to be smarter about when to update the avatar body size. Note that animating any of the joint positions used for height calculations can still trigger updates to body size, but you should see fewer such changes with this fix. Fix for wing positioning issues when avatar shape switches from female to male. Some topics from last week's meeting: Raising the animation size limit. This is definitely happening at some point, but schedule is still to be determined; has some dependencies on other projects. Discussion of making it easier for mesh hands to be animated consistently with system avatar (morph based) animations. Nothing new on this one so far. Teager reported some issues with feet positioning and intermittent animation issues with her horse model. I've done a bit of testing with a copy of the model but am having a hard time seeing the same issues. It would help to have more specifics on exactly what to watch for (for example, when should we expect that a particular animation is playing). Aki - wyvern jumping up and down when it blinks. This should be fixed in the next project viewer update. llSetAnimationOverride() - can it be applied to expressions? Needs more investigation, may be beyond the scope of the initial Bento release. Report of some kind of issue with materials editing. I doubt this is specific to Bento, but we would need a bug report with specific steps to reproduce the problem. Nalates, you mentioned an issue with clipping and sent a couple of snapshots. Unfortunately they're low res enough that I'm having a hard time seeing the issue. May be a known issue with bounding box calculations. Sorry if I missed anyone, and feel free to raise other questions in this thread. Otherwise, will see you next week.

Hi Siddean, Right, there is a potential for joint offsets to affect the behavior of sliders. Generally the order of precedence for joint operations is: Initial bone locations Effects from sliders Effects from joint position offsets (defined in mesh attachments) Animations Where later things in the list will override earlier things. If you define a joint position for a bone in an attached mesh, then that will override any effects on position from the sliders. Note that you can define joint positions for some bones but not others - even if you check "joint positions" on import, any bones that are still in the default position (as defined by the skeleton) will not have a joint position applied for them and will still respond to sliders.

Thanks for pointing that one out! It looks like an issue that's been there a while (not specific to Bento), but this would be a good time to fix it since we're working on those parts of the system anyway. We have a fix for this, should be in the next project viewer update.

I think blender files are on the way at some point - will link them when we have them. Not sure whether anyone is doing avatar work with poser these days, but if anyone has something to share, please let us know!

Re: the desire to create attachments that are rigged to bento bones (possibly in non-standard positions), without being affected by scale effects from the sliders: What if we extended the notion of position overrides in mesh models to also allow for scale overrides? This would be an additional checkbox in model upload, where some information in the dae would be used to determine a scale override (but only if the checkbox was also checked). If a scale override was present for a joint, this would prevent any scale effects from the sliders on that joint. I'm not sure how feasible this change would be, or whether it would fit in the bento schedule, but if it is possible, would it be a good solution to the problem? (Note that this is separate from the discussion about adding more sliders to help with customization of limbs and such, because the goal here is to create an accessory that will work with a range of pre-existing avatars, where the creator of the accessory does not have access to modify the avatar's shape.)

Thanks for the additional info! Tracing through this in the debugger, it looks like some change related to the blink is causing a bunch of recalculations to take place for updating the geometry. Ultimately one of the effects of the updates is to update the body size calculation. So it's likely that the actual change to the joint positions took place earlier (presumably from some other animation), but the effect wasn't immediately visible because the body size didn't get updated right away. If this is all correct, there are a couple of possible routes to go here: 1) Be careful about animations that affect the positions of the chain of joints used for body size calculations (note that unless you need to change the shape of wyvern, you should be able to use rotations instead, and rotations won't have any effect on the height calculation). 2) Minimize the use of changes that trigger geometry updates - for example, if the eye blink was implemented using an animation of the eyelid bones, you probably wouldn't see the same behavior. Neither of these is a really great solution for the problem, but they are things that could be done now on the content side. The underlying issue is that the height calculation was designed for upright humanoids at a time when animation of positions was not allowed, so it's not playing nicely with the current system. We'll have to do some more digging to see if there's a reasonable solution on the viewer code side.

Hi Aki, It looks like what's going on with the blink/height glitch may be that one of the bones that contributes to the avatar height calculation is changing position. You can see this by going into Advanced->Show Debug Settings and setting DebugAvatarAppearanceMessage to true. You will see a line of text above your avatar with a bunch of fields - one of these fields is bsz-z, that is, the z-componenent of the avatar body size. In the case of the wyvern, it looks like every blink also triggers a change in this value. Since the body size calculation works with the logic for maintaining ground contact, a change here can trigger a vertical movement of the avatar. The body size is computed using the position and scale of a chain of joints from the left foot to the head: mPelvis, mSkull, mChest, mHead, mTorso, mHipLeft, mKneeLeft, mAnkeLeft, and mFootLeft. Is it possible that the blink animation is causing a change in one of these joints?

Hi Mikki, Right, all of that should be true. For example, you should be able to make a rigged wing attachment that could be added to a system avatar to give them flapping wings, or an animated pet attachment using some of the extra bones that could accompany any avatar. The main thing to watch out for is that each attachment only touches the joints it needs, and that they don't conflict with each other. For example, if the wings and the animated pet were both trying to use the wing bones, you would get a huge mess if you tried to wear them both together.

Hi Teager, Disregarding questions of scope, could you clarify how these would work? The idea is you have a set of scale controls for each limb chain, and every bone in the chain gets scaled by that amount? Would this be in addition to the scale effects already present in the sliders, or would we remove those? If I'm understanding this right, I'm not sure this would help with Tyrian's case - it sounds like the desire there is to create accessories that would work with a range of existing avatars, without requiring access to the shape.

Hi Tyrian, That's an interesting point about scale changes with some bones. What's going on there is that scale changes are being applied to the hind limbs in order to keep them matched up with the front limbs, to handle cases like a centaur model where you want the legs to match up. You can prevent the bone positions from being changed by applying a position override in the mesh, but there is currently no comparable way to prevent scale changes. Perhaps we should also be preventing slider scale changes for bones that have position overrides defined? Usually that sort of change would break the expected behavior for some people, but I'm not sure how useful scale effects are if decoupled from position effects.

Contrary to what I think we said last week, we will be having a Bento user group meeting this week. It's at the usual time, but a new location on Agni - details at http://wiki.secondlife.com/wiki/Bento_User_Group . Hope to see you all there!

There are male and female dae files just updated today with the latest skeleton - see the links under Models in http://wiki.secondlife.com/wiki/Project_Bento_Testing

Please see the announcement at https://community.secondlife.com/t5/Featured-News/Project-Bento-Testing-Is-Now-Live-on-the-Main-Grid/ba-p/3035460 and let us know how it goes!

The Bento Project Viewer has been updated - you should receive this automatically when you run the previous version. The main changes here are support for Reset Skeleton, which can be used to try to fix "crunched up" avatars. If you get a chance to try it out, please let us know how it works for you. There are also a few last-minute updates to the slider support for mesh avatars.

Hi Teager, No, we're not live yet. Should be soon, but we still need to get the project viewer update pushed out first, and a few documentation updates. Meeting today will be in our regular aditi location. When we do go live, you'll see an announcement in this thread, a blog post, fireworks, etc... we'll try to make sure no one misses it :-)

Sorry if that was unclear. There's no change with respect to our support of .anim and .bvh as file formats. I just meant that the script itself isn't an officially supported part of the viewer, so there may or may not be bug fixes or other future work on it. It would be useful mainly as a starting point for someone who was already interesting in writing python code to manipulate .anim files (for example, in a blender plugin). The read and write parts are basically python ports of the corresponding C++ code in LLKeyframeMotion::serialize and deserialize. Re: bvh files, the bento project viewer does allow position animations now, but we don't have any other changes in the pipeline. If you know of other issues with bvh upload please do file bugs against them.

At the last user group meeting, I mentioned that we had done some script work for .anim files during Project Bento. The code for this can be found at anim_tool.py This is just part of the viewer source tree in the Bento repo, so once Bento becomes the default viewer you will be able to find the latest version of the file in the viewer-release repo. The disclaimer here is that this is not documented and isn't likely to be officially supported. It's mainly something we put together for testing so we could make test animations for Bento. However, it should understand all the fields of .anim files, so if you want to write python code that reads or writes .anim files this might save you some time. Requirements: you'll need python 2.7 installed, with the lxml module for etree. You'll need a version of avatar_skeleton.xml and avatar_lad.xml, which you can get from any viewer install or viewer repo. An example usage would be: % python <path>/anim_tool.py --skel avatar_skeleton.xml --lad avatar_lad.xml --joints bone attachment_point --no_hud --rand_pos input_file.anim output_file.anim This would read the animation fille input_file.anim, and add a new random position track for every bone and attachment point it found in avatar_skeleton.xml/avatar_lad.xml. The result would be written to output_file.anim. no_hud tells it to skip the on-screen attachments so you don't scramble them too. You could run this using either the bento or pre-bento versions of the skeleton and lad files. If you wanted to make an animation that sort of reversed this one, you could use --reset_pos instead of --rand_pos. That would move all bones and attachment points back to the default position defined in avatar_skeleton.xml. (It's not a true reset because it would still clobber the effects of any sliders, but it would make your avatar look no longer scrambled.)

Hi Gael, Thanks for the slider suggestions. As I'm sure everyone is tired of hearing by now, we're trying to avoid further changes at this point, but will take a look if possible.

Hi MoonHowler, sorry I didn't see your question earlier. Re: ankle attachment points: it certainly seems like a reasonable thing to have. At this stage in Bento development we are trying to keep the skeleton stable and focus on bug fixes, though, so it's most likely something to be considered later (unlike some types of skeleton changes, this is the sort of thing that could be added without affecting existing content, so it's not a now-or-never feature)