Bones names

[ElizaLiffy]

I have "Iliana" - standart avatar. I wanted to create own animation of dance, using Blender 3D. When I uploaded it, was the first trouble about (Root name must bee "hip"). I renamed root bone to "hip". And I see preview of my animation, when uploaded again. After this, I wanted to send ot for L$10. But there was problem again All names of my bones were "Unknown". Where I can get standart names of bones? Or full scelet? It is desirable for free. I heard about Avastar, but I don't want spend so much money just for fun. 

Edited December 15, 2018 by ElizaLiffy
Add tags

[Ipecac Burnham]

Your error usually happens to me if either the parenting or the bone hierarchy has changed, or new bones added.

 

The error is also seemingly wrong, the error should be stating that it's found a bone/chain with a parent that is NOT the hip, which is correctly named "mPelvis" and should remain named as "mPelvis".

 

It's common to get this error if you leave in F-curves and animation data for control rigs and IK targets(which the importer can't deal with, it seems to expect only SL bones).

edit: any bone data with NO parent may throw this error, not sure.

 

Perhaps it's something in the .anim stuff server side.

 

http://wiki.secondlife.com/wiki/Project_Bento_Skeleton_Guide

this link has the listing of the newer bones added with bento and the naming convention.

 

http://wiki.secondlife.com/wiki/Project_Bento_Testing

This link has further links to the standard rigs with correctly named bone sets.

Edited December 16, 2018 by Ipecac Burnham

[OptimoMaximo]

On 12/16/2018 at 1:02 AM, Ipecac Burnham said:

The error is also seemingly wrong, the error should be stating that it's found a bone/chain with a parent that is NOT the hip, which is correctly named "mPelvis" and should remain named as "mPelvis".

This is wrong, unfortunately. The primary name for the root bone in the BVH animation standards is "hip" even though it is stated that there are a few accepted aliases, including mPelvis. If the aliases may work using BVH, certainly it doesn't when using the .anim format and in such case mPelvis is the only correct name. But the problem here is another... 

Reading your error:

On 12/15/2018 at 3:23 AM, ElizaLiffy said:

 

All the bones name conventions are completely off. Plus, there are joint names in the list that are completely extraneous to the SL avatar's skeleton (such as the IK bones you have certainly used to animate).

Take a look at this link http://wiki.secondlife.com/wiki/Internal_Animations under "User Playable Animation" there is a link to download the BVH files used for the internal animations that should give you all the correct alias names used in BVH import. Or just download the avatar files from the rigging section changing the root name to "hip". Remember to export just the deformation skeleton and NEVER the utility bones such IK chains or other controllers. 

However, from the bone names i can read in the posted error, it seems you got an Avastar character and you're trying to export an animation using the Blender native BVH exporter. I can tell you that even if you fix the issue with the unrecognized names, the animation won' t work (and i won't explain why or how to make it work, you should buy Avastar if you're using their rig to animate)

 

[Ipecac Burnham]

2 minutes ago, OptimoMaximo said:

This is wrong, unfortunately. The primary name for the root bone in the BVH animation standards is "hip" even though it is stated that there are a few accepted aliases, including mPelvis. If the aliases may work using BVH, certainly it doesn't when using the .anim format and in such case mPelvis is the only correct name. But the problem here is another...

Good to know, care to share any info about it as it's not publicly available that I can find, nor seemingly anyone else.

Edited December 17, 2018 by Ipecac Burnham

[OptimoMaximo]

1 minute ago, Ipecac Burnham said:

Good to know, care to share any info about it as it's not publicly available that I can find, nor seemingly anyone else.

I had to dig in the documentation and in the viewer code to find this out when i was making my .anim exporter. You could also check in the viewer's folders, there are two .xml files containing the complete skeleton definition, avatar_lad (collision volume bones and attachments) and avatar_skeleton (the regular animation bones) to learn about the viewer handled bone aliases.

[Ipecac Burnham]

