Jump to content

Project Bento Feedback Thread


Linden Lab
 Share

You are about to reply to a thread that has been inactive for 2280 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts


Cathy Foil wrote:

Hey Medhue,

I just has an idea that might make it easier or quicker for you to convert your original animations using the old Bento skeleton to the new one.

What if you open your animation in Blender and then import the new Bento skeleton and constrain it to the original Bento skeleton?  Once constrained you should then be able to export out the animation of the new skeleton.

Hopefully you only need to constrain the new skeleton to the old one once to be able to export out all your animations you made.

Hope that helps.
:)

Cathy

Maybe, but let's also remember many of us used Avastar, which has many skeletons to deal with all the different bone sets, and now you want to constrain a whole different Avastar skeleton to it. I have no doubt that it can work, but how confusing is that going to be dealing with it all in the end? Then, if I need to make more animations, I can't use the latest version, as it is constrained to the old version, so now I'm constantly animating on the old version, and hoping I don't have any problems, because figuring out which rig is causing the problem would become a nightmare. I like to keep as clean a file as I can so that I can understand it all later.

Plus, let's hope we all never have to update this Bento rig again, lol.

Link to comment
Share on other sites

This general idea has already been submitted as a JIRA "suggestion" which has actually been accepted as well~

 

If you have access to the JIRA system here it is : https://jira.secondlife.com/browse/BUG-10980

 

The "Accepted" Status of the JIRA means it's an idea they're willing to consider and possibly implement.  This is NOT a project Bento extension but rather a "what comes after Bento ( maybe ) project~  that may or may not go forward.  That being said, Vir seemed to express great interest in it when it was pitched at the very early bento meetings.  ( Note the creation date of said JIRA issue ).

 

As always, no promises.  If you've got some further ideas on how to tweak or improve the proposal~ please do comment on said JIRA~~

Link to comment
Share on other sites


Cathy Foil wrote:


You can disable the translation affect on a face bone by any Slider by moving any bone associated with that slider to a custom position and uploading your mesh with "Include Joint Positions".  Now if a slider has scaling on it the scaling will
not
be disabled.

The Jaw Angle slider is a good example.  Currently the mFaceJaw moves way up and down when adjusting that slider.

If you wanted to disable that and have the mFaceJaw bone set so it stays in the same place disabling that slider you just slightly move the mFaceJaw bone to a new location.  Rig you mesh to it and upload your DAE with "Include Joint Positions".

 

Mel, Matrice, Vir and myself have been discussing ways and options to fix the Jaw Angle slider so the mFaceJaw bone doesn't have to move up and down.

Hope that helps.
:)

Cathy

Yeah that helped thanks! :smileyhappy:

Link to comment
Share on other sites

So I got a question... I've been experimenting with a mesh head and exporting some animations that use only Rotation, and a few that also use Location. When I play the ones with Location in world, they do screw up how the mesh looks(which is understandable from all I've read here), but then when I play an animation that only uses Rotation after it, the bones which were translated stay in place...I can't seem to get them to revert back unless I play another animation with translation.

So I'm unsure how to use both types of animations? Or are you just supposed to choose one or the other? This is on a mesh that only has skin weights imported into SL, not joint positions.

Link to comment
Share on other sites

I see the most recent hover-height related changes have been pulled in to the Bento viewer (previously having been confined to the Test viewer).

I'm going to say it now - the treatment of animations and camera position is undesirable.

- Attaching the camera to the z-offset of the avatar introduces significant vertical camera movement for avatars which move up and down (say for example breathing or walking animations for quads)

For example: https://i.gyazo.com/61c9a9628a5e0d16fc136382b7a9ed99.gif < i get nauseous looking at this from afar for a few seconds, let alone right up in front of a screen for extended periods. 

- The change in animation handling is now just pushing the avatar up and down and not handling movement and positions in the hind limbs. Whereas hind feet would rest properly on the ground where they were animated, now they just get pushed in to the ground and do not bend according to the loc/rot set out in the animation. 

Link to comment
Share on other sites


Krystal Silverweb wrote:

