I'm trying to build a shaking chandelier. It's symmetrical with many spokes but I don't want to build identical constraints for every part.
Is there are a way to do this efficiently? (DOP copy sop!)
Video:
http://www.vimeo.com/10712645 [vimeo.com]
Below is an image of the already overly crazy network.
Many many constraints
28487 28 6
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
-
- johner
- Staff
- 809 posts
- Joined: July 2006
- Offline
Have a look at the ApplyRelationship DOP.
Also see this thread [forums.odforce.net] over at odForce for a simple example of it in use.
Also see this thread [forums.odforce.net] over at odForce for a simple example of it in use.
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
thanks, not sure I understand quite how to transfer and implement it to my scene, but I'll keep messing with it.
In the meantime, perhaps it helps if I send a simplified scene. The DOP simulates one arm. I then import it into a sop network and copy it there, but as you can see it doesn't quite work because the center piece rotates as well.
In the meantime, perhaps it helps if I send a simplified scene. The DOP simulates one arm. I then import it into a sop network and copy it there, but as you can see it doesn't quite work because the center piece rotates as well.
--
Jobless
Jobless
-
- drew
- Member
- 117 posts
- Joined: July 2005
- Offline
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
Very tricky that node :shock:
I am trying to place the constraints on places. I know from the previous file that:
dopoption(“.”,$OBJID,“Position”,“pz”)
puts the constraints to the object centers, but I want them at specific points or pointgroups. So I thought the following expression could do that, but it doesn't:
point(“../applyrel1:”+$OBJNAME,0,“P”,2)
or
point(“../applyrel1:”+$OBJID,0,“P”,2)
Why not?
EDIT: I think this works for points, but I don't know about groups:
point(“.:” + chs(“group”) + “/Geometry”,0,“P”,1)
I am trying to place the constraints on places. I know from the previous file that:
dopoption(“.”,$OBJID,“Position”,“pz”)
puts the constraints to the object centers, but I want them at specific points or pointgroups. So I thought the following expression could do that, but it doesn't:
point(“../applyrel1:”+$OBJNAME,0,“P”,2)
or
point(“../applyrel1:”+$OBJID,0,“P”,2)
Why not?
EDIT: I think this works for points, but I don't know about groups:
point(“.:” + chs(“group”) + “/Geometry”,0,“P”,1)
--
Jobless
Jobless
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
Hmm. I think I understand now how to use this node to create chains. Very useful and very amazing. I learned a lot of new DOP stuff with it.
However, I'm not sure my problem requires this node. Rather than generate constraints procedurally and one by one, I need to use existing constraints/objects and copy them.
It's like spokes on a wheel. Make one and copy-rotate the rest in a circle. I can easily do this in SOP but not with the constraints in DOP!
However, I'm not sure my problem requires this node. Rather than generate constraints procedurally and one by one, I need to use existing constraints/objects and copy them.
It's like spokes on a wheel. Make one and copy-rotate the rest in a circle. I can easily do this in SOP but not with the constraints in DOP!
--
Jobless
Jobless
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
And this here completely baffles me. I have two nearly identical setups, with identical apply-relationship and constraint nodes. One works the other doesn't and I have no idea why. Something to do with the expression in the constrained location:
centroid(“.:” + chs(“group”) ,D_X)
It works in one file, but not the other. Why not?
centroid(“.:” + chs(“group”) ,D_X)
It works in one file, but not the other. Why not?
--
Jobless
Jobless
-
- johner
- Staff
- 809 posts
- Joined: July 2006
- Offline
I haven't yet had a chance to look at your files, but generally speaking, I don't think there's a way to copy constraints.
You might need to do something like create attributes in SOPs that represent the positions of the constraints, then read those in in DOPs. I'll try to create an example when I get a chance.
On a different note, have you tried any non-DOPs solutions for this? Is the shaking effect all you are trying to achieve or does it then need to fall to the ground or something? As you've found, ApplyRelationship is really powerful, but a bit tough to figure out.
If all you need is the shaking, you might be able to use a rigged solution along with CHOPs to give the dynamic spring motion. I put together a quick example just using the MotionFX Jiggle effect. At the moment it looks a bit like a spastic octopus, so you'd need to do some serious parameter tweaking, but you should get the idea.
The basic workflow in this example is to use the Bones tool set to “Forward Kinematics” to lay out the bones, then add use the Jiggle tool to add Motionfx to each created chain_goal. Then parent the different pieces to the bones. Make all the CHOPs references relative (not done by default
), collapse into a Subnet, then copy and paste for each arm.
You can delete arms 2-6 in this example, tweak arm_1, then copy and paste again. If a CHOPs solution is sufficent, it's pretty nice, since it's quite fast and you can get close to immediate feedback on parameter changes.
You might need to do something like create attributes in SOPs that represent the positions of the constraints, then read those in in DOPs. I'll try to create an example when I get a chance.
On a different note, have you tried any non-DOPs solutions for this? Is the shaking effect all you are trying to achieve or does it then need to fall to the ground or something? As you've found, ApplyRelationship is really powerful, but a bit tough to figure out.
If all you need is the shaking, you might be able to use a rigged solution along with CHOPs to give the dynamic spring motion. I put together a quick example just using the MotionFX Jiggle effect. At the moment it looks a bit like a spastic octopus, so you'd need to do some serious parameter tweaking, but you should get the idea.
The basic workflow in this example is to use the Bones tool set to “Forward Kinematics” to lay out the bones, then add use the Jiggle tool to add Motionfx to each created chain_goal. Then parent the different pieces to the bones. Make all the CHOPs references relative (not done by default
), collapse into a Subnet, then copy and paste for each arm.You can delete arms 2-6 in this example, tweak arm_1, then copy and paste again. If a CHOPs solution is sufficent, it's pretty nice, since it's quite fast and you can get close to immediate feedback on parameter changes.
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
I'm getting the hang of the apply relationship node. I can figure out more or less how it works but there is some deep deep mystery about how to get at geometry/object/group positions.
As I said before, sometimes this seems to work, and sometimes not:
centroid(“.:” + chs(“group”) ,D_X)
Then there is this:
dopoption(“.”,$OBJID,“Position”,“pz”)
Now, $OBJID is sometimes is interchangable with $OBJNAME and ch(“group”).
And this
“.:”
seems to be equivalent to:
“./”
We can't use $REL as is, but instead we have to turn it into “something else” and refer to it as:
stamp(“../apply”, “REL”, 0)
To refer to points we can use something like:
point(stamps(“../applyrel1”, “SOPPATH”, “”), ch(“ptgroup”), “P”, 0)
Where SOPPATH is, again, a “special something” we do in the apply node.
We also seem to need to use $tx instead of $TX, or sometimes “px”.
???
As I said before, sometimes this seems to work, and sometimes not:
centroid(“.:” + chs(“group”) ,D_X)
Then there is this:
dopoption(“.”,$OBJID,“Position”,“pz”)
Now, $OBJID is sometimes is interchangable with $OBJNAME and ch(“group”).
And this
“.:”
seems to be equivalent to:
“./”
We can't use $REL as is, but instead we have to turn it into “something else” and refer to it as:
stamp(“../apply”, “REL”, 0)
To refer to points we can use something like:
point(stamps(“../applyrel1”, “SOPPATH”, “”), ch(“ptgroup”), “P”, 0)
Where SOPPATH is, again, a “special something” we do in the apply node.
We also seem to need to use $tx instead of $TX, or sometimes “px”.
???
--
Jobless
Jobless
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
-
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
Soothsayer
We also seem to need to use $tx instead of $TX, or sometimes “px”.
???
Almost all DOPs can refer to the value of each parameter from the previous time step. Each parameter becomes a local variable this way.
$tx or more generally any parameter name in lower case preceded by a $ will fetch that parameter's previous value for the local node.
It's in the help on each and every DOP. It's that note after the local variables.
If the DOP processes objects in turn, then you get each value for each iteration.
That is what you are doing here. You are picking up the local parm value for “tx” and “px”.
As for $TX and upper case variables, you'd have to check the help for that DOP to see if it is supported.
There's at least one school like the old school!
-
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
Sorry I didn't get to this sooner. I have been swamped as of late.
Here's a file I will have committed to the help cards for the Apply Relationship DOP.
It's of a collapsing bridge. There are four DOP networks in there that step you through the working up of the final version that has random positioning of constraints snapping after colliding with an RBD object.
The approach I take is to just get a constraint going for one case. Then figure out how to stamp in to that one object. After that, it is a simple matter of copy and pasting to apply more constraints.
The beauty of this system is that new objects added to the system automatically receive the constraints.
I load nodes with comments so don't forget to MMB on SOPs to get context help.
Here's a file I will have committed to the help cards for the Apply Relationship DOP.
It's of a collapsing bridge. There are four DOP networks in there that step you through the working up of the final version that has random positioning of constraints snapping after colliding with an RBD object.
The approach I take is to just get a constraint going for one case. Then figure out how to stamp in to that one object. After that, it is a simple matter of copy and pasting to apply more constraints.
The beauty of this system is that new objects added to the system automatically receive the constraints.
I load nodes with comments so don't forget to MMB on SOPs to get context help.
There's at least one school like the old school!
-
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
-
- Soothsayer
- Member
- 856 posts
- Joined: Oct. 2008
- Offline
Thanks Jeff. There is good information in this file.
Maybe I am missing something but I still cannot see how to procedurally copy elements in a radial way.
I now understand the way I can make copies along a line, or a curve, and create anchors on points, and constrain procedurally, and it is very powerful, but making copies in a rotational symmetry kind of manner seems to require something more, or entirely different.
Okok, I'm going on about this a bit too much perhaps.
ops: I'll keep trying a couple more days and then give it a rest.
Maybe I am missing something but I still cannot see how to procedurally copy elements in a radial way.
I now understand the way I can make copies along a line, or a curve, and create anchors on points, and constrain procedurally, and it is very powerful, but making copies in a rotational symmetry kind of manner seems to require something more, or entirely different.
Okok, I'm going on about this a bit too much perhaps.
ops: I'll keep trying a couple more days and then give it a rest.
--
Jobless
Jobless
-
- goldleaf
- Staff
- 4159 posts
- Joined: Sept. 2007
- Online
Hope I'm not hijacking your thread, but this has been interesting to follow. However, I've been trying to get this to work with ODE, and it doesn't like Apply Relationship DOP for some reason. Is there something I'm missing?
The hip file is the help card example file, but modified for ODE.
The hip file is the help card example file, but modified for ODE.
I'm o.d.d.
-
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
-
- goldleaf
- Staff
- 4159 posts
- Joined: Sept. 2007
- Online
-
- johner
- Staff
- 809 posts
- Joined: July 2006
- Offline
johner
You might need to do something like create attributes in SOPs that represent the positions of the constraints, then read those in in DOPs. I'll try to create an example when I get a chance.
Looks like you've already figured out a way of doing this, but I finally got a chance to put together an example of what I meant here. It is indeed a little frustrating that you've got all these great tools for copying and transforming things in SOPs, but have little access to them in DOPs when it comes time to create constraints. So I was referring to the idea of using these same tools to add attributes to certain points that will then each represent a constraint, with those attributes being the parameters to the constraint.
In some cases these points can just be placeholders, i.e. not part of the sim geometry at all; you just create them at the same time as your copy-stamped geometry using similar geometry, parameters, etc. and reference them within the DOP sim. So you use an ApplyRelationship node with an “npoints” expression in the Number of Relationships field, then for each constraint reference the current “constraint point” using the $REL variable (or stamp). I'm attaching a simple example of spheres copied onto a circle, each with three procedurally placed constraints above it with varying spring strengths, etc.
You can also do things like designate certain points within the sim geometry itself to have constraints attached to it. I'm also including an example that's more similar to Jeff's, except that the constraint locations are figured out automatically in SOPs using an embedded Digital Asset called “Constraint Points”. It just uses a ForEach and an AttributeTransfer to figure out locations for point-to-point constraints. So you can lay out a chain of objects, for example, optionally designate which points are “constrainable”, set the “Max Distance” for the AttributeTransfer, and all the constrained points will end up in a “constraintpts” group on each object, with attributes set that control each constraint parameters.
In this case the ApplyRelationship is set to “Number of Relationships Per Affector Object”, and for each object the “Number of Relationships” field looks at the current object's geometry and counts the number of points in its “constraintpts” group. From there it uses a similar approach of pulling the constraint parameters from attributes.
Your example geo from your file above shows up as “box_chain” here.
Hopefully this is all somewhat clear looking at the .hip files.
-
- Quick Links