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.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

24 Excellent

About loudsubs

  • Rank

Personal Information

  • Name Arrev
  • Location USA
  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