Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

loudsubs

Members
  • Content count

    125
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by loudsubs

  1. here's how to do it with pyro instancing. I rarely use this method though, because I can't push the res of each instance as high as if each were an individual sim. And if one cluster needs tweaking, you have to redo the whole thing. Most of the time, I'll make a similar setup, but wedge through each container on the farm, as individual sims. Couple things: Each instance point can only be on for 1 timestep, otherwise you'll get mutiple containers on top of themselves. view the dop details view during the sim, to verify the new smoke objects are getting created you need 1 sop volume w/ different name, going into dops for each instance container. The fluid source sop will create and partition using the "cluster" attrib "continuous" needs to be on in smoke object instance tab to have new containers birth mid-sim you can control containers size on the instance points with the "scale" 3fv attrib. I think theres info in the help card too pyro_cluster.hip
  2. Thanks guys, yeah I probably just need to spend some more time coming looking into what's possible with the energy and fracture threshold attribs. And thanks for posting the FEM denting examples too.
  3. This screen shot is from an old cloth video, possibly Houdini 11 or earlier. Can we get some of these old features back into the current cloth solver? Specifially I'd really like to be able to access the internal force attributes, so that they can be used to create other secondary effects, dynamically, such as tearing. Plastic deformation would also be welcomed with open arms.
  4. The volume being advected needs to be an SDF. You had it set to fog, and then you were converting it to a regular Houdini volume. Needs to be a VDB, to work with the VDB advect node. AdvectVolumebyVolume1.hipnc
  5. I don't think there's a huge difference between using a delayed load shader and using the 'packed disk primitive' option on a file sop. they are both reading the geometry from disk at render time. Also, keep in mind that your geo doesn't have to be a 'packed primitive' to be loaded as a 'packed disk primitive'. They are 2 different things. I don't really use delayed load shaders anymore because they take more steps to setup. Packed disk primitive seems to work just as well, and you just have to change the drop down menu on the default file sop. easy peazy.
  6. A textport 'vexhelp' command. Identical to the textport 'exhelp' command, but brings up vex expressions and an actual example of using it. I find the help browser just doesnt work sometimes, or can take a while to load. probably a network thing, but it would be great to be able to access vex info and examples faster.
  7. It's be great to have a basic volume shader, that has an identical interface to the volume visualization SOP. And have a button on both the SOP and the shader that can easily transfer the settings from one to another. With the way things are now, it's possible to set the visualization settings 3 times, (inside the sim, in SOPs, and then in the shader). Pretty redundant, there should be a lot simpler and faster way to get what you are seeing in the viewport, into the render
  8. With cone twist and hard constraints, I always make the length zero. I've found exploding constraints usually have something to do with the rest length. So I always just set it to zero. Made a few changes to your file, including using a facet to get unique points. then the primitive sop can actually scale each prim down to zero length. constraint_a.hipnc
  9. check out the example hip in this thread.
  10. I came across this video the other night, and thought it had some really cool effects. It's done in 3DSMax. I'm trying to work out how I would approach this in Houdini. Right around 23:00 - 24:00 in the video he has some playblasts of what looks like an RBD sim turning into cloth, which continues to fracture after the initial hit. There are obviously multiple layers in there with the particles etc, but the part I'm interested in is the continuous fracture of something that has weight and mass, but seamlessly turns in cloth/ash. I think I would first try to do this with all RBD, and cheating gravity after the initial hit, not sure if that would give the right feel though, of lifeless ash blowing away in the wind. I am also curious about the idea of turning a fractured RBD into cloth, in order to get some nice bendy behavior as it turns weightless and blows away in the wind. But since the thing continues to fracture, things get complicated. What do you guys think?
  11. I'm trying to figure out the best way to transform packed RBD primitives. I'm doing this by modifying the packed primitive intrinsic 'transform'. The issue I'm wondering about, is that the collision hulls that bullet is creating (packed rbd object > bullet data > show guide geometry) change every frame, which seems weird. I want to create the collision hulls on the first frame, and then transform those shapes. I've tried 2 different ways in the attached file. One I set the 'initial object type' to 'create static objects', and then I transform them inside the sim using a Geo VOP DOP. The other way, I'm setting 'initial object type' to 'create animated static objects' and feeding in the transformed pieces straight into the sim. Both produce the same result, and the collision hull seems to get updated each frame. Is there a way to make sure the collision hulls not update each frame, but still give them rigid transforms? Thanks! xform_packedRBD.hipnc
  12. Here's one way of doing it. If you want the sand to gradually blow away, you probably dont want to reference @P.y inside the simulation to drive the force, because thats going to dynamically change during the sim, and if a particle gets outside of the threshold, the force could stop affecting it. So I here created a group in SOPs that grows over time based on the Y bounding box. It gets referenced in the DOP sim, and then particles always stay in the group once they have joined. If you want to add more forces using a POP VOP, make sure the noise is set to 3D noise, and then add that to @force, and put force_grp in the group parameter of the VOP. sandtest_forceRandom_01.hiplc.hipnc
  13. Hey Tomas, thanks for the example hip! I had a question about what you're doing with setting @orient in the wrangle. It seems to effect the range of rotation within the simulation. When I change the radians value in your vex code to 10 for example, the constrained objects no longer rotates as far as with 90 for the radians. I can see that changing that value changes the cone twist guide in DOPs. Skimming through the help card for the cone twist constraint, I don't see where it mentions using @orient anywhere. Can you explain what's happening here and how you knew about this? Thanks!
  14. The reason it wasn't working for you, was you need to convert to tets, and then create @pintoanimation. When using FEM, your geo has to tets for the sim, and then you convert back to polys after. Check this hip, I played with a few variations for both @pintoanimation and @targetv/P FEM_pin_a1.hipnc
  15. There's a few ways using attributes. The help card says: "The attributes targetP and targetv can be used to specify a target position and velocity for each object point. When you use the Import Target Geometry option on the simulated object, the targetP and targetv will be set automatically every frame. Alternatively, you can create and modify these attributes yourself, using a Multi Solver and a SOP Solver. This is a way to create soft constraints. You can use the pintoanimation to create hard constraints that make the simulated points follow targetP and targetv exactly." The target geo method is a little confusing to me, but it seems to be working. When I point to the Sop solver with the target geo parm, and export targetP or targetv, nothing happens. When I point to the Sop solver with the target geo parm, and export P or v, it seems to work. So I think that on the solid or cloth object, whatever you point the target geo parm to, uses those point positions and point velocities (P and v), and converts them into "targetP" and "targetv". Anyway, here's a file with those 2 ways. Maybe someone with a better understanding of the target geometry parm, can explain exactly the way it works. cloth_constrain.hipnc
  16. Yeah the static object using the volume sample bgeos (or live) from SOPs is the way to go. There's a SOP called the "collision source" that sets everything up to use in a static object DOP (collision SDF, and geometry point velocities if it's a deforming collider). You just need to use the @name syntax in the prim group parameter of the static object for both the SOP path and the volume sample path. There's a shelf tool that set everything up for you. Check this hip staticcollide.hipnc
  17. I'm wondering if there is a good way to add geometry to a cloth sim, during the simulation. I first tried merging the geo in with a sop solver, but the forces don't effect the new geo using that method. Using no sop solver, and putting $FF in the 'creation frame' parm of the cloth object works, everything sims properly, but this method creates a new cloth object in the details view each frame, which doesn't seem very efficient. The effect I'm making is some leaves falling from above camera to the ground, and I want to continuously emit new leaves over the the entire frame range. Pretty basic. Is there a way to merge in new geometry during a cloth sim, and have it all be part of the initial cloth object that is created on frame 1 of the sim, as opposed to getting a new cloth object each frame that new geo is merged in? H15.362 Thanks
  18. You can create a setup or tool to do what you want using clip sops. Basically build a box using a few clip sops. You can use expressions on each one to set the position and clip plane direction, based on a reference bound or box sop. The clip sop is sweet because it almost always gives you really clean cuts. Take it a step further and have an option to do a cap operation after each clip. Base it on the camera frustum...
  19. I did some erosion experiments a while back using VDB's. I'm not sure where the hip file is, but the overall workflow was to use particles converted to VDB, and then use the VDB combine in a solver node to subtract away at the collision SDF each frame. Then mesh it with VDB convert. It worked fairly well on a basic box. I liked the volume approach because the polygons don't get stretched as the erosion happens.
  20. Convert the vel field to a vdb along with density, and smooth both. Smoke_hoverboard.hipnc
  21. A few other ways to handle rotations: 1. If you are sourcing from points, give the source points initial angular velocity @w before they go into the popnet. The sourced particles will inherit the angular vel. They will also need @orient vector 4 attibute, otherwise they'll use @v to orient themselves. 2. Post sim, in a point VOP - use the rotate VOP to modify @orient. Make sure to normalize it. Get a random from @id, fit that, mult it by time, and plug into angle. Also create a random vector to plug into axis. Make sure to subtract 0.5 and normalize, since random will only get you 0-1 range by default. Then convert that matrix to a vector 4, @orient.
  22. What did you change in the shader? I put down a new Surface model but it still renders all black. H14.0.361 EDIT: my mistake, missed the bound geometry path in the shader. Awesome file. Thank you
  23. You can use the volume sample VOP to check volume properties according the point's position. Here I check if density = 0. If it is I set vel to 0, if not then let vel pass thru. Then get the length of each vel vector, normalize it, and drive a color ramp. Here's 2 ways. Just be aware of the primitive number of each volume, when using the volume sample VOP (middle mouse or geometry spreadsheet to check). flowmap_test_ac.hip
  24. I'm not experienced enough with the grain sims to give good advice, but maybe you need to up the sub-steps on the solver to avoid the exploding. For the shadow pass, have a look at the light linker tab. You may have to do 2 different renders for what you are describing, (one using a holdout object). Unfortunately I don't have access to houdini at the moment, so I can't look at your file. But try reading the help card for the light linker, I think you'll find the answer.
  25. I took a look at your file. A few things I notice: there is no temperature being sourced into the simulation, therefore bouyancy wont work. In H13 and before, the source volume would by default, use density to source into temperature if a temperature source field wasnt present. Now in H14, you must explicity tell the source volume to use the source density field to source into temperature as well. Source volume node > SOP to DOP bindings tab. You also need to account for the gravity in the sim. Currently it's force is greater than the bouyancy force, so the smoke will still go downwards. byuancy1.hip