I've been playing with python and such for my own .bvh exporters lately and looking into various open source .anim exporters, and seems even the blender foundation's bvh exporter has comments specific to SL that state it's expecting, or was, a strict ordered list of names.

 

No documentation I can find anywhere released by a Linden says anything similar.

 

I'd also take the xml's with a pinch of salt because as far as I can tell a lot of that stuff gets ignored at the viewer level to stop us setting everything to priority 5 and 6.

 

Most all released content from LL names the hip as "mPelvis" , I'd strongly advise keeping it that way, as .anim is very seldom needed now that a .bvh can honor translation info, and we've no idea what the internal converter is or isn't doing when we upload them.

 

I can't check the .anims on the wiki as they are binary and cannot be opened as text.

 

In short, if you work out the horrible scale and rotation conventions expected by the rig, a .bvh from the wiki ruth will export and upload just fine, with no need for .anim at all that I can find unless getting at priorities 5 and 6 somehow.

 

If rename the mPelvis bone to "hip" I get the error too.

[Ipecac Burnham]

This link is an imgur link, as it's a temp album of my week testing in blender after figuring out the constants.

 

There's 2 things I learned very fast, renaming the bones breaks everything, and changing the parenting structure breaks everything.

 

This is entirely in blender.

 

My next step hopefully is to learn enough python to bypass misnamed bones entirely in it's export loops, to both strip out my control rig - saving the need for a second target rig in the scene, and being able to throw a warning to myself that this "probably won't upload".

 

https://imgur.com/a/b1C5LHm

[OptimoMaximo]

On 12/17/2018 at 4:11 PM, Ipecac Burnham said:

I've been playing with python and such for my own .bvh exporters lately and looking into various open source .anim exporters,

anim per se is a arbitrary file extension and doesn't mean they comply with SL's internal format. Indeed, Maya has an .anim format on its own to transfer animations from scene to scene, for example; Unity also handles animations internally storing them as .anim. The encding is what makes the difference.

On 12/17/2018 at 4:11 PM, Ipecac Burnham said:

seems even the blender foundation's bvh exporter has comments specific to SL that state it's expecting, or was, a strict ordered list of names.

Indeed, the bones names must comply to a very precise list of names or the animation engine just rejects the whole file upon upload. Moreover, the bvh format skeleton also needs to be a specific size and more importantly, a specific world orientation

 

On 12/17/2018 at 4:11 PM, Ipecac Burnham said:

Most all released content from LL names the hip as "mPelvis" , I'd strongly advise keeping it that way, as .anim is very seldom needed now that a .bvh can honor translation info, 

Most content uses mPelvis because it's the primary (and only) name used in the .anim format. This latter has a huge advantage over using bvh though, especially when it comes to joint position: bvh format writes down ALL joints positions in the hierarchy description and upon playback, they're all applied to every avatar joint, regardless whether it's in use for animation or not; on the other hand, .anim stores animations on a "per animated bone" basis because the skeletal hierarchy is assumed. Another important advantage of .anim over bvh is that you can animate joints in the same animation with individual joints priorities, as opposed to bvh which uses a global priority for the whole animation.

On 12/17/2018 at 4:11 PM, Ipecac Burnham said:

and we've no idea what the internal converter is or isn't doing when we upload them.

