I am using redshift for quite a while now and I like it. It's fast, the houdini integration is really good and feature wise, it suits my needs.

I am a freelancer with a single workstation and three nvidia gpus. Mostly no USD/solaris. No heavy stuff for the most part.

I would like to hear what you guys think about switching to karma XPU. What are the (dis)advantages in terms of speed, tweaking and ease of use?

As I am no render expert at all, I always liked redshift's autosampling feature. Afaik, this is not yet implemented in Karma, right?

What else should I be aware of?

Cheers

I've been making the transition from Redshift to try and use KarmaXPU more in my workflow as well.
Had a few stumbles here and there. But now that I've been working in USD / mtlX / solaris a bit, it's making more and more sense.
A little more work in the setup, but I'm starting to get results similar to RS. The time to fist pixel is way faster in XPU especially in bigger scenes.

I'm not happy about the Adobefication of Maxon, and having a solid option directly developed by SideFX with more open standards is a great thing for me and my workflow.

Also been using Redshift for a while, what got me into Karma Xpu was the smoke, cloud, volumetric
Redshift is really lacking there. I then found a combination of ODTools and Karma XPU to be super fast
Drag and drop everything. Upgrading to H20 XPU got all the AOVs, just made a render with a lot of object lights, It looks great
But ODTools are not working, I must admit it is really slow for now setting up fast scenes
But I hope that ODTools update is coming very soon

Toketronic
Also been using Redshift for a while, what got me into Karma Xpu was the smoke, cloud, volumetric
Redshift is really lacking there. I then found a combination of ODTools and Karma XPU to be super fast
Drag and drop everything. Upgrading to H20 XPU got all the AOVs, just made a render with a lot of object lights, It looks great
But ODTools are not working, I must admit it is really slow for now setting up fast scenes
But I hope that ODTools update is coming very soon

OD Tools update on the 17th

You are good to re-download and use it in H20

I can't get Redshift to work,but I've been needing to learn Karma/XPU..so my joudney starts today!

I'm also trying to transition away from the Maxon licensing system, used to use C4D, moved to Houdini. Use Redshift but can't quite move away just yet. I think for the freelancer it is a hard transition as Karma / USD would appear to be for the large scenes and not the archetypal motion piece.

I am persisting as my license of RS runs out in March and I really hope to go over to XPU, but it isn't as full featured or efficient as RS. After all RS has been going some years and has a dedicated team to just rendering. Fair play to the H guys and Karma team.

Along with another thread, just remember to tick "Render all as one process" if you are rendering multiple frames. I think the fact RS isn't available to H20 just yet means more and more people are trying Karma.

Pixelised
I think the fact RS isn't available to H20 just yet means more and more people are trying Karma.

What do you mean by that? RS for h20 is already available since the beta.

bollili

Pixelised
I think the fact RS isn't available to H20 just yet means more and more people are trying Karma.

What do you mean by that? RS for h20 is already available since the beta.

Could you please elaborate on that? In the RS docs it says the latest version (3.5.20) is for Houdini 19.5.752 and there's nothing on Houdini 20. I'd really like to get it working on H20 but got no clue how to do that. Maybe you could help with that? I'd really appreciate it.

Houdini/Solaris plugins custom builds
https://redshift.maxon.net/topic/31230/houdini-solaris-plugins-custom-builds [redshift.maxon.net]

w_maro
Houdini/Solaris plugins custom builds
https://redshift.maxon.net/topic/31230/houdini-solaris-plugins-custom-builds [redshift.maxon.net]

Thank you much!

bollili
I am using redshift for quite a while now and I like it. It's fast, the houdini integration is really good and feature wise, it suits my needs.

I am a freelancer with a single workstation and three nvidia gpus. Mostly no USD/solaris. No heavy stuff for the most part.

I would like to hear what you guys think about switching to karma XPU. What are the (dis)advantages in terms of speed, tweaking and ease of use?

As I am no render expert at all, I always liked redshift's autosampling feature. Afaik, this is not yet implemented in Karma, right?

What else should I be aware of?

Cheers

well if you are using smoke,fire..... most of the users and me will suggest you to use karma because of the quality period.

and for the speed redshift is fast and very fast BUT (and thats a big but) in general it depends on the size of the scene ,in very large scenes karma is faster.
you have 3 gpu soo if the scene isn't go out-of core i dont think the speed differences will be relevent for you

for the tweaking again it depend which scene because karma XPU isn't perfect ( redshift is easier)

bollili
I am using redshift for quite a while now and I like it. It's fast, the houdini integration is really good and feature wise, it suits my needs.

I am a freelancer with a single workstation and three nvidia gpus. Mostly no USD/solaris. No heavy stuff for the most part.

