Apply different material and shading to each copy instance

   296   4   3
User Avatar
Member
21 posts
Joined: Jan. 2013
Offline
what I want is to apply different material and shading to each copy instance


basically in a foreach loop block

1 - im using the copy to point

2 - after assignt a diferent material to each instance
//as primitive string attribute
s@shop_materialpath = "material path";

3 - them Sop Pack each instance and finish the foreach loop block

4 - Cache the single frame

if load the cache as "all geometry" each instance packed it render the material fine in Mantra, but not in Karma rop.
if load as "packed disk primitive" it do not work in neither Mantra or Karma rop.
in Karma rop it only work if is not pack at all and load all geometry

if there is a better way please say it
Edited by sheep - Jan. 10, 2025 01:58:23
User Avatar
Member
406 posts
Joined: April 2018
Online
You can use the more user-friendly Vary Material Assignment LOP, but that will not make use of an existing SOPs attribute.

If you need to use your SOPs attribute, know that shop_materialpath is ignored by Solaris. It expects an attribute/primvar named usdmaterialpath. You can initialise this based on you existing materials in Solaris (and not materials outside Solaris). Then, on the SOP Import LOP, you need to set "Bind Materials" to "Bind Materials Based on Imported Attribute".

Keep in mind that none of this will translate any "legacy" materials into Solaris. You should have your materials set up in Solaris itself.

If you're comfortable with VEX, then on the Assign Material LOP you can leverage the "Specify Material Using" > "Vexpression" to get even more control over your material distribution. You can also override material parameters on a per-prim basis over there.
User Avatar
Member
21 posts
Joined: Jan. 2013
Offline
eikonoklastes
You can use the more user-friendly Vary Material Assignment LOP, but that will not make use of an existing SOPs attribute.

If you need to use your SOPs attribute, know that shop_materialpath is ignored by Solaris. It expects an attribute/primvar named usdmaterialpath. You can initialise this based on you existing materials in Solaris (and not materials outside Solaris). Then, on the SOP Import LOP, you need to set "Bind Materials" to "Bind Materials Based on Imported Attribute".

Keep in mind that none of this will translate any "legacy" materials into Solaris. You should have your materials set up in Solaris itself.

If you're comfortable with VEX, then on the Assign Material LOP you can leverage the "Specify Material Using" > "Vexpression" to get even more control over your material distribution. You can also override material parameters on a per-prim basis over there.

thanks a lot, I been trying to avoid LOP and Solaris, im not a big fan of it, do you know how would this be possible with the Mantra or Karma rop in the traditional way?
User Avatar
Staff
418 posts
Joined: Feb. 2008
Offline
You can prep most of it in SOPs without doing much in LOPs at all. The SOP Create LOP has a button to automatically detect and assign materials.

Here's an example showing how you can assign different materials to different instances (an example for native and for point instances) as well as getting variations in materials by using primvars (SOP attribs) to drive the material look.

Attachments:
Material_Variations.hip (578.3 KB)

User Avatar
Member
21 posts
Joined: Jan. 2013
Offline
npetit
You can prep most of it in SOPs without doing much in LOPs at all. The SOP Create LOP has a button to automatically detect and assign materials.

Here's an example showing how you can assign different materials to different instances (an example for native and for point instances) as well as getting variations in materials by using primvars (SOP attribs) to drive the material look.


thanks for the file, it work.

Actually i just realise in my case the geometry to be instace was pack and thats why Karma Rop was not working when I use also use "Pack and instance" in the copy to points. now it work same as with Mantra.

is normal that the assigned shader cant be read when loading the cache as "Packed disk primitive"?

im trying to safe memory and try to be efitien when scattering and rendering millions of instances loading it as pack disk primitive, would this be correct way?

here is a little example, I personally find it even more simpler and easier than using Solaris, still I will continue learning Solaris to learn these new ways
Edited by sheep - today 21:32:41

Attachments:
variation_material.hipnc (1.0 MB)

  • Quick Links