Hey, guys! i'm trying to use some geometry as a mask for blending things, but it seems i cant do it the way it used to be in mantra. see the screenshot
how can i access USD geometry from the shader?

Any news about this???

I did not figure it out

Karma is a Hydra delegate, so it can access only the data that Hydra provides to it. And I don't think Hydra provides access to the whole scene graph. So, Karma may not be able to access that data.

rafal
Karma is a Hydra delegate, so it can access only the data that Hydra provides to it. And I don't think Hydra provides access to the whole scene graph. So, Karma may not be able to access that data.

That´s sad news...
I love the Solaris workflow, I´ve been using Karma for 6 months or more in production (alongside with renderman and redshift) and for a pipeline standpoint It´s amazing, but for some features (like the one we´ve been discussing in this post) I think the USD workflow is creating more boundaries that we´ve been used with mantra....

For me, being able to access other geometry data at rendertime is a huge feature. I hope somehow you guys manage to overcome some of the usd limitations in time.

Some workaround ideas:
- use geometry primvars to access geometry in a shader at render-time
- write out the data disk as Houdini geometry file, which then you can use in the Import Point VOP

rafal
Some workaround ideas:
- use geometry primvars to access geometry in a shader at render-time
- write out the data disk as Houdini geometry file, which then you can use in the Import Point VOP

Cool, didn´t know that reading bgeos inside the shader would work. That´s enough for this type of workflow.
In H18 I´ve tryied that without success, but I´ll take a second look.

Thanks Rafal.

rafal
Karma is a Hydra delegate, so it can access only the data that Hydra provides to it. And I don't think Hydra provides access to the whole scene graph. So, Karma may not be able to access that data.

doesn't have to be the whole scene graph, but would there be a way to access at least what's actually passed? cameras, lights, geo that's passed through (this relates to rfe#100498)

I was so happy when Mantra was able to finally reference geo using op: syntax just to be taken away by Solaris, while the expectations were quite opposite (to be able to access much more than just geo)
going back to referencing files directly is another unnecessary layer of complexity, given that asset paths may need a resolver to be correcct so hacking that in the shader feels like a workaround

tamte

rafal
Karma is a Hydra delegate, so it can access only the data that Hydra provides to it. And I don't think Hydra provides access to the whole scene graph. So, Karma may not be able to access that data.

doesn't have to be the whole scene graph, but would there be a way to access at least what's actually passed? cameras, lights, geo that's passed through (this relates to rfe#100498)

I was so happy when Mantra was able to finally reference geo using op: syntax just to be taken away by Solaris, while the expectations were quite opposite (to be able to access much more than just geo)
going back to referencing files directly is another unnecessary layer of complexity, given that asset paths may need a resolver to be correcct so hacking that in the shader feels like a workaround

That´s true, if we could just access the geo from the stage would be better...

I´ve never used the "op" sintax because the geometryt was never included in the ifd. Did they change the behavior at some point?

guilhermecasagrandi
I´ve never used the "op" sintax because the geometryt was never included in the ifd. Did they change the behavior at some point?

yes, I think it was added around H16
you can use op: syntax to access any geometry that's in the ifd, so any renderable or nonrenderable object that's matching the Mantra object lists
weirdly enough you have to know it's SOP path, not just object level path, even though it should be clear, but that's another RFE, that feature though is a lifesaver especially with heavier procedural geos that don't have to be cached to disk this way saving not only extra step of managing the geometry export to get up to date render, but also saving potentially a lot of disk space

Being able to access the renderable USD scene graph would be a great Karma feature. It would be a competitive advantage from my POV. My guess is that it's probably hard to implement efficiently...

jparker
Being able to access the renderable USD scene graph would be a great Karma feature. It would be a competitive advantage from my POV. My guess is that it's probably hard to implement efficiently...

Shaders would probably need to be connectable to gprims for that to be possible.