Hello SideFX!

I've been putting together a comprehensive feature list that compares Redshift with Karma XPU, and I am posting here to get your feedback before publishing this as part of my upcoming render comparison video.

There are three questions that I've been asking myself when making this chart.

1. What does Karma do that Redshift cannot do?
2. What does Redshift do that Karma cannot do?
3. Which features are most important to the average user's workflow?

Not every single feature is part of this list (because, otherwise, it would be a mile long) but I want to know if there's anything here that should be added or corrected.

I'll need to have everything together by the end of this Thursday, and I'd love to have any/all constructive input.

Thank you all!

- Tyler

Actually, there is one correction that I just spotted here - I don't think XPU has any kind of Toon / Cell shading at the moment.

Thanks again,

- Tyler

Nice list

Found something that is not 100% correct.

Redshift does not have LPE tags or cell shading at the moment.

Redshift can have a room shader using a OSL shader from the Redshift OSL Github page https://github.com/redshift3d/RedshiftOSLShaders [github.com]

Heileif
Nice list

Found something that is not 100% correct.

Redshift does not have LPE tags or cell shading at the moment.

Redshift can have a room shader using a OSL shader from the Redshift OSL Github page https://github.com/redshift3d/RedshiftOSLShaders [github.com]

At the moment Redshift does not have a native cell shading.

Excellent! Thank you for the correction. I'll look into that, and fix it up.

Karma XPU is also missing the ability to turn a mesh into matte object [help.maxon.net].

Redshift can also not render AOV's at the same time as deep is active, only Cryptomatte works when it's activated.

Next RS release will have some long requested features, a few of them are huge.

One thing RS currently doesn’t have is support for Clone.

But like I said, wait until after the next RS release before you record/publish any video content, in comparison between the two.

TwinSnakes007
Next RS release will have some long requested features, a few of them are huge.

One thing RS currently doesn’t have is support for Clone.

But like I said, wait until after the next RS release before you record/publish any video content, in comparison between the two.

Thanks for the tip about Clone. I'll be sure to add that as well.

Unfortunately, I've already done the speed tests and recorded a lot of work prior to this list, so I won't be holding off until April. However, I know Redshift has a public-facing Trello board with many of the awesome new features that are currently in development, and I don't mind adding that to this list with a notation saying that it'll be releasing within the next month.

Does SideFX have something equivalent that's public-facing?

https://trello.com/b/QASr74yB/redshift [trello.com]

