Mel Vanbeeck

That all appears to be accurate.

I get it. You're not interested in making the sliders portion of this project work with animations, and I'm a bad guy for trying to get that portion patched up well enough that it can be used freely. In the video you posted, most of the expressions you made using translations can be reproduced fairly accurately with rotations, though. I don't disagree that building animations with translations is far more flexible, but it's only really a choice if the rotation animations have the benefit of working alongside sliders to a degree that justifies the constraints it imposes.

That looks pretty good.

 I would be thrilled if SL's facial rig could work like that, and believe it or not I'm very familiar with such facial rigs. I'd be delighted if there were a professional rigger working on this project who could advise on the best way to handle this, but when you jump in and start talking about translation animations for everything, you've completely stopped trying to solve the problem of how to work with sliders. If you were throwing sliders out the window from the start, the facial rig would have just about all of its bones right on the surface of the skin and look a lot more like this. The current rig would be complete nonsense. That's not the problem we're working on right now, though. I'm a little puzzled that you're saying that I haven't adequately demonstrated my points, though. You want me to do video rather than still images with ghost frames?

Generally speaking, your graphic looks pretty good to me. Matched X to center position is good, though I'll explain why I think the outer corners of the mouth may be an exception in a few minutes. The Y and Z position is going to depend on what is best suited to providing a good axis for sliding the lips around the teeth. For a general purpose rig, most likely having that set to the same depth for all the lip bones will be about right. The actual Y position should be based on matching the approximate center point of the arc that the front teeth follow. Z would most likely just be matched vertically to the lip verticies being controlled.  The outer corners of the mouth are somewhat different, since that part of the mouth needs to move down quite a bit when the mouth opens fully if you're not trying to make a smile like The Joker. As a result, some care needs to be made to allow the bones to rotate down as the jaw opens without having so short a radius that it starts to draw the corners of the mouth backwards, so it wouldn't hurt to move the bone a bit deeper into the face and across to the opposite side of the teeth to allow a maximum range of movement.

Yes, that is summarizes the adjustments without regard to slider issues. Regarding the teeth, the reasoning can't be entirely divorced from sliders, though. From what I can tell, there aren't any sliders which are applying scale to the jaw now which isn't also being applied to the mFaceRoot. If I'm wrong about this, then additional attention would be needed to ensure that upper and lower teeth wouldn't come out of alignment or have mismatched scales as a result of some sliders.

