Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

2 Neutral

About MoltenCrazy

  • Rank

Personal Information

  • Name
  • Location
  1. With the help of both the Redshift community and resources here, I finally figured out the proper workflow for dealing with Redshift proxies in Houdini. Quick summary: Out of the box, Mantra does a fantastic job automagically dealing with instanced packed primitives, carrying all the wonderful Houdini efficiencies right into the render. If you use the same workflow with Redshift, though, RS unpacks all of the primitives, consumes all your VRAM, blows out of core, devours your CPU RAM, and causes a star in nearby galaxy to supernova, annihilating several inhabited planets in the process. Okay, maybe not that last one, but you can't prove me wrong so it stays. The trick is to use RS proxies instead of Houdini instances that are in turn driven by the Houdini instances. A lot of this was based on Michael Buckley's post. I wanted to share an annotated file with some additional tweaks to make it easier for others to get up to speed quickly with RS proxies. Trust me; it's absolutely worth it. The speed compared to Mantra is just crazy. A few notes: Keep the workflow procedural by flagging Compute Number of Points in the Points Generate SOP instead of hard-coding a number Use paths that reference the Houdini $HIP and/or $JOB variables. For some reason the RS proxy calls fail if absolute paths are used Do not use the SOP Instance node in Houdini; instead use the instancefile attribute in a wrangle. This was confusing as it doesn’t match the typical Houdini workflow for instancing. There are a lot of posts on RS proxies that mention you always need to set the proxy geo at the world origin before caching them. That was not the case here, but I left the bypassed transform nodes in the network in case your mileage varies The newest version of Redshift for Houdini has a Instance SOP Level Packed Primitives flag on the OBJ node under the Instancing tab. This is designed to basically automatically do the same thing that Mantra does. It works for some scenarios but not all; it didn't work for this simple wall fracturing example. You might want to take that option for a spin before trying this workflow. If anyone just needs the Attribute Wrangle VEX code to copy, here it is: v@pivot = primintrinsic(1, “pivot”, @ptnum); 3@transform = primintrinsic(1, “transform”, @ptnum); s@name = point(1, “name_orig”, @ptnum); v@pos = point(1, “P”, @ptnum); v@v = point(1, “v”, @ptnum); Hope someone finds this useful. -- mC Proxy_Example_Final.hiplc
  2. I've got an R&D file in which it looks like the hair count is changing frame-to-frame. Both Mantra and Redshift are identifying the topology as changing frame-to-frame, so they're both disabling deformation motion blue for the object. This occurs whether the both the guides and the hair are cached or not. Is there a necessary rest setup for hair/fur? I've gone through the nodes in my set and the rest cache option under Static Generation on the Hair Generation node is about the only thing I see that might come into play. Attached are a few images showing the issue between frames 30 and 32, as well as the scene. – mC FurBall_ForRS_01.hiplc
  3. Can someone help me better understand making sim scenes more efficient when dealing with dense geo? An issue with Redshift displacement* means I may be forced to work with the full character geo as opposed to a subdivided base mesh with displacement/normal maps from ZBrush. Running ops on the high res model is pretty painful, so I'm trying to optimize on a per-shot basis by deleting unseen geo. In the attached file I've subdivided Tommy a bit to simulate a dense model (I couldn't do any more because it made the file too big to post, so let's pretend Tommy is really, really dense ). I've added the network I'm testing to speed things up. Is this a setup that makes sense? It seems to be faster but I'm not sure if there are better ways to do this. Any help would be great. Thanks! – mC *(The issue with Redshift displacement is that it shows cracks on fractured geo in the rest position before anything has even moved; there's no means of passing the displacement direction like the workaround in Mantra) . . ModelEfficiency_02.hiplc
  4. RBD Material Fracture for surface/thin shell

    [facepalm] Urghh...no idea how I missed that. Thanks, Dam! -- mC
  5. For a lookDev scene, I'm trying to create a more complex control node based off a Null with a number of spare parameters. I've got it working with some automation, but I'd like to increase the functionality with drop down menus that trigger one or more expression-driven parameter changes based on the value chosen. For example, if ‘Area’ was chosen from the drop-down menu ‘Light Type’, I would want to toggle the Area light on while toggling off all other lights in the scene. So, minimally it's an IF/THEN with multiple triggers in the function. This is something I've done in other packages with MEL, Python, etc but I'm not even clear on the terminology I should be searching for in Houdini. Can someone point me in the right direction? An example would be awesome. – mC
  6. Loving the new RBD Material Fracture. I'd like to use it to shatter a hollow model shell but I can't find a way to get rid of interior surface chunks. I attached a torus shell to show what I'm after (and the issue). Is there an attribute that can be processed to achieve this? Hoping this is possible as the new fracture looks better than the previous Voronoi approach and is noticeably faster/more stable than the boolean approach. Thanks! H17_RBDMatFrac_Example_01.hiplc
  7. Surface as force volume?

    Great example, Henry. I think I'm all set on the VDB approach. And it looks like I can use the approach on either static or deforming geo, which is fantastic. I'm curious about the the Field Force example you gave. I gave it a go based on your description but can't seem to make it work. I've tried referencing both the shatter geo and the interior geo in the SOP Geometry node, but in both cases the force attribute isn't coming in with the geo. Does this approach also require a SOP Solver node to wire up the points and forces? Metaball_Test_03a_FieldForce.hiplc
  8. Surface as force volume?

    In case it helps, this is a rough test of the metaball-based effect I'm hoping to replicate with the velocity volume. Metaball_Test_02.hiplc
  9. Surface as force volume?

    Thanks, toadstorm; this definitely helps. More and more impressed by the VDB functionality in Houdini. I'm still stuck on how to get the velocity to be fully recognized as a force in an RBD sim, though. With a FLIP solver it seems a bunch easier since there is an input for volumes on the solver. In an RBD DOPnet I'm bringing in the velocity with a SOP Vector Field and wiring it through a Field Force node. I have something happening, but the Field Force node only seems to work in a single direction; there's no sense of the velocity data from the surface/VDB 'normals'. volume_gradient_example_02.hiplc
  10. Surface as force volume?

    Hey, toadstorm...thanks for the response. Can you go into a little more detail? Are you suggesting I create a Volume Velocity node or a Volume Velocity From Surface node to create the initial volume? As for the point cloud functions, are you referring to something like pcfind in VEX, or a Point Cloud Iso node? And when you refer to 'binding' to the velocity volume, are you referring to using it as a mask? This is the first work I've done with volumes, so I'm not familiar with the approach. -- mC
  11. Is it possible to covert a surface into a form that defines a force volume? I have a character that will have pieces popping off it, basically a fracturing shell. I've (mostly) achieved the effect in tests with a sphere, randomly deleted glue constraints, and a metaball to provide the illusion the force is coming from under the surface itself. While I think I can mash together metaballs to get me the form I need, it would be better if I could just use the underlying surface as the repelling force volume, especially if the character is animated/deforming. Can this be done, either by using a surface directly as the volume or maybe as a force mask inside a larger metaball region? Thanks! -- mC
  12. Boolean Fracture Seams

    Hey, John! Thanks for the quick reply and...the solution! Pretty sure I had a bad node in my network, too...I modified my network in-place to match yours and still had seams. I completely rebuilt a new network beside it, and--boom--it worked, with the exception of the final Normal node. If I use it in my network, there are no seams at the Boolean node but they appear at the final Normals node. -- mC
  13. Boolean Fracture Seams

    Is there a way to fully eliminate seams in a model after a boolean shatter? I'm able to get rid of most of the seams with the boolean 'unique points along seams' flag and a Normals SOP, but in both Redshift and Mantra renders it's still clear that the surface has been shatter before a sim is applied. Any way around this? -- mC Boolean Seams - Sphere - 01.hiplc
  14. Shell fracture precision/interpenetration issues

    DoH! I was so focused on debugging the fracturing geo I didn't think about the collision geo! Thanks, Polyxion! Still new to a lot of this...do you think either the voronoifracture or the vdb approach (or both) would work with deforming/animated geo as well? Oh, and I'm about halfway through the recent videos by Jeff. Thanks for that as well. -- moltenCrazy
  15. Hi, all...need to do a shatter effect where the outer 'shell' of a static (for now) character/figure crumbles to reveal a different material/surface beneath. Been doing a lot of testing with a simple torus as it's a fair representation of the tubular topography of most of the figure (arms, legs, torso, etc). I feel I've finally got a good grasp on all the fracturing basics, but for the life of me I can't keep the outer shell fragments from interpenetrating with the underlying shell. I've tried: Increasing the DOP network substeps Increasing the rigid body solver substeps Switching the RBD packed object geo representation from Convex to Concave Altering the collision padding based on what it does to the guide geometry Increasing the number of fragments in connection with all of the above The changes either lead to little difference or in cases where I kick up the substeps and subsequently (I think) the precision, the fragments do the old-style 'exploding off the surface' thing. At this point, I have to wonder...in this situation should I just switch to the RBD solver? I'm okay getting hammered on sim time if I know it's going to work in the end. Oh, and a question about the collision padding...is that designed to pad the fragment intersection with other surfaces, each other, or both? Any help would be great. Really been banging my head against the wall on this one. -- moltenCrazy Shatter Tests - Torus - 02.hiplc