nuki

you are fetching the impact points tho, not the packed prims? The impact positions could be overlapping if your object is just bouncing in place. Maybe you could share the scene so we are on the same page here.

noobini is right in both points. The pointwrangle is executed for every point in input 1. Think about it from a single points perspective: It can have an id of EITHER 1 OR 3 for your code to fire. Its a single integer attribute, so how is it ever supposed to be both 1 AND 3? you'd have to use if(i@id ==1 || i@id ==3) {} look at the simple example attached - with these things its often easiest to test them outside of the dopnet if possible. you can even use an expression in the group field to achieve the same. pointwrangle.hiplc

you could use a scalar field (eg. with an animated 0-1 ramp) and multiply turbulence/vel with

The PolyExpand2d node should handle that out of the box

promoting P to a detail attribute (by avg, min/max etc.) can be a useful trick too!

ah, its the constraint force mixing - which is enabled by default for hard constraints on the solver.

hm, if i use my exact same setup, just with bullet sops, the whole thing gets unstable af. Raising constraint substeps helps a lot, but I cant get completely rid of the jittering. constd2.hiplc

I would use a hard constraint with type set to ''position'' for the hinge. For simple one-way collision with the fluid I'd mesh the fluid, convert that to vdb and get a collider for bullet with vdbtospheres. eg. like in the attached file it would probably be a good idea to match the flip solver substeps to the bullet substeps. constd.hipnc

@drøgö sorry for taking so long. What I meant was that, since SDF values just store the distance to the closest surface point, you can just subtract a fog volume from that SDF in order to dent it. Its scale dependant, but that could be compensated by using relbbox.

use this: s@constraint_name = 'ramped_glue'; s@constraint_type = 'glue'; f@strength = fit(v@P.y, ch('min'), ch('max'), 0.0, 1.0)*ch('strength'); in a primitive wrangle. Instead of just multiplying by the 'strength' factor, you could set out_min and out_max instead of 0.0 and 1.0 constraint_ramp.hiplc

Because filtering does distort the mesh a little I presume?

@Noobini thanks for the file - I will have a look in the evening! I did play around with attach to geo constraints, but deleted all of it in this simple example to exclude it as a possible source of error. I think you may be right about lowering the substeps since the pumping got worse with increasing temporal resolution . In the end I will probably need substeps tho because the whole thing should playback at 60fps. @anim @Atom I still have to familiarize myself with chops, but it seems super useful for that kind of stuff. The Mocap data is baked from a retargeted HIK in Maya, so theoretically it would also be possible to do the filtering there.

I am testing a cloth sim on this simple mocap dummy and get this weird pumping throughout the sim. My initial suspicion was that it was caused by the framerate of the alembic cache I use as a collider, but that seems to be interpolated nicely when inspecting with float frame numbers. The alembic cache is around 50mb so heres a OneDrive link to a cleaned up scene file. Theres really nothing beyond basic going on in this scene so I guess it would have to do with the cloth constraints. Since I'm new to vellum any suggestions on how I could get rid of that pumping (preferrably without filtering -> collisions) are really appreciated. scene file rr_test_v002.mp4

You can use foreach loops and their meta import to do just that. Check out the detail() expression reading the integer number of the current iteration to drive the seed. The copytop oints node can even pack the geo for you. test.hiplc

Add sop creates a polyline between the points in order, the scatter sop randomizes point order by default hence the messy appearance. You could do branching lighting with some vex growth, an l-system or shortestpath sop. One approach might be: