OTOY Forums

Hey,

One of the main advantages for me in using USD and within Houdini/Solaris specifically is the instancing support. I know there is probably a lot of work that needs to be done with octane core to support the full breath of instancing options available in USD (and reading primvars) BUT as of right now I can't seem to replicate the functionality that is working in the standard houdini plugin.

When I use the point instancer in LOPs I get the geometry showing correctly in Octane (not sure if its actually instancing though or expanding everything?) but if I try and use the "rgb4k_map" Instance Color trick in a material, everything just turns yellow. Is this a feature this is meant to be working already or something that isn't yet supported?

Thanks!

JPeg wrote:Hey,

One of the main advantages for me in using USD and within Houdini/Solaris specifically is the instancing support. I know there is probably a lot of work that needs to be done with octane core to support the full breath of instancing options available in USD (and reading primvars) BUT as of right now I can't seem to replicate the functionality that is working in the standard houdini plugin.

When I use the point instancer in LOPs I get the geometry showing correctly in Octane (not sure if its actually instancing though or expanding everything?) but if I try and use the "rgb4k_map" Instance Color trick in a material, everything just turns yellow. Is this a feature this is meant to be working already or something that isn't yet supported?

Thanks!

Hi Jpeg,

Thank you so much for your feedback.

Would you please share a sample file here or via PM for our devs to look at?

cheers

Hi BK,

I've attached a hip file that shows the issue, let me walk you through it here:

First I've made 2 example streams, a solaris based one (that isn't working) and a ROP based one that is (using the texture map workaround).

In the /obj root you will find 2 subnets that contain the different examples: Looking first at the ROP example: Here I've just setup 4 objects and assigned this basic material to them (the file path will need to be updated for you): Inside the instance1 object there are points with a "Cd" and "instance" attribute on them.

Then launching IPR from the Octane ROP: Produces this result: As far as I understand it, this is considered the "correct" workflow for instancing in Houdini and reading in a color value for use in the shader (the only attribute that is supported for instancing), unless I'm mistaken there? Either way, this example is working.

Now looking at my solaris example, back to root and diving into the LOP network: Here I have tried to replicate the same logic with this scene graph: The instancer LOP is set to "Point Instance" method so there is only 1 copy of the source mesh in the scene graph and its instanced onto the points (if you set the method to Reference, it will copy the mesh and apply the attributes, but that isn't instancing).

This seems to at least instance the geometry correctly when rendering with Octane, but the material assignment no longer works like it did before, it all just turns yellow Ideally (and this is now a feature request rather than a bug) you'd be able to read in primvars for use in the shader, like you can with the materialX nodes

primvars on the instancer: accessing them for the material: Thanks!

JPeg wrote:Hi BK,

I've attached a hip file that shows the issue, let me walk you through it here:

First I've made 2 example streams, a solaris based one (that isn't working) and a ROP based one that is (using the texture map workaround).

In the /obj root you will find 2 subnets that contain the different examples:

instancing001_1.jpg

Looking first at the ROP example:

instancing001_2.jpg

Here I've just setup 4 objects and assigned this basic material to them (the file path will need to be updated for you):

instancing001_5.jpg

Inside the instance1 object there are points with a "Cd" and "instance" attribute on them.

Then launching IPR from the Octane ROP:

instancing001_3.jpg

Produces this result:

instancing001_4.jpg

As far as I understand it, this is considered the "correct" workflow for instancing in Houdini and reading in a color value for use in the shader (the only attribute that is supported for instancing), unless I'm mistaken there? Either way, this example is working.

Now looking at my solaris example, back to root and diving into the LOP network:

instancing001_6.jpg

Here I have tried to replicate the same logic with this scene graph:

instancing001_7.jpg

The instancer LOP is set to "Point Instance" method so there is only 1 copy of the source mesh in the scene graph and its instanced onto the points (if you set the method to Reference, it will copy the mesh and apply the attributes, but that isn't instancing).

This seems to at least instance the geometry correctly when rendering with Octane, but the material assignment no longer works like it did before, it all just turns yellow

instancing001_8.jpg

Ideally (and this is now a feature request rather than a bug) you'd be able to read in primvars for use in the shader, like you can with the materialX nodes

primvars on the instancer:

instancing001_9.jpg

accessing them for the material:

instancing001_10.jpg

Thanks!

Hi JPeg,

thank you so much for your help!!
We have sent a request to our Solaris dev if we can implement this feature in future releases!

thanks again!

Cheers

BK wrote: Hi JPeg,

thank you so much for your help!!
We have sent a request to our Solaris dev if we can implement this feature in future releases!

thanks again!

Cheers

No worries, I hope this helps and please ping me if there is anything more I can test or provide examples for!! I'd really like to use octane more and in different workflows, so having a solid hydra delegate will _really_ help with that in the future. Also beyond Solaris as well; for example being able to use the brigade kernel with a USD scene will open up a lot of interesting real-time possibilities

JPeg wrote:

BK wrote: Hi JPeg,

thank you so much for your help!!
We have sent a request to our Solaris dev if we can implement this feature in future releases!

thanks again!

Cheers

No worries, I hope this helps and please ping me if there is anything more I can test or provide examples for!! I'd really like to use octane more and in different workflows, so having a solid hydra delegate will _really_ help with that in the future. Also beyond Solaris as well; for example being able to use the brigade kernel with a USD scene will open up a lot of interesting real-time possibilities

Thank you JPeg, for your kind offer. Yes, it helps us a lot.
Totally agree !! USD would be the future production pipeline for all the 3d sofwares!

Please feel free to let us know if any feedback especially the workflow!

cheers