Yes, I can't understand why you would ever use your opening paragraph as a design paradigm. The changes I outlined would result in a pretty good balance between slider functionality and animation control. Choosing not to reach that goal is just silly considering that it is well within reach at this point. I dont' feel that the sliders need to be "scale only" to get there, either, but translation elements do need to be approached with discretion and strategy. The translations used for eye size and eye width do not pose a problem to animation, since the relevant pivots remain in alignment well enough as they move, so they do not need to be considered. The problematic eye translations are only in the upper eyelid fold slider, as I mentioned, since it involves two body parts that need to have matching rotation axis. The lips are a similar type of situation — lips need to rotate around the teeth, so it is important to have the pivot in the right place, however the lips are more forgiving (thicker) than eyelids, so here I'm primarily concerned with getting the initial placement correct. It's hard to have a discussion about how features are working (or not working) when the opposition is that parties who are silent or not present to discuss anything may or may not have had reasons for leaving something broken. Yes, I can understand that someone made the decision at some point to make the sliders match the SL default blend shapes as much as possible, but there are already omissions here (certain sliders have no effect). The reasoning behind this is shaky in the first place. This rig needs to support animation well. That's just a basic requirement, so I would propose that "as much as possible" should stop short of causing animations to malfunction. Any slider which is pretty much guaranteed to take an animation that works well, and turn it into an animation that looks ridiculous or pushes parts of your face through your teeth or eyeballs just isn't configred well. It is very possible to fix this while still having substantial control over the shape.  Looking at where this facial rig was, it is that it is clear that from the beginning, this project has lacked an expert in the area of facial rigging and facial animation. The placement of the lip bones is a substantial error, and I am afraid that I can't accept the defense that "the people who put them there may have had a good reason for doing so". The bone placement errors of the jaw and eyelids should have made it abundantly clear that the people making these decisions were learning as they went, rather than drawing on a wealth of experience in this area. This makes complete sense, since rigging is not something that anyone in SL working on human heads normally has to learn, other than just basic skinning. The lip bones are just another case of this inexperience. Obviously this is a fairly special case since the challenge of trying to animate using only rotations is unusual, but I've explained the logic of all my statements on the subject in detail, and the validity of that logic has not been challenged. For the lip bone placement, yes, it is somewhat dependent on the shape of the face, but the facial shape that the lip bones are currently configured for is a flat face like grandpa here. This is not a typical face, and should not be the chosen configuration for default, especially if (as Vir said) head designers may have to wait for an undetermined time for the ability to reposition those lip bones so they can release heads with a properly configured rig. I'm repeating myself, though. Back to the jaw bone which you did not address — so your proposed solution is to keep the jaw slider the way it is, and expect users to know that they can only change their jaw angle a few points from the setting of 33 before their mouth animations will start to look absurd. This is a slider born to frustrate. If you have a slider which tempts you with something you might like, but forces you to sacrifice animations in the process, it just serves to torment people and cause them to get into arguments with designers about things they can't have. For Bento, it makes so much more sense to go with the design choice which can be described as "everything works well". If this slider is such an important feature that it can not be omitted, it needs its own bone so it can do its job without breaking animations. I'd say this feature is more important than dedicated teeth bones when the teeth can do their job just fine using the jaw bone so long as it stays put. I know it has been stated that animal head creators need teeth bones for their teeth, but frankly I'd like someone to make a compelling case for why teeth can't be rigged to a properly stationary jaw bone before I'll accept that statement as fact, since at a glance it doesn't really seem to be true unless we're talking about rigging sharks... but why on earth would we be sacrificing good functionality of that slider on human heads for the extreme fringe case of shark avatars which will use custom bone positons for everything anyway?

I've had a chance to look this over. While it is a substantial improvement, there are still many sliders that experience the same animation-breaking problems as before. The jaw bone has been discussed to death. All the major mesh head creators active in this thread are all saying that jaw bone must not get moved by sliders. I'm fairly certain that is a reasonable consensus. Aside from that, the new default jaw bone position right between the earlobes is pretty good, in my opinion! The eyelids are indeed much better, but the Upper Eyelid fold slider can still move the upper eyelid bone pivots down far enough that it will cause the eyelid to pull away from the eye when rotated down, or push backward as it's rotated up. The severity of this problem will vary from head to head, depending on how thin the eyelid is and how closely it follows the eyeball, and whether a round eyeball is used (vs. the tent-shaped default eyeball). This is another place where bones really should never move their pivot, as the effects on animations will be too severe. My suggestion here is to go with just scale, reduce the slider's range to about 25% of its current range, and/or just eliminate the slider completely. Animations will be the preferred method for controlling the eyelids, so all the eye sliders should have minimal effect here if they are going to be influencing the amount of rotation required to make the eyelids meet. Staying on the eye subject, the "Outer Eye Corner" slider is affecting a bone which is needed for animating the outside edge of the eyebrow. I don't know why it would be repurposed (dual purposed?) to the outer eye corner. Animating the eyebrows is far more important than reshaping the eyes. Besides, the paralyzing effect on the eyelids of weighting this bone onto the eyelids would be more trouble than it's worth. If there isn't going to be a separate bone for the outer eye corner, this slider needs to be abandoned for project Bento, as it will just confuse people as to what a proper weighting is for this bone. It appears that you did not make any substantial changes to the lip bones other than eliminating the unwanted influence from the mHead bones. While that fix is a major improvement, the bone positioning for the lips is still very problematic. Please move all of the bones to the center of the mouth so when they are rotated side to side, the lips will slide properly along the teeth. I posted many graphics demonstrating the problem in the thread (https://community.secondlife.com/t5/Building-and-Texturing-Forum/Project-Bento-Feedback-Thread/m-p/3041766#M15279) and (https://community.secondlife.com/t5/Building-and-Texturing-Forum/Project-Bento-Feedback-Thread/m-p/3041015#M15253) so this should be apparent now. The mouth corner bones are the most important ones on this issue, but really all of the bones should be moved to the center of the mouth (and a little to the opposite side, in the case of the lip corner bones. Obviously the JIRA I mentioned earlier will allow people to fix this in their own rigs, but it's much better if the default bone placement is more advantageous for the newbies who don't understand the problem of trying to animate with just rotations. The Lip Fullness and Thickness sliders are another place where the substantial translation of the bone pivot will cause animations to begin to malfunction. By increasing the distance between the bone pivot and the vertecies they control, any rotations made to the lip bones would have proportionally more effect, which could amount to some serious weirdness (especially if the initial bone placement is not optimal for the face/teeth contours). This is more problematic in the case of the Lip Fullness slider which translates the bones back into the face, but both will suffer from this effect. This is another candidate for a reduction in slider range by at least 50%. It is very important that the pivots on these most expressive parts of the face do not move much, since precise control is necessary for good animation. Likewise Lip Ratio does not need such an extreme range. Cutting its maximum effect by 50% would help keep things attractive.

