Which one to use when?

There is a feature comparison in the Help Desk section of Houdini:
https://www.sidefx.com/faq/question/karma-vs-mantra/ [www.sidefx.com]

The main difference is that Karma is currently in beta and works with USD via Solaris/LOPS. Normal scenes must be imported into Solaris in order to render with Karma.

Mantra is production-ready but doesn't work with USD and development time is focused on Karma going forward.

Does karma parse usd directly without any convertion?

Mantra must wait for ifd convertion that is usually slow.

USD is to Karma what IFD is for Mantra

jerry7
Does karma parse usd directly without any convertion?

Mantra must wait for ifd convertion that is usually slow.

AFAIK Karma does not parse USD the way mantra would parse an IFD. Karma is a hydra delegate, so hydra exists as the layer that translates the usd to calls karma understands.

Correct me if I'm wrong here.

Yeah I was never a 100% clear on this either. In the HIVE talks it was stated that Karma ingests USD, but I don't think you can really say that if it's going through Hydra first. Maybe it's a moot distinction. Are there any renderers that bypass Hydra and deal with USD files directly or is that just not the way things are meant to work?

When I requested shaders in Karma to be able to use existing usd_* functions (once they can take .usd file handle as an argument) to access the data from .usd being rendered
the answer was, that this is unlikely because “The architecture of karma puts a thin layer between USD and the actual renderer implementation. The rendering library (and shaders) don't actually know that USD is the front-end”

Which was a big disappointment and while it doesn't answer any questions whether Karma parses usd directly and that thin layer is part of Karma or whether it is the actual Hydra they are talking about it certainly shows that shaders don't have access to the .usd which to me sounds like a wasted opportunity, since all the information is already there and access to it would open a great potential

and it actually brings up the question how will Karma handle access to such information which in very limited sense Mantra handles using op: references to the geometry in .ifd for example

tamte
When I requested shaders in Karma to be able to use existing usd_* functions (once they can take .usd file handle as an argument) to access the data from .usd being rendered
the answer was, that this is unlikely because “The architecture of karma puts a thin layer between USD and the actual renderer implementation. The rendering library (and shaders) don't actually know that USD is the front-end”

Which was a big disappointment and while it doesn't answer any questions whether Karma parses usd directly and that thin layer is part of Karma or whether it is the actual Hydra they are talking about it certainly shows that shaders don't have access to the .usd which to me sounds like a wasted opportunity, since all the information is already there and access to it would open a great potential

and it actually brings up the question how will Karma handle access to such information which in very limited sense Mantra handles using op: references to the geometry in .ifd for example

Could this be solved on the USD side with the creation of a geometry relationship on material prims? Sort of the opposite of a material relationship on GPrims.

jsmack
Could this be solved on the USD side with the creation of a geometry relationship on material prims? Sort of the opposite of a material relationship on GPrims.

not sure, anything else than direct access to the .usd handle that already exists as an efficiently composited and resolved usd stage somewhere in memory sounds like just cherrypicking subset of information to send to shader and also locks the shader to use just that binding, while I may need it to be reaching for completely different data based on object it is assigned to

but also what use would be relatioship binding to GPrim if shader will still not be able to access that GPrim and do pointcloud lookup to it for example as we currently can do against geo in the .ifd?
or also just to get any property value of currently shaded object (not the granular ones that we can use primvars: for but any, like transform) also transform or properties to compute projection matrix of currently used camera or any camera in usd if I want to do camera mapping shader, simply in theory all I need is access to that stage in memory, rather than cherrypicking data for each object and shader and trying to pass it as primvars: or any other way
also there was a talk about coordinate systems, but that's the same thing, just subset of the information I may need

rmagee
There is a feature comparison in the Help Desk section of Houdini:
https://www.sidefx.com/faq/question/karma-vs-mantra/ [www.sidefx.com]

The main difference is that Karma is currently in beta and works with USD via Solaris/LOPS. Normal scenes must be imported into Solaris in order to render with Karma.

Mantra is production-ready but doesn't work with USD and development time is focused on Karma going forward.

Is it possible to have the faq updated for Houdini 18.5 please?

The comparison chart has been updated to show both 18 and 18.5 status compared to Mantra:

https://www.sidefx.com/faq/question/karma-vs-mantra/ [www.sidefx.com]

Thank you Robert.