I would like to hear what you guys think about switching to karma XPU. What are the (dis)advantages in terms of speed, tweaking and ease of use?

As I am no render expert at all, I always liked redshift's autosampling feature. Afaik, this is not yet implemented in Karma, right?

What else should I be aware of?

Cheers

I've been running quite a few different tests / scenarios with Redshift vs. XPU, and I wouldn't switch from Redshift quite yet. Karma has been crashy, buggy, lacking in features, lacking in documentation, and harder to use than Redshift for me thus far. The devil is always in the details, so I'll give you some examples:

Crashy:

* Yesterday I crashed around 8 times and had one hard reset where my GPU froze. If I spend a whole day shading in Karma, I would expect the same.
* I've noticed that Karma will gradually slow down as I'm building shader trees. The only fix is to reset it occasionally by going to the Houdini GL --> dropdown --> reset Karma

Buggy:

* Mtlx Ambient Occlusion doesn't work for me.
* You can't layer multiple materials together with a mtlx mix node
* I've run across major freezes with motion blur.
* Color management is inconsistent depending on where you decide to preview / export your images.

Lacking in Features:

* Karma doesn't have nearly the same variety of noises that Redshift does. This can make a huge difference in shading workflows that need to take advantage of hi-fidelity detail that doesn't look like a perlin noise. You can hack noises, but at that point you're just creating your own algorithms, and that won't come close to touching the artistic quality offered by Maxon noises. Besides, artists don't have time for that. That's what artists should pay software devs for.

* Many basic functions are missing in Mtlx nodes. For example, in the tri-planar node, you cannot scale, rotate, or offset your projections. Ambient occlusion doesn't work, and even if it did, the node doesn't have any features which would allow you to control things like spread angle, remap the values, etc...

* When it comes to SSS, redshift provides you with the option of random walk, ray-traced diffusion, and point-based diffusion. Karma doesn't offer you those options.

* Plus, there's a lot of other misc. things that come with age that Karma has yet to incorporate. For example, you won't find a car paint shader with Karma, but Redshift you have lots of tools there for layering multiple clear coats, adding specular flakes, and dealing with that specific situation. Redshift has the advantage of being in the game longer than Karma has. Karma, as a render engine, is still green - Redshift is more mature.

* No PostFX options... which is nice to have when you're time is in a pinch and you need to get a render out quickly.

* Karma is still new, and it will take awhile to catch up to some of the latest tech. For example, Redshift just added support for Transmission BTDF shadows. I haven't tested this in Karma (and maybe it's there) but I doubt you'll find the same thing because SideFX has been trying to catch up with basic features to make a brand new render engine.


Lacking in Documentation:

* Just try to pull up some Mtlx nodes, you won't find much.
* Motion blur documentation features scattered ideas that shoot in different directions, don't provide you with the best (or any) examples, and seem to be written with multiple ideas in mind which makes it confusing to read.


Harder to use than Redshift:

* Being that you're a solo/freelance artist, I don't think you'll see as much benefit with USD. USD can add a lot of complications and a significant learning curve. I wouldn't underestimate the gravity of that when you're faced with tight deadlines on a freelance project. There's a lot of complications to USD, and Pixar, the developer of USD, is used to deadlines that are much longer than your average freelance artist. That being said, simplicity isn't the highest virtue with USD, and having the option to bypass those complications with Redshift is a big advantage to a freelancer who needs as much simplicity as possible to remain fast.

* I think it's a big deal to have a mismatch between your viewport preview render and the final USD information that gets processed when using the USD Rop. It's really easy to make a viewport override, forget that you did that, make a bunch of decisions based on those overrides, and then come to find that it doesn't match the information that's sent to your ROP node.

* Backplates can be a little tricky to manage at first because you need to figure out what blend of viewport options and light overrides will provide you an accurate assessment of your scene.

* Redshift has a brilliant feature that lets you select "low" "mid" and "high" quality render presets. It then goes into your scene, figures out what you have going on, and makes all sorts of intelligent decisions depending on the quality you're after. That feature is fantastic for a freelance artist who may not have the time to dial in all the optimizations required for those different types of renders. Karma currently lacks that feature.


Speed:

* I've found that the speed in Karma still suffers quite a bit compared to Redshift depending on the feature at hand. Thus far, I find that Karma gets bogged down by indirect volume samples, displacements, and motion blur moreso than redshift does. I'll have to do some more tests to really confirm that, but so far, that seems to be the case.


-------------
-------------

In conclusion:

I really do love the idea of Karma being a replacement to Redshift, but I don't think it's close right now if your top priorities are ease-of-use, stability, and features that add quality to your workflow. I'm not a fan of Maxon buying Redshift either. In the long run, I'm hoping that Karma steps it up a few notches, but it's going to take time, and it's not there yet in my opinion. That said, I'm still testing it, but I wouldn't jump ship right away if I was in your shoes. You might be right about the decision of switching over eventually, but you need to be careful about the timing of that when you have tight deadlines as a freelancer.


