Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Atom last won the day on August 7

Atom had the most liked content!

Community Reputation

1,292 Excellent

About Atom

  • Rank
    Grand Master

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    Columbus, Ohio

Recent Profile Visitors

13,463 profile views
  1. rbd object ignores velicity past first frame

    As far as I know, there is only one valid case where you actually need to use the Hero RBD object. That case is if you want to have the object float upon the flip surface. If you can work with packed objects, you might want to go with that. I agree with your observation, though. I can't find any way to alter the velocity beyond the initial velocity.
  2. Thanks. I was able to get what I need using MOPs, but your solution works too!
  3. While it's not super critical, it does seem like the collision version of the objects lag behind the actual location of the RBD objects in the simulation. I tried adding a time shift $F-1 and $F+1, but that didn't seem to fix it.
  4. It seems to work for me. Just make sure that when you animate the box, that the group points are still being created. If you are scaling the box, make sure your centroid is correct.
  5. Tutorial HIP Library

    If you've worked through a tutorial and want to share your HIP file with the community, post it here. I completed one where Mikael Pettersen demonstrates how to create a Blendshape crowd agent. ap_mp_blendshape_crowd_character_052120.hiplc
  6. How to export vdb's in the right way

    On the Smoke Object node, disable sparse solving, and enable max size. If you're using an older DOPs system, disable the Gas Resize Fluid Dynamic node.
  7. Well, they are all connected, right? You mean connected by a certain vertex count? You could select a bunch of random points, then throw away the ones that fail the neighbor vertex count test. https://www.sidefx.com/docs/houdini/vex/functions/neighbourcount.html
  8. How to export vdb's in the right way

    My guess is that your simulation continuously expands. That means you will always run out of ram. Disable the continuous expansion of the domain and lock down the domain size. This will result in clipping near the edges where density meets the borders. Consider increasing dissipation to remove density before the smoke reaches those edges. I don't think Blender supports motion blur for volumes yet IDK, so you may not need to write vel.x, vel.y, and vel.z to disk. Save some file size and turn them off during final export. Or kick out .sim files first, and try continuing the simulation a frame before the crash.
  9. Packed geo motion blur

    Inspect the geometry to make sure that v@v is something other than {0,0,0}. You may have to unpack it to expose that attribute.
  10. What about something convoluted like this? Use an input to bring in the volume, merge packed results, then pack the result and unpack it at the top of the loop..? Not sure if this technique works, but you can switch based upon iteration. Every iteration past the first one should supply the merged result. Now that I look at this some more, the switch should probably intercept before the unpack, so you can filter the volume with a blast or delete node.
  11. Attaching Vellum to a pop advection sim

    On the popsource birth tab type "justborn" into the justborn field. Add a delete or blast node after the popnet and filter by the justborn group. Delete non-selected to keep newly generated points.
  12. Pop Grain Birth Collisions [SOLVED]

    Try moving the popgrain node after the popwrangle. This way the pscale you have calculated can be taken into account by the particle separation algorithm of the popgrain node. Also, try animating the seed on the popsource so you aren't generating the same point set each time. My guess with your current setup is separation occurs, then pscale is generated. This causes a momentary overlap that the popgrain node repairs on the next frame. This is probably what causes that jumping action. By solving separation after scale, you should be able to avoid or limit that.
  13. Render huge amount instances

    Hmm, weird. Here is a mantra scene where I am rendering with 10 million pig heads on a 32Gb system. I'm only consuming 8.6 gig of system memory, and no crash. One thing I highly recommend is pressing the D-KEY and lowering the viewport instance number from 100% to 0.1% on the Geometry tab. I also set the Stand In geometry to Display OFF. There really isn't much of a reason to leave a 10 million particle display on, unless you are planning a camera move and need to navigate through them? Maybe the graphics card is being overloaded and is leaking/consuming memory? ap_instance_ten_million.hiplc
  14. There may be holes in your polygon mesh, or non-fused points. Try dropping down a polyfill and choose single polygon fill mode before your vdbfrompolygons. After that, if you still have holes, you may need to reduce voxel size on the vdbfrompolygons until they disappear. For a shape like you have shown in your reference, I might be tempted to construct a low poly proxy mesh to serve as the collision object. The higher resolution you need for collision, means the higher resolution you will have to push the fluid simulation. This can increases the simulation time. It's worth the effort to simplify your collider unless the shot specifically requires an up-close interaction with the "hero" collision object.