So I got a question... I've been experimenting with a mesh head and exporting some animations that use only Rotation, and a few that also use Location. When I play the ones with Location in world, they do screw up how the mesh looks(which is understandable from all I've read here), but then when I play an animation that only uses Rotation after it, the bones which were translated stay in place...I can't seem to get them to revert back unless I play another animation with translation.

So I'm unsure how to use both types of animations? Or are you just supposed to choose one or the other? This is on a mesh that only has skin weights imported into SL, not joint positions.

What you need is an underlying animation with a lower priority that is always playing in the background.

Link to comment
Share on other sites

  • Lindens

The latest Bento Project Viewer, with the final skeleton/slider values, has been released. You should get it automatically if you log in with a previous project viewer. The updated skeleton information has also been pushed to the main grid and most of aditi, so you should be able to upload content based on the latest skeleton.

The testing page at https://wiki.secondlife.com/wiki/Project_Bento_Testing has some updated collada files consistent with the latest skeleton. Some other files on that page will still need to be updated.

Link to comment
Share on other sites

 

Medhue Simoni wrote



What you need is an underlying animation with a lower priority that is always playing in the background.


 

Thanks, ok, so you need to always have an animation with translation playing, if you want the other translate ones to work so bones will go back to their default locations.

So, after doing my bit of testing, I think I would have to stick with rotation only animations-which because of the new changes(thanks everyone!), I'm able to make a bunch of basic facial expressions look pretty good! The only thing I can't do is move the tongue out of the mouth, but I don't think that's a biggie.... I do think people will like the ability to customize the face as much as possible, and won't miss the few animations needing translate so much.

Link to comment
Share on other sites

Hi Vir and all Bento developers.

It's great to see the SL community working alongside Linden Lab so well in the development of Bento.

This is just a quick reminder to please think about including compatibility support for the old facial animations by adding a script call like llSetAnimationOverride().

The legacy facial animations are among those listed here. And I'm sure our avatars have all pulled our fair share of those faces in SL using them. These expressions are used in the gestures found in the standard avatar Library, and they are also used widely in resident-made gestures and scripted content such as furniture and avatar accessories.

The main advantages of overrides for the old facial expressions are:

* Bento avatars can be made to work with existing content that makes use of facial expressions.

* Creators can continue to use the legacy names list of facial expressions, and it will act as a starting point for further standards to be developed and adopted by the community.

For testing purposes, the "legacy" facial expression HUD is still available here.

I'm unable to attend the meetings due to time-zone issues. It would be great to know if/when this idea is being considered :)

Link to comment
Share on other sites

  • Lindens

We would like to have a more complete mechanism for animation overrides; unfortunately this looks to be a large enough project that it wouldn't fit within the scope for Bento. The current override mechanism is implemented on the server side and works with the management of locomotion state (walking/running/flying etc), so extending it to work with arbitrary animations that are not part of locomtion would entail a fair amount of new work.

The proposal is currently on the list of possible post-Bento projects. As always we can't make promises about future projects, but I hope we will be able to address it at some point.

Link to comment
Share on other sites


Vir Linden wrote:

We would like to have a more complete mechanism for animation overrides; unfortunately this looks to be a large enough project that it wouldn't fit within the scope for Bento. The current override mechanism is implemented on the server side and works with the management of locomotion state (walking/running/flying etc), so extending it to work with arbitrary animations that are not part of locomtion would entail a fair amount of new work.

The proposal is currently on the list of possible post-Bento projects. As always we can't make promises about future projects, but I hope we will be able to address it at some point.

That sounds great Vir. I agree that overrides should not slow down completing the Bento avatar. However I do urge your team to look at it as soon as possible, because early availability of overrides would be important for making avatars backward compatible with existing content from the start. As Bento does so much to enhance facial expressions, it would seem a waste for it to just ignore the legacy facial expression framework used for so many years in SL.

 

Avatar creators please think about how your creations will interact with furniture and attachments, when it comes to facial expressions. So that when someone passes your avatar an ice cream its mesh head will know what to do! As facial animations will be triggered by scripts, perhaps often by external triggers, consistent naming will be important. So I suggest you use the legacy facial expression names as a base. That is: express_laugh_emote, express_bored_emote, express_cry_emote, etc.

