jsmack
Copy to points with packed prims or alembic prims is what I would consider the state of the art workflow--and solaris instancer node works roughly the same way. You can even skip the instancer node and import packed prims directly from sops--and they'll keep their instancing.

Thank you. I have this working now, (skipping the instancer node). But had to "pack" the geometry after the "copytopoints" node in the foreach loop so point colors and velocity would work in LOPs. BTW, cannot seem to get angular velocity (w) to work. Is this supported in Karma?

jsmak
For building instancing natively in LOPs, start with the same point cloud in sops as for copytopoints: with the transform attributes, instance identifier (variant)...

Have not got to this yet... am still trying to understand what the "instance identifier (variant)" is. Is this an attribute on the target points with a path to geometry in the network or on disk? (Still so much USD vocabulary & concepts to learn.)

fgillis
Thank you. I have this working now, (skipping the instancer node). But had to "pack" the geometry after the "copytopoints" node in the foreach loop so point colors and velocity would work in LOPs. BTW, cannot seem to get angular velocity (w) to work. Is this supported in Karma?

That sounds like no instancing then. If you pack after, then there is just one detail.

fgillis
Have not got to this yet... am still trying to understand what the "instance identifier (variant)" is. Is this an attribute on the target points with a path to geometry in the network or on disk? (Still so much USD vocabulary & concepts to learn.)

For the instancer lop, the identifier is a name attribute on the points, it corresponds to the name of the prims in the template geometry. You can't point to anything on disk.

I made a little demo scene showing instancing with inherited color from points

jsmack
I made a little demo scene showing instancing with inherited color from points

Thank you for the hip file, the three examples are really helpful!
Will be spending more time experimenting with your methods, trying to understand them, and adapting them to my needs.

One note though, not all versions work with CPU and XPU. As a test, I also added a velocity attribute (v) to the points in your "copytopoints_native" SOP Create. These were my results...

Switch 0:
Karma CPU: no velocity
Karma XPU: no point colors or velocity

Switch 1:
Karma CPU: OK
Karma XPU: no point colors

Switch 2:
Karma CPU: OK
Karma XPU: no point colors

I guess that brings us almost full circle to the original question of this post.

BTW... kinda cool seeing DOF in Houdini GL viewport.

Cheers.

fgillis

jsmack
I made a little demo scene showing instancing with inherited color from points

Thank you for the hip file, the three examples are really helpful!
Will be spending more time experimenting with your methods, trying to understand them, and adapting them to my needs.

One note though, not all versions work with CPU and XPU. As a test, I also added a velocity attribute (v) to the points in your "copytopoints_native" SOP Create. These were my results...

Switch 0:
Karma CPU: no velocity
Karma XPU: no point colors or velocity

Switch 1:
Karma CPU: OK
Karma XPU: no point colors

Switch 2:
Karma CPU: OK
Karma XPU: no point colors

I guess that brings us almost full circle to the original question of this post.

BTW... kinda cool seeing DOF in Houdini GL viewport.

Cheers.

Yeah, unfortunately XPU doesn't really support instancing with different inherited attributes yet. There's no way to get different colors on different instances with XPU.

Velocity won't work on the first switch because it uses native instances, not point instances. Velocities can only be applied to points/vertices and not xforms (which are more like objects). For xform motion blur, multiple time samples of the transform matrix would be used.