Project Bento Feedback Thread

[Cathy Foil]

An interesting experiment would be, since we can move the bones around with animations using translations,  to move mChest bone and animate it to follow the head bone but not animate the left and right pec bones.  In theory one could then turn on breast physics and have ponytails or hair that would bounce around the head.

Might be interesting to apply physics to the tail bones but I doubt we have enough time to do it in Bento.  It would probably have to be a separate project.

[Medhue Simoni]

A few times last week, and now today, I've logged onto Aditi and I can do almost nothing with my avatar. How exactly are we suppose to create things, and test things, when the grid is unstable? We also get no warnings about these problems, and no confirmation that the grid is working again, as it should. See photo below. I'm obviously supposed to be a mesh avatar, not a greyed out default.

[Medhue Simoni]

I also contacted live support, which informed me that they can do nothing, not even restart the region I'm testing on. Not only that, but there is no path to getting a region restarted on Aditi. So, we're just SOL, until some1 higher up figures out the grid is borked.

[mikka Luik]

Not sure if this is related but as of today had a string of 'failed to find item in database' on logging in to Aditi, both on lates LL Viewer and Kokua, both with cache cleared and no Main Grid (Agni) log in between (as there have been similar problems before).

No amount of attempting to reclothe worked, finally had to resort to the last Singularity main release to get dressed...

Not sure if its caused by the new synch feature or the coming changes to how inv is handled?

 

 

[Medhue Simoni]

Looks like things are fixed now.

[Cathy Foil]

Aditi back up and running normally.

[Kitsune Shan]

The suggestion I did some time ago was directed to how bones with different offsets behave with animations. It was only aimed to translation and was a simple math form. I am not programmer but you can do similar math forms inside of 3D Max through script commands to allow wider rig customization and different effects which make me guess that should work on any environment like in SL. That suggestion only would fix certain animations. Right now, face animations cant work with deforming bones. There is simply no way to do so. We may have to renunce to bones deforming mesh shape. It would be nice top have both but right now seems impossible. I cant think in any way of having animations behave different depending of the offset in something so complex as a face because you wont only animation with translations but with rotations too. And I dont think there is any method to make SL predict certain animation based in certain offset to apply the proper scale. We can only do that through translations but not all together. If bones could deform the mesh shapes only through bone scale then we may have a chance but then the deformations wouldnt be any good at all.

So, basically, we may want to discard bones deforming face shapes in favor of being able to animate them. The most we can keep its the three base bones for each face bone group that act as root and allow for small adjustments which to me would be nearly the same as not being able to change anything at all. Another solution could be to allow the creator to choose wether their mesh should deform or not at time to upload but I dont see this implemented by LL at all.

[Medhue Simoni]

---

Kitsune Shan wrote:

So, basically, we may want to discard bones deforming face shapes in favor of being able to animate them. The most we can keep its the three base bones for each face bone group that act as root and allow for small adjustments which to me would be nearly the same as not being able to change anything at all.

---

Currently, there are a number of face sliders that work, with or without face animations. Of course, not all of the sliders will work, but it is definitely more than I ever expected to have when Bento started. Add Fitted Mesh to the mix, and I think the consumer has many options to play with. The only part that bothers me, is that the user doesn't know right off the bat which sliders will work. So, I wish there was some easy way for the user to know this. Heck, I might have to make videos for every avatar, just to show which sliders the user can adjust. Me, I'm happy we have the options, and that LL decided to push it this far.

[Vir Linden]

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.

[Teager]

Vir, I think that's a great idea.

 

 

Sorry I've been out all week - we've sort of been in crisis flood mode down here. I just got caught up on last week's meeting, and can confirm that constraining bones in the sl skeleton to a secondary skeleton for ease of animating nonstandard bone structures does work as long as all animations include translations. This has been my standard way of working for the last 2 years on all avatars that I make. Since I work entirely with nonhuman avatars, I have a tendency to need bones where there aren't bones, and I find this method easiest.