Have fun :)

 

 

 

Link to comment
Share on other sites

mFaceJaw is there and very alive.

If you refer to Avastar then you need to know about a recently added change:

By default Avastar exports only the bones which are used for weighting in at least one of the exported meshes. We have moved the weights from the jaw bone to the jaw shaper bone some days ago (in our default models). Consequently new exported meshes possibly do not include the jaw bone (by default).

The Collada exporter has options to enforce the export of all animation bones including those which are not used on the exported meshes:

Open the advanced export options. The provided tool tips should be self explaining. If they are not, then please complain !

Link to comment
Share on other sites


Mel Vanbeeck wrote:

That file is clearly very messed up.

Can you give more details about where the file is clearly messed up?

The Jaw Bone is missing in the files that we created on 12 july because the collada exporter dropped all bones which are not used for weighting. This is an intentional optimization to only provide the used bones. This optimization was discussed in the bento meetings a couple of months ago (allow partial rigs). I do not see where the collada files are messed up.

The files from 15 july have been exported with the "include all animation bones" option and the jaw bone is again available in the dae (although it is not used for weighting the models)

Link to comment
Share on other sites

I recognize I'm late to the party, but this is clearly a step in the right direction to add more possibilities.
I'm not sure it's entirely on topic, but it's about how I think skeletons should progress, so I think it's on topic enough.

However I would propose that you make it possible to add a completely custom skeleton (mayhaps after this project is done).
This will suit everyone's needs, regardless of what it is.
There should be a list of standard joint and bone names or IDs that current animations and meshes will map to. But in addition to these, you could make whatever you want.
Attachment points would be added to the skeleton by the designer and the viewer would download the skeleton information and dynamically change its attachments support accordingly.
The current attachment points have their standard names and locations, but other can be added as well and scripts functions will return those names based on the custom skeleton. If an attachment point can be targeted by a function, it returns a -1 if it doesn't find it.

In addition to that, please make it possible to rez skeletons inworld and dress them up with objects and animate them as you would an avatar.
The skeleton object would have folders in its contents window for each of the attachment points and objects dropped in those folders are automatically worn and can be edited as a linked object as if it was worn on your avatar. Remove the object from the folder and it is removed from the skeleton object.

And lastly, higher capacity for simultaneous attachments or a way to faux-link objects so that they are still their own objects, but are linked together so that they can be put on as a single object on an attachment point. But they still retain their own local link numbers. It's getting hard to wear modern complex avatars and add accessories to them due to the low capacity.

Link to comment
Share on other sites

Vir - As we discussed weeks ago, it does seem like something isn't right with the Reset Skeleton option.

This is what happens when I use it on the latest version of my Coyot avatar.

 

This is very problematic, especially after I tested the default human skeleton. Not using translation on bones is crucial to getting as many sliders to work as possible. If the skeleton never holds it's initial joint positions tho, then animations with bone positions is the only way to fix it, which will destroy many of the slider options. As I've shown, we can still have some customization, but unless this is fixed, avatars using unique joint positions will be less customizable.

To me, it looks like some of the bones, primarily in the head, are reverting back to the positions of the default skeleton.

 

Edited:

It seems to be only a few bones, so most of the customization will still be there. That said, still should be fixed.

Link to comment
Share on other sites


Himechan wrote:

I recognize I'm late to the party, but this is clearly a step in the right direction to add more possibilities.

I'm not sure it's entirely on topic, but it's about how I think skeletons should progress, so I think it's on topic enough.

 

However I would propose that you make it possible to add a completely custom skeleton (mayhaps after this project is done).

This will suit everyone's needs, regardless of what it is.

There should be a list of standard joint and bone names or IDs that current animations and meshes will map to. But in addition to these, you could make whatever you want.

Attachment points would be added to the skeleton by the designer and the viewer would download the skeleton information and dynamically change its attachments support accordingly.