https://jira.secondlife.com/browse/BUG-20049 was accepted, so the pro you listed is not needed. We will be able to freely define the joint position that best suits our meshes without worry. This design choice will be completely meaningless if the jaw angle slider takes that joint and moves it to a completely different position, though. It feels fairly odd to list the con as "when used wrong", since there's no way to really use it wrong. It is part of the rig whether you want it or not, and it is the end user who decides where to put their jaw angle slider. If they use it at all, things will go horribly wrong for them. So it's more like "when used, users will horribly distort face animations". And there is no pro.

You are mistaken in what sort of distinction is being made here. When it comes to heads, Bento is purely about replacement mesh heads. Just like when it comes to bodies, Bento is purely about replacement mesh bodies. There is nothing in project Bento that affects anything other than these types of third-party attachments. The default avatar mesh and its shape slider behaviors will not be affected in any way. People discussing the feature set in the project Bento meetings would be wasting everyone's time if they stopped to explain the basics of project Bento before proceeding with describing each new revision. If somone is relaying the content of these meetings to a ley audience, then it's on them to properly explain any relevant context (though they may have covered this in a prior post on the same subject).

Anyone thinking Matrice's proposed change would have any effect on the default avatar's blend shape deformations just has a fundamental misunderstanding of what project Bento is. There's no fault on Matrice's part for failing to explain that. If it comes to sacrificing the functionality of that slider vs. having it function as-is, there is no question that this slider needs to be disabled for Bento, though. The disruptive effect of making any mouth animations malfunction is far more of a problem than not being able to tighten or loosen your chin. These models will be created by your favorite designers, so theoretically the chin should already look pretty nice. Yes, it is possible to leavea it as-is and then try to tell customers that in order for your mouth animations to look right they need to set the jaw angle to X setting, but realistically that will only get through to a certain percentage of customers, with the remaining (more than half) never realizing that the gasp animation looks so odd because they changed something they shouldn't have. There shouldn't be any slider which has the kind of impact that the jaw angle slider has on animations. If some other bone can not be added or substituted, then 100% that slider needs to be disabled. Some businesses can get by with minimal time required for customer support. This would put that possibility completely out of the picture for a Bento head creator.

Translation animations are not like normal animations where the effects vanish once the translation stops, since there is no background animation with the joint in its original position to draw the bone back home. Unless Tapple Gao's JIRA is accepted which is requesting relative positioning for translation animations, the translation animations you are using will override any bone positioning from shape slider changes and leave the bones wherever they are when the animation stops. If you have exported the mesh without moving any of the sliders in Avastar, without using custom joint positions, and you are wearing the default shape, you can predict where the bone needs to go back to, but unless all three of those cases are true you won't be able to anticipate what the "home" position for the bone is, since that's a moving target. As it is, I think the only bones human head designers will be able to safely use translation animations on are the tongue bones for two reasons shape sliders will not affect the tongue bones with translations (after the next set of changes are available). the tongue is generally hidden when at rest, so any misalignments should be concealed. Other than that, there is a compatibility problem between shape sliders and translation animations for any bones that are translated by shape sliders. It's possible that the jaw will also be translation friendly, but I'll need to see the next iteration before I can say that for sure.

