Many many constraints
29585 28 6- johner
- Staff
- 823 posts
- Joined: July 2006
- Offline
Here's another example of creating constraints from point location / attributes calculated in SOPs, this time using a SOP Solver to dynamically create constraint points. It uses the Ray SOP as a kind of poor-man's collision detection, then creates spring constraints everywhere a “contact” occurs. When the spring stretches past the minimum ray distance, the constraint will automatically be broken.
This basically gives you “sticky” collisions.
This basically gives you “sticky” collisions.
- Soothsayer
- Member
- 874 posts
- Joined: Oct. 2008
- Offline
- johner
- Staff
- 823 posts
- Joined: July 2006
- Offline
Thanks, that last one actually worked better than I expected it to.
It can be pretty funny to decrease the spring strength to 1000-2000 or so, then increase the Max Ray Dist in the Ray SOP in the Sop Solver to 0.5 or more. You end up with more, stretchier springs and the spheres look like little creatures with yellow legs trying to hold on for dear life.
I didn't document that .hip very well (or at all), so let me know if things are unclear. Off the top of my head: the ApplyRelationship node is very similar to those other examples. The SOP Solver operates on a separate piece of geometry data, mostly to avoid the constant recalculation of the collision volume. The Object Space Anchor that attaches to the rotating boxes needed its Offset set to Set Always since the SopSolver is constantly updating the positions of the constraints.
It can be pretty funny to decrease the spring strength to 1000-2000 or so, then increase the Max Ray Dist in the Ray SOP in the Sop Solver to 0.5 or more. You end up with more, stretchier springs and the spheres look like little creatures with yellow legs trying to hold on for dear life.
I didn't document that .hip very well (or at all), so let me know if things are unclear. Off the top of my head: the ApplyRelationship node is very similar to those other examples. The SOP Solver operates on a separate piece of geometry data, mostly to avoid the constant recalculation of the collision volume. The Object Space Anchor that attaches to the rotating boxes needed its Offset set to Set Always since the SopSolver is constantly updating the positions of the constraints.
- Soothsayer
- Member
- 874 posts
- Joined: Oct. 2008
- Offline
I can kind of follow what you did there although there are a lot of expressions to wade through. It's quite a brain grinder.
I'd like to render out those little leggy creatures. They look like susuwatari in Totoro:
http://blogimg.goo.ne.jp/user_image/0d/4e/345275f7e62afeb5a469e8e009e40eca.jpg [blogimg.goo.ne.jp]
How can I get at the geometry of those guide legs? I can access the end points in via ConstraintPts as my Geometry Data Path, but the rest is missing.
Perhaps I can extract them with a geometrycopy, but I am venturing beyond my capacities.
I'd like to render out those little leggy creatures. They look like susuwatari in Totoro:
http://blogimg.goo.ne.jp/user_image/0d/4e/345275f7e62afeb5a469e8e009e40eca.jpg [blogimg.goo.ne.jp]
How can I get at the geometry of those guide legs? I can access the end points in via ConstraintPts as my Geometry Data Path, but the rest is missing.
Perhaps I can extract them with a geometrycopy, but I am venturing beyond my capacities.
--
Jobless
Jobless
- johner
- Staff
- 823 posts
- Joined: July 2006
- Offline
Yep, they look a lot like those little creatures
The expressions can get pretty tricky, but it's still kind of amazing you can get that kind of “emergent behavior” in so few nodes. I said in some other thread that I think ApplyRelationship is probably the most complex yet powerful single node in Houdini, which is saying a lot.
As for rendering the constraints, I don't think you can get at the Guide geometry easily, unlike something like fluids where you can fetch the Visualization geometry. I would just re-create them in SOPs anyway, which will give you a lot more control over their look.
The constraint points are already at the world space position of one end of the constraints, and the other end is at the specified point number of the individual sphere.
I've attached an example that just recreates the look from DOPs, but you could do all sorts of things once you have the two endpoints of the constraints.
The expressions can get pretty tricky, but it's still kind of amazing you can get that kind of “emergent behavior” in so few nodes. I said in some other thread that I think ApplyRelationship is probably the most complex yet powerful single node in Houdini, which is saying a lot.
As for rendering the constraints, I don't think you can get at the Guide geometry easily, unlike something like fluids where you can fetch the Visualization geometry. I would just re-create them in SOPs anyway, which will give you a lot more control over their look.
The constraint points are already at the world space position of one end of the constraints, and the other end is at the specified point number of the individual sphere.
I've attached an example that just recreates the look from DOPs, but you could do all sorts of things once you have the two endpoints of the constraints.
- dvfedele
- Member
- 33 posts
- Joined:
- Offline
Wow this thread is phenomenal!! This leads me to a question which ties in to the the examples above.
I'm trying to replicate maya's hair solver feature, “start curve attract.”
That way I can get my hair sims to follow the input curves more closely. My current solution is to make groups for each point down the hair and then use one wireAngularSpringConstraint.
It works well but doesn't allow for a few things:
1) Ultimately, I want to control the strength of the constraint down the length of the hairs. This means I need one constraint per point group.
2) If I resample the curves my point groups are made correctly but the constraint breaks down since it currently relies on hand typed group names for the constrained points.
Was thinking of using the applyRel to make the constraints and adding sliders so I could control the strength/damp parameters down the length of the curve. Default should be stronger at root and weaker at tip, but allow for adjustment.
Appreciate all your help!! Sorry for my long winded explanation!
I'm trying to replicate maya's hair solver feature, “start curve attract.”
That way I can get my hair sims to follow the input curves more closely. My current solution is to make groups for each point down the hair and then use one wireAngularSpringConstraint.
It works well but doesn't allow for a few things:
1) Ultimately, I want to control the strength of the constraint down the length of the hairs. This means I need one constraint per point group.
2) If I resample the curves my point groups are made correctly but the constraint breaks down since it currently relies on hand typed group names for the constrained points.
Was thinking of using the applyRel to make the constraints and adding sliders so I could control the strength/damp parameters down the length of the curve. Default should be stronger at root and weaker at tip, but allow for adjustment.
Appreciate all your help!! Sorry for my long winded explanation!
- monkeybar
- Member
- 4 posts
- Joined: Oct. 2010
- Offline
This thread got me all excited about constraints again so I did a few tests on a simple animated hierarchy to see what would happen! If you have a look at the 3 dopnets here you'll see I've strung together some hinge constraints that get created when the rbd object is made active. I tried a few variations ranging from the very simple to the more complex stamping approach building on johner's lovely setup.
I must admit, I didn't expect the instability I'm seeing here, it looks like the position data is being written to twice or the velocity is being calculated incorrectly. The apply relationship dop is awesome indeed but for something like this I would have thought a straightforward hinge constraint would just work!
must be doing something silly..
I must admit, I didn't expect the instability I'm seeing here, it looks like the position data is being written to twice or the velocity is being calculated incorrectly. The apply relationship dop is awesome indeed but for something like this I would have thought a straightforward hinge constraint would just work!
must be doing something silly..
- monkeybar
- Member
- 4 posts
- Joined: Oct. 2010
- Offline
- monkeybar
- Member
- 4 posts
- Joined: Oct. 2010
- Offline
-
- Quick Links