I would add that using a deform animation is a must when working this way - without it, the avatar will be likely to explode momentarily between animations from your animation overrider, or when a new user loads your avatar. If you script a very low priority deform animation to play every 10 or 20 seconds, it will catch any deformities and fix you for new users logging in or entering the sim at any given time.

This is, however, based on the assumption that a background animation is added to the sl viewer for all of the new bones, which I still believe it should be. Without a background animation, bones moved to irregular positions will stay in their irregular positions, which would benefit the relatively small number of users who will rig and animate this way, but will also mean that for the greater number of users who choose to rely on the default bone positions, any animation played on new bones will get stuck in place. For example, if I were to play a single frame animation for a shocked face pose, to take a picture with, my face would stay shocked after I stop the animation, until relog or until I play another animation to put my face back in the default position. By that logic, you would be requiring either (1) every animation to "unanimate" itself back to the default position on the last frame, or (2) every creator of a face/hands/tail/whatever to include a background deform animation, even for meshes using the standard bone locations. If a default position is added to the sl background AO, my face would reset itself naturally without any extra expectations on the mesh makers or animators.

[Medhue Simoni]

Seems reasonable to me.:smileyhappy:

[Gael Streeter]

This seems a good solution indeed.

Perhaps this check could be done at the import time instead of the loading time to avoid any "existing content break" ?

One point of concern may be the accuracy of this check... What will be the precision of it ? Will all the tools like Avastar be able to follow these new rules precisely ?

[Vir Linden]

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.

[Kitsune Shan]

Could we get some way to debug if joints offset are being detected and where? A simple info window that lists all the bones with joints offset detected would be a must have. Otherwise we may not be able to, later on, find wether certain bone have been locked or not. This is specially important as working with different softwares and exporters often gives different measures. The change on the UI would be totally minimal and could be added to Advanced or Develop menus as a setting called something similar to "joints check" where, after loading a mesh on the uploader and checking joints offset, would display a simple list of all bones displaying in green those with the default original offset and in red those that have been modified and joints offset will be locked and applied.

[MoonHowler Snowpaw]

Vir please test also on a tiny scaled avatar, check that the precision is small enough to not deform some tinies faces in future.

[Medhue Simoni]

---

Teager wrote:

This is, however, based on the assumption that a background animation is added to the sl viewer for all of the new bones, which I still believe it should be. Without a background animation, bones moved to irregular positions will stay in their irregular positions, which would benefit the relatively small number of users who will rig and animate this way, but will also mean that for the greater number of users who choose to rely on the default bone positions, any animation played on new bones will get stuck in place. For example, if I were to play a single frame animation for a shocked face pose, to take a picture with, my face would stay shocked after I stop the animation, until relog or until I play another animation to put my face back in the default position. By that logic, you would be requiring either (1) every animation to "unanimate" itself back to the default position on the last frame, or (2) every creator of a face/hands/tail/whatever to include a background deform animation, even for meshes using the standard bone locations. If a default position is added to the sl background AO, my face would reset itself naturally without any extra expectations on the mesh makers or animators.

---

I'm of 2 minds thinking about this, and the reason is because of these slider bones. Without the slider bones tho, there is no need for some kind of default, because this is already inherent in the SL animation system. The stand animation serves this purpose, as the system always comes back to the stand animation, or if you are flying it's the hover animation, and similarly with the swim animations you have the floating animation.

All that said, there are 2 issues with this. The first is that if you set a face animation as the default stand with SetAnimationOverride, it will override the whole skeleton, even the body's animation. Currently, this is not so much an issue with the current AO systems being used, as most aren't using the SetAnimationOverride function.

The 2nd issue is directly related to the slider bones. I saw some of this when I rigged my wolf's teeth to the Teethbones. When I uploaded the wolf, the teeth were offset, as I had no animation to set the position of the teeth, and I can't add 1 because it will reset any offset created by the sliders. It seems to me, that the problem is that the mesh itself isn't holding onto it's initial joint positions. So......, what I think is needed, is a default joint position that takes into consideration the initial joint positions, and the sliders, and created by the system itself, not us. This should really be a very low priority animation that is playing all the time, and within the server or viewer code.

