Teager

The joints would still be extremely useful without an IK chain. My recommendation would be to set them up exactly like the current avatar legs, in which the first 3 bones are connected to the IK chain and the toe is not. That way, anyone wanting to use the limbs as extra humanoid legs could do so relatively easily, and anyone wanting to use them for some other creature still has that ability. The fourth bone would also be useful for pets - any winged pet will want that fourth "finger" bone to help the wings move, and any four legged pet would benefit from being able to split each limb chain into two and two bones, to allow for at least 2 moving joints per leg on a four legged creature. Then you could apply the 5 tail bones to be the head, neck, body, and tail of the pet.

Actually, for animation purposes, that first joint you hilighted doesn't need a bone, since the whole limb chain can be moved with bone translation. The feet, however, do - the toes on the dog and the hooves on the horse. Most mammals would require 4 bones to animate, as Tyrian said above and I mentioned a page or two ago. To continue the dog example:  These two pictures illustrate very clearly why mammals require 4 bone limb chains; with only 3 bones, either the orange bone would be sacrificed and they would not be able to sit, or the green bone would be sacrificed and their feet would be constantly stuck at a 90 degree angle, clipping through the ground when moving or sticking straight up in the air when sitting or laying down. Humans actually have 4 section limbs too - the fourth section is our toes. That's why, as discussed earlier in this thread, it looks very awkward that most sl animations currently do not animate any bend in the foot. Human toes don't stay perfectly in line with our feet. Neither do dog toes, cat toes, horse toes, or any other four legged mammal toes. It's simply more obvious with them since they walk on their toes, so the default position of their toes is rotated 90 degrees out from their "feet" - the blue bones above.

I'm a bit confused at the decision to add 4 new bones to the spine, but have none of them in the neck. I thought the original intent behind the idea to add additional bones in the spine chain was primarily to offer more neck movement. I still believe that the facial root bone can do the trick for full avatar makers, but obviously having an extra bone in the avatar neck would be more ideal. Why have a 7 bone torso with a 1 bone neck? Was there some additional problem in the neck that did not exist in the torso?

So sorry I missed the meeting this week. In response to some items that were discussed: - I think it's a wonderful idea to have 3 limb chains rooted to mPelvis. That opens up a lot of possibilities. - I disagree with the thought to remove wing tips. You should absolutely reduce the wing base to only one bone, but should leave 4 bones per chain in each wing. 4 bones will allow for that integral "finger" bone to aid animation of bat and dragon wings. Also, for anyone wanting to use the wings as limbs, arms and legs of most creatures found in nature contain 4 segments, not 3. - In the event that no additional bones can be added inside the spine chain, I still hold that some number of facial root bones would greatly alleviate the need for an extra bone in the head and neck chain. Presumably most people who need more movement in the neck are already not working off of a human skeleton and could shift bones as needed.

Pirschjaeger Fassbinder wrote: I'm trying to rig dragon wings that resemble bat wings and I am not having much luck with just using the four provided bones for each wing. I am also trying to make wings that can also fold when not flying. However, the other "fingers" of the wings that are not aligned with the bones get distorted when I try to fold the wings. I have rotated the bones around to simulate the wings flapping and my results are okay when it comes to that. This was the reason that wing "fingers" were suggested - with the current wing setup, it will be next to impossible to actually achieve a wing fold. Wings rigged on the current wing bones can flap, and can "flop" down to the sides or behind when not in use, but cannot fold so long as the bones are all parented in a straight line.  The above image shows the folding and fanning motion of a bat's wing. You can see here that the "fingers" inside the filament of the wing, at their tips, actually rotate in towards each other, and out away from each other. This would be difficult to do with all four wing bones in a straight line, but if you use translations to move the fourth wing bone to be parented to the second wing bone like in the following image, you should be able to get a decent approximation of a bat wing fold:  Using this method you will need to set location frames on every keyframe of the wings, but should be able to create a better wing fold. Unfortunately, where feathered bird wings are involved, there is no good workaround with the current system. The best bet for an avatar maker would be to use the human arms and fingers, but that won't be ideal for anyone wanting to put angel wings on a human avatar, obviously. A bird's wing doesn't just crunch in and crunch out like a bat's wing does - it actually fanfolds in on itself, such that each section of the wing overlaps the next section of the wing.  You can see in these images that the three sections of wing - primaries, secondaries, and scapulars - don't just squish closer together like a bat's wing does. They actually fold one section on top of another. In fact, what's actually happening is that each individual feather is sliding on top of the feather next to it, within its section, while each section is also sliding beneath the section before it. You can get a better look at what's happening here: For a good bird wing fold, you would therefore need a completely different bone setup than you would need for bat wings. A bird's wing comes in 3 main, parent sections, which would create the 3 bones along the top of the wing, but also needs the ability to fold each individual section of wing in on itself (think like a chinese fan) and finally the ability to layer each of those sections one on top of another. I don't really consider myself an expert in bird wings, but this is how I imagine you would accomplish a feathered wing fold in the fewest bones possible:  In this setup, there are 3 parent bones for the 3 sections of wing. The second and third sections of wing each have two child bones to complete the ends of the "fan fold" action for each of those sections of wing. I've given the first section only one child bone because the other could, presumably, be mChest. Watch it animate here: https://i.gyazo.com/3f901e225bd44f35c762c6ca698a2cea.gif For a creator of full avatars, this setup could be recreated using the arm and finger bones and using translations to reparent the finger bones. For anyone wanting to make bird wings to sit on the back of the human avatar, this setup seems unreasonably clunky. I don't feel we can reasonably expect LL to raise the wing bone count from 8 to 16, so the best advice I can give for anyone making angel wings is to either let them "flop" behind the avatar, as so many wings do, or to use an alternate mesh for the folded wings.