Medhue Simoni wrote: Hmmm, In my video, where I take a non human head, and make it work with a system made for human heads, I had little to no problems with those variations working almost perfectly with the animations I designed for them. Granted, I didn't show expressions, but at best I would need to make a few different versions of an expression to match everything fairly well. Which do you think is harder tho, to make a dog's head work with this system made for human heads, or a human's head with a system made for human heads? Which do you think is going to have more problems?Never mind that it wasn't a human head, you were showing a model which has overrided all translation effects from sliders, which is the entire source of the problem. It was irrelevant to the discussion of making the sliders function as they were intended to function. Medhue Simoni wrote: Is compatibility across designers now possible with most of their parts? I also think you are making many more assumption than can possibly be assumed. As far as weights, I haven't looked at them or tested them very much because I'm mostly doing animals right now. That said, I have every bit of confidence that the Machinimatrix team has done a decent job, and ....... that despite this, I'll likely tweak them anyways, as I expect every artist that is decent at weighting would. Some, yes, but basically the weights of the example head should represent the best case scenario for the balance of head slider/animation control. Those are the weights that were used to configure exactly how the sliders would scale and translate, what path they would follow, etc. In other words, that is how it was configured when the designer had full control over every element of the design. After Bento is set in stone, though, those original parameters are not changeable. Animators don't even have access to bone scale. What I've shown is that what is supposed to be the best case scenario doesn't actually work properly — not even close. Yes, you can disable half of the features and get something that works on a smaller feature set, but that's not what one would normally want out of a finished product. It is fine if it turns out that the facial sliders are just too complicated and they just need to be removed or substantially scaled back. If it gets to that point, that's another way to go. Releasing it with features that don't work, though, I should not need to explain that this is something usually avoided like the plague in the professional world. Think about Steve Jobs presenting the first Apple computer and it fails to say "Hello". That very nearly happened, but they scrambled at the last minute and managed to make it work the way they said it would.

There's no need for the sliders to match the range or exact appearance of the existing sliders other than in the most general terms. So long as the slider label describes what is happening to the rig, that's plenty. What isn't ok is when moving that slider breaks related animations. Human customers don't have the kind of patience for those malfunctions that furries have. They expect the things they pay for to work well without extensive configuration and troubleshooting. For your custom slider system, it is far more efficient to just lock all the bones in place and build a different head mesh to suit the different appearance than try to mix and match 100 animations. Aside from that, if the weighting on the model used to develop the sliders in the first place is not good enough to serve as a rock solid standard for all content, that is another missed opportunity for the grid. With every head designer going their own way in terms of how to weight the face, compatibility for animations and accessories is not possible. About the only thing that is guaranteed to be standardized is the skull in order to match hair.

Just a quick look at the eyelid situation I've alluded to several times. I could see it would be a problem just based on watching the bones move in the Bento viewer, but just today decided to actually put the model to the verify my suspicions.  To elaborate a bit further on this, in order for a head designer to try to fix this using custom joint positions and translation animations, the following bones would need to be locked: eyes, eyelids, eyebrows, inner eye corners All eye-related sliders would for the most part become non-functional, including ones which are primarily about scaling like "eye size" since they also use translations to keep the eyeball from growing through the eyelids. After locking all the bones that will cause animations to malfunction, you're pretty much just left with nose sliders and some semi-functional head shape sliders. For a thorough fix, the eyelids would need to pivot on the same pivot as the eyeball, and any adjustments would need to be limited to scale or translations matched with the eyeball. Possibly a child bone or two could be added to tweak the eyelid shape, though that would need to be adjusted with great apprehension and caution.

