main differences between Karma and Mantra?
7023 11 0- johnmarc
- Member
- 10 posts
- Joined: July 2020
- Offline
- rmagee
- Staff
- 1171 posts
- Joined: July 2005
- Offline
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.
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.
Robert Magee
Senior Product Marketing Manager
SideFX
Senior Product Marketing Manager
SideFX
- jerry7
- Member
- 617 posts
- Joined: Nov. 2013
- Offline
- rmagee
- Staff
- 1171 posts
- Joined: July 2005
- Offline
- jsmack
- Member
- 7658 posts
- Joined: Sept. 2011
- Online
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.
- Siavash Tehrani
- Member
- 710 posts
- Joined: July 2005
- Offline
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?
- tamte
- Member
- 8449 posts
- Joined: July 2007
- Offline
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
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
Edited by tamte - July 8, 2020 21:41:04
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- jsmack
- Member
- 7658 posts
- Joined: Sept. 2011
- Online
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.
- tamte
- Member
- 8449 posts
- Joined: July 2007
- Offline
jsmacknot 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
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.
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
Edited by tamte - July 8, 2020 22:07:35
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- benco
- Member
- 35 posts
- Joined: July 2005
- Offline
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?
- rmagee
- Staff
- 1171 posts
- Joined: July 2005
- Offline
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]
https://www.sidefx.com/faq/question/karma-vs-mantra/ [www.sidefx.com]
Edited by rmagee - Oct. 26, 2020 14:14:43
Robert Magee
Senior Product Marketing Manager
SideFX
Senior Product Marketing Manager
SideFX
- benco
- Member
- 35 posts
- Joined: July 2005
- Offline
-
- Quick Links