When should we expect to see the results of the poll regarding which bones to add?

Medhue Simoni wrote: Here's a tangent, but relevant. The facial bones parented to the skull bone, I really don't have any issues with. Wish we didn't have to, but I do understand the issue fully, and why. Again tho, that said, will I be updating my wolf to utilize that extra head bone? No, I will not be, because I do like to make all my avatar's heads move with the mouse, and then try and blend in the body movement, when that works best. The neck on my wolf is not really an issue, at all. The plural of anecdote is not data. Humans, canines, and many other creatures have short necks without many vertebrae, and therefore look perfectly normal with only a single neck bone. But that doesn't mean that other creatures would not benefit from the option of an extra bone. It's dangerous at this stage of the project to proclaim that anything isn't needed or won't be used, especially when you can see what value it might offer to someone else. Obviously any new bones that come out of the bento project, including the bones already in the bento skeleton, will be properly tested to assure that they don't break existing content or in any way affect those creators who choose not to use them.

Yep, it uses just one additional bone. I attended this last bento meeting with my modified xml file still active, and everyone looked perfectly fine. Theoretically it should only affect anyone wearing a rigged face - the rest of the avatar skeleton is unaffected. My original thought was that if the facial bones were parented to mSkull instead of mHead, that would allow anyone needing a 2 bone neck to use mNeck and mHead for the neck and mSkull for the head without breaking any compatibility with the existing avatar. It was pointed out though that some hair is rigged to mSkull, so it's possible that there may be some negative effects there, though I can't think of what they might be. Just to be safe, for the purpose of demonstration, I added a new bone instead. FaceBase is a child of mHead and the new parent of all of the facial bones. For the creators who don't need it, it essentially does nothing. All they need to do is not rig it. For the creators who do need it, it'll allow us to scoot bones around to create a third bone on the head and neck chain.  Here's a shot of the bones labeled. You can see I added faceBase parallel to mSkull, then continued the chain along the faceBase line with all of the facial bones. So if you follow the bone chains, mSkull is a dead end just as it's always been, and the new bones are the ones to lengthen the chain. That way it can't possibly break compatibility with anything anyone is currently using mSkull for.  Here's an example of what it would look like on the standard avatar. I've moved mSkull out of the way a bit so you can see both bones forking off from mHead. Note that the standard set of eye bones will still need to be parented to mHead as they were before to avoid any possible negative effects - only the bento bones have had any changes made.

