Skybar

Depending on what you are doing and how your geo looks like, you can also abuse compiled foreach loops to multithread otherwise single-threaded stuff.

Ah nice catch! I haven't used the new sourcing system that much and didn't know about this. In the old Source Volume DOP you could use only "vel" fine even if it was consisting of .xyz scalar volumes. With the new Volume Source DOP however, it is as you describe.

Yeah you could transfer the normals from the geometry to the curves afterwards, and ray them to the surface. And then some more smoothing and resampling. Could be a little jittery though.

Threw something together quick, might get you started dv_smoothcurve.hipnc

It can be done in a number of ways, I had a go at it. Hope it helps! dv_alignPlanks.hipnc

Well, no. The wrangle loops over all input points, and @ptnum will return the point number of the current point. So when it runs the code over the first point, @ptnum will return 0 - over the second point, 1 - over the third point, 2, etc. Up to 29 since we got 30 points that have point numbers 0-29. We established before that it will only loop over the input points, not new ones created in the wrangle. So if we use @ptnum when trying to set an attribute for a new point, it will return 0 because we are not currently looping over a point (essentially). So for all new points @ptnum will always return 0 and @numpt will return 30 (number of input points). We can see this because with your original code we actually get 31 points in the basePoints group - thats because @ptnum+@numpt is currently 0+30 - so point number 30 will be added which happens to be the first new point. But for all the other new points, it will still evaluate to 0+30 so none of those will be added. I'm not exactly sure of the specifics, but I'd imagine it first runs the code, then creates geometry, and then creates attributes. Or if it creates attributes on new geometry at the same time it is created. Something like that

It will run the code for every point, yes. Geometry will only be created after the code has run though, so @numpt won't update - it will only show the number of points in the input. If you are trying to add the new points to the group, you can simply do: setpointgroup(0, "basePoints", newpt, 1);

You can use setcomp() https://www.sidefx.com/docs/houdini/vex/functions/setcomp.html

Here is one way to do it. Emitting particles in one solver without collisions, and if they are X amount inside the collision sdf we can add those to a group. We then emit those particles in that group in another solver with collisions. We also delete the original particles afterwards because we dont need them anymore, and finally we can combine both in SOPs. dv_flipEmitIntoSphere.hipnc

You need to bind it in as v@upA. Houdini doesn't know that it is a vector, so everything that is bound as @attribute will be bound as a float. Exceptions are the standard attributes like P, N, up, v etc that is known by default.

Creation/deletion of geometry happens after the code is run. So it creates new points, and deletes the primitives. Since the newly created points isnt there until after the code is run, they wont be deleted.

Mantra ROP -> Rendering -> Render -> Use Max Processors

Yes, take a look at Split SOP for example.

You need to choose what volume you want to trail in the Velocity Volumes parameter.