Hey,

I'm trying to figure best workflow for multi-shot managing intstances, and figure creating point clouds in a layer to be instanced after the shot switching is best approach.

However I lose the orientation and point attributes.

I've attached a hip to show the different behaviour I"m seeing:

First tree - using "Internal Sop" gives me orientation and point attributes I'm after. Then to get my second set of instances I'm object merging the same point cloud. This is how I've been doing things, but doesn't suit my intended workflow and involves object merging at sop levels which is too old school.

Second tree - Using "Internal Sop" again for first instance.. second instance I'm attempting to instance to the first input primitives. This gives me orientation, but I lose the point attributes. ( Some times as I click around in Houdini GL view the balls turn coloured, but never in Karma )

Third tree - this is my intended workflow - create the point cloud then instance to "First Input's Points". Works in that I can repeat that instance the second time using the same technique. But I don't get orientation or point attributes on either instanced set.

Is that third tree a bug I should be reporting? Is there a different workflow someone might suggest?

Cheers

You are correct that these are somewhat unexpected limitations. But no need to submit any bugs. These issues are already being tracked (114060 for copying primvars and 117937 for respecting the normals attribute when building instance transforms).

In the interim, you can generate the required "primvars:orient" from "N" or "up" in SOPs via an Attribute Wrangle like this:

19.0.497 will have changes for both the issues mentioned above:

N/v/up will now be used when orienting instances. The behaviour should match the Copy To Points SOP.

Much less excitingly, "Point attributes to copy" will be disabled when using a "First input's points" and "Point instancer" configuration. It's still on the to-do list to make this work but, for the time being, at least we'll make it more obvious that this isn't currently supported.

That'll be very convenient, thank you Rob. Does it follow the entire cascade we see in: https://www.sidefx.com/docs/houdini/copy/instanceattrs [www.sidefx.com] ?

jason_iversen
That'll be very convenient, thank you Rob. Does it follow the entire cascade we see in: https://www.sidefx.com/docs/houdini/copy/instanceattrs [www.sidefx.com] ?

It's very likely not an exact match for that page, but it's getting much closer.

My target is that you should be able to use the same SOP points (with N/v/etc) and feed them into either a Copy To Points SOP or an Instancer LOP (via SOP/Scene Import to first convert them to a USD point cloud) and get the same transformations of the instances coming out.

As/when differences are spotted, you know I'm only a bug report or forum post away

robp_sidefx
It's very likely not an exact match for that page, but it's getting much closer.

Cool, thanks for the effort. Just FYI, in my experience, I'm usually messing with various combos of N/v/up (where any of those three can be present or missing), often coupled with with 'pscale' or 'scale') before going to or 'rot', orient'. I hate dealing with quaternions and prefer matrices.

robp_sidefx
It's very likely not an exact match for that page, but it's getting much closer.

I believe it's worth investing some time to make it match since the rules are known and it even has instance() vex function to build it (or if it's done through Python maybe equivalent function would be useful)
since if done incrementally some not so commonly used attributes may be omitted like @trans, @pivot, @rot or @transform

otherwise if someone runs into this in production it's stressful to wait for updated build or impossible if on locked stable build