Project Bento Feedback Thread

[Gael Streeter]

I can confirm what Medhue said.

This is a very very old known bug :

When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load).
But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long incoherent moves. 
A nightmare for animators...

This optimization is fortunately not applied (or without bugs) on the .anim animations... ouffff

 

[Medhue Simoni]

---

Gael Streeter wrote:

This is a very very old known bug :

 

 

---

I really don't think it's a bug, but an LL feature. Personally, once I understood what was going on, I've never had an issue with it. If I did, I'd just lower my fps, and it would likely work fine.

[Brac Collins]

I don't understand the "secrecy" in such either. It's a poor choice by a business,while certain aspects are proprietary, not everything about an SL Avatar is total secret. They live in a world of fear, as other platforms approach their existing capabilities, while planning more for the VR platform and its associated hype.

From a marketing standpoint, this is too little too late and does nothing to reverse the negative trend line that Second Life has been riding for some time now. While these bone additions could possible be inclusions in "Project Sansar" would be the only feasible reason for such CLASSIFIED - ABOVE TOP SECRET type of mentality.

So this project is only being implemented to test the "frame rate" within Second Life platform, solicit solutions to their problems from the general community, and assist them in the "NEW PLATFORM" development.

 

[Teager]

At Sansar's announcement, it was stated by LL CEO Ebbe Altberg that it was his intention that Sansar should allow creators the ability to upload their own custom armatures - not only for avatars but for objects as well. I'm hoping that's still the case when Sansar launches to the public. If so, adding new bones to the sl skeleton is fairly useless for Sansar purposes, but could at least assist those of us creators who will inevitably be creating on both platforms by increasing the capabilities of avatars made for use in both grids, so that our Second Life content isn't hopelessly behind the times in terms of quality and function compared to content made specifically for Sansar.

[Kitsune Shan]

Free avastar would indeed help but I really wouldn't mind paying for it to be honest. 

I have once played with it but couldn't do too much as I am 3d max user. The main problem I found on avastar is that I wasn't able to import my own avatar as dae or FBX and export anim files. Only making an avastar entity allowed me to do such task. I know it may be possible to retarget and export but it makes a bit tedious something that should be easier. Could be possible an animation exporter that allows you to export whatever animated mesh you import? Because then people that uses others softwares for modelling and animation could simply use avastar as exporting animations softwares. 

It seems that some people misunderstood what I meant by using blender for animations. I never said that is bad or that it lacks features for said task. But it's very clear that isn't an easy task to animate there. Let's say that isn't so user friendly. For example, knowing 3d max, I can pretty much manage any software like Maya and cinema without too much hassle but blender is always a different whole thing. 

The main objective with dae animations support would be to make it easier and open to everyone and every software out there. Dae files, as you know, are simple xml files. To do an anim conversion internally from a dae skeleton shouldn't be an issue. Who would know better anim files than LL? An alternative could be bvh files but that's the thing. All key frames are stored, this have good and bad things. Bad things is how file size quickly increase and SL have a limit that, despite of being doubled recently, it will not be that big once you try to upload 200 bones animations with translations and rotations. I'm afraid that SL optimization system may kill too much quality. It have the good side of having fidelity but since it's killed in the optimization process, I'm not sure if compensates. Dae animations could be done virtually on every software, or even exported as FBX, reimported to a different software and exported again. Bvh files are OK, but not every software exports in such format. 

Again I would like to do special emphasis, could every other software user export an animated model as FBX or dae and export the files from avastar as anim? It wouldn't fix the whole problem but it could be something really useful. If this is possible, my apologies but I never found an easy way for such task. 

[Gaia Clary]

The problem with importing dae or fbx to Avastar is actually a problem of blender. If anybody has issues with importing a second life compatible Collada file into blender, please report this to the blender bug reporting system. We (Machinimatrix) look at Collada related issues. Please add a reference to "SL" in the subject. That speeds up things a bit :smileyhappy:

Currently we do not provide an easy method to transfer animations. However we can take a look into this next week.

Here is what we have by now:
Once you could import your model into blender, then (assuming it is compatible to the SL rig) it is easy to transfer your rig to Avastar:

This is a typical third party SL compatible Rig (including meshes) imported to Blender:

After you click the "Convert to Avastar Rig" button, you get this:

This is a default SL compatible Avatar Mesh character plus the custom mesh(es) all rigged to the Avastar rig in its full glory (including the Bento bones of course)

However if your imported object contains an animation, then we still need to add some magic to get the animation converted and attached to the Avastar Rig as well. It is probably not a big thing to do, but it needs to be implemented.

