Jump to content

Recommended Posts

Hello to all...

I have a scene where I have animated geometry written out and I bring it back in via a file sop.  The animation is just of some rocks flying up in the air flying down inside some water.  I'm using a vdb from polygons on the file and I'm bringing that into the dop network as a static object with the mode set to Volume Sample and pointing to the object in the proxy volume field  .  The problem I run into is when the rocks collide with the fluid, the fluid collapses.  I can remove the proxy volume and reset the mode to ray intersect and things will be fine....I have tried to explore on how to fix this but I can't seem to find the solution...  does anyone have any ideas?  I can upload the scene later if needed.

flip_tests.hipnc

Edited by ntkirby
adding hip file
Link to comment
Share on other sites

This is an interesting case! rocks "static object" having hard time to extrapolate correct sdf values.. I'm starting to belive. however working around creating an sdf vdb called @collision with @collisionvel and adding it in to the third imput of the flip solver as a sourcevolume with preset collision, splash will work fine preserving at the same time the level of water in the pool -- Cheers

 

flip_tests_collVel.hipnc

Edited by Dam
Link to comment
Share on other sites

And yes "static object" still works fine..  equal particle separation on ---> rocks vdb -- terrain vdb -- and "collision separation" helps a lot for the flipSIm and vdb collision detection. The water doesn't collapse enymore expecially with lower "particle sep". Setting the "collision separation" as the particle separation increase the stability too with lowRes flipSims. I've attached the new hip.hope it helps :) Cheers-Dam

flip_tests_debugStatiObjectFIX.hipnc

flip_tests_testPrtSepFIX.hipnc

Edited by Dam
Link to comment
Share on other sites

Ok, so ...  after looking at your files, I decided to do a little troubleshooting on my own based off your findings....and

It looks like all I needed to do was add a trail sop in..and it wouldn't make the volume collapse...

Now, as far as the collision separation, I played around turning it on and off and matching the vdb resolution to that value...  what I found was that even though it didn't affect the particles (as long as I had that trail sop in) it still showed slightly weird behavior if I didn't match the resolutions..  if I made collision separation different than the particle separation, I would still get a little weird behavior...  

So...    

Add a trail sop after the animated objects before bringing them into flips...
vdb resoltuion = collision separation = particle separation

Link to comment
Share on other sites

Mmm that's interesting, as far I tested, the trail sop doesn't change the sim in my "flip_tests_testPrtSepFIX", what I changed from the original hip was: the popadvectbyvolumes I've moved it to the second input of the flipSolver, on the VDBs I've switched off fill interior.. that slow down the sim  and doesn't make much difference in this case. I've changed also a couple of parameters on collision tab of the flipSolver like the collision extrapolation and at the end matching --> vdb resoltuion = collision separation = particle separation, 

If a simple trail sop fixed the original issue with only matching the resolutions, would be interesting see this case, can you post the updated hip with your latest debug? :) Cheers 

Edited by Dam
Link to comment
Share on other sites

Ok, so...  I just did a quick test with the popadvectbyvolume in both inputs and removing it altogether with and without the trail sop, and on my end, without that trail sop on the unpacked object...  the fluid collapsed....without the trail sop....  it's wierd

Edited by ntkirby
Link to comment
Share on other sites

So I took a look at your latest debug, and yes the trail sop did the magic in this case.

Visualizing the velocity on the RBD chunks after the unpack looks like even they don't move at the bottom of the pool the pieces have velocity pointing up and down, I guess that's why the water it's been pushed to the bottom.. I did a quick test deleting attribute @v and it's working as well, so the water collapse at the end it's caused by the incorrect velocity coming from the Dop. Good case that deserved an investigation :). Popadvect should be plugged to the second input of flipS, third input accept only volume velocity.

Cheers - Dam

 

Edited by Dam
Link to comment
Share on other sites

Thanks for the help Dam...  it looks like I just need to get rid of the velocity after I write it out and bring it back in....  I think it's coming from the point vop and it's just not really writing it out from the dop network...  or just use that trail sop before bringing it into the flip sim..  either way, we figured it out! :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...