Hi. How do I get the Instancer to read the displayColor primvar on my points? The USD that I am loading has colour on the points, but as soon as I apply the Instancer, I no longer have any colour.

Applying a material and feeding displayColor to baseColor does nothing.

Works fine for me, at least with karma as the renderer... See attached hip file.

Mark

mtucker
at least with karma as the renderer.

Just a small note that with HoudiniGL you'll need a material that explicitly binds displayColor.

mtucker
Works fine for me, at least with karma as the renderer... See attached hip file.

Mark

Hi there. I am using Karma, and with the setup I'm trying to use, I can't get the point colour to work, even in your scene. Am I doing something wrong?

Modified scene also attached here. Cheers.

Unfortunately what you're trying to achieve won't work in this way. We can only extract point information (to copy to the instancer) from SOPs sources. Even though you're using a SOP Create, in the mode you have the instancer, you're asking it to use a LOPs (USD) source.

robp_sidefx
Unfortunately what you're trying to achieve won't work in this way. We can only extract point information (to copy to the instancer) from SOPs sources. Even though you're using a SOP Create, in the mode you have the instancer, you're asking it to use a LOPs (USD) source.

In that case, I'm thoroughly confused, because I am able to read the pscale/widths attribute from the same SOP Create LOP, just not the colour.

eikonoklastes
I am able to read the pscale/widths attribute from the same SOP Create LOP, just not the colour

That's an excellent observation. We handle transform-affecting attributes (such as pscale) as a special-case, for example the "Set Scale" parameter (marked in pink). For general attributes (such as displayColor) we rely on the "Point Attributes to Copy" parameter (marked in orange), which isn't available when using a LOP input for the "Target Points - Location Source". There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.

eikonoklastes
In that case, I'm thoroughly confused, because I am able to read the pscale/widths attribute from the same SOP Create LOP, just not the colour.

That's because the widths do work, but color doesn't.

robp_sidefx
That's an excellent observation. We handle transform-affecting attributes (such as pscale) as a special-case, for example the "Set Scale" parameter (marked in pink). For general attributes (such as displayColor) we rely on the "Point Attributes to Copy" parameter (marked in orange), which isn't available when using a LOP input for the "Target Points - Location Source". There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.

Thanks for the clarification. I'll switch to importing the points inside the Instancer.

jsmack

eikonoklastes
In that case, I'm thoroughly confused, because I am able to read the pscale/widths attribute from the same SOP Create LOP, just not the colour.

That's because the widths do work, but color doesn't.

Yes. What I said was in response to the statement, "We can only extract point information (to copy to the instancer) from SOPs sources." which is true in theory, but thanks to some wrangling, not true in practice, so the situation is a bit confusing.

robp_sidefx

eikonoklastes
I am able to read the pscale/widths attribute from the same SOP Create LOP, just not the colour

That's an excellent observation. We handle transform-affecting attributes (such as pscale) as a special-case, for example the "Set Scale" parameter (marked in pink). For general attributes (such as displayColor) we rely on the "Point Attributes to Copy" parameter (marked in orange), which isn't available when using a LOP input for the "Target Points - Location Source". There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.

Thanks for the explanation. I would add that, in my opinion, these kind of details and minor annoyances or unexpected results are what keeps me from enjoying Solaris as an individual, despite all the obvious and great workflow improvements it also offers.

Just ran into this same behavior and took most of a day before I found this post to explain why displayColor or other general purpose primvars aren't picked up from LOP inputs.
Stuff like this makes Solaris really difficult to troubleshoot, when there is a long-standing SOP behavior shadowed by a new LOP feature with a nearly identical interface and workflow which doesn't follow the same rules. I think in cases like this there should be a massive note to flag it in the docs.

jedmitchell
I think in cases like this there should be a massive note to flag it in the docs.

That is a fair criticism. I'll ensure this happens.

robp_sidefx

jedmitchell
I think in cases like this there should be a massive note to flag it in the docs.

That is a fair criticism. I'll ensure this happens.