If SideFX has something like this, then I am willing to include that to this list as well (so long as it's planned to release within a month from now)

nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.

and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds

but isn't the comparison too early? because XPU is relative new

habernir
and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ?

RS supports hybrid rendering, so its an appropriate feature to compare.

habernir
nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.

and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds

but isn't the comparison too early? because XPU is relative new

I think it's important to mention the MaterialX in the comparison. Especially for people who are planning on interchanging shaders, or have a MaterialX library they still want to use without converting all the shaders.

Just tried karma xpu, stuff i miss thats not on the lists:

- Mipmap control
- Area light spread (honeycomb version)
- Autobump (without the need of extra primvars)

You have a nice overview.

It is a little misleading to say there is no XPU non-USD workflow. I get that Karma is a USD render system, but you can use the ROP to render a non-Solaris SOP-based scene in the traditional Houdini manner.

habernir
nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.

and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds

but isn't the comparison too early? because XPU is relative new

Hey there,

Thanks for commenting, and I'll elaborate on those topics. When it comes to a "non usd" workflow, what that means is that Redshift has the ability to process non-usd information that's compatible with pre-solaris workflows. By comparison, with Karma, everything must be turned into usd in order to render something. Even if you go with the Karma ROP, it's using a scene import all to turn it into USD and then render. That has some major implications on certain things. For example, that has an impact on motion blur because you'll need to cache USD sub-frame data in order to get curved motion blur. Yes, you do have the accel / v / w attribute for curved motion blur, but the quality doesn't hold up to sub-frame data if the motion blur is long enough. So, that would be a situation where it matters to have the option for a non-usd workflow if you didn't want to go through the extra step of caching out subframe usd. USD has many additional quirks that introduce extra steps to workflows, and extra steps = more opportunities for failure points in the workflow. It also has an impact on any studio that doesn't want to use Disney's public version of USD. With RS, you have the option to process non-usd info which may make it easier for other studios to build their own custom "USD-like" pipeline around it. With Karma, you may be able to do that, but it's much more closely integrated with Disney's version of USD, so it may be impossible / much more difficult.

When it comes to "rsProxies" that also matters for freelancers and piplelines that use multiple software packages in their pipeline. In spite of the name, "Universal Scene Description" it is one of the least universally implemented formats between software packages at the moment because each software package seems to understand and write it out differently. Having the option to simplify the render data as a proxy is quite useful because it eliminates many cross-platform complications.

Hybrid rendering means that it uses both CPU and GPU devices. RS and Karma are both able to utilize them, and in the speed tests, I will break down how much utilization they were using for each test. Interestingly enough, in one of the tests, hybrid rendering proved slower than GPU-only rendering due to CPU buckets getting caught in complex areas of the frame.

And no, I don't believe this comparison is too early. SideFX has announced that XPU is "gold," which means that it should be able to compete with other software packages for its place in production pipelines, and it's been publicly released for about 5 years now.

Heileif

habernir
nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.

and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds

but isn't the comparison too early? because XPU is relative new

I think it's important to mention the MaterialX in the comparison. Especially for people who are planning on interchanging shaders, or have a MaterialX library they still want to use without converting all the shaders.

Yep, I agree - "Material X Support" is in there on the last page

tbay312
Thanks for commenting, and I'll elaborate on those topics. When it comes to a "non usd" workflow, what that means is that Redshift has the ability to process non-usd information that's compatible with pre-solaris workflows. By comparison, with Karma, everything must be turned into usd in order to render something. Even if you go with the Karma ROP, it's using a scene import all to turn it into USD and then render. That has some major implications on certain things. For example, that has an impact on motion blur because you'll need to cache USD sub-frame data in order to get curved motion blur. Yes, you do have the accel / v / w attribute for curved motion blur, but the quality doesn't hold up to sub-frame data if the motion blur is long enough. So, that would be a situation where it matters to have the option for a non-usd workflow if you didn't want to go through the extra step of caching out subframe usd. USD has many additional quirks that introduce extra steps to workflows, and extra steps = more opportunities for failure points in the workflow. It also has an impact on any studio that doesn't want to use Disney's public version of USD. With RS, you have the option to process non-usd info which may make it easier for other studios to build their own custom "USD-like" pipeline around it. With Karma, you may be able to do that, but it's much more closely integrated with Disney's version of USD, so it may be impossible / much more difficult.

you may want to word these things differently
since every renderer has to translate the Houdini scene to the format they can understand first, even if it's hidden from the user and only in memory, for Mantra it's ifd, for Karma usd for Redshift rs, etc
so talking about non-usd for Karma is like talking about non-rs for Redshift

what is the issue however is that the translation from /obj to LOPs is not as optimized as it is for ifd or rs since it has bottlenecks like:
- it dirties more of the stage than seemingly necessary
- doesn't have dedicated set of Karma properties on /obj level, which it easily could have and they would be 1-1 translated to stage
- probably more, but I haven't used it much
however MB shouldn't be an issue since there can be internal Cache LOP or Motion Blur LOP which is equivalent of Mantra caching the geo substeps before frame render or I assume Resdhift has to do that as well

so rather than calling it non-usd workflow or pushing for it, I see it more like oprimizing the translators and integrating the controls on Ojbect level that directly translate to the stage and then the "hidden" USD layer could feel like the hidden RS layer for Resdhift or at least that's my understanding of the whole thing

tbay312
When it comes to "rsProxies" that also matters for freelancers and piplelines that use multiple software packages in their pipeline. In spite of the name, "Universal Scene Description" it is one of the least universally implemented formats between software packages at the moment because each software package seems to understand and write it out differently. Having the option to simplify the render data as a proxy is quite useful because it eliminates many cross-platform complications.

aren't references or instanceable references equivalent of rs proxies?
but of course for Object level workflows it would be ideal if Packed Disk Primitive pointing to .usd can automatically translate to USD reference on the stage, but that again comes to the translators and nodes like SOP Import LOP


Overall I agree that XPU despite being "gold" is missing a lot of features, for me Material blending is the major one, even currently supported surface shader blending doesn't not blend AOVs as we are used to from Mantra, but overall MtlX is currently very limited for any serious material authoring even with the addition of current kma nodes
some modern features would also be nice like AOV propagation through light paths (reflections, refractions, custom LPE, ...), roughness to bump, ...

tamte

tbay312
Thanks for commenting, and I'll elaborate on those topics. When it comes to a "non usd" workflow, what that means is that Redshift has the ability to process non-usd information that's compatible with pre-solaris workflows. By comparison, with Karma, everything must be turned into usd in order to render something. Even if you go with the Karma ROP, it's using a scene import all to turn it into USD and then render. That has some major implications on certain things. For example, that has an impact on motion blur because you'll need to cache USD sub-frame data in order to get curved motion blur. Yes, you do have the accel / v / w attribute for curved motion blur, but the quality doesn't hold up to sub-frame data if the motion blur is long enough. So, that would be a situation where it matters to have the option for a non-usd workflow if you didn't want to go through the extra step of caching out subframe usd. USD has many additional quirks that introduce extra steps to workflows, and extra steps = more opportunities for failure points in the workflow. It also has an impact on any studio that doesn't want to use Disney's public version of USD. With RS, you have the option to process non-usd info which may make it easier for other studios to build their own custom "USD-like" pipeline around it. With Karma, you may be able to do that, but it's much more closely integrated with Disney's version of USD, so it may be impossible / much more difficult.

you may want to word these things differently
since every renderer has to translate the Houdini scene to the format they can understand first, even if it's hidden from the user and only in memory, for Mantra it's ifd, for Karma usd for Redshift rs, etc
so talking about non-usd for Karma is like talking about non-rs for Redshift

what is the issue however is that the translation from /obj to LOPs is not as optimized as it is for ifd or rs since it has bottlenecks like:
- it dirties more of the stage than seemingly necessary
- doesn't have dedicated set of Karma properties on /obj level, which it easily could have and they would be 1-1 translated to stage
- probably more, but I haven't used it much
however MB shouldn't be an issue since there can be internal Cache LOP or Motion Blur LOP which is equivalent of Mantra caching the geo substeps before frame render or I assume Resdhift has to do that as well

so rather than calling it non-usd workflow or pushing for it, I see it more like oprimizing the translators and integrating the controls on Ojbect level that directly translate to the stage and then the "hidden" USD layer could feel like the hidden RS layer for Resdhift or at least that's my understanding of the whole thing

tbay312
When it comes to "rsProxies" that also matters for freelancers and piplelines that use multiple software packages in their pipeline. In spite of the name, "Universal Scene Description" it is one of the least universally implemented formats between software packages at the moment because each software package seems to understand and write it out differently. Having the option to simplify the render data as a proxy is quite useful because it eliminates many cross-platform complications.

aren't references or instanceable references equivalent of rs proxies?
but of course for Object level workflows it would be ideal if Packed Disk Primitive pointing to .usd can automatically translate to USD reference on the stage, but that again comes to the translators and nodes like SOP Import LOP


Overall I agree that XPU despite being "gold" is missing a lot of features, for me Material blending is the major one, even currently supported surface shader blending doesn't not blend AOVs as we are used to from Mantra, but overall MtlX is currently very limited for any serious material authoring even with the addition of current kma nodes
some modern features would also be nice like AOV propagation through light paths (reflections, refractions, custom LPE, ...), roughness to bump, ...

Thanks for the detailed feedback Tomas. I'll definitely be sure to consider the non-usd definition more over the next few days. You bring up a solid point that USD is a translated format similarly to RS when generating its version of an ifd. The thing that gets me as an artist, though, is that USD isn't just a translated format that gets created at render time.

It's an entire framework of working that requires artists to think in a specific way, and it adds additional compilations to a variety of workflows. Going back to the motion blur example - as you said, rs does interpolate sub-frame data in a way that's similar to what happens when you cache out sub-frame USD. However, it's not going to freeze up your whole LOP network every time you change a shader parameter. It's not going to introduce a potential failure point because you forgot to re-cache the correct sub-frame data before rendering. If an artist is trying to get that sub-stepped motion blur, they'll need to... 1. Generate sub-frame data in sops if it's not there, 2. Cache out sub-frame USD 3. Adjust render settings accordingly so that it's picking up the data. By comparison, with RS, it would be... 1. Generate sub-frame data in sops if it's not there and then 2. Adjust render settings accordingly so that it's picking up the data. So, in that way, working with USD isn't really equivalent to the conversion that RS does at render time because it's re-defining entire workflows and terminology in a way that's been specifically designed by Disney and SideFX.

For pipeline TDs, that shift in workflows + terminology also has a big impact because it places Disney + SideFX's way of working at the backbone of their pipeline. If everything is USD, that means their Maya pipeline needs to be compatible. What are the knock-on effects if they use Unreal Engine? etc etc... I could see, for example, many of Disney's competitors also not liking the idea that Disney has that much control over how their artists work and think. By comparison, RS is more agnostic in that you have the option of working with a USD mindset, or you can just work / think in a more traditional way. So, in that way, I think it's worth mentioning that you have a choice.

And then, when it comes to rspoxies, the main utility of that is cross-platform compatibility. If, for example, I have a 1,000 chunks of grass that get made in Houdini and they need to make their way to Maya, rsproxies have much less complexity and compatibility issues than USD will at the moment. That's a + for freelancers who need to jump around pipelines as well as in-house artists that need to minimize the risks / steps for getting everything to work.

tbay312
If an artist is trying to get that sub-stepped motion blur, they'll need to... 1. Generate sub-frame data in sops if it's not there, 2. Cache out sub-frame USD 3. Adjust render settings accordingly so that it's picking up the data. By comparison, with RS, it would be... 1. Generate sub-frame data in sops if it's not there and then 2. Adjust render settings accordingly so that it's picking up the data. So, in that way, working with USD isn't really equivalent to the conversion that RS does at render time

as I said I'm not using Karma ROP so not sure if its doing the correct thing

but regarding MB I was talking about Karma ROP and that "hidden" USD translation layer
enabling MB turns on internal Cache LOP path automatically and infers the caching steps from the stage settings
so theoretically should be doing what RS or Mantra do, as you said at "rendertime" but technically at scene translation time
in other words, in ideal scenario artist should not notice that Karma ROP is using usd under the hood, if all scene translators were doing the ideal and optimized thing

the fact that USD and LOPs allow you to do much more stuff should be irrelevant if the translator from Object to USD is solid and handles all kinds of cases

In my mind USD workflow in LOPs is completely different topic than just using .usd as a temporary scene description like .rs or .ifd, .ass, .rib with automatic translation layer from Obj

Which doesn't change the fact that it's currently not ideal so all this feeds into your points of it currently not feeling the same, but my point is that I don't believe it's due to USD itself


EDIT: Just imagine hypothetically that Houdini doesn't have LOPs and Karma ROP needs to translate the obj scene into it's scene description file let's call it .kma (which by coincidence would be identical to .usd, but you would now be able to officially call it non-usd, but would not be any better if the scene translators do the same job as now)
So Obj to .kma translators would need to be as optimized as obj to .ifd or to .rs at least that's my point of view
that's essentially what needs to happen with Obj to USD Stage (.usd)
the fact that we have LOPs to have additional control over this translation and on top of it is just a bonus

tamte

tbay312
If an artist is trying to get that sub-stepped motion blur, they'll need to... 1. Generate sub-frame data in sops if it's not there, 2. Cache out sub-frame USD 3. Adjust render settings accordingly so that it's picking up the data. By comparison, with RS, it would be... 1. Generate sub-frame data in sops if it's not there and then 2. Adjust render settings accordingly so that it's picking up the data. So, in that way, working with USD isn't really equivalent to the conversion that RS does at render time

as I said I'm not using Karma ROP so not sure if its doing the correct thing

but regarding MB I was talking about Karma ROP and that "hidden" USD translation layer
enabling MB turns on internal Cache LOP path automatically and infers the caching steps from the stage settings
so theoretically should be doing what RS or Mantra do, as you said at "rendertime" but technically at scene translation time
in other words, in ideal scenario artist should not notice that Karma ROP is using usd under the hood, if all scene translators were doing the ideal and optimized thing

the fact that USD and LOPs allow you to do much more stuff should be irrelevant if the translator from Object to USD is solid and handles all kinds of cases

In my mind USD workflow in LOPs is completely different topic than just using .usd as a temporary scene description like .rs or .ifd, .ass, .rib with automatic translation layer from Obj

Which doesn't change the fact that it's currently not ideal so all this feeds into your points of it currently not feeling the same, but my point is that I don't believe it's due to USD itself


EDIT: Just imagine hypothetically that Houdini doesn't have LOPs and Karma ROP needs to translate the obj scene into it's scene description file let's call it .kma (which by coincidence would be identical to .usd )
So Obj to .kma translators would need to be as optimized as obj to .ifd or to .rs at least that's my point of view
that's essentially what needs to happen with Obj to USD Stage (.usd)
the fact that we have LOPs to have additional control over this translation is just a bonus

Ahhh okay, I gotcha. I think I understand what you're saying more clearly after reading it again. When it comes to user experience, the workflow quirks come from the combination of Solaris / LOPS and USD rather than just USD itself. In that way, I agree - assuming that USD always translates the scenes perfectly from obj --> USD... which, I don't think is always the case.

I'll be sure to think more about it. It's worth mentioning that this required learning for USD + Karma is significant though. And it does have some big knock-on effects on the rest of a pipeline. So perhaps a better way of describing it would be, "Non-USD Workflow Compatibility" or something like that. Either way, it's going to be triggering for some folks, but it's an important point to mention.

Very well said - I freakin hate trying to do layout/materials in LOPs, not that it’s broken, it’s just different - in a non-intuitive kind of way.

I try to do as much as I can in SOPs and kinda set things up for LOPs using attributes that get automatically converted into their PrimVar counterparts.

tbay312
When it comes to user experience, the workflow quirks come from the combination of Solaris / LOPS and USD rather than just USD itself. In that way, I agree - assuming that USD always translates the scenes perfectly from obj --> USD... which, I don't think is always the case.

Just for correctness sake - USD never translates anything from obj --> USD, Houdini does.