I’m setting up facial controls on a rig, in this case bones which drive shapes, much like the ManCandy rig.
The attached jpeg is a driver on a bone called JawControl, which drives a shape called jawdown. The movement of JawControl is downwards, from the 0 value to the -.5 value, and the shape’s value should go from 0 to 1 (or a bit over).
This is all working fine, and if you look at the curve, it’s pretty much just as I want it (the curve overshoots the 1 value a bit in the y axis just to get a little follow through). So, if it was just me and my rig, I’d be all set, because the driver is working fine. But because I’m trying to write a detailed explanation of this, I don’t want to just gloss over things I don’t understand.
The detail here I don’t understand is why the Ymax field of my driver here says “7.80”. And if I adjust it, it bounces back to 7.80 no matter what I do. It seems to have no relation at all to the actual maximal value of y.
Anybody have any idea where that number is coming from and why it’s not about 1.6, as it is in the curve graph display?
Unfortunately, I cannot figure out how on earth you’ve got that problem. When making a test case myself, I didn’t encounter any problems of this sort, and checking the code reveals nothing unsavory.
Have you tried manually (numerically) adjusting the upper vertex, then trying again? It might help…
Yes. Believe me, I wouldn’t be worrying about stuff like this if it wasn’t. The driver works fine, as I said. But, it’s just not very professional to be saying “and, uh, just disregard the value in that box, it doesn’t make any sense to me either…”
Anyway, I tried putting the value into the vertex field manually, but the value there was already correct anyway, and it did nothing. The value in the Ymax remained 7.8.
Here’s some further diagnostics.
If I hit an arrow key in the Ymax field, say down to 6.8, it will go down to 6.8, and the vertex on the curve will move down to another, apparently unrelated value (actually, it goes down approximately by .2, but seems to be different every time). Then the number in the Ymax field will magically bounce back to 7.8. The curve vertex value does not bump back up, it stays where it was changed to.
If I set the vertex postion numerically or if I edit the curve, that Ymax value isn’t affected.
The shape slider for that shape has a range of zero to one. Nothing strange seems to be going on there.
Edit: The only way I can reproduce the effect is to have a second shape channel selected. Have you scrolled down the list to make sure nothing is selected down off screen?
I checked and there are no other channels selected, all shape keys slider values were at zero… I deleted what keys were in the action editor window and also deleted a few other drivers I had set up, so now there are no shape keys keyed anywhere except for this one driver… still Ymax is 7.8.
7.8 is the Y-Max to which the IPO-Curve can go, beyond which the shape will ‘hold’ (to use an NLA expression). You have the left CV set at 1.6, but, if you drag it up the 7.80 value will change once you pass 7.80.
(lotta downloading for so small a bug, man… giggle)
I see. Thanks for the explanation… and sure enough you’re right about the value going higher. But… why 7.8? Is this automatically calculated? Why isn’t that value at the max value I set for my shape sliders? How can I make it go lower? 780 percent is a lot more leeway than I need…
(lotta downloading for so small a bug, man… giggle)
With regard to the size, I just hope you picked the 2 MB version and not the 15 MB version (my unsolicited “explanation” is that I’ve been doing a lot of rendering online lately and I’d just gotten in to the habit of uploading packed files, didn’t think to unpack it)… with regard to the pun, I’m at a loss for words.
Hehe… I got the 15MB one but no problem, there were no more bots trying to assail me.
Theeth is the one to ask about how that 7.8 is arrived at. I’ll take a wild guess and say it’s some measurement of the median point of the translated verts of the Shape key relative to the Object center (Ob Data relative to Object), represented by “1” in the sliders to avoid having to deal with a graphical representation of scale.
I’ll take a wild guess and say it’s some measurement of the median point of the translated verts of the Shape key relative to the Object center (Ob Data relative to Object), represented by “1” in the sliders to avoid having to deal with a graphical representation of scale.
LOL. So I guess my explanation will read “disregard the value in the box” after all…
Far be it from me to question Fligh’s explanation but I think I’m going to question Fligh’s explanation. “That’s the number it stays at until it changes”??? What?
I made a simple little test with a bone and the default cube and a few useless shape keys. I set the driver and could not get it to match your description except when I had two keys selected in the IPO window. Then it behaved exactly as you described. Since that isn’t your problem, I’m at a loss. But if my Ymax didn’t default to 7.8 I can’t see why yours should - that just wouldn’t be fair - we should all the get the same goodies.
I’m at work now but I’ll see if I can have some fun with your file tonight (Gee, I hope Fligh isn’t right after this. That could be embarrasing).
What Blender version are you using? Have you tried it in other versions? Have you tried re-creating the problem with a simple setup from scratch? Is it reproducible or is it this one file?
As for the book, if all else fails write “Ignore the 7.8 number for now, we’ll cover that later” - just don’t mention how much later you plan to cover it.
Yeah, I’d been wondering that too… if I can’t go above it, how come I can go above it?
But if my Ymax didn’t default to 7.8 I can’t see why yours should - that just wouldn’t be fair - we should all the get the same goodies.
I assume it’s somehow calculated from the mesh itself and considering something about the actual vert positions. If that’s the case then the number might be kind of mesh-specific or shape specific (although other shapes in the same mesh have the same and different values in there…)
What Blender version are you using? Have you tried it in other versions? Have you tried re-creating the problem with a simple setup from scratch? Is it reproducible or is it this one file?
2.42. I haven’t noticed this in simpler sample setups. Seems to be this mesh, but as I said, if it depends on the mesh then it may be only possible to reproduce with a similarly complex mesh. I could of course try deleting some verts and seeing how things change… but I haven’t been able to give it the intense attention that it so clearly deserves…
As for the book, if all else fails write “Ignore the 7.8 number for now, we’ll cover that later” - just don’t mention how much later you plan to cover it.
I was thinking of leaving it as “an exercise for the reader”…
By the way, this is a separate question but closely related and I don’t think it needs a new thread…
Is there a way to look at the local transform properties of bones in IK chains directly? I want to set up a driver on the rotation of a bone in an IK chain, and actually I was able to do this, but only by adjusting the curve by trial and error, because when I looked at the transform properties themselves they all read zero all the time.
Hmm… while coding my Transform Limiting Constraints, I was thinking whether it was a good idea to add some buttons to the transform panel which let the user choose what stage of transforms should be displayed. I think that theeth would be a good person to ask on these matters…
I haven’t had a chance to check out your patch. Is there a 2.42 build out with your patch in? I’d like to use the tranform constraints… they seem like a cool idea. And choosing the stage of transforms to be displayed would be fantastic. I think it would definitely take some of the guesswork out of setting up drivers.
I’m afraid to say I didn’t have a single clue (heck, I barely knew the basics about drivers), but I investigated a bit.
I’m still not sure how it’s linked, but that value (and the other min/max values) seems to be related to the Key Y value of the key curve (it’s displayed in the Properties panel when you’re not in edit mode). In a simple test I made, it was a 1 to 1 mapping, but in bugman’s file, it’s a little weirder than that.
A challenge to the reader I’d say.
Actually, that’s not quite the problem in this case (local/global). The problem is that by using an IK constraint, you’re overiding the “user” rotation with the constraint. The “user” rotation being the one set in the Properties panel.
To display this (keeping in mind those values would be read only) would probably mean adding a toggle to that panel (kinda like the Local/Global switch in edit mode) to display the “final” transform properties. That would also mean you’ll most likely get normalized values for rotations (since extracting euler angles from a matrix is funny at best), that is, values between 0 and 360 degrees.
It would be possible though, that much is for sure.
Thanks very much everybody for all your observations. I feel more comfortable putting this 7.8 in the “don’t know, don’t care” file for now. It’s clearly something that an introductory book on character animation doesn’t need to be worrying about.
I think the only point I need to make is that that field is not where you should be putting your desired y value, but rather you should be setting the control points of the curve as you want them directly (either in the position fields or by editing the curve by hand). That in itself his helpful to know.