Good luck,

- Tyler

Tyler,
What's your opinion about running Redshift in the traditional OBJ>ROP workflow versus Redshift in Solaris. Which do you recommend?

Mike_A
Tyler,
What's your opinion about running Redshift in the traditional OBJ>ROP workflow versus Redshift in Solaris. Which do you recommend?

I think it totally depends on the project. If you have a large scene with a bunch of instancing and you know how to comfortably manage that in USD, then building in Solaris might make sense because you'll get some performance benefits. That would also be true if you had a team + pipeline that's already comfortable with USD. Might as well go that route if everyone knows how to get around. But, for smaller scenes/projects, or if you're a solo artist without too much knowledge in USD yet, then I think the OBJ>ROP workflow is better.

Tyler hit the nail on the head there - the benefits of USD really start to shine with larger productions, where multiple people are working in a pipeline.

But that kind of flexibility has inherent complexities that small productions dont even need to get the frame(s) done.

Like, I still dont fully understand why you cant change the material on an Instance in USD (in certain scenarios), and literally dont wanna know at this point.

These are great insights, thank you very much. I appreciate it a lot.

I have a follow up question:
Using karma with the karma rop (circumventing Solaris and sticking to the old obj-workflow), is this an option in your opinion? What are the drawbacks? I suppose the time to first pixel will be affected and the snappiness gets lost? Or is this no problem at all?

Thanks guys!

bollili
Using karma with the karma rop (circumventing Solaris and sticking to the old obj-workflow), is this an option in your opinion?

You are not circumventing Solaris
Karma ROP is a wrapper around LOP network, so it's partially for convenience for simple use cases where Scene Import LOP logic is enough to translate the obj level correctly and you don't need to configure anything beyond what Karma ROP offers to you

But of course you can always jump in and edit the LOP network directly if needed

I've been considering the same question as the OP over the last few days. For me Karma XPU + Mtlx isn't quite there yet - the limitations with material mixing (two materials only), the limited set of prebuilt noise patterns, the need for overly fragmented shading networks - multiple nodes where Rs requires one, no OSL - and some missing functionality in the ubershader. I'll be sticking with Redshift for a while.

This is going a bit off-topic, but I strongly disagree with the comments made about Solaris being beneficial only to larger productions.

I am pretty much a solo guy myself and have been using Solaris for my work for over a year now, and I will never want to use the traditional workflow again. Solaris brings many, many things to the table that are absolutely fantastic for shot setup, that are straight up clunky in the traditional workflow.

Something as simple as varying a light parameter for 2 shots will need separate Takes, keyframes or worse - separate lights - all clunky and/or unintuitive ways to accomplish it. Then, when things invariably get more granular, they get significantly messier the old way, whereas Solaris is always visually clean and intuitive at a glance. That's just one example. Listing them all here would bloat this message to beyond the scope of this thread.

Yes, there is a fair bit of a technical learning curve to it, but for me at least, the pros far outweigh the cons, and overcoming that curve was entirely worth it.

Thanks for all the feedback on this thread. XPU continues to improve at a rapid pace, so hearing this kind of thing helps guide development.

I'm sorry to hear you're having stability problems though.

tbay312
* Yesterday I crashed around 8 times and had one hard reset where my GPU froze. If I spend a whole day shading in Karma, I would expect the same.
* I've noticed that Karma will gradually slow down as I'm building shader trees. The only fix is to reset it occasionally by going to the Houdini GL --> dropdown --> reset Karma
* I've run across major freezes with motion blur.

We would really like to get onto some of these.
Is it possible for you could submit some bug reports, with reproducible steps?

thanks very much

eikonoklastes
This is going a bit off-topic, but I strongly disagree with the comments made about Solaris being beneficial only to larger productions.

I am pretty much a solo guy myself and have been using Solaris for my work for over a year now, and I will never want to use the traditional workflow again. Solaris brings many, many things to the table that are absolutely fantastic for shot setup, that are straight up clunky in the traditional workflow.

Something as simple as varying a light parameter for 2 shots will need separate Takes, keyframes or worse - separate lights - all clunky and/or unintuitive ways to accomplish it. Then, when things invariably get more granular, they get significantly messier the old way, whereas Solaris is always visually clean and intuitive at a glance. That's just one example. Listing them all here would bloat this message to beyond the scope of this thread.

Yes, there is a fair bit of a technical learning curve to it, but for me at least, the pros far outweigh the cons, and overcoming that curve was entirely worth it.

I also start to like Solaris/Karma in H20. For shot production the camera switcher would be cool, also to access the camera switcher from the obj context.