Whatsinaname

visualize the collisions inside the FLIPobject during your simulation. It will show you how the solver 'sees' the collisions. I think this will give you a clue.

Looks like you are using an attribute name that is used internally, making something freak out. Send your scene to SideFX.

add a preroll. Create a thinner version of that intersecting geometry (no idea where you created it or how it was done, so it's difficult to be any more specific about it), ideally with the same point count. Use a blendshape during preroll to grow it from its shrunk/non-intersecting position into the desired position. You can also turn it into a vellum object (but without any forces such as gravity applied to that very vellum object) during the process described above. As cloth/vellum objects cannot self-intersect it would create proper folds during the (aforementioned) growth during preroll.

Use volumes. a) turn the object you want to collide it with into a VDB. b ) pipe the geo object (your plant...whatever) into a point wrangle. c) pipe the VDB into the point wrangle's 2nd input. float f = volumesample(1, "surface", @P) //samples a volume called "surface" which is fed into the second input as counting starts at 0 if(f<0) { @Cd=set(1,0,0); } else { @Cd=set(0,1,0); } This will colour the collided points red. Depending on your implementation of the growth animation, you can now use this collision information to make your 'plant' do something when it is colliding with that collision object. The reason why you don't get an earlier answer is probably that nobody knows how you implemented that 'animated growth'. Your description is rather murky and there are many ways to do this.

Couldn't run your scene because of my ancient Houdini version. However: I guess the solver won't update the attribute if you're using a wrangle. Try using a vellumconstraintproperty node, instead. This is the proper way to change constraint properties inside a vellum simulation.

They can do whatever they like, but: - fix that annoying memory leak. Having to re-start Houdini every hour because it doesn't release memory is no fun. (Yes, I am running Linux) - fix the viewport. Killing and re-opening the viewport every 15mins because it is displaying garbage (especially when working with packed geo) is a productivity killer.

When trying to close Houdini, a dialogue window pops up asking the user if they want to save the file or close Houdini right away. It seems like the saving (using this dialogue, not saving in general which is working fine) has lead to several corrupted files in our internal network, therefore I was wondering if there was an option to de-activate this? When closing Houdini, the scene should just close and neither try and save anything nor should the user have the option of doing so as this might result in corrupted files. Is that possible somehow?

I'm using a Gas Damp Microsolver to slow down my pyro sim. However, it seems like it is broken (H17.5.258). No matter which parameter I change, it sucks out all momentum of the sim, bringing it to a standstill. I'm using really ridiculous values, like a Target Speed of 500 (my sim is waaaay slower than that.) As far as I understand it, values below 500 should be ignored, but no matter what I put in there as a target speed, all velocities are lost after a few frames. Scale...well, if it's 1, 0.1, 0.0001 or whatever...it kills all motion after a few frames. Controlling it by a field...same result. Did anybody else ever have a similar issue with this particular microsolver?

Use some dissipation, I think that might help a lot.

That weird pyramid in the bg? My first guess would be some rogue particles at arbitrary positions making the meshing algorithm go crazy. Try creating a bounding box around the area of you want to mesh and kill everything that is outside that area. On top of that, delete any attribute that you don't need for meshing, using an attribute delete before using the particle surface SOP. It could also be a weird hiccup...try adding a slightly different number to your Particle Separation value, something like 0.11 instead of 0.1. See if the odd structure is generated with slightly different settings.

Inside your FLIP sim, look for the FLIPobject > VIsualisation > Collision. Turn that on. Run a few frames of the sim, so you can see how the solver sees your collision object. My guess is that it might be all over the place. Ideally, you want a closed (no holes) model for this purpose, therefore you will have to create a proxy of your boat to make it collide.

This is a relatively complex effect and not something you can easily do out of the box. I'd suggest you try getting the layering behaviour right, first. You could achieve this by looking into Viscosity (FLIP Solver> Volume Motion > Viscosity). Use this as a starting point: https://www.sidefx.com/docs/houdini/fluid/lava.html After that is more or less working, you could have this interact with an underlying fluid, or maybe fake it with some geometry.

Hm...how about some attribute blur on P...?

FBX comes with a bit of an overhead and it can be tough to get the settings right. If it is not an animated object, you might want to use something else. red/snowflake is referring to the orangey-red button on your SOPs. if you zoom in closely, you'll see it is represented by a snowflake icon. If you activate this, your modelling history will be baked into this very node, similar to 'delete history' in Maya.

Depends on what you want to do. Splitting up the clusters so they can get simulated on individual machines or in individual chunks is one thing. I'm not further elaborating on this here unless this is your question. If you simulate all your clusters in one go on a single machine, Houdini assigns a primitive group to the individual smoke objects that are generated during the cluster sim. You probably see some groups like smokeobject1_1, smokeobject1_2.... smokeobject1_6 Each of those groups represents one cluster. If you now use e.g. a Blast, you can separate the individual clusters from your caches.