stabby

...sorry if it's too late... curves_withSpheres_dirty.hip

Hi, If you're working with polys, then you should convert your curves to nurbs, order 2. Use a basis SOP and change U parameterization to 'Approximate Arc Length'. The carve SOP and primuv etc. will use the new parameterization. EDIT: should probably add that changing the parameterization of nurbs with order > 2 will change the shape of your curve a little.

This should work with arbitrary geo. The nodes you might have to tweak are in yellow. Pick you start points with ROOTS, adjust the max number on GET_DISTANCE so the mesh has no yellow, and use the Distance channel on ANIMATE to carve away the mesh. There are three carve nodes because sometimes just using one doesn't totally cut all the poly edges into separate prims - three usually does the job. The network relies on every prim having only two vertices. Also, there are occasions when an edge should be carved away from both ends, this network doesn't deal with that. Instead, the edge will be carved from one end only, but too quickly... carve.hip ps. to make it grow, not shrink, change the expressions in delete1 to $CUT == 0, and delete2 to $MAPU > $CUT

well, here is my half-arsed effort: swivel.hip It only works with triangles and needs nice clean geometry - ie. no more than two faces per edge (probably). ...it'll also screw up on the boundaries of open surfaces. I imagine you could do it much better with a few python sops.

I've fixed a couple of bugs - it should properly interpolate the forces and velocity now: equidistant3.hipnc

er.. i mean this one: equidistant2.hipnc the Texture Type on the texture node should be Rows & Columns.

this works i think - change the length on the resample sop equidistant2.hipnc

I don't really understand what you're trying to do with the trigger thing, but if you're trying to compute the distance traveled per frame in CHOPs, you should use the slope CHOP to get the velocity of the point, and the vector CHOP to get the magnitude, ie speed. then: speed * time-between-samples = distance-traveled-per-sample

Hi, we had to deal with this on a recent project. Ended up using the resample CHOP/SOP to get the subframe positions/velocities of the source, and integrating the particle system ourselves (in VOPs) - taking into account the subframe age of the particle (called framefrac in this example). The other difference between this VOP integrator and the houdini's integrator is the order it updates the attributes. Houdini updates the position of the particle first, then the velocity. The VOP integrator updates the velocity first, then uses the new velocity to update the position. I can't remember why we did it like this, but it seemed important at the time... hope it helps! equidistant2.hipnc

The 'rot' attribute is a quaternion, and the 4 numbers don't correspond directly to $rotx, $roty, $rotz and $rota. The actual equations are: rot[0] = rotx * sin(rota/2) rot[1] = roty * sin(rota/2) rot[2] = rotz * sin(rota/2) rot[3] = cos(rota/2) (this is assuming your axis is already normalized)

...there's also the metagroups SOP, if you want to keep everything in the same chain.

This doesn't count as doing it properly, but: x == x * 1e-45 + 1 is true when x == inf or -inf and false otherwise

It's only really slow if you echo one line at a time. I generally concatenate a thousand or so lines into a single string, and echo it all at once. It seems to be about, well, a thousand times faster.

Use another copy sop and the dopobjectlist expression to stamp the name of the objects back up the network - see attachment! pop_dop_impact_data.hip

Nice problem! Here's a solution using the SOP solver - it just slides a random piece each time. ...and it's not very elegant. slide.hip