1 Slider, 2 Attributes
Okay, so I tought this would be really simple, but I haven't been able to solve it.
What I want is to make one slider. Standard on the 0 value. Where the value of 0 to -1 follows one blendshape and 0 to 1 follows another one.
Here's the script with two sliders:
I tought if I could somehow make clear that it was the same slider the min and max values would solve it. But I haven't been able to do so.
So here's my latest attempt.
However it's probably rubish, especially the proc. I think it needs something to help determine the values, maybe a ramp or clamp?
Hopefully someone knows how to solve this.
A couple of suggestions for you:
First, instead of using two 'if' statements, use one 'if' and then an 'else.' Right now, if the slider value is exactly zero, neither of those 'if' statements will evaluate.
Second, watch your typing... you've got one '–at' and one '-at' in your procedure. See the difference? One uses a dash, and one a hyphen. MEL understands the hyphen, but the dash will throw an error.
Third, your setAttr commands aren't actually setting the attribute in question. You need to actually read the value of the slider and then pass that value to the setAttr command.
Finally, in addition to setting the desired blendshape value, you need to simultaneously set the other blendshape value to zero, otherwise when the slider crosses zero you'll get a mix of both effects.
Hope that helps,
Okay, so played around with it a bit. I got a better understanding of the formLayout and some experience with the procedures while making checkboxes and radiobuttons. So I finaly was able to get the slider! yay! But when I adjust the slider I get: // Error: Object's name 'mySliderGrp' is not unique.
Why? I added the name to the floatSliderGrp, then attached it to the form and then used it in the procedure. So it's unique right? I'm guessing the problem is the combination with the slider. Right? Probably because it only happens when I slide it.
Besides that error I still need to fix the feedback of the slider. I think I have to first make a slider that automaticly adjusts itself to the ty of the cube? Do I still do it in the global procedure? is there any "Get value" function?
(I abondoned the blendshapes, hoping adjusting the height would be easier)
So yeah, strugling with point 3, so plx another nudge in the right direction. ^^
When you use the 'floatSliderGrp' command in your 'if' statements, you are neglecting to use the '-query' flag. Without '-q' Maya assumes you are trying to create a new floatSliderGrp, not find out information about an existing one. Hence you are getting the 'name is not unique' message; you are trying to create a new slider with the same name as an existing one.
As a note on good practice, rather than specify a particular name for any script-created object or control ("pCube1" or "mySliderGrp"), it is better to take the extra step of setting a string variable equal to the name of the created-and-named object, then simply refer to that variable throughout your script.
The rationale behind this is that you can never predict what will be happening in the environment in which you run your script. What if you run it in an instance of Maya which already has a script-created window with a control called 'mySliderGrp', or (more likely) already has an object called 'pCube1'? Your code would then be referring to the wrong thing. If instead you create something and simultaneously capture its name as a variable, you can then safely refer to that thing using that variable. It's more awkward to code at first, but it's the better practice.
So, for example:
Also note that when you query a control, you usually have to specify what property it is you want to investigate. In this case you probably want the '-value' flag to query the slider's value.
When I try this using your script, I still get an error about the returned data being of 'no type'. Declaring a float variable and setting it to the results of a slider value query, then having the 'if' statements compare that variable (instead of each running a query themselves) seems to work. I also tweaked your conditional statements; I'm not sure exactly what effect you're after:
Hope that helps!
Note also that another (better?) way to do this would be to give the object a single custom attribute which the slider controls, and then use Set Driven Key to have that single attribute control the two blendshape values simultaneously. That would give you more control over the relationship (you could overlap them slightly in the middle, e.g.).
I actually used that trick with the set Driven Key with the feet. Where I needed to adjust two things at the same time: Making the model stand on her toes and altering the blendshape of the shoes to create heels. It worked perfectly for that but it never occured to me I could do the same here. So yes, exilent plan B. ^^ However I don't want to drown in added attributes so I'm still going to try and get this script working. I'm almost there. I only need to find a way to reverse a negative blendshape to a positive blendshape.
Here's the script so far. As you can see, it has two adjustable blendshapes. But it takes the second blendshape towards the negative values.
I only need to *-1 the blendshape and it should work. But it doesn't like me adding math to the set Attribute... :/
When you're trying to add math to commands you are often required to put it in parentheses. So this might work:
Another way to get rid of a negative number is with the abs() function. abs($mySliderPos) will always return a positive value.
Remember you're still going to need to add some extra code to zero the unwanted blendshape in both cases, since I assume you don't want them to overlap and add to one another.
Hope that helps,
I don't see any overlapping of blendshapes. Maybe it's because of the way I set up my project. The base model is 0 and if the slider is > 0 it will follow one blendshape and otherwize it will follow the other blendshape. Or maybe because the values are so small it's hardly notisheable? I don't know. But it works like a charm now. ^^ Here's the full script if anyone needs it.
Just so you know, you will be honorably mentioned in my report and the presentation reel. You've helped me out with so much so far. T.T I'll make sure you'll get a glimpse of it when it's done...
Look carefully at the blendshape values that show up when you use the slider. I suspect that after you slide past zero in one direction or the other, you'll be left with nonzero values on the blendshape you just moved 'away' from. You may not see it on the model because, as you say, the values are small--perhaps 0.1, 0.2.
Try this, though. Drag the slider all the way to -1. Now, instead of dragging, type the number 1 in the text entry field. You probably won't see a change right away (if you want to be able to do this you should set '-changeCommand' to your procedure as well as '-dragCommand'--sorry, I overlooked that earlier). But if you now drag the slider a little bit, you should see the model jump to a state where both blendshapes are fully active and overlapping.
Again, the act of dragging the slider past zero doesn't explicitly zero the blendshape value for the one that you're moving 'away' from. The fact that you've used the '-dragCommand' flag means that as you slide past zero you'll pass through a point very close to zero for that blendshape, but chances are a small nonzero value will be left behind--which might even depend on how large your slider is and how quickly you drag with your mouse. Adding code to explicitly zero competing blendshapes is definitely a good idea.