Please tell me why the Bento bone head sliders need to precisely reproduce the blend shapes of the base mesh. Why, for example, would the nose slider need to have exactly the same types of controls? (will probably be interpreted differently than I was thinking so struck it out). Is it a problem to remove (omit) nose sliders from the Bento nose, or for a slider to not have exactly the same range? You're mistaken on this point. And how exactly would I go about making my own slider system? A gazillion translation animations? There are limits to practicality here you're ignoring.

Medhue Simoni wrote: Mel Vanbeeck wrote: Edit: Oh I see what your issue was. I wasn't clear that I meant it's entirely about controlling mesh heads as opposed to the SL default head, which becomes irrelevant as soon as someone attaches a mesh head. My issue? Why exactly would I care so much about the SL default head? Outside of some jiras, I have no issues at all. If you are asking why I'm responding to you, I'm trying to help you. You keep stating all these problems, when the soluton for you is obvious. The real question should be to you. Why won't you use translation? I guarantee that other mesh head designers will be using translation, and yours will suffer for not. You took issue with me saying "Bento is entirely about controlling mesh heads.", but the entire sentence read "There is no real reason this needs to mimic the slider behavior of the base head, Bento is entirely about controlling mesh heads.". You felt it needed to be reiterated that Bento wasn't just about heads. I agree, but the head is where these problems lie, so that's what we're talking about.

Did you use any custom bone positions? Have you tried any animations with it?

Use the mFaceJaw only for animation but not for weighting. This avoids that changing the Jaw angle slider modifies the mesh So you'd have to weight your jaw to the lower teeth bone instead. This is one way to avoid a completely broken rig component, but then you still have to ↓ Set the Jaw angle slider to specify your favorite jaw pivot point and tell your customers which slider value is the optimal setting for your creation. One more way to try to avoid a feature that completely malfunctions when used. Then cope with the regular backlash from annoyed customers who don't understand why it doesn't work the way it's supposed to. Realistically you have to ↓ If you do not trust your customers then add a joint offset to mFaceJaw This make the jaw bone keep its joint position) One other possible solution to this problem: We could add one more bone that only is used for defining the jaw angle. But this sounds like overkill to me. ...then do the same for the rest of the bones in the face. How do you figure that second paragraph is overkill? Right now, the only way to have a jaw which can be animated is to completely disable all translations from that slider. If you lock it with a custom joint position, you must include all the chin, lip and mouth bones as well, since you can't have the lower lip bones locked in place while the upper lip bones get shifted around by mouth slider translations. What you have there is completely broken slider system on the lower half of the face, and the way the eyelids will go is much the same. You only get to launch Bento once. I realize that making changes to this stuff is a crazy amount of work, but that's why work like this wouldn't normally be handled by volunteers. I just don't see how that is a reasonable choice for a product as significant as SecondLife's facial rig. You can't just launch something that's this insanely broken.

It's not entirely about controlling mesh heads, but that is certainly a key part of the project. These behaviors are not helpful to any kind of creation, though, and bone translations "fix" it by disabling the feature that is broken. Sort of like removing the shift lever fixes a car that is stuck in first gear. Edit: Oh I see what your issue was. I wasn't clear that I meant it's entirely about controlling mesh heads as opposed to the SL default head, which becomes irrelevant as soon as someone attaches a mesh head.

What is pictured above should be fairly shocking to you, but for some reason you seem to be ok with it. Sorry if this sounds harsh, but this is not some class project — this is the facial rig that will determine how half a million SL users' expressions will look for the foreseeable future. This is the sort of decision that later results in "Unfortunately we can't fix it now without breaking content, so despite its problems we're stuck with it. Maybe someday we'll build an avatar 2.0 and do everything right.". The problem is not limited to a mouth that can stick out like a cash register drawer or shrivel up like you know what on a cold day when it's supposed to simply be yawning. There are other major issues as well, but aside from that, think about the difference between a "bored" expression and a "displeased" expression. The difference is minute, but properly exectued, humans can tell one from the other. Unfortunately, with these types of wildcards in a rig, there isn't a prayer of even approaching these kinds of subtle changes of expression with any sort of consistency, much less avoid veering off into something utterly disturbing if it turns out someone decided to tighten up their chin. It is entirely possible to build a facial rig that supports both sliders and animation which works extremely well for both. There is no real reason this needs to mimic the slider behavior of the base head, since Bento is entirely about controlling mesh heads. It is not something that is simple to accomplish, but it can be done. Whether Bento stops short of that standard is obviously a decision beyond my control, but I really hope it doesn't.