I am also not sure what Avastar does when it gets a Bento skeleton as starting point. We have not yet tested this situation yet (we will check this and if necessary fix it in the next days)

If someone can provide an SL compatible Collada file that includes an animation, we can give it a try and see if we can improve the workflow so that at the end we have something like this:

 

1. import collada/fbx to Blender
2. convert to avastar
3. export animation as .anim or .bvh

We also might be able to eventually provide an export to .anim without need to first convert to Avastar (but no promise here)

[Polymath Snuggler]

Okay ~ I've actually got a proper answer-answer to this question.   The internal animation format for Second Life does not contain scaling data at all.   The entire data-array inside the actual .anim files themselves is exclusively rotation and positional information stored on a per-joint basis in an array, which is then crammed into Hexadecimal for file size concerns.  So scaling isn't possible presently without rewriting the entire internal animation file structure, then rewriting the the animation interperters to deal with the new file structure.  On top of that ~ any old viewers would look at the new animation files and be very very confused, so it would have to be a massive update~ etc etc.

 

Basically ~ I don't think it's worth it.

[Fashionboi Landar]

Would it be possible to add a bone to keep mesh grounded? I think it would be amazing to finally have gowns, or really long dresses that actually sticks to the ground rather than lifting awkwadly when moving. 

[Kitsune Shan]

I think you didnt got what I meant.

What I gave you with that little math form is to scale translations without having to use bone scale .

In others words, it would take joints offset into account to scale how much translation would move meaning that smaller avatars would move less while bigger avatars would move more. The animation system itself for supported anim or bvh files wouldnt need to change at all, just how SL handles animations. We may still upload animations in bothways, original as absolute or new as relative because certain situations wouldnt require relatives animations. Take intoa ccount that relatives animations only aims to give compatibility between different sizes humanoid avatars and not to something different like quadrupeds. But the good thing is that it would work even on avatars that uses joints offsets for some deformations as long as they are humanoid like. This isnt really a big issue about updating itself because all new avatars made with bento will also look wrong on outdated viewers. So having to change some details on animations wouldnt meant a big deal knowing that everything may have to change anyway due bento bones. Have you looked a bento avatar on a non bento viewer? It doesnt looks just non rigged but totally deformed.

 

And to Gaia, thanks for taking such task into consideration. I have no idea how avastar animation exporter works but I guess it would mean just export based on bone naming. This would require to meet certain criteria like proper size and orientation but once users gets used to it, things should be easy enough. Ill try to make some dummy avatar with some animations on it and give you the file so you can test how to make it work. Thanks .

[Medhue Simoni]

---

Kitsune Shan wrote:

I have once played with it but couldn't do too much as I am 3d max user.

---

I actually switched from 3ds Max to Blender. I think it was easier for me to switch from 3ds Max, because there are quite a few similarities between the 2. From how modifiers work, to rigging, it was all very similar, at least to me. Maybe you just need to play with it more.

[MoonHowler Snowpaw]

I've just got some time to start exploring the face bones. Some have asked before how to move the tongue out with only rotations. If you use joint translations for the uploaded skeleton, i think something like this could work. Though, of course, i hope the final decision will be to allow bone translations for more freedom in animations, just the current avastar still doesn't allow bones translations, so i'm experimenting with the current abilities to see what is possible with rotations for the tongue.



[Kitsune Shan]

I have been using 3D Max for too much time to do the switch, plus I dont feel I should simply because SL uses a propietary animation format. I have played with it, did things, isnt too hard. But I can simply work thousand times faster on a software that I know completely rather than always have to search and learn how to do something that I already knew in Max. I dont even have the time to learn a whole new 3D software and if I had to for whatever reasson I probably would choose a different one .

[Lyoto Steamweaver]

I use maya and not switching either.

That being said I'd pay (resonable amount) for a compatible .anim exporter plugin OR avastar if it gets a nice quick and easy import and export.  

[Polymath Snuggler]

I posted this on the AV_Sitter2 Forums and got in contact with Code Violet about this idea.  It's still an idea. Just that.  It's a simple idea though and easy to implement but it would solve a LOT of problems. 

 

As project Bento is progressing, we, the design community should probably start thinking about adapting some sort of standardized metric for playing facial animations.  Since it's unlikely that any given mesh head will have the same rigging and weighting as another one ( Especially in the case of non-human avatars ) I'm proposing we standardize a simple single-script ( or partial script )  implementation for broadcasting facial animation requests. I'm trying to start this standardization early so that creators can adopt it early and save ourselves the hassle of muddling through until a standard arises later on.

The nature of this script is simple, if your piece of furniture has an animation to play that you would like accompanied by a facial animation, it will send a targeted animation request to an avatar UUID to play an animation of that type.  IE : if you have a kissing animation the seated avatars will receive an animation play request on a pre-determined negative channel  "MESH_KISS" .  If there are any avatars wearing a mesh head that understand that request, they will attempt to play their own internal "MESH_KISS" animation.  This way we can skip-over the problem of trying to standardize rigs and weighting as we can just have a list of "Standardized animations" that each head can perform ( obviously not a requirement ).  I just want the infrastructure to be there.

Just to specify the example, all I'm proposing is when an animation is a message similar to the following will be broadcast on a channel.

[AVATAR KEY] | PLAY | "MESH_KISS" | [LOOP TRUE/FALSE] | [LOOPTIME] | [ STOP_BLINK TRUE_FALSE ]

( recipient avatar, play animation, animation_name , whether it's a looping animation, whether the animation should stop after a specified time , whether the animation should stop you from blinking while you're doing it )

The difficult part of establishing the protocol is defining what sort of animations should come "standard" on a mesh head.  Just as examples:

MESH_SMILE , MESH_YAWN , MESH_KISS, MESH_LICK , MESH_PH_A  ( Mesh Phonetic A  ) , MESH_PH_O , MESH_PH_S, MESH_PH_P (etc etc etc)  , MESH_YAWN  ~  and so on and so forth.

The list need not be exhaustive and can always have more animations added at a later time.  The furniture scripts need only have the animation names tacked onto their pre-load notecards.  The majority of the "work" will be the animation players inside the heads.  The idea is simply to establish the protocol NOW so we don't have to muddle through disparate rigs and weirdness later on.

This idea is just that~ an idea at the moment.  I'm eagerly awaiting feedback on what it should also contain/ do and what people think the "basic" animations that a mesh head should be able to run.

Please note: the list need not be exhaustive:  as any animation requests that are not understood will simply be ignored.  The idea is simply to get this project going early so we have a reliable infrastructure to count on later.

My hope is to nudge the community in the direction of keeping facial animations and body animations as two separate animations.  The situation I'm trying to avoid here is having animators animating the face when creating their own somatic animations and then having the head-designer community trying to fight against the incursion of "bad head animations" that don't work for their particular content.  I want to set precedents and minimize user AND creator confusion from the start.  In addition it would help solve the animation file-size problems if we had a established 'split' between facial and body animations, but I don't want to go so far as to ask the lab to enforce a restriction, as that would limit the creativity of the platform.  But ideally I would like an announcement that establishes this precedent when Bento goes live.

[Oz Linden]

---

Gael Streeter wrote:

This is a very very old known bug :

When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load).

But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long

incoherent

moves. 

---

We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem.

It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions.

[Medhue Simoni]

---

polysail wrote:

 

My hope is to nudge the community in the direction of keeping facial animations and body animations as two separate animations.  The situation I'm trying to avoid here is having animators animating the face when creating their own somatic animations and then having the head-designer community trying to fight against the incursion of "bad head animations" that don't work for their particular content.  I want to set precedents and minimize user AND creator confusion from the start.  In addition it would help solve the animation file-size problems if we had a established 'split' between facial and body animations, but I don't want to go so far as to ask the lab to enforce a restriction, as that would limit the creativity of the platform.  But ideally I would like an announcement that establishes this precedent when Bento goes live.

---

I'll just point out that it need not be either/or. A creator could include face animations in their normal avatar animation or AO animation, and as long as those animations are priority 4 or below, you can still override them. All facial animations should be priority 5 or 6. I'd actually encourage creators to, at least, include a default facial expression in their body movments, because if you do not, then the face will be stuck in whatever expression was last played. With a facial animation in the body movments, you know that at some point the face will come back to some normal expression.

[Oz Linden]

Can we please try to keep this thread focused on the Bento features and bugs without getting into a discussion of the relative merits of different modeling and animating tools?

[Medhue Simoni]

---

MoonHowler Snowpaw wrote:

Though, of course, i hope the final decision will be to allow bone translations for more freedom in animations, just the current avastar still doesn't allow bones translations, so i'm experimenting with the current abilities to see what is possible with rotations for the tongue.

---

Avastar just has some constraints on the face bones, to only rotate like LL had wanted. But since LL has openly stated they are allowing and working on bone translation, you just need to go into the bone contrainst in your Properties Window in Blender, and delete those constraints.

 

