Or get it off the Exchange:
http://www.sidefx.com/exchange/info.php?fileid=660&versionid=660 [sidefx.com]
Found 183 posts.
Search results Show results as topic list.
Houdini Indie and Apprentice » voronoi shatter
- johner
- 809 posts
- Offline
Technical Discussion » Dynamically adding new geo to a dops sim
- johner
- 809 posts
- Offline
You're right, I think using the group mask is a better way to do it, assuming you can generate group names that contain multiple objects and can be calculated from the frame number or otherwise.
In that case, your SOP network doesn't necessarily need to be time-dependent and can cook only once, which is always a good thing. Also, the Fractured Object creates no objects if the provided group is empty, so you can just set the Creation Frame to $F and be done. Definitely cleaner than my example.
In that case, your SOP network doesn't necessarily need to be time-dependent and can cook only once, which is always a good thing. Also, the Fractured Object creates no objects if the provided group is empty, so you can just set the Creation Frame to $F and be done. Definitely cleaner than my example.
Technical Discussion » Dynamically adding new geo to a dops sim
- johner
- 809 posts
- Offline
Yes, Creation Frame is the key to getting a node like RBD Fractured Object to create objects on several different frames. (It just triggers the Activation of the underlying Empty Object DOP)
One way to handle the multiple objects is just make sure that your SOP network only produces the geometry that is to be turned into DOP objects for the current timestep. Then uses a “nprims” expression to only update the CreationFrame when there are new objects to create.
See the attached example.
One way to handle the multiple objects is just make sure that your SOP network only produces the geometry that is to be turned into DOP objects for the current timestep. Then uses a “nprims” expression to only update the CreationFrame when there are new objects to create.
See the attached example.
Houdini Indie and Apprentice » Carving up geometry using voxels
- johner
- 809 posts
- Offline
DMM sounds interesting, although I don't know much about it except that it's Finite Element-based.
Sorry, I didn't answer your question about wood splintering. You're right that an out-of-the-box Voronoi-based fracture operation tends to be better at creating rubble and debris and such where there's no real preferred axes of fracture, unlike something like wood.
As Jeff points out you can do some transformation of the fracturing points ahead of time to achieve different looks. You can even go so far as to transform the geometry before the fracture, do a Voronoi fracture, then transform it back to the original space. In this case the pieces back in the original space may no longer be Voronoi, not that that really matters; as long as it's a linear transformation they should still be a non-overlapping division of the original object.
Attached is an example by Marc Horsfield, where a non-uniform scale is applied to the object before fracturing. The axes that get scaled up will be squashed when transformed back, and you can get some pretty convincing looking splintering that way, especially when combined with the Interior Detail feature.
This file uses the version of the Fracture OTL from the Exchange, but I locked the RESULT node so you can see a couple of pieces without having the OTL (just ignore the warnings).
Just clear the Cell Point Group parameter to fracture the whole object, although keeping one or two points in there is a good way to experiment, for example by changing the amount of scaling in each axis before fracturing.
Sorry, I didn't answer your question about wood splintering. You're right that an out-of-the-box Voronoi-based fracture operation tends to be better at creating rubble and debris and such where there's no real preferred axes of fracture, unlike something like wood.
As Jeff points out you can do some transformation of the fracturing points ahead of time to achieve different looks. You can even go so far as to transform the geometry before the fracture, do a Voronoi fracture, then transform it back to the original space. In this case the pieces back in the original space may no longer be Voronoi, not that that really matters; as long as it's a linear transformation they should still be a non-overlapping division of the original object.
Attached is an example by Marc Horsfield, where a non-uniform scale is applied to the object before fracturing. The axes that get scaled up will be squashed when transformed back, and you can get some pretty convincing looking splintering that way, especially when combined with the Interior Detail feature.
This file uses the version of the Fracture OTL from the Exchange, but I locked the RESULT node so you can see a couple of pieces without having the OTL (just ignore the warnings).
Just clear the Cell Point Group parameter to fracture the whole object, although keeping one or two points in there is a good way to experiment, for example by changing the amount of scaling in each axis before fracturing.
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Houdini Indie and Apprentice » Carving up geometry using voxels
- johner
- 809 posts
- Offline
I actually did some experimentation with Volume based fracturing before deciding on a geometric approach. The nice thing about volume fracturing is you can manipulate it in all kinds of ways and get arbitrarily noisy surfaces out of it. The downside is you have to build a high-quality volume representation of the object you want to fracture, usually as a Signed Distance Function. Also, once you've converted to a volume and fractured, you need to convert back to a polygonal representation that's not insanely dense, and map the UV's and any other attributes back on, which can get tricky as well.
While Houdini has nice tools for all of this, to maintain detail you really need very high resolution volumes, which gets expensive in a hurry in memory and processing time (doubling the resolution means 8 times more memory and processing).
If you're dealing with more straightforward geometry like walls and columns, you might get away with lower res volumes. But for high-res you start needing a more specialized toolkit. I don't have any experience with it, but apparently Digital Domain has a volume-based fracturing toolkit called “Cracktastic”. You can read a short sketch of it here. [ken.museth.org] They describe using resolutions up to 8000^3 (!).
There was also a talk given at Siggraph ‘09 by one of the guys from Guerrilla Games about how they used Houdini in Killzone2 that touches on the volume fracturing and other interesting things. The talk is called “Houdini in a Games Pipeline”. If you’re interested, you can get it for about ten bucks from http://encore.siggraph.org [encore.siggraph.org]. Just browse 2009 and search for “Houdini”.
Jeff gave some great advice on ways to scatter points to feed to the Voronoi Fracture SOP, which hopefully will give you the control you need.
There's also some examples in that thread of using the output of that SOP with the Cookie SOP as well, i.e voronoi-fracturing the bounding box of the object with noisy interiors, then cookie intersecting the result with the original geometry.
If you're interested in what a Volume-based Voronoi fracturing might look like, I'm attaching a somewhat cleaned-up version of some early experiments I did. It's not terribly fast, especially as you increase the resolution of the volume, but looking at the Volume VOPs there might give you some ideas. There's one in there that will turn the object into a shell using some basic SDF math, and then the one that generates each (possibly noisy) Voronoi cell.
While Houdini has nice tools for all of this, to maintain detail you really need very high resolution volumes, which gets expensive in a hurry in memory and processing time (doubling the resolution means 8 times more memory and processing).
If you're dealing with more straightforward geometry like walls and columns, you might get away with lower res volumes. But for high-res you start needing a more specialized toolkit. I don't have any experience with it, but apparently Digital Domain has a volume-based fracturing toolkit called “Cracktastic”. You can read a short sketch of it here. [ken.museth.org] They describe using resolutions up to 8000^3 (!).
There was also a talk given at Siggraph ‘09 by one of the guys from Guerrilla Games about how they used Houdini in Killzone2 that touches on the volume fracturing and other interesting things. The talk is called “Houdini in a Games Pipeline”. If you’re interested, you can get it for about ten bucks from http://encore.siggraph.org [encore.siggraph.org]. Just browse 2009 and search for “Houdini”.
Jeff gave some great advice on ways to scatter points to feed to the Voronoi Fracture SOP, which hopefully will give you the control you need.
There's also some examples in that thread of using the output of that SOP with the Cookie SOP as well, i.e voronoi-fracturing the bounding box of the object with noisy interiors, then cookie intersecting the result with the original geometry.
If you're interested in what a Volume-based Voronoi fracturing might look like, I'm attaching a somewhat cleaned-up version of some early experiments I did. It's not terribly fast, especially as you increase the resolution of the volume, but looking at the Volume VOPs there might give you some ideas. There's one in there that will turn the object into a shell using some basic SDF math, and then the one that generates each (possibly noisy) Voronoi cell.
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Houdini Indie and Apprentice » pyro FX animation skipping
- johner
- 809 posts
- Offline
Hi Andrew,
The Pyro Solver does the rest field resetting with two Gas Intermittent Solve nodes. Sounds like you've already figured this part out, but I had no idea how that node responds to changing the start frame of simulations, so I put together a quick test.
Looks like changing the “Start Frame” of the entire DOPNet works best, if that's an option. If you change that to 40, for example, and have a Start Frame of 1, reset rate of 50, then the initialization of the Rest frame should be on frame 41, then every 50 frames thereafter.
But if you're using Object Creation frame, the Intermittent Solve doesn't pay any attention to that, it just tries to solve based on the sim Start Frame and its Offset time, even if no objects have been created yet.
Attached is the test I used; it just sets the density and heat fields to 1 using overlapping Intermittent Solves and visualizes that. Setting the Frame Offset and Frames Between Solves parameters in gasintermittentsolve1 should let you experiment.
I haven't had a chance to try a custom shader yet. Just curious, are you using this on top of upres'ing the smoke?
The Pyro Solver does the rest field resetting with two Gas Intermittent Solve nodes. Sounds like you've already figured this part out, but I had no idea how that node responds to changing the start frame of simulations, so I put together a quick test.
Looks like changing the “Start Frame” of the entire DOPNet works best, if that's an option. If you change that to 40, for example, and have a Start Frame of 1, reset rate of 50, then the initialization of the Rest frame should be on frame 41, then every 50 frames thereafter.
But if you're using Object Creation frame, the Intermittent Solve doesn't pay any attention to that, it just tries to solve based on the sim Start Frame and its Offset time, even if no objects have been created yet.
Attached is the test I used; it just sets the density and heat fields to 1 using overlapping Intermittent Solves and visualizes that. Setting the Frame Offset and Frames Between Solves parameters in gasintermittentsolve1 should let you experiment.
I haven't had a chance to try a custom shader yet. Just curious, are you using this on top of upres'ing the smoke?
Houdini Indie and Apprentice » pyro FX animation skipping
- johner
- 809 posts
- Offline
Mix VOP.
Come to think of it, you could also just stick that code snippet in an Inline VOP. Might be helpful to ensure you got identical results from VOPs, at least.
Come to think of it, you could also just stick that code snippet in an Inline VOP. Might be helpful to ensure you got identical results from VOPs, at least.
Houdini Indie and Apprentice » pyro FX animation skipping
- johner
- 809 posts
- Offline
Hey Andrew,
Mario can answer this best of course, but the code for the dual rest noise interpolation looks like this:
float drw = modulo(drframe-drstart,drrate);
drw = smooth(0,drrate*0.5,drw) - smooth(drrate*0.5,drrate,drw);
chaos = lerp(chaos2,chaos,drw);
where drframe is usually the current frame, drstart is the dual rest start frame, and drrate is the reset rate. Chaos and chaos2 are noise values generated with identical input parameters except the two different rest values as the input positions (with rest2 possibly being further offset by a constant value).
So it calculates a smooth interpolation between those two noise values based on how far along the reset interval the current frame is. Shouldn't be too bad in VOPs.
Mario can answer this best of course, but the code for the dual rest noise interpolation looks like this:
float drw = modulo(drframe-drstart,drrate);
drw = smooth(0,drrate*0.5,drw) - smooth(drrate*0.5,drrate,drw);
chaos = lerp(chaos2,chaos,drw);
where drframe is usually the current frame, drstart is the dual rest start frame, and drrate is the reset rate. Chaos and chaos2 are noise values generated with identical input parameters except the two different rest values as the input positions (with rest2 possibly being further offset by a constant value).
So it calculates a smooth interpolation between those two noise values based on how far along the reset interval the current frame is. Shouldn't be too bad in VOPs.
Houdini Lounge » (to Webmaster) Links to Posts
- johner
- 809 posts
- Offline
There's a little icon just to left of the date on each message, i.e. right before “Posted: Fri Apr 09, 2010 10:33 am”. I think that provides a link to the specific post, no?
Here's one to a random post in a two-page topic that is from Edward and says:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&p=85319#85319 [sidefx.com]
Here's one to a random post in a two-page topic that is from Edward and says:
Plus you need to delete “$HFS/hsvg/lib*”.
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&p=85319#85319 [sidefx.com]
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Technical Discussion » Many many constraints
- johner
- 809 posts
- 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.
Technical Discussion » Pyro, Voxels & Particles, Time based effects.
- johner
- 809 posts
- Offline
Hi Andrew,
There's some different approaches for using particles as a source for density in this thread:
http://forums.odforce.net/index.php?/topic/8822-particle-rasterization-to-voxel-grid [forums.odforce.net]
Using them for fuel instead/also should be relatively straightforward.
Please ignore most of my blatherings in that thread until the last blather (at which point I finally realized that Houdini has native support for using particles as a fluids source).
Good luck
There's some different approaches for using particles as a source for density in this thread:
http://forums.odforce.net/index.php?/topic/8822-particle-rasterization-to-voxel-grid [forums.odforce.net]
Using them for fuel instead/also should be relatively straightforward.
Please ignore most of my blatherings in that thread until the last blather (at which point I finally realized that Houdini has native support for using particles as a fluids source).
Good luck
Technical Discussion » houdini pattern matched attributes with HOM
- johner
- 809 posts
- Offline
Well, it's a little ugly (and slow), but you can access the strmatch hscript function through hou.hscriptExpression.
So something like:
attrs = hou.node('/obj/geo/blah').geometry().primAttribs()
pattern = “* ^life* ^d”
filtered =
So something like:
attrs = hou.node('/obj/geo/blah').geometry().primAttribs()
pattern = “* ^life* ^d”
filtered =
Technical Discussion » group fused points
- johner
- 809 posts
- Offline
I've attached another way to do it. The first is relatively straightforward and uses the topology of the geometry pre- and post-fusing to create the group. Basically you calculate the number of primitives for each point before and after the fuse, and the points where that number has changed represent the points that have been fused.
This only works for points that are part of primitives; i.e. not raw points, so I also put a “stupid Houdini tricks” way of dealing with just points.
This works by creating both integer and float attributes that store the original point number for each point. When fusing two or more points together, Houdini updates float attributes with the average of all the fused points. With integer attributes it chooses whichever value is on the lowest point number. So any point where the integer and float attribute values differ has been fused.
This only works for points that are part of primitives; i.e. not raw points, so I also put a “stupid Houdini tricks” way of dealing with just points.
This works by creating both integer and float attributes that store the original point number for each point. When fusing two or more points together, Houdini updates float attributes with the average of all the fused points. With integer attributes it chooses whichever value is on the lowest point number. So any point where the integer and float attribute values differ has been fused.
Technical Discussion » Pyro driven by POPs.
- johner
- 809 posts
- Offline
This post [forums.odforce.net] over at odforce has an example of using particles as a fluid source, which is quite straigthforward these days, although offhand I don't know if the Shelf tools will set it up for you automatically.
The particle's pscale attribute is used to control the size of the particles source.
The particle's pscale attribute is used to control the size of the particles source.
Technical Discussion » DOP and Foreach
- johner
- 809 posts
- Offline
Look at the Apply Relationship DOP. In particular the Chain example that's referenced from its help card.
-
- Quick Links