@ Kwakkelde - I did, though the weighting on the mane definitely isn't the best. You can see the mane motion in this gif - https://i.gyazo.com/3869792a6fb5bde8bf1dcce40cd9e6ca.gif @ Medhue - Using translations to lock parent and create an extra bone that way was what I was doing originally, before bento was launched, and is still my backup plan in case no ability for an extra neck bone gets added. For now I've posted this version of the rig as my example for LL to go along with my suggestion for an extra neck bone, to show a little of what can be done with it. Having an extra bone would definitely be preferable over using translations to force a bone where there was no bone previously. If I use translations to lock the facial bones to mSkull and rig the head to mSkull, I will be unable to animate the head and neck independently, which means I cannot make animations for just the face which play on top of whatever else the horse is doing in the background. Using translations to lock the shoulders to mTorso so I can use mChest and mNeck for the neck, and keep mHead as the head, means I cannot animate the front legs independently of the neck. That second option would offer a little more freedom, since there are fewer situations where I'd want to animate the legs and the neck independently, but is still a limitation. Adding the extra bone would mean no such limitations and would make me a very happy animator.

I figured I'd add my tinkerings as well, since I've been quiet for a while. Here's my current horse setup, fancy new bones and all:  The hilighted bone is my added bone, faceBase. FaceBase was inserted between mHead and the facial bones and acts as a new parent bone to the facial bones. This allows me (or anyone else who needs it) to create a two bone neck without inserting any new bones into the existing spine chain or breaking rigging to any existing meshes. If you follow the hilighted faceBase to the right, the next bones in the chain are mHead and mNeck, which are both being used in the horse's neck here, followed by mChest (between the shoulders), mTorso, and mPelvis. * All the gifs are cut short; click the links to view the full motion  (FULL GIF - https://i.gyazo.com/d77d48e965838bfb93a8290305f1eefc.gif ) A look at the two bone neck at work, and a little bit of tail action. I also decided to use mSkull (the long bone above the horse's forehead) to rig the hair falling over the horse's forehead, so it has some motion and isn't stuck flat to the head.  (FULL GIF - https://i.gyazo.com/3869792a6fb5bde8bf1dcce40cd9e6ca.gif ) The wing bones have been repurposed as the left and right side of the horse's mane. Rigging the mane this way will allow a mesh mane to move, bounce, and drape as though there were physics acting on the mesh hair. The horse here is only wearing the left side mane, but using both wings will allow users to decide if they would like their hair on the left, right, or both to give a little bit more customizability.  (FULL GIF - https://i.gyazo.com/925d998b6f69e9aeec92d74c64356182.gif ) Some tail motion. Yay tail  (FULL GIF - https://i.gyazo.com/94571d72d83b8060dc2330b5fd606445.gif ) And some simple facial expressions. I haven't yet rigged the eyelids or eyebrows, but have set up my face rig with the intention to rig those later. The ears, nostrils, nose, upper lip, lower lip, lip corner, tongue, jaw, and eyeballs are rigged here.

I was indeed on BentoExperimental1. After playing around some more, my horse mesh is consistently unable to upload, with the viewer claiming it doesn't recognize my new bone faceBase. I'm inclined to say I've probably done something wrong in my mesh or .xml, but since I can't seem to find any such error, I went ahead and posted a jira at https://jira.secondlife.com/browse/BUG-11211

I tried altering the xml file to insert a new bone between mHead and all of the facial bones called faceBase, which I wanted to be the new parent of every facial bone. I inserted this line between mHead and the face section - <bone connected="true" end="0.000 0.000 0.079" group="Face" name="faceBase" pivot="0.000000 0.000000 0.000000" pos="0.000 0.000 0.000" rot="0.000000 0.000000 0.000000" scale="1.000 1.000 1.000" support="extended"> With this setup, every time I try to log in to the bento viewer, it crashes before I get online. Can I get some guidance on what I've done wrong? Edit - I'm super dumb. For anyone else experiencing the same problem... change the number of bones on the very first line of the file. Everything works; nothing is ruined. Having now successfully fixed my xml file to add the new bone "faceBase" and gone to BentoExperimental1, I am still experiencing issues with the viewer not wanting to recognize my new bone. 

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.

New jira added per discussion in this thread and at the bento meeting today - https://jira.secondlife.com/browse/BUG-11157

Lexbot Sinister wrote: Vir Linden wrote: To do a “touch your toes” animation, you would have to move every joint of the upper body at every keyframe. With a conventional skeleton, you would have to bend at the waist and shoulders, and the rest of the bones could just follow along based on the skeletal hierarchy. I believe this is a false assumption. You can never animate a "touch your toes" position by leaving any joints untouched/unanimated with the conventional skeleton. It leaves those joints "free" and they will be animated, but by the default SL animations. This is a very common beginner mistake when people make poses. " I made a sit, but my foot/head/arm is twitching/moving". Every joint has to be moved to become locked in it's position, unless it's planned to be animated by another animation, but eiher way, no joints are ever left unanimated, at least in the current body. I believe the exceptions are very few, like leaving the neck or head free to move, so the avatars head follows the camera. Most of the time though, it's undesired. As Lexbot said, the only situations where you can animate only a small number of bones is if another animation is already playing beneath it, which you want to continue playing. In this manner, every bone is always animating. For a "touch your toes" animation that bends only the spine, you would first need a background animation which animates all of the avatar's limbs in a fixed position, so that they're not flailing around. For something like a "take a sip of coffee" animation, you could animate only the avatar's arm, head, and neck while expecting the rest of the body to continue animating with the user's animation overrider. Also, unless I've vastly misunderstood the way animations work on the back end once you've exported them, if you have an animation that moves 3 bones (like an arm) over 100 frames, with a keyframe at 1, 50, and 100, you are not exporting an animation that has a total of 9 keyframes. You're exporting an animation that has 300 keyframes, in which each bone's position is recorded on each of the 100 frames. So by that logic, even if a bone is left freefloating and must be animated along with its parent bone, not much is lost from a performance standpoint. Please do correct me if I'm wrong, though, as my expertise lies in making things look pretty and not in writing the code that makes them function. I do understand that the root of your argument is that it would be BETTER if all the bones were not freefloating, and obviously I agree with that. But let's make sure we're not painting the picture of freefloating bones as the root of all evil, as they can actually serve a great purpose in expanding the limited capabilities of the sl armature when used well.

Gaia Clary wrote: Alternative to the 2 tails solution: "constraints" This idea came to our minds when we where working on the bone constraints for the Avastar IK Rig. The idea is: Parent the Wings root to the Spine, but also add for example a (configurable) constraint to the local rotation of mChest to mWingRoot. If possible make the constraint target configurable, so that users can "clamp" the wings to mChest, or mTorso or mSpine, or mhead, ... To explain this a little better: This idea does not change the topology of the Skeleton. It only adds bone movement constraints which make one bone (the driven bone) follow another bone (the controlling bone). Bone constraints are very common in animation programs, so maybe it is also doable in the Second Life Viewer. We use this technique in Avastar to separate the deform bone animations from the Rig (so we could add IK based animations) Generalize constraints If constraints can be implemented in general, then this concept could be generalized to work for all limbs, then users can for example constrain the root bones of the legs, arms, wings and tail to mSpine and create a 7 legged creature that can be animated without adding odd rules to the animation. Thinking even further, if location constraints where allowed, then this idea allows to constrain any limb to any bone. Wings could then be constrained to eye brows for antennas, tail(s) could be constrained to chest for 4 winged creatures, etc. I very much support the idea of a built-in feature to constrain a bone chain to a different parent bone! This is something I do all the time via custom animations, and am very disappointed to potentially lose if indeed bento does launch without the ability to animate translations in bones. Having a built-in option to permanently constrain a bone chain to a new parent for a mesh, however, would be far superior to what I'm doing now, as it would mean a much simpler animation process which is more accessible to less experienced animators and mesh creators. This would make me so very happy. <3

Heads rigged with bento would not be limited to preset animations. They'll be limited only by what animations are made for that particular head, either by its creator or by third party creators. [Trying to make a single set of facial animations that works with all heads would be incredibly difficult, even if they were done without translations.] To trigger the animation on the head when a user speaks on voice, you'd just need to use gestures to trigger the animations for /voicelevel1, /voicelevel2, and /voicelevel3, as seen here: https://community.secondlife.com/t5/English-Knowledge-Base/Using-gestures-and-animations/ta-p/700069#Section_.1.2.1

I wasn't aware any hairs were rigged to mSkull... news to me. If that's the case, an additional bone between mHead and the facial bones - something like faceBase maybe - would do the same job.

Fiona Branagh wrote: As some people have noted, having extra bones in the neck or legs would be extremely useful for non-human avatars. Currently, the necks are not very fluid for long necked creatures such as dragons, and trying to attach prim objects along a long neck fails pretty badly because they don't turn enough with the curving action (they stick out straight due to too few bones to follow.) I made this suggestion earlier in the thread, but I'll suggest it again in case it was overlooked - If the face bones are all parented to mSkull instead of mHead, an extra neck bone can be added for those avatar creators that need it without affecting anything else on the rig. mSkull currently serves no purpose for standard human avatars - volume HEAD takes the heavy lifting there. Nonhuman avatars typically use mSkull to animate a moving jaw, but that is no longer necessary since we now have jaw bones. Parenting the facial bones to mSkull will not in any way damage existing animations or compatability between avatars, because no one animates the mSkull bone, which previously served no purpose. mSkull will follow all rotations and translations that mHead makes, and therefore the facial bones will too. This offers a solution to a very specific-case problem with minimal work to LL and with no negative consequences to the avatars that don't need it. Let's do that, yes?

There actually is a toe bone already, but very few mesh makers seem to rig to it - I suppose because the default avatar isn't rigged to it. If mesh body makers would start taking advantage of that toe bone, animators would be able to animate a bend in the ball of the foot.

What a great rig! I particularly love the wrinkles in the skin. Unfortunately I think we'd need integrated slider support to get something quite that realistic, but we could absolutely achieve the rig itself, for some quick and snazzy facial animation. - Obligitory statement that I am still for bone translation and believe that trying to bandaid the issue with a spider rig is the wrong way to go -

Tornleaf wrote: I think LL's big issue with translated animations is how it wrecks the rig until relog This argument is moot if the viewer cannot sort joint offsets correctly. We deform anyway. Animations can and do fix that. Example of an avatar that failed to load its joint offsets and has no additional animations acting upon it - https://gyazo.com/3b06ca6a0ac4ad4cf539e988931ad313 [for LL, not for you, because I know you've seen it <3] Avatar begins with incorrectly loaded joint positions, then an animation kicks in to fix the joint positions - https://gyazo.com/4235f82e234b6adc2738ba030d363e2f Each person's viewer loads their joint positions individually. User A's viewer might fail to load User B's joint positions, while User B's joint positions loaded fine on their own screen. Without animated deformers, User B would have to continually detach and reattach their avatar until everyone on sim sees them correctly. With a deformer, everyone sees User B exactly the same. Tornleaf wrote: and even undeformer animations can never return you back to your original shape. My undeformers just snap you back to the default female, so most people have to relog anyhow. This is actually false. If you just upload animations with the mbones, the volumes, and the attachment points all in the starting positions straight out of avastar, I'd say you get at least 99% back to the original shape. At the very least, it's incrediby difficult to see any lingering deformations with the human eye. I make sure that all of my avatars play these undeform animations when they are detached, and since you use the same scripter I do, your avatars have the same capability. If all mesh avatar creators would be responsible with their undeformers, and/or if undeform objects were more widely circulated, this would not be a problem except in cases where the sl viewer wildly deforms the avatar in a way that is not caused by any animation at all. Here's the same avatar as aboved when the outfit is replaced with a human one. When detached, the mesh plays animations that undeform mbones, attachment points, and volumes, so no lingering deformation is left. https://gyazo.com/80c7d2bb679c0c12cfe95881e4f0dfd7 (Note when the avatar goes into T-pose; that's the undeformer doing its thing.) I'm not saying your points above are incorrect, because I think you're right in believing that that's LL's line of thought. I'm just pointing out that they are invalid arguments.

