So I'm looking through this example file of Cubes Marching.
http://www.tokeru.com/cgwiki/index.php?title=Houdini#Cubes_marching [tokeru.com]

But for my scene, I'm trying to achieve a Loop Animation of the cubes falling onto the stairs and then dropping off thus creating a loop. I managed to get the looping done, however the problem I'm facing now is the rotation of the Cubes.

Problems:
When the cubes rotate in the Y axis, the cubes will randomly scales in sizes which confuses me.

That is weird but you are passing incorrect values to the functions. The help file mentions that the primintrinsic is used for operating upon primitives yet you are passing a point index. You are doing the same on the set. My guess is your are not changing what you intend to change because of index skew.

A few things wrong there, most of the problems become evident if you enable the geometry spreadsheet, set the viewport to show point numbers, and set the display mode to wireframe (not the default wireframe ghost, as that will hide the point numbers of the packed cubes).

Watch cube 0 when it shrinks. If you look in the spreadsheet, you can see that the @axis vector is {0,0,0} at these times. The rotate command has no rational way to deal with this, so just shrinks the cubes.

Regardless, the cubes never change their axis of rotation in your example. As such, you don't need to calculate the axis, just hardcode it to be along the x-axis, so @axis = {1,0,0};

Having done that, the rotation still does odd things. This becomes clear if you display the copy sop; the cubes are being rotated because your input points have @v. You can either remove @v before the copy, or turn off ‘transform using template point attributes’ on the copy sop.

So with that sorted, we can look at the rotation itself. There's still pops and kicks, looking in the geo spreadsheet again can see they correspond to when the cubes make a sharp turn; there's an instantaneous change of velocity, which doesn't look nice.

You're using the length of @v to drive the rotation speed, if you bind that to an attribute and watch it, you can see its pretty much constant (apart from the kicks), so may as well drive that with a constant too for now.

Finally there's offsetting the cubes so they sit on the stairs. With the cubes now doing a smooth rotation, you can see that they intersect the stairs a little, which they shouldn't do. The idea of that second wrangle is to query the bounding box of each packed prim, get the y-position of the lowest edge, and lift it up. It should be changing all the time (its in worldspace after all), but the value you're getting is a constant; that can't be right.

To find out which of the values in the bounds array is the right one, I switched to the right viewport, watched just cube 0, and tried to observe when different parts of it crossed different obvious thresholds. By watching when the lowest part of the cube touched the ground (ie when y=0), I could see that it was b(3). Similarly observing for the right-most edge of the cube, the z-offset was b(5).

All done! OR ARE WE?

It looks ok when the cube is rolling on a flat part of the step, but when its rolling over the corner it offsets quite far from the step. The reason is that the bounds is a worldspace-aligned cube around the whole packed geo, it doesn't rotate along with your cube, Unfortunately after all this effort, this technique won't work for this geometry! Arrgh!

Lucky for you, I started experimenting with rolling cubes over arbitrary 3d geo, not just a ground plane. It takes into account the normal of the surface its rolling on, and calculates along that normal to know how to offset the cube (at the bottom of the page) :

http://www.tokeru.com/cgwiki/index.php?title=HoudiniExperiments [tokeru.com]

It's not finished (that's why its on the experiments page), but could give you some clues.

Enivob, because this setup is using packed primitives, each point represents one primitive, so @ptnum and @primnum match.

Enivob, because this setup is using packed primitives, each point represents one primitive, so @ptnum and @primnum match.

@Matt: Ah, but is that good practice to obfuscate nodes? Would the code still work running over primitives instead of points?

Welllll… it's much of a muchness. @P is on the point, but the transform matrix is on the prim. Here this setup uses a point wrangle, looks up ptnum and @P, then manipulates the matching primnum attributes. If this were a prim wrangle, you'd modify prim attributes but then still have to go and manipulate point @P anyway.

It's a variation of the points/verts/prims stuff I discuss here:

http://www.tokeru.com/cgwiki/index.php?title=Points_and_Verts_and_Prims [tokeru.com]

Ultimately prims are connected to and driven by points, prims themselves aren't really meant to have position. Part of the speed benefits (and fun) of working with packed prims is being able to treat them as points.

I looked through the Generic Cube March example and also tried Hard-code the Axis normals. It certainly does fix the scaling problem of the cubes. But as you said, the technique wouldn't work on this scene but overall it's still quite a fun example to try on.

realised after having a play that the generic one won't work either; it only supports travelling over convex shapes, as it only does a single intersection check along the normal to the surface; for steps it would need to check twice, and its nearly midnight and I shouldn't get suckered in to working that out at this time of night.

instead, here's a cheaty alternative.

(and file)

Thanks! Will have a look at the files.