r/Houdini • u/abhisheknaidu • 25d ago
Redshift vs Karma in Houdini 22 Solaris — real-world experience?
Redshift now officially supports Houdini 22, so I’m considering switching from Karma to Redshift for my Houdini/Solaris workflow.
I’m mainly doing product visualization and automotive-style cinematic work, but I also want to use Houdini for Pyro/smoke/fire, volumes, hair/groom, particles, water/FX, etc.
I’d really like to hear from people who are actually using Redshift inside Solaris/Houdini 22, rather than general Redshift vs Karma comparisons.
A few things I’m specifically interested in:
How stable is Redshift in Solaris/Houdini 22?
How is the Redshift Hydra viewport compared with Karma XPU
Does Redshift render Pyro/smoke/fire/large volumes reliably in Solaris?
How is hair/groom/curves compared with Karma XPU?
How is Redshift with 4K textures, glass, automotive paint, reflections and HDRIs?
How useful is Redshift Live inside Houdini/Solaris for lookdev?
Are there any important Solaris features that don’t work as well in Redshift?
Does Redshift require significantly more setup/work compared with Karma in Solaris?
For final production renders, which one do you personally prefer: Karma XPU or Redshift, and why?
If you’ve used both extensively, which one would you choose today for automotive/product commercials?
I’m not looking for benchmarks alone. I’d really appreciate people’s actual production experience with Redshift + Solaris, including any problems or limitations you’ve encountered.
Thanks!
4
u/FormFollowsFunc 25d ago edited 24d ago
That's a lot of questions which I won't be able to answer. I'm exploring Redshift (2026.8.0) in Solaris (Houdini 22.0.368) at the moment. This is what I found so far.
Redshift materials (RS USD Material Builder) don't show up in the Vulkan viewport but if you put a RS USD Material Builder node in a subnet and add a USD Preview Material node and add both to a Collect node, it will work but it's double the work.
Redshift does seem to support MaterialX materials (USD MaterialX Builder). In theory this allows you to use the same material in Karma and Redshift. It has an annoying bug where if you change a texture it won't update in the viewport but if you toggle the material's orange flag it should fix it.
I think in your case Redshift would be a good match for product commercials as it produces a more polished look - it's less noisy out of the box.
5
u/CG-Forge 24d ago
These are great questions, but most professionals are too busy to provide you with a detailed review and/or don't want to deal with fanboys (of either side) on reddit. Keep that in mind.
I'll give you the short story of my opinion on this (because this topic gets brought up a few times a year and turns into a render wars battlefield almost every time). For many people, their preferred render engine is like a religion, and I'm about to spit on their golden cow.
Have you been using Houdini for less than a year? -- Use Redshift or any other render engine that doesn't force you to use USD right away. Why? Because you shouldn't be worrying about USD yet. Karma forces you to USD. Many beginners are focusing on USD terminology before they even know the difference between an attribute and a variable. Most beginners don't know what a solver is yet or how to cache something out. USD is not a beginner topic. It's the #1 reason for beginner burnout. Redshift makes USD optional, and that's a huge benefit for a beginner that wants to focus on more important topics first while making better looking renders out of the box.
Additionally, if you go with Redshift, you don't need to worry about color management right away. RS takes care of that for you properly. Karma does not. Redshift is faster and less noisy. Karma often forces users to just denoise it in comp (which is a bad habit to get into anyway imo) especially if you're a beginner who can't pick out the artifacts denoising creates in a render. Documentation? Miles better with RS than Karma. That's a big deal for a beginner. I can go on, but as someone who directly works beginners every day, Karma has been a complete and utter disaster for them, (many beginners not realizing it either) and using Redshift will be worth the quirks it has by comparison.
Are you more intermediate / advanced in Houdini? -- If so, the question becomes what kind of work are you doing? Are you building a personal portfolio? Redshift will probably be a better route. Are you working with smaller scenes? (like what you mentioned with product ads) Redshift is great. Other engines, in my opinion, start becoming more interesting when you're encountering very large scenes and require a pipeline with multiple people in it. Redshift can absolutely work with massive scenes. After all, it uses USD just like Karma and all the others do. However, Redshift can require a handful of tricks to optimize things properly, and it's understandable if a team doesn't want to educate everyone on those optimizations and just brute force it with a farm. Even then, I'd suggest looking at vray, arnold, etc. because Karma isn't developed to the same standards of quality that the other render engine are at the moment. Additionally, other render engines allow for cross-platform compatibility. Most studios don't just use Houdini. They're using maya, max, nuke, blender, etc etc... and other render engines can exist outside of Houdini in a way that Karma does not.
2
u/abhisheknaidu 24d ago
Thanks, this actually clears things up a lot. I’m mainly focused on Houdini for product/automotive cinematics and some VFX, and I’m trying to decide whether it’s worth going deeper into Karma/Solaris or learning Redshift instead. I was mostly worried that choosing Redshift would mean giving up the advantages of Houdini’s procedural and simulation workflow. Your explanation makes the tradeoff much clearer. Appreciate the detailed answer.
And thank u fr ur time and fr the tutorials u make1
u/iwearblueshirts 24d ago
You hit an interesting point here about color management and OCIO differences between the two. Curious if anyone here has good resources for their Karma color management workflow. It is definitely one of the more confusing parts to get right…
1
u/abhisheknaidu 24d ago
Can u please make a tutorial on how to render using redshift in Solaris in the houdini 22 so tat we can try how it is in Solaris as im nt find any tutorial on it wat are the render settings etc
1
u/CG-Forge 24d ago edited 24d ago
Fortunately, there have been some improvements with H22, but much of what I talk about here in H21 still applies: https://youtu.be/E3QoZNXI1Sg
More specifically, the defaults for your OCIO config automatically set your viewport correct. However, by default, when you export by hitting "Render to Disk" it's not going to line up with what you see in your viewport because it doesn't apply tonemapping by default.
From my understanding, it's still not possible to apply tonemapping to your output image. So, you need to uncheck your beauty pass, make a new custom AOV with beauty, and overwrite the OCIO rules to export as AcesCG. Then, you pop it into resolve and apply your tonemapping over there.
If you save out from mplay, there is an option to bake your tonemapping into the exr when you go to export.
That's the gist of it.
1
u/Beginning_Expert_970 24d ago
Nothing beats the speed of redshift, but you kinda sacrifice “realism” given that is biased, but in production nobody uses out of the box renders, we render as many AOVs as we can to have total control in comp. Karma is really good, I only use it for personal stuff.
4
u/CG-Forge 24d ago
Have a read on this: https://blog.chaos.com/the-truth-about-unbiased-rendering
You want biased rendering. You don't want unbiased. Biased doesn't make it look better enough to justify the major increase in render time.
-- "Long story short: if you are doing true scientific physical calculations and have a ton of computational power and time, unbiased may serve you well. If you are interested in rendering physically plausible images in a reasonable amount of time, biased solutions will get you there faster. Chances are you are already doing this no matter what rendering engine you are using."
1
u/Beginning_Expert_970 24d ago
Thanks for the insight, this is very true at least in the current times, GPU renderers didn’t have all the features that CPU renderers had few years ago, the line is indistinguishable now. But back then we would need to do heavy lifting on GPU render images in post because they always look plastic and video-game-ish at least in our experience . But yeah, I agree, today biased renderers are production ready.
2
u/CG-Forge 24d ago
The plasticy SSS was definitely an issue at one point. Nowadays, however, that's not the case.
1
u/abhisheknaidu 24d ago
So ur saying karma gives u more realism out of the box dan redshift r both delivers the same photo realism
1
u/Beginning_Expert_970 24d ago
For simple stuff yeah, but if you push it really hard, it shows. Redshift is our to go option, market is really fast nowadays, we need a render engine that can keep up.
2
u/abhisheknaidu 24d ago
Ya in my pc redshift is faster dan karma so now fr product viz and small scale vfx shld i consider redshift based on ur experience?!
2
2
u/PixelNinja_Design 24d ago
Had to use it recently for a product focused motion graphics piece. The general lighting and rendering process was fine but here are a few issues I encountered.
The setup was a bit of a pain. Having to find the latest version on the Redshift forums and copying the various plugin folders into the correct locations in the Redshift installation directory was a pain. For me some of the plugins actually conflicted and crashed Houdini so I had to remove them (I think it was the USD procedural one?).
RSProxy generation is a bit clunky and weird in LOPs. You have to have a camera, it bakes in the headlight light by default and renders blank frames alongside every proxy output.
AOV options felt quite limited compared to Karma, and I had issues getting setting changes to show in the viewport renderer. For example, changing an AOV to refract through glass required the scene graph tree to change before the viewport would render with the new setting. I usually did this by bypassing and unbypassing nodes.
Cryptomattes are exported as a separate sequence because of a core Redshift limitation. They set the path on an attribute on the Cryptomatte Render Var prim rather than using a separate Render Product, which breaks USD convention.
Speaking of breaking USD convention they also have a product name override on the Render Settings prim. Multiple render passes/settings/products at once tends to break in unexpected ways too, which I expect is a bug.
Cryptomattes would also change their ID constantly, which made them break when rendering across multiple machines unless you hard code paths.
Instances cause a bunch of issues because if of how they're converted under the hood. Making managing cryptomattes and other attributes a pain. I ended up with a super messy scene because I had to keep breaking apart my instances into multiple groups of instances just to set differing attributes per instance.
Varying the texture per material is a little annoying because there's no way to pipe a texture path into an RS Texture. You instead have to duplicate the material and directly override the texture path on the RS Texture prim.
I also found the viewport to respond significantly slower than Karma.
The crew I was working with had major issues getting the scene rendering through a clouds render service too. Though I can't speak to that personally because I render locally and I didn't have any issues on my farm.
I don't mean for this to sound negative. The actual rendering was quite smooth and fast, and ultimately gave a great result. I would still recommend people to give it a go. If you aren't used to relying on USD features then you'll probably have far less issues than I did. I still greatly prefer Karma though.
2
u/Chemist-Chemical 24d ago
Im hearing your voice when reading this. Questtion for u.. do you like only post vids once a year 😁
2
u/PixelNinja_Design 24d ago
Hahaha. Hopefully that's a good thing.
Yeah I only make a video when I have the time (it takes ages to put together) and more specifically when I have experience with something that I don't think has been covered already by the other great people in the community.
The last few months have been hectic with work but I did put together a talk for the Sydney Hive, which might end up online at some point. I'm also working on a course for SideFX, which will be more long form and less dense than my usual stuff. Struggling to find the time to edit it down though.
2
u/abhisheknaidu 23d ago
Thank u for ur feedback and man i love ur videos plz dont stop posting do upload the mechanical rigging course in the latest H22 workflow if possible
1
u/LewisVTaylor Effects Artist Senior MOFO 23d ago
I've been having to use it daily for the last 1 1/2 years and it is borderline unusable as a true Production Renderer.
The issues you noted we hit as well, along with the laundry list of core renderer limitations that Karma doesn't have.
* Particles in RS are not 1st class objects, so GI and reflections don't behave the same as polygonal spheres.
* volume fields all need to still be the same voxel resolution
* instancing is capped at a hard limit, irrespective of the GPU VRAM
* nested instancing support is limited, and variant shading of those even more so
* hair shader has no Medulla componentScene evaluation being faster in Karma makes sense, as it's native geometry format is USD, so no translating USD > hydea > renderer native geometry format.
-3
0
u/PhilippPavlov 25d ago
I use Redshift and am trying to switch to Karma. Karma seems a bit slower, but better in all other ways. If you work for a studio whose main render is Redshift, then you probably have to switch. Otherwise, there is no real reason to switch.
-1
u/clao800 25d ago
Biased vs unbiased is the main issue/choice.
4
u/LewisVTaylor Effects Artist Senior MOFO 25d ago
They are both biased. There are only a couple unbiased engines, and Karma and Redshift are both biased.
2
u/abhisheknaidu 24d ago
But y du everyone say it’s unbiased
3
u/CG-Forge 24d ago
Because someone else on reddit said it at some point, so they assume it's correct.
1
0
u/clao800 24d ago
Ok, short definition from the SideFX website:
"Karma is Houdini’s physically-based path tracer"Generally speaking
Physically-based path tracer = unbiasedA little less short definition: karma does not a totally fully 100% unbiased calculation, but that doesn't mean you can put it in the biased category.
"RenderMan and Karma sit in between, using sophisticated caching and approximation that's close enough to unbiased for production work"(cglounge)2
u/LewisVTaylor Effects Artist Senior MOFO 24d ago edited 24d ago
Again, no.
Physcially based has nothing to do with whether the engine is biased or not, it has to do with how it respects energy conservation.Biased approaches use all manner of methods to arrive at the final light transport values, Vs an unbiased renderer, where the light paths and energy loss is left to bounce around until it's extinct.
Just to clarify, Physically Based Rendering HAS NOTHING TO DO with being unbiased or biased. It has to do with conservation of energy, so a material cannot reflect more energy than it absorbs.
Biasing in a renderer is to do with radiance maps, point clouds, cut offs, approximations, all manner of methods to get to what would be a reasonable approximation of the light transport if it were left to just trace paths until the energy loss was complete.
1
u/clao800 23d ago
Yes, technically PBR and path tracing don’t necessarily mean unbiased. PBR means a realistic reproduction of something (materials, lights, volumes, ...). Path tracing is about how light is traced. Biased/unbiased is about the mathematical calculation, pure simulation of rays from lights vs using "shortcuts" to simplify the calculations.
To me, a "physically-based path tracer" implies an actual, realistic calculation of light, and the true calculation of light behavior falls into the unbiased category in this context. In that sentence, it specifies that the light calculation is PB, it’s not talking about the render engine as a whole, materials, reflections, or anything else.
Anyway, it feels like denying reality by clinging to technicalities.
If we assume that the mathematical calculation of light can be 100% real (unbiased) or 0% real (fully approximated, biased):
Karma is 50%-100%
Redshift is 10%–70%Position them wherever you want, but 99% of people would tell you that Karma belongs in the unbiased category, and Redshift in the biased one.
1
u/abhisheknaidu 23d ago
Dude wat a technical explanation and ur understanding abt rendering is awsm man wer did u evn learn this stuff
0
u/jemabaris 24d ago
Karma is unbiased
2
u/LewisVTaylor Effects Artist Senior MOFO 24d ago
No it isn't.
Guys, you're getting super confused between terminology here.
An unbiased renderer doesn't do any approximation tricks to arrive at the light transport result.Karma is 100% biased, as is Arnold, Redshift, Renderman, Vray, etc, etc, etc.
Only Maxwell and one or two other old engines are Unbiased, that is why they were orders of magnitude slower to converge to a result.
1
u/jemabaris 24d ago
Karma is an unbiased renderer, architecturally speaking — it's a physically-based path tracer, same category as Arnold, Cycles, or RenderMan's path-tracing integrator. Karma is Houdini's physically-based path tracer, deeply integrated with USD, with two delegates, Karma CPU and Karma XPU, differing mainly in hardware target and shading-language support. sidefx
That said, "unbiased" is a bit of a loaded term in production rendering, and the honest, definitive answer has two layers:
Core algorithm: unbiased. Karma's light transport is a physically-based path tracer with no fundamental bias in the estimator — given enough samples, it converges to the physically correct image, same as any Monte Carlo path tracer. In practice, like every production renderer, it exposes biased shortcuts you can opt into. Karma has settings like firefly/color clamping (a "Limit" on sample contribution to suppress fireflies), denoisers (Intel/NVIDIA), and other approximations that trade strict correctness for speed or noise reduction. Using those knowingly introduces bias — but they're optional, not baked into the core algorithm.
1
u/LewisVTaylor Effects Artist Senior MOFO 24d ago edited 24d ago
That is true of any Path Tracer, the term is clear though. An unbiased renderer does not allow you to bias the convergence.
Karma, Arnold, etc, etc are all able to be biased, which literally means they are biased engines.
So when someone says Karma is unbiased, in that respect it means, "if you turn off every single default behavior in the engine, it will become unbiased, to a degree.
Unlike an actual unbiased engine where there no option to deviate.
Your point is valid, but that is true of the base application in almost all path tracers. It doesn't make them able to be advertised as unbiased, because they aren't really, not if you're talking in literal terms.
1
u/jemabaris 24d ago
I mean I don't care about biased or unbiased anyway, if it looks good it looks good, but; I think I'd still categorize it as unbiased and Redshift for example as biased because while you can use Karma unbiased (if you don't opt in on certain settings) you can't do that with Redshift. It will always deliver biased render results given its core architecture. Yes you are right, strictly speaking almost nothing is truely unbiased nowadays, but if you keep the definition so strict you can basically do away with those two terms anyway. Just my two cents.
1
u/LewisVTaylor Effects Artist Senior MOFO 24d ago
That's not how we've categorized those terms for the last 20yrs or so though.
Unbiased has always equated to ground truth renderering, used generally only to create a reference result, or if you're crazy, you'd use it to produce actual images.
The core of the path tracer not being biased is a semantic detail, when in reality a renderer is the sum of it's parts, not one piece.
The path tracer is but 1/3 of the engine, and it's results are the product of those multiple biases.I don't mean to go into the weeds here, but your unbiased comment is ignoring that a big chunk of what makes the engine what it is is all the rest that comes after the initial tracing of rays.
-2
u/clao800 24d ago
No, karma is unbiased (full real light calculation), redshift is biased. And in many professional shots you can see the difference.
2
u/smb3d Generalist - 24 years experience 24d ago
I'd love to see any example where the difference is actually visible and or detectable.
1
u/clao800 24d ago
quite old but i notice more or less the same issues:
https://www.youtube.com/watch?v=rJghpp8RVmw
more recent:
https://www.youtube.com/watch?v=dL2peMzFsYMHonestly these comparisons don't make much sense, a lot depends on the settings and render times, noise, materials.... But as a general (personal) feel, renderman, karma, and arnold calculate light in a much more realistic way, and you can see it right away from the render passes and how they render translucent materials. Or rather, these allow you to achieve completely realistic renders where biased fast renderers fall short.
15
u/monstrupufos 25d ago
Choosing to go from SideFX to Maxon is crazy in my opinion. I understand people who used RedShift and didn't get the time to learn Karma, but if you're using Karma already, I see no reason to switch. Just the fact that you can upgrade Houdini subversion without having to wait for a RedShift build alone is enough reason for me, given the huge changes that Houdini underwent in 22 and how buggy it is at the moment (you will definitely want to keep updating it as soon as a new production build is available).