@ Vir Linden: If your main concern with bone translations is that facial animations won't translate between one face and another... could you not just explain that in bento's release documentation, so that animators who intend to make their facial animations widely compatible amongst multiple human faces can knowingly release their animations with rotation only? Why force everyone to adhere to a rule that doesn't need to affect everyone? Not all heads need to share the same animations. Not even MOST heads need to share the same animations - different facial shapes, features, and rigging will make unique facial expressions per avatar almost a necessity. I imagine many avatar creators, like myself, will WANT to provide unique, custom animations that fit their own avatar head flawlessly, and ought to be allowed to do so to the highest quality they are able. Facial bones that are rotated simply don't make for the same high quality, realistic look that facial bones that are translated do. But moreover... not everyone is human! ---------------------------------------------------------------- I'm going to take some time to elaborate on another argument in favor of bone translation in animations that I don't feel anyone else has adequately covered. Restricting bone translation is extremely debilitating to those of us who are not creating human avatars. Before bento released, I was working on a new horse avatar that had a 2 bone neck, to simulate more realistic movement for an animal with many vertebrae in the neck. The avatar also had rigged upper and lower eyelids, rigged jaw, rigged upper and lower lips, rigged left and right ears, and a rigged tongue. I achieved this by moving the position of the shoulders relative to the mTorso bone instead of the mChest bone in each of my avatar's unique stand and action animations, so that the mChest bone could be used as the base of the animal's neck. This was a thing I could do as a creator of a uniquely rigged and uniquely animated avatar. It was a simple and efficient solution that made a big difference. What I had before - https://gyazo.com/18fc9ddf561ceb5cb0f2cdb58c007fda See how beautiful that motion is? Just lovely. Now that I am expecting to no longer be able to move the location of the shoulders, I am left with few options to achieve what I had planned to achieve. Let's review the options: Option 0: Keep the rig I have now and provide no compatibility for new animations in the future. Out of the question. I will not do this as this is unfair to my customers and means no longevity for my avatar. Option 1: If I use mChest as part of the neck as I was doing before, the horse's front legs will follow the neck, not the body. Not desired action. Example - https://gyazo.com/09abe61a07c41c0762f40fe757593635 Option 2: If I use only the mNeck bone in the horse's neck, I lose the realistic motion that's had my customers raving - the main selling point of my new avatar. I am once again stuck with the same stiff, rigid, unrealistic neck that comparable avatars have today. This is not attractive and wouldn't be acceptable in ANY 3D platform outside of second life, so why settle for stiff motion here? I strive to achieve better. Example - https://gyazo.com/cc48424ef640036a108b7eb687f5ceee Option 3: If I use the mNeck and mHead bones in the horse's neck, use FaceJaw for the head, and FaceTongue Base for the jaw, I can achieve a neck and head that bend properly. However, I'm left with only 3 additional bones with which to rig the head - one of which must go to either the lower lip or the tongue, as it is parented to the bone being used for the jaw. However, since it can only rotate, not extend out of the mouth, I can safely eliminate the tongue and thus assume it must be used to rig the lower lip. With the remaining two bones, I must choose between rigging the eyelids - likely the upper, not lower, eyelids - or the ears. Either way, I lose a great deal of motion. Example - https://gyazo.com/7d21fcf0a5b1504c5041a0ff906e73c1 Option 4: Here's where I hope I really make my point. In order to best achieve the same range of motion I would have had with bone translations, my best option appears to be to rig the head and neck to one of the avatar's arms. Yes, really. If I am to rig the neck to the three arm bones and the head to mWrist, I am left with 5 strings of finger bones to use on the face. One set must obviously go to the jaw, with spare bones to be used on either the lower lip or the tongue. I am then left with 4 chains to sort out between the left ear, right ear, left eye, right eye, and upper lip. This option provides the widest range of motion and comes the closest to achieving what I would have achieved with bone translations. The obvious drawback of this solution is that, when rigging to the avatar's arm, shape sliders will be awfully skewed and will not scale symmetrically from left to right. Example - https://gyazo.com/51e8291af31925b0d01bc67e121e9d46 Think this last idea is stupid? I do too! And yet, it speaks volumes that option 4 is my best available option. It seems clear to me - and I hope it's clear to you too, from viewing these gifs - that this fourth rig example provides the best range of motion, and that is just not good design. As a creator who models, rigs, and animates my own avatars, I should have the freedom to take enough liberties with my own rigging and animation to achieve a range of motion similar to what I would be able to achieve on any other platform. LL should absolutely ENCOURAGE compatibility between avatars - especially human avatars, which number in the dozens. But should you FORCE it? I don't feel it should. Second Life was founded on the basis of enabling creativity. By forcing this restriction, you place the conformation of the masses above the creativity of the few.

Alternative suggestion: IF for whatever reason adding an additional small neck bone (which is just made to not rotate when not specifically animated) isn't a possibility - I suggest adding an additional bone at the top of the head chain which all of the facial bones are parented to OR parenting the facial bones to mSkull. Why? There just needs to be more options for bones above the arms. There are 3 bones, or as many as 6 bones now, to work with beneath where the shoulders begin. Above the shoulder, there is only ONE neck bone and ONE head bone. If you want to make use of these new facial bones, you can't have any more than basic human movement on the neck and head. No dragons, no horses, no giraffes.

If that is what Vir is saying that's a large improvement. But being "overridden within an uploaded mesh" speaks to me of just straight up joint offsets in an uploaded mesh, not assisted by animation at all. And the viewer's built in joint offsets simply don't work reliably enough to use.