The following notes and audio were taken from the weekly Bento User Group meeting, held on Thursday, March 3rd at 13:00 SLT on Aditi. For details on each meeting and the location, please refer to the Bento User Group wiki page.
Note that this update is not intended to offer a full transcript of the meeting, nor does it present the discussion points in chronological order. rather, it represents the core points of discussion to Project Bento, grouped together by subject matter were relevant / possible, together with any additional discussion on potential future projects the Lab might be willing to examine for possible adoption in the future.
Skeleton and Viewer Status
Bento viewer work is now focused on finalising the new skeleton, working on bug fixes and investigating hooking the new skeleton into the appearance sliders where is can be done.
It’s anticipated that there will not be any further significant changes to the bones within the skeleton, although there has been some discussion on adding a couple of extra bones into the “hind” limbs. Content creators are therefore being encouraged to develop new test models utilising the skeleton, as available in the current project viewer (version 220.127.116.111861 at the time of writing).
A couple of issues have come to light with the additional bones. In the first, the alternate eye bones weren’t quite lined up with the original eyes, and this is being fixed. There also appears to be some issues arising from the inclusion of additional spine bones, which is discussed below.
The Lab has been investigating the potential of modifying the appearance sliders (controlled through the avatar.LAD file). This means taking some of the sliders that are based on morphs which deform the default avatar, and allowing them to also be utilised by the Bento skeleton when an avatar mesh employing the skeleton is worn. This work looks “promising”, although the number of sliders means that it is unlikely all of them will be dual-purposed in this way. However, as a part of this work, the Lab will be addressing the slider bugs which have been reported against the latest Bento skeleton as well.
Vir discusses the current status with the Bento skeleton and project viewer
Some additional attachment points were added specifically for use with the new skeleton, and consideration is being given to adding some more (such as to the new “hind” limbs – which can be used for a variety of purposes other than “just” hind legs, as noted in my last update). Currently, no clear preference for extra attachment points has been expressed by content creators working on Bento. One group of suggested attach points put forward in the meeting was for rear left leg and rear right leg (upper and lower). rear hip, rear groin, rear left foot, rear right foot, and rear back (for rideable centaurs/saddles).
Responding to this Vir indicated some of these may already be possible, and that others such as those for the hind legs / back are hard to determine as the joints are repositionable,. The suggestion for catering to some of these bones might be to reposition existing attachment point to suit, or the possible inclusion of a new hip root attachment point for the “hind” bones root.
The question was also raised on whether attachment points are lag producing in the same way joints can be. Vir indicated that lag isn’t really an issue with attachment points on their own (although animating them can obviously add an overhead). However, there are other issues with regards to UI / menu management which can make additional attachment points a problem.
For example, there is only a single menu structure available for selecting an attachment point for an item directly from inventory. So the more attachment points added, the more unwieldy the menu gets. The same issue isn’t so apparent when attachment an object from in-world, where the code allows for sub-menus to be added.
Another limiting aspect with attachment points is that there is a hard limit on the total number of joints which can be used (thought to be 255). so if an attachment point was added to every bone, this would likely be exceeded, so things like an attachment point for every finger would probably be out of the question.
Work is continuing on issues of avatar deformation, but as yet there have been no major breakthroughs.
However, problems appea rto have arisen as a result of the new spine bones. In particular, quadruped avatars appear to “dip” their forelegs and shoulders forward when shifting between certain animations. The precise cause is unclear (this may not even be a new issue, just one that is exacerbated by the new bones), but it could be the result of an interpolation issues, an i-k (inverse kinematics issue) or even some issue relating to bipedal animations (a human avatar tends to lean into something like a walk, and this default movement might be affecting thing). However, the larger the quadruped avatar, the more pronounced the up-and-down motion of the forelegs seems to be.
This problem is further compounded by a problem whereby if the avatar mesh is animated while ignoring the spine bones, then the avatar can end up being distorted following something like a relog; the spine bones must be keyframed in order for the avatar mesh to remain correctly formed.
One possible explanation for this latter issue is that there might be a missing transform in the hierarchy data, such that the weights associated with a joint are skipped, together with any child joints, causing the model to collapse.
As it is, the model in question, animations, etc., are being passed to the Lab so that they can investigate and test things.
Other issues have also been seen with the additional spine bones, which might be down to order of use or correct alignment, as the method by which they have been implemented, in order to preserve backwards compatibility with the avatar skeleton, is complicated.
Dan Linden has been working on the issue with quadrupeds crossing their forelegs, which has become more noticeable as a result of the Bento project. Thinking is now swinging back to the idea that it is due to a viewer / simulator race condition occurring when the avatar is loading. However, it also appears that the new spine updates to the Bento skeleton may be further exacerbating the issue, as it can now be more consistently seen, possibly as a result of more bone positions having to be checked.
As it now appears the problem can be reproduced even when using llSetAnimation Override as well as with scripted AO systems, a request has been made to see if there is a way to completely stop any default animations from running server-side, so that further diagnostic tests can be run against both scripted AO calls and the use of llSetAnimationOverride in the hope that issues can be more cleanly and consistently reproduced and investigated.
Making Mesh Models More Efficient
One of the reasons Bento skeletons are expensive to render is due to the “onion” effect: mesh avatars often comprise multiple layers stacked together, each with tier own vertices, which are currently required to allow for wearing multiple layers of clothing (tattoo, underwear, etc). This means for example, that typical female mesh body currently averages somewhere between 50K – 193K Tris / 38K – 110K vertices – see here), which, if reduced, could greatly benefit rendering performance.
One suggestion put forward has been to “unwear” the default avatar (rather than masking it), which would allow the default system layers to be used with mesh avatars, removing the need for them to have the additional “onion” layers (see BUG-10980).
A further suggestion raised at the meeting would be to enable multiple UV sets to allow the layering of textures on a single mesh model, rather than having multiple models associated with the one avatar mesh.
The Lab are very aware of the issue of avatar loads on rendering, and in part are hoping that the new Avatar Complexity controls will both help to limit performance issues people are experiencing and also encourage content designers to try to further optimise their designs over time.
The BUG-10980 approach is also seen as something which could be adopted, although it does have some limitations vis. UV maps. However, this work would very much be something to follow Project Bento, if it is taken on at all (a decision has yet to be made).
OptimoMaximo raises the subject of mesh avatar complexity and the potential to reduce it (and other potential options for mesh in general)
Blend Shape / Shape Keys
OptimoMaximo asked about having blend shapes or shape keys for morphs / animations added to the mesh importer. While a lot of interest has been expressed for this by content creators, the overall scope of the work, which would likely require a considerable overhaul of the existing avatar infrastructure, means it sits well outside of Bento. The overall technical scale of the project, together with the likely time frames involved, also means it would have to be very carefully considered before the Lab gave any confirmation that they would be willing to attempt the work.
Adjusting Walking / Running Speed
While it is also outside the scope of Project Bento, a further request has been made to allow adjustments to be made to locomotive speeds of avatars – so that, for example, a wolf or tiger or other fast-running animal avatar can run faster than a human avatar. There is already a feature request for this capability, although how it would be implemented (either a scripted control to adjust the sever-side locomotion events or a viewer-side change, or possibly both to allow the fullest flexibility), where it to be taken up as a project, is open to question.
The next Bento User Group meeting will be Thursday, March 24th. There is no meeting on the 17th.