hi, I have a FLIP sop solver setup of water over a terrain, the water source is a "surface" and "vel" field from a lower res setup.
there are two dinosaurs running in the shallow water interacting with it.

How do you mix static and deforming collisions without killing performance?
- merging the collisions together into the 4th input of "FLIP collider" will vdb merge everything which is abhorrently slow but works.
- Using multiple "static colliders" DOPs is the logical solution but it simply breaks the sim internally.
- "volume source" dops are logical and the one already inside is set to "copy" to "collision" target field, copying more fields into the "collision" field wont work. I tried different operations like "maximum", "minimum", and "add".

AhmedHindy
"volume source" dops are logical and the one already inside is set to "copy" to "collision" target field, copy more fields into the "collision" field wont work. I tried different operations like "maximum", "minimum", and "add".

multiple Volume Source DOP nodes should work fine to combine multiple collision volumes
drop down Intitialize to Collision, it should work at those settings, maybe just correct the field names

EDIT: oh, you are probably talking about new FLIP Solver SOP
I think the idea is to use FLIP Collide SOP
merging of collision volumes into a single volume always has to happen, in old FLIP it was during solve, in new FLIP it's before, in SOPs

tamte
multiple Volume Source DOP nodes should work fine to combine multiple collision volumes

yeah but which operation should I choose? "copy" will override the collision, maybe "maximum" but it doesnt work with me.

also what do you mean collisions are combined in sim in DOPs either way? you think it is better to vdb merge them in SOPs before sending them to DOPs? is there a more efficient way?

AhmedHindy
yeah but which operation should I choose? "copy" will override the collision, maybe "maximum" but it doesnt work with me.

tamte
drop down Intitialize to Collision, it should work at those settings, maybe just correct the field names

AhmedHindy
also what do you mean collisions are combined in sim in DOPs either way? you think it is better to vdb merge them in SOPs before sending them to DOPs? is there a more efficient way?

in DOP workflow the Static Object Colliders as well as all Volume Source based colliders are eventually all combined into collision field of FLIP object and are resampled to its resolution
it is fine to use multiple Volume Source to combine them if you are working in DOPs

my note was for the case if you are working with FLIP Solver SOP
in which case I assume the workflow is to be chaining multiple FLIP Collide Nodes in SOPs which is combining them immediately
so in case you'd think less efficient to have static combined with deforming colliders I mentioned that they have to be combined somewhere
but also not claiming it's more efficient in SOPs, I have my doubts also, but it seems to be the workflow with FLIP Solver SOP unless you want to be unlocking it and do it in DOPs which you can still do

I do unlocked it so I am indeed working directly in DOPs,

speaking strictly in DOPs, how do chain multiple "volume source" DOPs set to source collision from multiple vdbs prepared in SOPs? you can't just "copy" since you are overwriting.

As I mentioned before, drop down the Initialize and choose collision, that defaults to Maximum and other settings

The main point is to merge sdf values and since in DOP sdfs are inverted (positive inside} Maximum should work

You can also visualize the Collision field to see if they are being combined correctly

Continuing from here and using this thread as an addendum for my doubt.

Is that just me or using colliders in general animated or static is much slower on flip SOP than the old DOP setup? Because that is what I am experiencing so far although I love the SOP dynamics nodes and I really wish to have they as my primary setup which I already do with Pyro and RBDs, but for now on H19.5 I am getting some really bad performance issues on this flip SOP compared the the old school DOP setup, it is not on everything like I said I am felling more towards the collision part.
So it is just me?
Any tips?

mzigaib
Continuing from here and using this thread as an addendum for my doubt.

Is that just me or using colliders in general animated or static is much slower on flip SOP than the old DOP setup? Because that is what I am experiencing so far although I love the SOP dynamics nodes and I really wish to have they as my primary setup which I already do with Pyro and RBDs, but for now on H19.5 I am getting some really bad performance issues on this flip SOP compared the the old school DOP setup, it is not on everything like I said I am felling more towards the collision part.
So it is just me?
Any tips?

yeah performance is horrible with collisions since it does alot of vdb merging under the hood. also it can lock you of out of cooking with a "operation interrupted" message and refuse to recook unless you restart Houdini (not reload the .hip file), this behaviour has been observed on a couple of machines so I am not alone

Yeah I noticed this behavior which is really annoying! But the performance is still the worst thing and it seems this performance issue is there from the begging I hope Sidefx is aware and can fix this.
I've read somewhere that there is a way to give a better performance "making your on collisions" but I didn't understand what it means and how to do that to fit this current SOP setup, if you have any tips feel welcome to share.

AhmedHindy
yeah performance is horrible with collisions since it does alot of vdb merging under the hood.

This was the worry from the introduction of SOP flip setup

We have been told that the performance should be similar since before this merging was happening in DOPs anyway

I'm not really sure how those operations compare, but I believe it's not that straightforward
As in DOPs it seems more optimized as collisions don't have to build outside of particle bbox so if they were sampled from transforming vdbs or static objects I believe it was much faster as currently the collisions have to be sampled in the whole container domain whether there is a liquid at current frame or not
But there may be also more to it as I'm just guessing, not really using SOP fluid much yet