Well i have an idea of what it does (just read the python plug in in the viewer code): first it reads the file and checks the bone names against the list of allowed names, including the aliases for the mPelvis (hip works, it's how the bvh exporter for Maya works). Aliases are there for multiple avatar animation scenes in order to avoid the so called name-clashing btw. The second thing the uploader does is to apply some matrix math on the scale to convert joint locations from local inch-scale derived locations into absolute metric-based locations and lastly, some more matrix math on rotations to switch world orientation. After all this, if everything went as expected, it begins the conversion from eurler rotations to normalized quaternions, "clean up" and serialization into binary encoded values.

 

On 12/17/2018 at 4:11 PM, Ipecac Burnham said:

In short, if you work out the horrible scale and rotation conventions expected by the rig, a .bvh from the wiki ruth will export and upload just fine, with no need for .anim at all that I can find unless getting at priorities 5 and 6 somehow.

In longer wording though, those conventions require a lot of code and math that a .anim exporter just doesn't have to use at all, and again each joint can get its own priority if needed. The limit to priority 6 is something that LL has requested because the priority slot can take any 1 digit value, theoretically expanding the possible priorities up to 9. But, aside from this, .anim format allows for more precise animations with smoother motion due to the bypass of the "clean up" that the uploader does in a very harsh manner.

On 12/17/2018 at 5:53 PM, Ipecac Burnham said:

There's 2 things I learned very fast, renaming the bones breaks everything, and changing the parenting structure breaks everything.

If the naming is done correctly, matching the aliases, everything works. The proof is in the bvh exporter for Maya. Changing the hierarchy, instead, is something that has always been established as a "don't".

On 12/17/2018 at 5:53 PM, Ipecac Burnham said:

My next step hopefully is to learn enough python to bypass misnamed bones entirely in it's export loops, to both strip out my control rig - saving the need for a second target rig in the scene,

A deforming rig driven by a control rig is a common industry standard for various reasons, one of which is the override of established/unchangeable hierarchy structures such as SL's skeleton. The way it is constructed wouldn't allow an easy manipulation of the lower body independently from the upper body, as it is. An overriding control rig instead does the job. There is a long list of reasons for which you actually want a control rig that controls a deforming skeleton, from naming conventions to reusability across different characters to actual body mechanics, and more. One of which is the joint orientation, which might not be apparent to Blender users as it's not a really supported feature. Blender supports only roll and has its own standard orientation because it assumes the transform as being a bone, while the more general concept of joint allows for a wider range of orientations which actually do make a difference. Indeed, the SL avatar's joints assume a very specific orientation, dependent from the standard you use (BVH or .anim) that doesn't match with the bone orientation in Blender. Therefore a control rig is a better choice because you can animate the control bones as you like, keep all your animation data on them, while the animation export can happen by sampling the deforming bones in world space rather than in local space, making it easier to evaluate the actual rotations with fewer math passes to conform the orientations and rotation orders to the assumed standards.

[Erwin Solo]

On 12/17/2018 at 10:11 AM, Ipecac Burnham said:

seems even the blender foundation's bvh exporter has comments specific to SL that state it's expecting, or was, a strict ordered list of names.

Avastar Team has made significant contributions to Blender over the last ten years; perhaps this is one.

[OptimoMaximo]

1 hour ago, Erwin Solo said:

Avastar Team has made significant contributions to Blender over the last ten years; perhaps this is one.

Just read the commentary of such script, it's from a long term contributor of Blender scripts whose name I can't remember, but it's not from avastar team. Avastar has its own bvh exporter

[Erwin Solo]

6 hours ago, OptimoMaximo said:

Just read the commentary of such script, it's from a long term contributor of Blender scripts whose name I can't remember, but it's not from avastar team. Avastar has its own bvh exporter

I have a nicely rigged bird in Blender 2.81 that I'd like to animesh.  I suppose that if I really knew what I was doing, I could rename the bones and make it animesh now, but I'm waiting on Avastar 2.81 to pop out of the oven before I do it.  

[OptimoMaximo]

2 hours ago, Erwin Solo said:

I suppose that if I really knew what I was doing, I could rename the bones and make it animesh now, but I'm waiting on Avastar 2.81 to pop out of the oven before I do

Well, I think the major game stopper is to create a functional animation rig to control the bones, which avastar excels in helping with. Animation rrigs are quite time consuming and very much prone to misbehavior and/or collapses if you don't have a solid tested knowledge of how things should work for you, and anyway a scripted solution to do so is always best as it nullifies the chances of mistakes due to overlooking or forgetting something.