Jesper Rahlff

the static object is internally converting v attribute from your incoming geometry to collisionvel even if you specify a proxy volume to sample collision from. In order for you to scale down your collision velocity you can simply just multiply down your v attribute on your geometry before it is sourced in like so:

pre solve means before the timestep has been solved. Post solve means after the timestep has been solved. In a very simple term you can think of it like this: Before the point has moved, after the point has moved for the given timestep

can you upload the hipfile by chance?

This is a good starting point? its a Subsurface scattering shader, that has a milk preset you can use. You can put down this material in the /mat context

start off with the preset on the physical SSS shader

you can also disable the turbulence microsolver in the setup as well

The setup you have is pretty good. I tweaked just a few things (I actually just simplified everything a little) and optimized your sim so it runs faster. Attached is the modified file. I copied your geo node and renamed it so you can see the difference between the two. Feel free to ask questions if any may arise. Tornado_JR_v1.hiplc

in order to do that you would in another if statement check if they have collided with the ground. Same concept

you are mixing things together. That is not a name attribute on the primitives. That is a path attribute. You name attribute exists on the points. Each individual cube is represented by a point. This is what happens when you pack the geometry. So in order to color some of the cubes for instance you need the sop solver to be attached to the rigid body solver. Not the constraint solver. (unless you are trying to color the constraint primitives.) See below Lastly in order to access the cube geometry (the points) you need to work from the dop_geometry node inside the sop solver and not the Impacts. Once all of that has been setup you can then write your code. Your code should look something like this: Take note of the fact that the wrangle node is running over the points and not primitives. Since your geometry is packed I only have one point or one primitive available per cube. The name attribute exists on the points, so we have to run over points. A simple string condition does the trick to isolate the desired cubes. Inside the if statement I choose to add my color attribute to the primitive instead of the point which I am running over. This is simply just because Houdini is not very good at displaying colors that sits as a point attribute when dealing with packed geometry. So in order for it to show in the viewport I added the color in a primitive attribute instead.

yes you can use the s@name string attribute to identify your pieces with. This is why we setup unique names for our packed geometry. So the solver can keep track of each individual piece.

The ObjId has nothing to do with your packed geoemtry. Your ObjId describes the different dynamic objects. for example your RBDpackedobject1 node has objid == 0 and your groundplane has objid == 1 I am a little confused as what you are trying to add a color to? Is it the cubes or the constraints?

Also the documentation is quite well updated with the difference between the new sparse solver and the old dense solver. https://www.sidefx.com/docs/houdini/pyro/index.html

you could create a piece of geo with uv's apply they texture and instance that only the grain particles?

you can enable a bevel scale as a point attribute on the polybevel. this can give you a nice rounded bevel at the top and a hard square edge at the bottom.