[Whirly Fizzle]

---

Oz Linden wrote:

---

Gael Streeter wrote:

This is a very very old known bug :

When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load).

But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long

incoherent

moves. 

---

We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem.

It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions.

---

I believe this bug is caused by the same optimization issue - it has a repro bvh and a video showing the problem

BUG-5146 - Animation skipping frames

5146 is probably the same bug as VWR-2461 - Preserve subtle movements when uploading animations

 

[Whirly Fizzle]

---

Oz Linden wrote:

---

We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one.

There is also the long standing SH-2550 - First frame of uploaded animations is triplicated

which Medhue has already brought up in this thread.

[Vir Linden]

We've had some requests for the ability to experiment with alternative bones to the current Bento skeleton. Since bone names are checked on upload of animations and meshes, trying to change the bones will not work on most Aditi regions. To enable such experimentation, we have set up a region where the bone name checks are disabled, so uploaded content can reference any desired bone names. The region is called BentoExperimental1. Some things to keep in mind about testing with alternative skeletons:

• You don't need to use this for typical Bento testing. The experimental region is only useful if you want to experiment with alternative bone proposals.
• Testing alternative skeletons requires you to edit a complicated and undocumented file in the viewer, called avatar_skeleton.xml. If this file gets messed up, things may display incorrectly or the viewer may not run at all. We suggest saving a copy of the file before doing any editing. If things get completely messed up, you can always restore the file by reinstalling the latest Bento project viewer.
• The viewer only has one representation of the expected skeleton structure; if you change avatar_skeleton.xml, you will change how your own avatar and all other avatars will be displayed in your viewer. On the other hand, no changes you make to your own viewer will affect how anyone else sees you. If you want someone else to see your altered skeleton, they would need to change their own copy of the file to match your changes. So bear in mind that people running un-altered Bento viewers will not see your new bones as intended and your avatar may look completely wrong to them.
• There is a known limitation that adding new bones between the bones of the standard skeleton does not work correctly - for example, trying to add additional joints along the neck/spine. If you make such changes, the default avatar will display incorrectly. We may or may not have time to investigate this issue before Bento is released.

Please let us know how it goes!

[Medhue Simoni]

---

Whirly Fizzle wrote:

---

Oz Linden wrote:

---

Gael Streeter wrote:

This is a very very old known bug :

When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load).

But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long

incoherent

moves. 

---

We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem.

It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions.

---

I believe this bug is caused by the same optimization issue - it has a repro bvh and a video showing the problem

BUG-5146 - Animation skipping frames

5146 is probably the same bug as

VWR-2461 - Preserve subtle movements when uploading animations

 

---

I've uploaded tens of thousands of animations, and I've only come across this problem a few times, if that. I really didn't even know about it until people kept asking, but hadn't experienced it myself, because I always somewhat adjust the frame rate to what the animation needs. Some people tho, just use 30 fps as their standard and every animation they make has that frame rate. This is where problems arise with the uploader. At 30 fps, it is possible to make a movement so slight that the uploader ignores it. The solution is simply to use a lower frame rate. If the movement is that slight, lowering the frame rate is not going to impact the quality. Now, you could say this is a bug because the user gets an animation that doesn't match. So, IMHO, this is really an issue of letting them upload the animation at all. IMHO, the uploader should just fail, and give them the reason.

It's also worth noting that we can upload animations as fast as 60 fps, so it is likely more people see the issue because of that.

[Fiona Branagh]

Exciting news about the extra bone experimentation! Too bad about the neck and spine though. For the most part, that will probably be the area where extra bones are most desired. Definitely let us know if/when that changes, as for many of us doing non-human avatars, it will be a complete game-changer.

[Kitsune Shan]

My comments are all toward Bento project.

I wouldnt do such comments if people like me could upload animations in a proper format rather than rely on hacks and scripts to be able to export to anim format.

So far Im totally stuck if I cant use bones translations to test all the Bento features. A good start, now that translations are possible, could be to open at least BVH files so translations arent locked anymore. Then Im sure that the debate about which software to use to be able to do such task could end.

[Kitsune Shan]

Could the preview window show the animations after the performing the optimization?

Would be nice to see how the animations will really look once uploaded. Could help to get a real idea about if our animations are really well done or not.

For example, alerting users about framerate may not be a bad idea but take into account that this optimization doesnt really depends on framerate itself but the whole file size. So an animation could work perfectly at 30fps as long as isnt too long.