instancing + material variation - why is it working?
7871 9 1- Marco Dörner
- Member
- 31 posts
- Joined: June 2016
- Offline
Please see the attached screenshot, then this should make more sense. It is a simple setup of a pointinstancer where the primvar "color" of one instance gets overwritten. I do not understand why it works and was hoping someone can shed a light.
Without the instance, the mesh prim soccerball_IDcolor has a primvar "color" and is assigned a (redshift) shader, which reads this primvar to drive the material color. This primvar has to be on the same mesh that holds the shader (I think).
Now, when instancing, afaik only the top level primitive of an instance can hold modified parameters - I would expect this to be either Root here or soccerball - especially that the material variation node only points to /addpointinstancer1 (instad of /addpointinstancer/soccerball/soccerballAva/render/soccerball_IDwhite or something like that).
So it seems to me this new primvar, created by material variation is sitting on an Xform primitive somewhere "above" the actual mesh primitive. And yet - the color of the shader changes - how?
Thanks for any help - still learning more about USD every day.
Without the instance, the mesh prim soccerball_IDcolor has a primvar "color" and is assigned a (redshift) shader, which reads this primvar to drive the material color. This primvar has to be on the same mesh that holds the shader (I think).
Now, when instancing, afaik only the top level primitive of an instance can hold modified parameters - I would expect this to be either Root here or soccerball - especially that the material variation node only points to /addpointinstancer1 (instad of /addpointinstancer/soccerball/soccerballAva/render/soccerball_IDwhite or something like that).
So it seems to me this new primvar, created by material variation is sitting on an Xform primitive somewhere "above" the actual mesh primitive. And yet - the color of the shader changes - how?
Thanks for any help - still learning more about USD every day.
- antc
- Member
- 335 posts
- Joined: Nov. 2013
- Offline
- goldleaf
- Staff
- 4195 posts
- Joined: Sept. 2007
- Offline
- Marco Dörner
- Member
- 31 posts
- Joined: June 2016
- Offline
Inheritance - I see thanks.
If I change materialvariation2 to point to a primitive further up (like /soccerball) I can see the parameter being passed down and when rendering (before instancing) I see the color - great!
However after instancing this does not work anymore - the materialvariation acting on instances only seems to have an effect if there is a primvar of the same name already on the mesh prims (not inherited). Further the default value is reset: if materialvariation1 (after the instancer) is set to only affect a specific instance (with for example) all other soccer balls have black as a color (the default in the shader), NOT the color specified in materialvariation2.
If I change materialvariation2 to point to a primitive further up (like /soccerball) I can see the parameter being passed down and when rendering (before instancing) I see the color - great!
However after instancing this does not work anymore - the materialvariation acting on instances only seems to have an effect if there is a primvar of the same name already on the mesh prims (not inherited). Further the default value is reset: if materialvariation1 (after the instancer) is set to only affect a specific instance (with for example) all other soccer balls have black as a color (the default in the shader), NOT the color specified in materialvariation2.
- goldleaf
- Staff
- 4195 posts
- Joined: Sept. 2007
- Offline
Marco Dörner
Inheritance - I see thanks.
If I change materialvariation2 to point to a primitive further up (like /soccerball) I can see the parameter being passed down and when rendering (before instancing) I see the color - great!
However after instancing this does not work anymore - the materialvariation acting on instances only seems to have an effect if there is a primvar of the same name already on the mesh prims (not inherited). Further the default value is reset: if materialvariation1 (after the instancer) is set to only affect a specific instance (with for example) all other soccer balls have black as a color (the default in the shader), NOT the color specified in materialvariation2.
It should work, if I'm understanding what you want correctly. Here is an attached example.
Edited by goldleaf - July 2, 2021 09:33:25
I'm o.d.d.
- Tim Crowson
- Member
- 247 posts
- Joined: Oct. 2014
- Offline
- jsmack
- Member
- 8038 posts
- Joined: Sept. 2011
- Online
- goldleaf
- Staff
- 4195 posts
- Joined: Sept. 2007
- Offline
- Marco Dörner
- Member
- 31 posts
- Joined: June 2016
- Offline
Thanks. I checked out your scene, but I think it's a little bit different as you use duplicates, instead of instancing.
I added a scene to demonstrate what I am going for. On the left there is the Karma approach - however I wasn't able to get that to work at all.
On the right side there is redshift. Redshift needs a "user data" node in the shader to pick up the primvars on primitives (from the documentation it sounds like Karma does that without an extra node). This userdata is set to look for the primvar "color". The pointinstancer creates instances. Then with materialvariation4 a primvar "color" is written to all instances. When I render here I see all soccer balls turn yellow - success! Then I want to overwrite a specific one which I can do with (materialvariation5) - also that works, success!
However when I now extract this particular instance (5) all the user data set before is lost. The color primvar doesn't exist at all.
So my original question is - is there a way to extract an instance with all the data on it?
EDIT: figured out how to show the problem with Karma (left side): when rendering materialvariation7 the 5th instance is blue, but after it is extracted with extractInstances it becomes grey and the primvar "basecolor" is nowhere on the primitives.
I added a scene to demonstrate what I am going for. On the left there is the Karma approach - however I wasn't able to get that to work at all.
On the right side there is redshift. Redshift needs a "user data" node in the shader to pick up the primvars on primitives (from the documentation it sounds like Karma does that without an extra node). This userdata is set to look for the primvar "color". The pointinstancer creates instances. Then with materialvariation4 a primvar "color" is written to all instances. When I render here I see all soccer balls turn yellow - success! Then I want to overwrite a specific one which I can do with (materialvariation5) - also that works, success!
However when I now extract this particular instance (5) all the user data set before is lost. The color primvar doesn't exist at all.
So my original question is - is there a way to extract an instance with all the data on it?
EDIT: figured out how to show the problem with Karma (left side): when rendering materialvariation7 the 5th instance is blue, but after it is extracted with extractInstances it becomes grey and the primvar "basecolor" is nowhere on the primitives.
Edited by Marco Dörner - July 12, 2021 11:27:20
- Hamilton Meathouse
- Member
- 199 posts
- Joined: Nov. 2013
- Offline
Marco Dörner
Further the default value is reset: if materialvariation1 (after the instancer) is set to only affect a specific instance (with for example) all other soccer balls have black as a color (the default in the shader), NOT the color specified in materialvariation2.
I have found this as well - specifying a single point instance in the Material Variation LOP will mean the override is obeyed by that particular instance, but all other instances get a value of zero (in my case I'm driving the Diffuse Gain or Albedo Multiplier value).
-
- Quick Links