Jump to content

Atom

Members
  • Content count

    3,441
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    119

Posts posted by Atom


  1. 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.

    • Like 1

  2. 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.


  3. 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.

    Untitled-1.jpg

    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.


  4. 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.

    pop_grain.gif

    • Like 1

  5. 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


  6. 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.

    • Like 2
    • Thanks 1

  7. Each character motion is going to loop at a different time, setting the range is important (the green fields are placeholders that are meant to be deleted). After reviewing mocapbiped3, I have concluded that frame 17 is the loop point for the running animation, not 24. Try that number in your range instead. Also, don't change the speed of the animation on the biped to 0.1, leave it at 1.0. You were effectively time stretching your input, which is not good. Most of the time you want a 1:1 timing relationship with your agents before you submit them for simulation. Use the Gait Speed on the CrowdState node to adjust agent speeds after you have submitted your crowd source to DOPs for simulation.

    When you make changes to the character rig or fbx that the Agent node is referencing, don't forget to click the Reload button to forward your new settings down stream.

    crowd.gif


  8. It looks like on the Agent node you have the frame range set to Scene. This means the agent will loop over 1-240 frames or the playbar range. Change it to User Specific and dial in the start and end frames for the loop that matches your animation. In your example file I set the range from 1-24 which causes mocapbiped3 to loop seamlessly.

×