ziconic

Thanks for sharing your setup! One thing it made me realized was that, in addition to having a sufficiently small particle separation, turning "Solve Pressure With Adaptivity" can help prevent air bubbles from collapsing. Btw what was your motivation for using the gas vortex confinement DOP? Was it to help break up the bubbles even more?

If you are looking for something out of the box, you can try the "enable air incompressibility" option in the FLIP solver, as described here: https://www.sidefx.com/docs/houdini/fluid/bubbles.html Note that I had to turn on viscosity and surface tension to prevent the air bubbles from collapsing right after they are born.

Are you planning to have the balloons deflate or squish against one another? If not, perhaps you don't have to use Vellum and can go with a simple rigids sim instead. If you are going to do a Vellum sim, it may be better to sim using simplified proxy geometry and then point deform the results to high-res geometry that contains additional detail (e.g. the fins around the balloons, wrinkles) that isn't going to be affected by the sim. Also, your current sim takes place in a vacuum with no external forces, so any tiny velocities that arise from resolving the constraints can move your geometry around unpredictably. You might want to attach your balloons to a string that is pinned at one end, and apply an upward force in the Vellum solver to push the balloons up, for example.

You could try the technique described here https://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#Pyro_stick_to_surface_with_project_non_divergent_sop, which is to source in a velocity field that pulls the smoke toward the collision surface, and once it's close to the surface, blend to a velocity that moves the smoke along the surface. That said, I'm guessing you'll have an easier time running a particle sim and using that to source the density for your smoke, as you originally suspected.

Maybe it would help if you described the problem you are trying to solve? TBH I'm not sure what you mean by grabbing the position of a volume on a different input. The Volume VOP iterates over the volumes in the first input by position, so there is only one position P of interest at any time. There are no other positions being generated for the other inputs. Now, if you have a specific position to look up in the volume in input 2 (e.g. the current P + some offset), you can use the Volume Sample node to read the second input's volume at some arbitrary position.

I'm guessing you've probably already figured it out by now but you don't actually have any geometry lights set up in your hip file. Also note that you can't set up a geometry light from points alone. You have to have some sort of primitive geometry, e.g. polygons, line segments, volumes. Copy to points using a sphere should have worked though (but would be very inefficient).

It's hard to tell what's happening without seeing the hip file.

How are you rendering the smoke volume? Is your shader doing any displacement or uprezzing of any kind? I could be mistaken but your renders seem to show a level of detail higher than what you would expect to get from the voxel res in your sim....

The smoke dissipation in sandboxpop.hip is too high. Did you mean to set it at 0.05 and not 0.5? Also you don't have a temperature attribute on the points going into Volume Rasterize Attributes, which means that it won't create a temperature volume that your sim can source. Without temperature your smoke won't rise and because dissipation is so high it pretty much vanishes by the time the next frame rolls along. As for the black box sprites, you just need to delete the shop_materialpath prim attribute going into the popnet to prevent the popnet from copying the attribute over to each point that it scatters on the source geometry.

I haven't been able to find any documentation that discusses the behavior of the volume wrangle when it is run on multiple volume primitives. It appears that, if all the bound volumes have the same voxel size, the wrangle finds the bounds encompassing all of the voxels and runs the snippet once per voxel. If the voxel sizes are different, the wrangle iterates through each volume individually and runs the snippet per voxel per volume primitive. This can produce very different results if the snippet reads and writes from both volumes. Can anyone confirm or correct this understanding?