The current attachment points have their standard names and locations, but other can be added as well and scripts functions will return those names based on the custom skeleton. If an attachment point can be targeted by a function, it returns a -1 if it doesn't find it.

 

In addition to that, please make it possible to rez skeletons inworld and dress them up with objects and animate them as you would an avatar.

The skeleton object would have folders in its contents window for each of the attachment points and objects dropped in those folders are automatically worn and can be edited as a linked object as if it was worn on your avatar. Remove the object from the folder and it is removed from the skeleton object.

 

And lastly, higher capacity for simultaneous attachments or a way to faux-link objects so that they are still their own objects, but are linked together so that they can be put on as a single object on an attachment point. But they still retain their own local link numbers. It's getting hard to wear modern complex avatars and add accessories to them due to the low capacity.

Sadly, while at the base level this suggestion seems fine, even helpful, there's multiple reasons why this isn't a good idea. First and foremost, many creators aren't well versed on optimization and would likely add way more bones than are needed, causing unnecissary strain to many people's already struggling computers and internet connections.

Another very big issue is that many people would create their own custom skeletons for everything, removing the animation compatability that's so integral to have between mesh avatar creators and stand-alone animation creators, not only frustrating people who didn't know or didn't understand that a custom skeleton was being used, but also potentially tanking businesses and forcing people to use only compatible animations created for whatever specific avatar they're using. With the introduction of custom skeletons, where would be the incentive to use the system skeleton anymore, if you could make more money for yourself by not using it?

Lastly, the system handling the skeleton and animations would likely have to have major recoding done to allow a custom skeleton to be used at all. Sliders wouldn't be compatible at all no matter what, because as I understand it, the sliders are tied to specific bones.

The introduction of Bento will be plenty. People have worked around the system skeleton for as long as it's been around, and with this it'll be much easier to do, well, everything. There won't have to be 10 different meshes layered on ton of each other to create different expressions, there will be less intense scripting and alpha face-switching "animation" which will take a load off the server.

Link to comment
Share on other sites

Well.. I can't really agree with you.
You're basically saying "People are stupid and because of that, it's a bad idea".
The same issues you're mentioning are there for mesh as well.
People may create mesh that's not perfect, they may use their own mesh avatars instead of the standard avatar and people may get confused about it.

As you do with mesh nowadays, you include a note in the product that it's a custom skeleton, include an optional note what bones it has.
There is a very large incentive for using the standard skeleton because most of the products will be using that skeleton. If you're creating a human avatar, there's no point in making your own skeleton for it as there's already one and if you create your own skeleton, you run the risk of people not buying it because of compatibility issues.
The point with a custom skeleton is to be able to make custom style avatars or, in the case where you can rez them, custom style animated objects, like a car for example.
And if you use the same named / IDs of the bones as the standard skeleton, anything that works for the standard skeleton will also automatically work for your skeleton as it's mapped the same way.
I don't think "people are stupid" is a very valid argument.
People will want to create optimized and compatible products in order to be able to sell them to a broader audience. Where this cannot be applied, because their ideas are too outside the box, then a custom skeleton works wonders.

Skeleton A will work just the same as skeleton B. Animating one skeleton isn't different from animating another, mechanically. It just requires support for dynamically changing what skeleton is used for what avatar.
The slider limits will be set by the designer of the skeleton and a created shape will hold the information about the shape for the skeleton it was designed for. Basically it's about dynamic data size as opposed to static data size. Dynamic data size is a little less efficient than static, but it doesn't matter that much for today's processors. Or you can simply limit the amount of bones to a certain number and then have every skeleton be that number of bones if you require static data size.

Bento is an improvement, but needless to say, it has it's limitations. You can't have a finger with 4 bones, should you want that. You can't have 2 heads and 2 necks. You can't put wings on your legs or your head. And you can't make a car (well.. you might be able to, but you'll have 1000 extra bones and you won't necessarily get the exact structure you want)

So while I understand this won't happen tomorrow, I definitely think that this is something to work towards in the future. And frankly, it shouldn't be that hard. Would probably require around the same work as creating a new hardcoded skeleton and support for it, but instead of making everything static, you make it dynamic.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2280 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...