I don't think you moved the sliders that are relevant, based on what you're saying. This is the same exact simple jaw rotation animation on 3 different shapes.  Obviously we can't expect perfection at all extremes of the shape sliders, but this is what I mean when I say that the nature of the pose changes drastically based on how these sliders are set, even when you're working with modest adjustments. The jaw pivot is not such an arbitrary thing that it can move around this much without issues. The eyelids will suffer the same problems with their pivot moving all over the place from various eye sliders. This leads to the general point about a major conflict between the same bones being used for sliders and animation. When your verts have such light weighting to bones that will be used to animate it, the sliders will always be causing significant changes in the relative position of joints to the verts they control. Take the lips on this example. The jaw opens and the lips don't stay with the lip bones, so lip rotations will start pulling them in a completely different direction. Sometimes this is fine if it was an animation which caused the lip bones to change relative to the lips and that would be compensated for by the same animator who opened the jaw, but when it is shapes causing the change things go out the window. In this the third photo the lower lip bone pivots are now inside the lower lip, so they can no longer be used to control the lower lipat all. In the standard shape, the lip bones are situated straight back from the lips by a few cm, so they could be used to some extent to cotrol the lower lip. In the second photo, the lip bones are twice as far when compared to the first photo, so those same compensations you use for the standard shape would have the effect doubled. To make this completely unworkable, you've got users moving sliders inviting more errors as vertecies get animated on pivots that are being moved 3-4x as far as the shape change they represent. This can't be compensated for by the animator, since it's a moving target.

Nice helpful video to help visualize where the pivot should be for proper jaw movement. The key point is at 1:05

Well, the position of the jaw bone as the pivot for the jaw is not a trivial thing which can happily be shifted up and down without consequence. This situation would cause animations to behave very differently depending on one's shape, which is not the desired outcome. I would suggest that these jaw angle/chin depth sliders should probably not affect the jaw bone at all (since it is mainly supposed to represent the temporomandibular joint), but possibly a new bone should take over that role if it is needed. You could actually probably recycle the teeth bones, since if you keep the jaw bone behavior similar to how your real life jaw bone behaves, then you really don't need teeth bones. However, there are several other ways that the teeth bones could be repurposed which I'd actually be sad to see go, so I'd really just suggest adding a new child to the jaw bone to serve the jaw-related sliders.

The likely reason this worked somewhat well is that the sliders are expecting almost no weight to be on the jaw bone itself for verticies in the jaw (otherwise you wouldn't be able to move the jaw bone 30cm up and down without sucking your neck up into your brain and introducing your chin to your eyebrows). Reducing the weight of a vertex to say 5% virtually moves the bone's pivot point 95% of the way toward that vertex, as shown by the doppler-like circles of vertex influence in one of my previous graphics, significantly reducing the range of movement of that vertex compared to its distance from the bone. Regardless, with these sliders in one case you have the pivot below the actual jaw, and in the other you have it up above the jaw. This means that at the upper extreme rotating the jaw down will cause the jaw to move down and back, while the lower extreme will cause the jaw to rock down and forward — two completely different types of jaw movement for different types of expressions. Unless there is a different pivot that isn't in the same location as the jaw bone which is counteracting that massive range of movement, I don't see how this could be even remotely workable for animation. It's not necessarily a question of whether it looks like something the jaw might do someday, some time. It's a question of whether that one rotation setting makes the same type of expression as you move the jaw pivot around, since you'll be moving all the the other bones expecting that the influence from the jaw is going in a certain direction. Aside from that, if I'm not mistaken, simply overriding the mFaceJaw bone would not be enough, since the slider offsets all the child bones of that bone to counteract the large changes to its position, so you would also have to override all the lower lip bones, the tongue bone, and the chin bone as well —essentially paralyzing the entire lower portion of the face from any translation-based slider effects.