[Teager]

---

Medhue Simoni wrote:

---

So......, what I think is needed, is a default joint position that takes into consideration the initial joint positions, and the sliders, and created by the system itself, not us. This should really be a very low priority animation that is playing all the time, and within the server or viewer code.

---

This is exactly what I was advocating above. Currently the background stand animation inherent to sl (last I checked) still didn't do anything with any of the new bones. I was saying that it should. The new bones should, at minimum, have a low priority animation with 0 rotation applied, playing at all times. 

[Medhue Simoni]

Here's another example of what is possible with the Bento Project.

 

[Lee McKay]

I want to drop in a topic that I discussed with Cathy Foil recently regarding the mGroin bone.  This bone was supposed to have been linked to the "Coin Purse" slider in Edit Shape.  It was discussed at meeting(s) and then it was overlooked.  This needs to be fixed before Bento is released. It will help those who create clothing for men (Yes, Virginia, they exist) to make bulges that the wearer can customize rather than being limited to either poorly designed (flat-fronted) pants, etc.  This is not a simple thing that should be brushed aside and ignored just because it's late in the game. It's a simple fix and it is both needed and wanted by designers.

[miguelectronique]

As a men's designer I also agree that the inclusion of the men's groin bone associated with the coinpurse slider will allow my client's more expression in how they chose to wear my designs. I try to sculpt something flattering to fill out the shorts, pants, undies and the like but for those who want a little more - or those who are a bit more modest- this would be a great addition to the Bento skeleton. Please don't over look the growing population of menswear designers and limit their options due to this oversight. 

[Gaia Clary]

Hi, Medhue;

One of the reasons why Avastar has duplicated the blue SL Skeleton into the green Control Skeleton was for reusing the control rig to animate the SL Bones in which way ever we want. This includes the restructuring of the control bone hierarchy.

However at the moment a reorganisation of the control rig has become a bit tedious because of the IK constraints all over the place. Do you think it is beneficial to simplify the customizing of the control rig so that hierarchie changes become easier? Would this avoid the need for an external animation rig?

[Medhue Simoni]

---

Gaia Clary wrote:

Hi, Medhue;

Do you think it is beneficial to simplify the customizing of the control rig so that hierarchie changes become easier? Would this avoid the need for an external animation rig?

---

The elephant trunk is 1 good example, and originally it was a snake avatar that brought up the use of an external rig. If you think that both of these can be done and animated easily without an external rig, I'd love to see it. I might even kiss your feet.

[Medhue Simoni]

Oh, and while we are talking about this, I might as well add in some comments about my adventures animating the nunchakus, as it might be useful in making Avastar better. I mean, Avastar is awesome, but nothing stands still, and I can kind of envision what you are talking about, as the bones are all there to do as you please with. It's just about how the best and easiest way to do it.

In the case of my nunchakus, it would be handy to be able to quickly attach/parent bones together at will, as in 1 frame they are parented and the next frame they aren't parented, and the next frame they are parented to another bone. I chose the nunchakus to do, not just because they are cool and I'm an expert user of them, lol, but because they have this unique need to switch hands. This could be useful for a number of things, not just weapons like this. Imagine dribbling a basketball.

You also talked about baking animation, and how the the exporter works, or something about that. I just want to say that I always feel the need to never bake animations until I have to, so the animations are always in a perpetual editing stage, and this way I can always comeback to it. If that makes any sense. I just never need to bake animations, nor want to. Keeping things in the prebake stage gives me a clean set of keyframes to look at, and easily see how and when bones are interacting. Or maybe I don't understand what you were saying.

[Dobby Meskin]

As a designer this would be a great addtion to the male commmunity, would allow for so much more creativeness. Please consider this. Often the male communty is the least thought of in secondlife.

[Dobby Meskin]

this would be a great benefit for the male communtiy, would allow for us to be even more creative with things...... Often the male community is the last to be thought of..... Please reconsider this