Why is it hard to loft primvars from a points prim to a point instancer? It seems like it would be trivial. I suppose it's complicated by the fact that the same node can also create references instead of a point instancer. Is it an issue of how to solve the UI/UX for all cases and not a technical one?

Why is anyone trying to use a points prim source at all though? Is there a desire to render the source points as particles at the same time as copied instances, or is it just a lack of understanding the purpose of putting geometry on the stage?

jsmack
Why is it hard to loft primvars from a points prim to a point instancer?

The main challenge (if I remember correctly) is that we allow multiple prims to act as sources. So, best case, we need to merge N primvars into the point instancer. Not-so-best case, we find that some prims have the relevant primvars while others don't (in the context of a Merge SOP we'd throw up a warning and fill in the missing data with 0/"" - do we do the same here? do we instead ignore that primvar completely?). Worst case, different prims have different data types for the same primvar.

This is not an insurmountable challenge, of course, but it's still a complication that needs to be sorted out.

robp_sidefx

jsmack
Why is it hard to loft primvars from a points prim to a point instancer?

The main challenge (if I remember correctly) is that we allow multiple prims to act as sources. So, best case, we need to merge N primvars into the point instancer. Not-so-best case, we find that some prims have the relevant primvars while others don't (in the context of a Merge SOP we'd throw up a warning and fill in the missing data with 0/"" - do we do the same here? do we instead ignore that primvar completely?). Worst case, different prims have different data types for the same primvar.

This is not an insurmountable challenge, of course, but it's still a complication that needs to be sorted out.

Oh, interesting. I assumed it was a one-to-one requirement, as the SOP source only takes one SOP.

Just wasted a couple of days on this same issue before seeing this post.

Really want to make the move from Redshift to Karma XPU.

Have tried several times to transition, but some relatively simple things with mantra and Redshift are overly complex and frustrating with Solaris/Lops/Karma.

The following doesn't make me feel like the "simple things" are taken too seriously...
There is an open RFE to add this general support. In the interim, it might be interesting for us to consider treating colour as a special-case as well. I'll need to think a bit about the pros&cons here.

And, I have no idea where to start instancing in Solaris/Lops/Karma similar to the older, simpler way of just using "instancefile" or "instance" point attributes.

(Disclaimer: I hated VEX when it first came out. Didn't take long before I loved it. Am hoping it will end up being the same with Solaris/Lops/Karma.)

Hi Floyd, it would definitely help us (or at least help me) to have more user .hip files to better understand: how artists were working in Mantra, what their initial attempts to use Solaris look like, etc. If there's anything you can share (either here on the forum, or directly sent to us), it'd be much appreciated. I would like to work with you to repeat your hate->love transition.

fgillis
And, I have no idea where to start instancing in Solaris/Lops/Karma similar to the older, simpler way of just using "instancefile" or "instance" point attributes.

The instance/file attribute and instance object workflow is outmoded except for some third party renderers that don't understand packed prims such as Redshift. (Although Redshift probably supports packs now, it didn't at first.) Perhaps Redshift's dev adopted that workflow for instancing first since it was simple to implement in Houdini and now it stuck around as a standard workflow longer than it would have otherwise. 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.

For building instancing natively in LOPs, start with the same point cloud in sops as for copytopoints: with the transform attributes, instance identifier (variant), and any other attributes to be copied. Use this point cloud as the Internal or External SOP target points source for the instancer. I wouldn't use "first input's points or primitives" that are on the usd stage for instancing as these will also be rendered along with the instances. Using prims might be useful for placing lights or something, but I can't think of a use for copying to a points prim (USD native particles).

jsmack
The instance/file attribute and instance object workflow is outmoded...
For building instancing natively in LOPs...

Yes, I've been using Redshift for years and am (too?) comfortable with that workflow.

Thank you for the clear explanation! Will give it a try later today.

robp_sidefx
I would like to work with you to repeat your hate->love transition.

Thanks Rob. Cranky old people (like me) are always complaining about change.

Was putting together example hip files of my instancing "problems" when I came across this post.

Looking forward to trying jsmack's suggestions.