I’m making a ‘collision box’ rig where the dimensions of a simple box need to be controlled by controllers on all 6 of its faces. Moving one of these controllers around stretches the box along the respective face, while keeping the other faces in place. This part is doable, but in addition to the controllers, I also want the user to be able to select the box to move the entire rig. Trouble with this is that the position of the box already depends on face controllers.
I could set up an extra parent controller that moves the entire rig, but I want to keep the rig minimal. How can this be setup to work so that the user sees ONLY the box and the face controllers?
is this a 3DS Max box object?
Maybe add a second box…
box a = what you have
box b= new box
box a and controllers are children of box b
box b.length (&width, height) = box a.length (&width, height) (probably via script controller)
hide box a (not its controllers)
if its in maya i think you should create a plugin or something with a smart scriptjob for that.
i tried it just now with clustering but having multiple clusters on a single vertex gives it double transforms
joint skinning might work if you do not normalize the weights to allow overshoot, but this might also cause the same double transforms,
you can also counter the double transforms by connection the maincontrol worldmatrix as a reverse in the box world matrix (or something like that)
If something is giving you double transforms, but not throwing circular dependency errors, you could wire the transform changes negatively onto it self.
I’m not sure if I’m understating correctly, but wOuldn’t you simply be able to parent the controls to the box then drive the collision rig with the controls via local space transform?
Mambo - box b will get the length, width and height but it wont get the position of box a
peerke88 - I’m using max, i dont know if there’s a way to script plugins in max where nodes can be set to react in real time to other nodes, without actually being wired to them.
The way the rig works is that when you move one of the controls, the box squeezes within the confines of the controls. For that to happen, the box will have to move (by exactly half of the distance covered by that control object) to stay in the center of the controls. As long as the position of the box is influenced by the controls within the rig system, i’ve come to the conclusion there is no (apparent?) way to use that very box or any of its dependents to influence the ENTIRE system.
For now I am using a separate control parented to the system to move the whole rig. Which, I did not want to do in the first place.
The problem is relatively simple but impossible to resolve without some sort of plug in that works outside the dependency graph. General rule is you can’t drive an object with another object and drive the driven object with the driver object, as there is no solution for cyclic dependency.
But there’s always a solution for specific issues(often times quite painful though), in your case you would simply have to calculate the vertex positions of your box at the local level with your controls so you can parent the controls to the box. So in effect your boxes world space transform is the top of the chain then the controls and the vertices are both children of the boxes transform.
But common practice is using a parent object because the time put into developing a way to do it vs the small convenience is never worth it.
++ to that, the dependency chain for an object is a logical necessity. The only logical alternative is a simulation - like physics - where objects interact with each other iteratively. If you go that route, though, you’re really just moving the hierarchy implicit in the evaluation order into time: a frame of physics depends the sequence of time , where a keyframe in conventional kinematic animation depends on the evaluation order of the rig.
And, if you’ve ever done simulation animation you know it’s a pain in the butt, since you can’t just say “I want it to look like this at this time.”
This is quite a simple task if all you want to do is move a particular face along its normal vector, just create 6 morph targets which showing each face moving as described, load them onto your main object, create six controllers and link them to the box containing the morpher modifier and then do a wire parameter between the relevant targets and the relevant control axis. Doing it this way avoids double transformations because all your doing is using the control to drive the target weight attribute rather than trying to control the transforms of the objects’ vertices.
-Harry
EDIT: If you want to move each face in XYZ then you’d need to create 3 morph targets per face, one for each axis. Of course this setup doesn’t work if you want to rotate the controls, but you didn’t mention that that was something you wanted.
Ohk, that is a really cool way to use the Morpher modifier, thanks Hazmondo! It seems to work counter intuitively to the actual influence hierarchy since it acts on the box’s local space. This is also a caveat since in addition to this setup, I needed to extract the transform of the box that I get as a result of the deformation. Which means if the box is compressed, it should reflect the corresponding scale change that would cause that compression (similarly also get rot and pos). To achieve that I created another box (hidden) that calculates those values through math in script controllers and constraints connected to the face controls. It looks like i have everything i need!
It’s gotten me thinking if using local space transforms is a common technique used to circumvent the node dependency graph in rigs. Do you guys know of any other examples?
[QUOTE=peerke88;25383]i managed to pull it off in maya as well without plugin, used blendshapes and clusters
so if anyone want to check how it can be done in maya:
select the vertices for each facet of the cube and create a Cluster.
parent all six clusters to the cube.
set each cluster to Relative.
Each cluster handle can be used to control the shape of the cube, and the clusters follow the cube when it is moved.
Change the Move Tool to Object Space so when the Cube is Rotated, you can still move the clusters in the plane defined by each side of the cube.
You can also lock the translation of the Clusters so they can only move along the normal of each facet (if that is also a requirement).
I didn’t need any blendshapes, I’m not sure how they are useful?
tried just clustering as a first try (also with relative) but somehow maya did not want to work properly, thats how i came up with the new setup with blendshapes as they work additive when they are all active at the same time
next time ill restart maya a couple of times just to be sure
also editted the zip file above, the 14.3kb file should work propperly