Karma XPU vs Redshift - A Comprehensive Review

If you're interested in downloading the scene files for yourself, then visit this link:
www.cgforge.com/karma-rs-revi...
Timestamps:
00:00:00 - Intro
00:01:47 - Testing Criteria
Criteria 1: Speed
00:02:47 - How Scenes Were Tested
00:10:50 - Shaderbot Lineup
00:11:28 - Adaptive Tessellation
00:11:38 - Bubble Blob
00:12:25 - Caustics
00:12:35 - Global Illumination
00:13:31 - Volume Rendering
00:14:10 - Motion Blur
00:14:20 - Instancing
00:14:31 - Stability
00:15:01 - Shaderbot Commentary
00:17:10 - Tessellation Commentary
00:18:19 - Bubble Blob Commentary
00:21:29 - Caustics Commentary
00:22:43 - Global Illumination Commentary
00:25:03 - Volume Rendering Commentary
00:26:22 - Motion Blur
00:27:08 - Instancing Test
Criteria 2: Features
00:29:04 - Considerations for Features
00:29:44 - Features List
00:30:29 - Features Commentary
Criteria 3: User Experience
00:31:15 - Redshift Documentation
00:33:55 - Karma Documentation
00:37:19 - Redshift Color Correction
00:39:11 - Karma Color Correction
00:42:06 - Redshift Viewport Integration
00:42:37 - Karma Solaris Viewport Overrides
00:46:08 - Renderview Comparisons
00:47:40 - PostFX
00:48:42 - Karma Viewport Render Settings
00:49:54 - Render Settings Comparison
00:51:49 - Commentary About USD
Criteria 4: Pricing
00:54:51 - Houdini Pricing
00:56:00 - Redshift Pricing
00:56:21 - Pricing Breakdown Scenario
Criteria 5: Visual Quality
01:00:35 - Defining Visual Quality
01:01:17 - Final Thoughts
** Karma partially supports matte objects
---------
For more high quality content, visit www.cgforge.com
Thanks for watching!

[@SaladFX]

Thank you for creating this video! It addresses several issues I’ve encountered with Solaris. I really want to use Karma XPU in production, I was happy when they said that Karma XPU is production-ready, but the reality is that Solaris itself requires some fixes and optimizations. Let’s hope that Solaris improves in the future as I like the concept of LOPs in houdini.

[@chr1st0pher]

For sure Karma XPU (and karma as a whole) is less mature than Redshift, but I still vastly prefer it for myself. I spent a year on a project with redshift + solaris and it was so painful (the year of RS driver issues) but it also got me over the hump of learning solaris, and now that I get it I much prefer it and wouldn’t want to go back to obj. I really struggled with stability with RS and massively struggled with time to first pixel. Since moving to karma it’s been a relief to not have to deal with the hassle of an extra plugin, knowing it’s all integrated, which makes updating houdini and a lot of other things easier easier. More important though, I’ve found it to be way more reliable/less crashy, and way more interactive which makes it actually fun to work with again, especially in complex scenes that would take 45+ seconds to get anything to show up with redshift and often crash while making changes. I also like that karma cpu has a lot of extra niche features that I can fall back on if I ever need them. I don’t think karma beats RS for everyone yet, but for those reasons it def beats it for me. I think it’s worth everyone giving it a shot and see how they feel, if/where it falls short, and giving that feedback to sidefx, and give it another shot with each release to see if those things have been improved. I don’t think solaris is perfect, esp for new users, but I think the right path if for sidefx to continue improving UX there and making it easier for smaller studios/indie artists, which they have been doing well imo. I also think the pace of development has slowed dramatically with rs whereas karma is being developed very fast and adding even more features, which makes me a lot more hopeful for it. For a new student though, I would recommend karma because it’s built in, and because they have no prior knowledge of the /out context. You can do a lot with solaris without worrying about USD imo and just treat it as a lighting environment. I would at least encourage them to start with karma, try learning on it, and if they are finding it too slow for their hardware try giving some other engines a shot.

[@chr1st0pher]

I’ll also add one last thing, not to just be a karma fanboy, but I was blown away by the irradiance point cache interior speed. I always used IPC secondary in RS and never felt like it caused any issues but also didn’t feel it sped things up much, but that is amazing. I’d be super curious to see something like that as an option in karma.

[@cgforge]

Hey Chris, thanks for the reply. Ya know, I think a lot of it all comes down to personal preference, and if Karma clicks for your workflow, then that's awesome. I wasn't using Redshift when it first getting support for the USD/Solaris workflow. I stuck with the traditional obj --> rops workflow for a bit, but it sounds like the first few iterations were bumpy. During the tests, the main stability issue came down to the Solaris viewport and how it crashed whenever starting / stopping / resetting the renders. That was equally true for Karma and RS, so that, to me, says that it's probably some kind of bug related to the Houdini viewport that was underpinning those problems. In general, I suppose we agree to disagree on some of those topics, but that's totally alright. It will be interesting to see how Karma and Redshift track over time.

[@chr1st0pher]

@@cgforge for sure. i think we probably mainly just disagree on solaris/usd -- which i also think still needs more work but is still in a decent place for now and i really love it. always with render engines though its personal preference as you say, and usually ultimately using whatever works with the least resistance-- which can mean dealing with bugs/issues/lack of feature as well as having to learn new paradigms like solaris/usd, altho the latter is dependent partly on the user putting in that work (and determining if its worth them putting it in). in general though, you are right that RS is hard to beat on pure speed to final frame and features and i can't disagree there at all, I mostly just weighed the other stuff vs that and decided it was worth using karma for me after jumping through the hoops to get comfortable with solaris anyway. hopefully both keep getting developed competitively and make our lives easier over time :)

[@BenVoldman]

@@chr1st0pherI've been trying to get into Krama but the bouncing back and forth between OBJ and Stage I find sucks the joy out as it lacks spontaneity. Do you have any good secrets for bouncing back and forth between contexts?

[@chr1st0pher]

@@BenVoldman theres def a lot of small things ive sort of figured out over time. sometimes i pin the view in lops and make changes at sop level. you can have both views open at the same time. i strongly recommend against trying to do layout in lops, just treat it only as a lighting context. keep things live if you want spontenaity but def cache certain things where it makes sense, and update those caches as needed. you can mostly work as you would previously if you just rely on the scene import nodes which ive been enjoying using over sop import in a lot of cases recently. all that said, theres definitely ux improvements sideFX can and should make here, and houdini has never been as fast or spontaneous as other packages to just get a render with materials and lights up and running. i definitely want to keep pushing them on this stuff and giving feedback, but its come a long way and will get better.

[@marklin2372]

It is so impressive to see such a detail test. The comment also discuss in a very friendly and serious way. Thank you for bring it to me!😊

[@cgforge]

Thanks for watching! 🙂👍

[@noisebiccys]

Awesome resource as usual. Thanks for posting.

[@philippwelsing9108]

Thanks so much for this excellent piece of work!!

[@FabianStrube]

Great Review. I needed that! Thanks a lot!

[@TomCushwa]

Very interesting video.. Thanks for putting in the work in to do this. I learned a lot.

[@DomZeal]

Appreciate the time you put into making this video.

[@pant0n1k]

Thanks for your job! It's really helpful!

[@Josh_Foster]

Thank you for all the time you spent making this video!

[@untitled_exr]

Great work was done, it was a pleasure to watch, also I have someone to share it with, thank you! p.s. It would be great to discuss Renderman and Arnold as well

[@cgforge]

Thanks for watching @untitled_exr ! A Renderman Arnold one would be very interesting. A Vray / Houdini integration could shape up to be a strong contender one day as well.

[@raghnarock]

Great ressource thank you for your wonderfull work. Deserves more recognition !

[@matthewalfonsodurante]

Very useful, thanks!

[@vfxskull6208]

This is fantastic, thank you!

[@SaladFX]

40:15 I noticed you say that you cannot see the preview while rendering to disk with Karma, however you can do it, If you go to the USD render rop, go to the 'husk' tab, then under the 'Monitor' tab you can see 'MPlay Monitor' you need to check that, that will launch Mplay when you click save to disk. It is not very user friendly and should be checked by default, I can see an average user missing that option.

[@cgforge]

Good catch! I didn't even know about that one. Which - to your point - isn't really that user friendly. But, thank you for sharing that bit of info for everyone.

[@RuslanShaov]

Except 'MPlay Monitor' doesn't really work. What it does it renders the sequence to Mplay but it doesnt actually save files to disk. I just wasted so much time waiting for my render to complete and then Mplay crashed and nothing was saved to the render destination. H 20.0.653. @cgforge Great review dude, this was really helpfull. I'm finally gonna get myself redshift. After working with Karma for 2 years I'm definitely switching. Edit: it saves the files only if the folder exists.

[@SaladFX]

​@@RuslanShaov It does save files for me, I even use it with deadline to inspect the frames. Make sure you set the output picture on the karma render settings tab instead of overriding output image in the render rop.

[@RuslanShaov]

@@SaladFX As I mentioned in my first comment it does save files if the folder exists. In my case the folder did not exist and I never thought that would be an issue. Anyway the choice has been made.

[@TabascoDev]

Thanks so much for your precious time for prepare this video. 😀

[@johnli4006]

thanks for doing this man

[@RAzeempk]

Exactly what we freaking needed

[@arsen_wasted]

Hard to say how great your research is. I believe many people was waiting for it in SFX forums etc. And yes - Houdini devs should have some sort of a open list of future improvements. Be well, thank you!

[@serjanburlak2736]

Thank you! Really useful!

[@sjm418]

Thank! You! Tyler! What a helpful video on a very undocumeted topic

[@bram_gunst]

Well done

[@EMVF]

amazing i always love redshift !!!

[@kir11]

Now all very clear! RS wins. Thank you!

[@uzizizu]

So new Karma XPU is adaptive and Houdini now have post-process effects (Slap Comp)

[@cgforge]

Indeed! There are a lot of major improvements coming soon with 20.5. SideFX addressed many issues that were brought up in this video, and it's great to see things change quickly.

[@whocares6302]

@@cgforge could concider making another 1 hour video for that haha

[@cgforge]

I know right! I'm chasing my tail over here. haha In general though, Redshift still wins out at the moment. Karma is much closer than before. Adaptive sampling is finally here, (SideFX should have released XPU with it because it's such a critical feature when rendering), and PostFX is also a win... but XPU is still not there yet when it comes a few other things. Forcing beginners to learn USD right away is still a pretty treacherous task, there are still many quirks to transparent materials, color management may or may not be better, and the user experience portion is yet to be seen. I'll wait another release cycle before doing an update video. For now, I need to focus on what to do with the, Node "Bible." SideFX decided to make their own node "book" that's nearly identical to the "Bible" that I've been developing for years, and I need to make sure that I'm providing value that goes beyond the SideFX documentation / free videos in order to serve my subscribers.

[@coolguy137]

As a beginner / intermediate user working up a demo reel, and having just bought redshift barely a week ago, I too do notice a striking difference between the two but articulating why was more complicated than I thought. Thank you so much for taking the time to do the tests that we "should do" but rarely have the time and patience for!

[@MarioSundays]

Great video! Tks! I love Houdini and I use it everyday, but something similar can be applied to C4D vs Houdini. Not in every aspect but mostly User Experience and hassle.

[@2Z_ccc]

And you can layer or blend your surface material, normal, bump with mtlx Mix node, just need to set it to correspondent signature

[@cgforge]

The mtlx Mix node doesn't match the functionality of a RS material layer node. In RS, you can take an entire shader and layer on other shaders on top of it. The Mtlx Mix node doesn't work for multiple BSDFs. When testing this with XPU, it will provide an error which states, "KarmaXPU: ShaderGraph _sg_s_8576986C5FBFA6FB has rootnode-type not handled by XPU, skipped [ND_mix_surfaceshader]" The only way around it is to layer your signals before they hit a shader, and then rely on one material for everything. This can create networks that are more complex and isn't as ideal as a proper layer node.

[@mzigaib]

This is one of most useful videos I've seen for Houdini for quite a while and as a Sr VFX Artist myself I am biased towards anything that Sidefx does and I quite embraced the USD way of doing things for a quite while now, even though I agree almost 100% of what you just said and opened my eyes for a lot of stuff I was not aware on Karma. That being said I've being rendering stuff even with Karma on H19.5 that did faster and with less issues with most renders like Arnold and even Redshift in production in a medium and big studios but yeah you need to be aware of the problems inside USD/Solaris side, caching and rendering in USD is unbeatable in terms of efficiency on load multiple frames on a farm and Network usage normal Houdini workflow of rendering stuff with big data can not compete with that really, I think this workflow without USD really works very nicely with freelancers with your own local machine and rendering locally but with medium/bigger studios going USD is becoming standard in my view even with the problems so I would suggest to at least learn it. Thanks for the awesome video and I hope Sidefx watches this.

[@mzigaib]

Also about the save jpg/exr alignment to the viewport on Karma you can align the jpgs on the save menu to bake what you are seeing you just need to line up the LUT you are using and I would suggest to use the ACES which has the standard universal options and it comes to Houdini as default, I know I got a little bit a time to get it right but it is just a matter of get the right options on the save dialog.

[@cgforge]

Totally! Thanks for mentioning that @mzigaib as well as checking out the video in general as well. Color correction isn't so much of a big deal for advanced users and/or pipelines that iron out those things, but for students/beginners it's a big problem. Heck, even just getting students to export a render without a ton of noise is very difficult to manage sometimes. And you brought up a great point with USD as well. I agree that it should be learned at some point - even if it's just for the sake of wider employment opportunities. However, I think that study should come along later in one's journey and not right away. To me, USD falls in line as an intermediate / advanced topic if someone is trying to do a proper study of it. Thanks for your input as well as stopping by.

[@3dforever717]

Very very interesting video! Thanks a lot! 👍👍 Now I'm really sure I'll keep my Redshift licence for at least a year minimum... 😅😉

[@klausberfelde-je2ye]

Thank you for this very informative comparison. I really appreciate, that you are not using the Maxon marketing term “Solaris plugin”. My first attempt was Houdini 19 and for obvious reason I tried to get familiar with the Solaris Karma workflow. Having this said, I thought my Houdini FX 20.0.653 and Redshift 3.6.01 combined would be a great workflow improvement, seeing all the rendering results around...but it´s like going back to the old Mantra workflow. However, Solaris (especially Houdini GL) and Redshift RT are anything else then friends. For some Reason materials build up with RS Mat Builder are only displayed as default Material in the in the common Solaris Viewport (Houdini GL) so while adjusting Materials I always have to use Redshift RT. On the other Hand, using material X as mtlxshader builder, Redshift renders out the Base (incl. a attached texture map) and Specular section from the Standard mtlx without any problem. Trying to use anything else from this shader type (incl. the mtlxdisplacement section) don´t work. Something you also shouldn´t do, is adjusting the camera viewport from your active camera while using Redshift RT in comparison to Karma XPU. Because otherwise the viewport went into pure black. So, you are totally right, and I fully agree with you, when it comes to the pure comparison of render time. But taking for example material adjustments also into consideration, this topic looks different to me. So yes, Redshift and the traditional workflow is great and works. But when it comes to Solaris and its workflow using MaterialX and USD, this RS-Plugin is only a kind of pre alpha version of a Solaris Redshift Render Plugin. Conclusion: Redshift 3.6.01 is great if someone grew up with Redshift and/or the Mantra rendering workflow. For people that jumped into Houdini since the Solaris workflow has passed the Beta version and want to use it this way, pls be aware that you have to use a different approach then the common Solaris workflow if you don´t want to run directly into a bunch of trouble.

[@2Z_ccc]

and you can matte object in render geometry settings node under shading->holdout mode

[@cgforge]

This one is partially true, and I'll add an additional note to the video description mentioning it. It is, however, missing some important controls that are present in the RS Matte Shadow shader for holdouts such as the ability to act as a shadow catcher, and there is currently no dedicated shader available within the Karma Material Builder to control settings.

[@michimussato]

Thanks a lot for your work Tyler! It looks like Karma needs a lot of work still. I'm still a Houdini beginner and will remain to be so for a long time. How (although deprecated) would you rank Mantra within this competition? Would it be a better fallback if no Redshift is available?

[@cgforge]

Hey there @michimussato , thanks for watching. I think Mantra is very depreciated at this point. If Redshift is not available, then I would look into arnold or perhaps vray. I haven't ran those engines through these tests to compare, but they are widely used as well.

[@vadimandriushchenko5171]

It's very interesting to see such comparison between redshift and octane for houdini. Will you plan to do it?

[@cgforge]

Unfortunately, I need to attend to my students at CG Forge by updating existing courses and expanding the catalog to topics like procedural modeling, oceans, etc. In the future, I might do this again comparing other render engines like arnold / vray / octane, but that'll be a few years down the line most likely.

[@z8editing]

thank you for making this very interesting recap to put things into perspective its very eye opening about karmas limitations however there are two things that made me drop redshift that you only briefly touched on: stability and development getting slower and slower over the years features like the toon shader and volume improvements were apparently already being worked on when they announced the 3.0 release about 5 years ago the stability was the main reason i canceled my subscription and the studio where i'm working the most is using it less and less for arnold because of the same reasons the random bugs that you can get and the famous crashes that closes houdini instantly with no backup are infuriating that being said, i agree with judgment, especially for students or beginners redshift has pitfalls, but you need complex/heavy scenes to reach them, while karma puts pitfalls in every other steps and strange irregularities in the workflow here and there i'm hoping my personal gamble of switchting to karma will pay out in the long run, which is promising at the moment: development is fast and stability -beyond the pitfalls- is surprisingly solid sadly, i wasn't fully aware of disney's hand in the matter. really hoping it won't hinder further solaris development again, thanks for sharing these kind of information !

[@pinkmoon5332]

I haven't done a bubble blob, but on a previous gig, I tested karma on a simple sphere (which was going to be instanced on some objects to depict water beads). In karma, I saw black using a simple sphere when rendered over other objects (not over black). My approach to a solution was to introduce a fresnel falloff in the MatX shader which got rid of the black issue. But the render times went through the roof on Karma. With Redshift however, this was a non-issue - no black showing up - just typical highlights and some refraction, plus fast renders. I should add, my shaders were Redshift and then using MaterialX for Karma.

[@Bag99Rom]

Like, Like!

[@mirkoventuri6660]

This is the video I needed. I'm constantly jumping back and forth between the two. I use redshift for complete scenes and Karma for small specific tasks. One question regarding the xpu performing better with just the GPUs: I've got a bit confused when you mentioned that the cpu buckets get stuck trying to clean certain areas, in the cloud render, but XPU is only progressive and I can't seem to be able to render with buckets on that one. Only Karma CPU does. By the way I'm disabling CPU for XPU and i actually gain some seconds per render. Pretty good to know when you have hundreds if not thousands of renders in the queue.

[@cgforge]

Hey thanks for watching. I should have phrased that part differently - What i mean there is that I turned off hybrid rendering for Redshift. So, when you're bucket rendering in hybrid mode, you'll want to watch out for those cpu buckets getting stuck. The way around that is either by doing GPU only or using a progressive mode instead.

[@CarlosDordelly]

Hey Tyler! Thanks a lot for this video, some thoughts also to share: - Yes definitely Karma is in a better place right now in H20 and it will be better on each release, saying that, even at this point I think that there is still missing some more "artist friendly" shaders, as you said, most of the shaders are directly from the MaterialX implementation, it would be nice to see more HDAs or custom compiled nodes that offers a more seamless experience compared to other render engines I have a few of then on the DyLib library (but for example layers node, noises with transform parms, etc). - You nailed with the PFX point, I know that also there is a trend of what kind of users have each render engine based on the specialization (most VFX users uses Arnold, Karma, Mantra, etc. Most motion users uses RS, Octane, etc), and there is not a secret that the main user base from Houdini is focused in VFX where there is a very evident process difference between 3D and Compositing, where almost everyone does those on a the dedicated compositing software but it doesn't mean that have a render PostFX can offer some advantage for new or experienced users, for new users of course it saves time to learn a lot of compositing by just setting up a PFX very quickly, for experienced users and/or art directs are extremely useful to do concepts of the scenes very quickly before start doing a real compositing process, or even for projects that have pretty low budget they offer the possibility to make the finishing directly like that with the PFX. For me, Karma (H20) performance shines for open scenes without too many GI bounces, and the volumes looks pretty good, let's see how the new Volume tech of RS will look very soon. I think one very interesting feature that Karma has is the possibility to control the bounces per object and/or per shader. Let's see how Karma will be when it has adaptive sampling too. On the RS side with Solaris, it is way more stable than previous versions, I reported a huge amount of thing to the RS developer and it is on a better place, the same thing with Karma, for me it is way more stable right now in H20 compared to previous versions. Also some stability issues that you had could be caused by the 1080 card, unfortunately due to the time that card has, I recently developed a shader/HDA for RS with a colleague, and the shader had some random instability issues on his machine with the same card where on my tests with 3090 + 4090 worked with no crashes, so good to know that you will have the chance to upgrade it soon :). Because of the same thing, I'll try to test your scenes and post the result on the RS forum thread where you shared this. Also I think that definitely was complicated the render time/performance comparisons, specially because almost every user will use the best possible configuration of each render engine and how it works better, as you already mentioned, RS Hybrid can have performance issues and is because the hybrid mode is very slow compared to the normal GPU that RS has by default, unfortunately we'll need to wait for a future version of Karma with adaptive sampling in order to have a more fair performance comparison I think but those should be compared GPU vs XPU, because AFAIK and based in older tests in H19, Karma XPU with GPU only is a bit slower than GPU+CPU due to some optimizations and how it works, and RS is even faster with the automatic sampling disabled hehe. Just to give a huge good one to Karma, the responsiveness is very impressive on a full viewport rendering session, for simple and more complex scenes, I definitely wish that RS have this responsiveness (for me RS is more responsive in Solaris compared to OBJ/RV btw), I hope that the compilation times will be way faster in future versions. Regarding USD and Solaris, after 1 year of using Solaris yes I think that the main issue thing is that almost all the educational content that there is online is more focused on bigger teams, and or complex things, Solaris definitely can be used in more simple ways without breaking the head dealing with complex USD stuff, that's why I'm doing all my Mardini entries with Solaris just to hopefully record some "quick course" to demonstrate this, I really want to do it hehe There are some other thoughts that probably I'll share later on the RS forum thread, this is already a book hehe... Thanks as always again, the video is pretty objective and with a lot of information, cheers! 😄

[@cgforge]

Hey Carlos! Thanks for the book review. haha You made some excellent points in there. My graphics card is starting to turn into a fossil at this point, so I definitely need to upgrade that when the next gen comes out. There's also another bug related to the 1080 where it creates a black strip on the top of the viewport for some reason, so I don't think the stability support is getting any better looking into the future. When it comes to sampling - I agree that it was tricky to do an apples-to-apples comparison because XPU lacks adaptive sampling. For me though, the issue with that isn't just speed, it's also that I couldn't tell how many samples I need for a clean render. If everything is progressive, then you just need to wing it and hope for the best or overshoot what you think you need to play it safe. But anyway, thanks again for sharing your thoughts as well as watching the video. Cheers!

[@maxmax003]

I haven't finished watching the video yet, but isn't it bad for todays renderers to use a 1080 card? Doesn't the rtx models are better for redshift(not sure about karma)?

[@cgforge]

Yeah, it's definitely getting old. With the 1080, I can't use a lot of the new raytracing tech that's available with the newer cards. Some of my students can only afford a budget rig though, so I try to keep similar specs just to make sure they have a similar experience. When the new Nvidia cards come out, I'll probably upgrade around then. Redshift RT, for example, will perform quite faster than Karma XPU and requires a newer card. From my understanding, right now SideFX is developing a real-time renderer that aims to do the same thing as Redshift RT, but it's not released yet.

[@2Z_ccc]

You can monitor your karma rendering in real time while click render to disk, just turn on mplay monitor in the usd render rop node

[@cgforge]

Good to know! I had no idea - and neither will others users which will negatively affect user experience.

[@Electricvfx]

For the lighting issue at 43 mins, isn't it better to use the light mixer for something like that.

[@InsideTheMindSpace]

The light mixer is still buggy. It can work but in a recent project I lost a lot of time due to a bug with it displaying correctly in the viewport but not displaying at render time. Use it with caution.

[@Electricvfx]

@@InsideTheMindSpace I just had a similar issue with light linker , the mixer has been working for me.

[@InsideTheMindSpace]

@Electricvfx Interesting. It definitely doesn't happen every time but it does happen. Some bug they need to work out.

[@Electricvfx]

@@InsideTheMindSpace on the sidefx forum there are a few posts about issues with the light linker. it does work with CPU render.

[@Francis-yc9nc]

it is really hard to make a comparison and try to bring it to the same level that takes a lot of time. THANK YOU. for Mtlx it is really tricky it should be the universal shader language for Karma, Arnold, Renderman, Unreal Engine and there is also something with gltf. a normal thing in houdini first they write the code and later the documentation gets written( Hello H20.5 🙂). currently SideFx had a update or create new nodes at rate of about +200 Nodes per Release in the last years. next release they could add 2d compositing what is also a mature task (rumor).

[@Wolfnimations]

58:40 - The Senior TD would not be able to use the Houdini Indie license option as they make more than 100k USD a year. At that point they would have to use the Houdini Artist license which is $1,995 a year for Core or $4,495 a year for Houdini FX.

[@cgforge]

Yes, that is indeed correct. Thank you for mentioning that. Unfortunately I'm not able to go back and edit this video once it's published, but for anyone reading that is what it costs.

[@danielkoncur1549]

Thanks for taking your time to save us some time. Methodical, thorough, and what your students have come to expect from CG Forge. I really appreciate your observation that usd is the brain-child of a large studio, and following such protocol means playing by the rules of a large corporation. In a pipeline that employs many individuals these rules are both welcomed and necessary; for the independent filmmaker and small studio, not so much. I find in order to compete with large production companies, for the small studio to even have a chance, new approaches must be developed to replace the resources and manpower of large conglomerates. The proceduralism Houdini offers is a great advantage in the development of innovative ways to accomplish these new approaches. So, it is my hope that SideFX will continue to recognize and equip the David’s of the industry and not solely cater to the Goliaths. I fear that by producing a render engine that only follows usd protocol reveals SideFX’s plans for the future. One of the many wonderful things about Houdini is there is hundreds of ways to accomplish any one thing. Please SideFX, if you are reading this, leave us options for obj level productions as well as lops/usd integration.

[@lewistaylorFX]

It's of benefit to even a solo operator. The workflows it unlocks are useful for everyone. Plenty of Solo/freelancer using it right now and not ever going back to OBJ, give it another try and push through the learning material, it's worth it.

[@musashidanmcgrath]

I was horrified at the terrible interaction you were getting in the IPR and then I saw that you are using a 1080. 😄 Great review/comparison. I'm primarily coming from Arnold as my main renderer for the last 5+ years, but the one thing that stood out for me in this whole video is your report of constant viewport crashes with the IPR. MASSIVE red flag. Maybe an issue with the 1080. Have you done any of these tests on a proper 3x/4x gen RTX card?

[@cgforge]

I know, my 1080 card has been getting a little senile lately. haha When the new 50 cards come out, I'll jump on that pronto. I have some limited experience with the 30 and 40 cards. The performance is much faster for both Redshift and Karma, but I wouldn't be able to give you specific stats until I upgrade eventually.

[@jimmay7736]

Those black things in the bubble test are because Karma lacks a 'last-ray" option that specifies what color to return when refraction ray depth is exceeded. It's odd, as even Lightwave's renderer had an option to send the ray out to infinity and pull the color from the "sky" - for shots like that, it could be an HDR or environment done. You could get some pretty results cheaply that way. Defaulting to black for that ray is embarassingly dumb.

[@jimmay7736]

35:00 I've noticed that SideFX takes that "not developed here" attitude in the code as well. It seems like for things like VDB and Alembic, they just take the reference code from those groups and give it a cursory implementation in Houdini itself. So you end up with slow, single-threaded, unoptimized code, making those formats weigh a thousand pounds in your scene. (Alembic is terrible that way, while at least OpenVDB seems to have done a better job.)

[@lewistaylorFX]

That statement doesn't ring true at all. If you implement open source tools you are bound to keep in lock step with them so data published in one DCC loads correctly in another one. Alembic isn't terrible, it's done a great job of being an interchange cache format and VDB is volumetric data they share little similarity. Volumes are not connected geometry so they are able to be multi-threaded easily. Geometric data like meshes are reliant on point order and polygons, they are always going to be single-threaded, there is no way around that. Your criticisms do not make a lot of sense. If you are curious as to the overheads involved in coding CG to be multi-threaded you can take a look at "Multithreading for Visual Effects" which is a great run through.

[@cgforge]

@lewistaylorFX , you can't deny that the documentation is big problem though with the, "not my code, not my problem" mindset. That at least rings true for MaterialX right now.

[@lewistaylorFX]

@@cgforge yes indeed MaterialX Documentation is very much a technical zone at present. But it's at the bleeding edge, as is Karma in terms of adopting it, so I expect it to take a little while to get some better Docs. Mantra was equally as sparse and not helpful too.

[@cgsudo]

I had same black artifact problem with karma. I'm curious if its possible. Is there any way of using "Unreal for rendering" while still aiming results as for FX portfolio. Like, if can we transfer attributes from Houdini and render something similar to it. Sir, I would like to inform you that in India. Companies are offering average of about $178-$239/month to Jr. Fx Artist. Usually working hours a week is about 54 hours.

[@cgforge]

Hello @cgsudo , yes, you can bring your FX into Unreal and render it there. That will be good for a game dev / real time portfolio. For VFX, however, you will want to use a full-blown render engine to achieve the highest quality possible. That means using Redshift, Arnold, Vray, Renderman, or Karma for example. Good to know about the Indian wages as well. I had no idea they were offering that little for Jr. FX artists in India. I simply looked up the average Indian wage and assumed that VFX artist would at least make the average. Also, it's worth keeping in mind that what studios offer is not what they might be willing to actually pay artists. In other words, what the studio wants is not always what they are willing to get depending on how well other artists negotiate their wages. It would be interesting to see how much they actually pay vs. what studios want to pay.

[@portmantologist]

I recently experimented with Redshift in C4D, mainly to weigh it against my preferred renderer Arnold. They're pretty comparable, with Arnold edging out Redshift in a lot of ways for me, but there is one feature of Redshift that gives it a massive advantage: one of C4D's best features is its suite of noise generators for procedural texturing, and Redshift, being owned by Maxon, gives you the ability to use those in other programs like Houdini - which has, in my opinion, incredibly lacking procedural texturing capabilities unless you're willing and able to do some complex math.

[@erichocean8746]

tl;dr If you don't have a USD pipeline and don't know how to color correct your renders after you make them, you'll get significantly better results faster with Redshift and the normal /obj approach. (Though you might as well use Cinema 4D with Redshift and make things even easier on yourself if you don't actually use Houdini for what it's good at.)

[@2Z_ccc]

and you can use a collect node in material library to assign both karma material or principle material and the redshift shader, so you can preview the textures in openGL while doing the final render in redshift

[@cgforge]

That's true, but setting up two shaders to just to see and openGL preview isn't great from a user experience perspective. Ideally, you should be able to assign a shader, plug in a texture map, and see everything you need to see in the viewport without any other complications. In professional pipelines, this can be resolved by hacking the defaults, but it tends to be a source of concern for beginners who don't know what's going on.

[@philippwelsing9108]

Would be super awesome to have this with RS and Octane... :))

[@PauloCesarDuarte]

Thanks so much for the video, it would be great if you could make a video like this, with more established renderers in the VFX field like, RenderMan and Arnold. Cheers.

[@JacKsCave]

I think there are setup issues with usd and karma .

[@NathanApffel]

An advantage that karma has over redshift that wasn't mentioned in the pricing section of the video, is that with the Engine Indie licenses, you can render on up to 5 machines at once per indie license. Compared to $22 x 5 to render redshift on 5 machines. For a small studio with a small render farm, redshift might still be worth it, but the savings might also be a an extra graphics card.

[@Francis-yc9nc]

the scene file is as non-commercial (.hipnc) with that it is tricky to test the scene file 1:1 because the gltf doesn't get loaded. would be nice to have the scene as hip or hiplc. i guess it has been done with a education license.

[@cgforge]

Hey, @Francis-yc9nc , yes, unfortunately it is made with the educational version of Houdini. I came to realize that most folks will run into those limitations after these tests have been made. My instructor license makes it so that I'm able to get around the resolution limits and use a third-party render engine. However, you can always build your own setups by taking a look at what I did if there's something in particular that you would like to try out. Thanks for watching, good luck

[@photoindra]

1080 for Redshift? I had to check the year this video was recorder after seeing this :)

[@cgforge]

Yeah my computer is a fossil at this point. Just waiting on those new Nvidia chips, and I'm in.

[@ahmednasr93]

I wish you also made a speed comparison for animation, as karma has a huge wait time between frames, sometimes it is equal to the single frame render time and sometimes even more. it depends on the scene size for me.

[@cgforge]

That's interesting - when you say animation, is that when you're rendering from one frame to the next? Like it takes a long time for it to write a frame and then boot up the next?

[@ahmednasr93]

well, I have a fast gen 4 nvme, so not the write speed. I think it is like getting the first pixel time is repeated for every frame(maybe?). I never used redshift but for octane after each frame the next frame starts immediately. you can press "render all frames with a single process." then if the scene is huge then you might wait an hour or more before the first frame starts rendering, then the render won't wait before each frame. this doesn't solve the issue as it just makes me wait the time before the whole render starts instead of between frames. @@cgforge

[@cgforge]

Oh okay, I think I know what you mean. That would mostly come down to the time to first pixel measurement then. Whenever you send out a render, Redshift, or any other render engine, needs to create a set of instructions for the render engine to consider. One of the big culprits for a long time to first pixel is adaptive tesselation and displacement. If you have that going on, then it'll take a long time to subdivide geometry and then write out that info as part of the instructions for the render engine on what to do. There can be other processes too that the render engine figures out before making its set of instructions. So, depending on your scene, that's probably why it's taking a long time for one frame to move onto the next.

[@o.b.a6035]

Did you use path tracing with XPU?

[@cgforge]

Yes, XPU only path traces by default

[@InsideTheMindSpace]

Overall I think this is a great comparison. I have two issues that stuck out to me with what you talk about. When you talk about the overrides from the scene graph that is not inherently a Karma issue and you would have the same issue if you were using Redshift in Solaris. I dont think its fair to dock Karma for that. My second issue is with your pricing discussion. You make assumptions that these people are already making $35 an hour. You are missing a big demographic which is those trying to get into the industry. For those individuals the cost of Redshift can be quite significant. In certain areas especially that could be a significant sacrifice. I also feel like you talk about Redshift as if it's cost is just $250 a year when it reality it is useless without a DCC. So the discussion really is about whether you can afford something else on top of the cost of Houdini. I get that is a given but if it's do I buy Houdini or Redshift there's no point to buying Redshift without the DCC. Also you can monitor the rendering of Karma by checking mplay monitor on the usd rop I believe it is. Yes that isn't user friendly but if you want to nitpick then we need to also talk about how Redshift doesn't have SOP level updates checked by default. When working with the IPR that can cost a new Redshift user an incredible amount of time. Good comparison though. As someone who decided not to renew Redshift and exclusively use XPU for now it was quite eye opening along with the experience that I have gained from forcing myself to use XPU.

[@cgforge]

Hey @InsideTheMindSpace , thanks for watching along with the feedback. We might agree to disagree when it comes to the scene graph issues and affordability. But, I'm curious about the Redshift SOP level updates. From my understanding, if you were to tweak something in SOPs and re-kick a RS render from Solaris, then it ought update it. Is that what you're referring to there?

[@InsideTheMindSpace]

@cgforge Am I wrong in saying that whether you render with Redshift or Karma and you use the overrides in the scene graph it will override those settings? I haven't really used Redshift much in Solaris so perhaps that is different. As far as the SOP level updates, when you change the frame, at least in the geo context, the Redshift render view does not update unless you have the sop level updates settings checked until you restart the render. Personally, it never made sense to me why it wasn't on by default. It may not work that way in Solaris. I'm not sure because when I did use Redshift in Solaris I was using the viewport IPR, which, as far as I remember, didn't have that issue.

[@cgforge]

@InsideTheMindSpace - The scene graph overrides apply the same in RS and Karma if you're using Solaris, and, in my opinion, it's easy to go wrong if you're not careful. My point with RS there is that you have the option of using USD or not using USD which can save you the hassle when it comes to those quirks. When it comes to SOP level updates, I never noticed that before. But, I also haven't really scrubbed frames during a progressive render like that either. I'll have to check that out at some point.

[@NoobNoob339]

Hmmmm karma xpu does have a rayswitch though I've used it before 🤔

[@cgforge]

If you find out about it, let me know. Redshift has a rayswitch node in the material builder, but when I did a keyword "ray" in the karma material builder, there was nothing there to act as an equivalent.

[@ujulspins]

21:00 i believe you should crank up reflections too for this too work

[@cgforge]

I gave that a try, but it didn't seem to do the trick. I think it might have something to do with refractive shadows or perhaps a very small red cut off threshold that's getting enacted because the geometry is really close together between the bubbles. I'm not 100% sure why that's the case, but I believe it's something along those lines

[@ujulspins]

@@cgforge Yeah, what can I say. Karma, like the rest of Houdini, is a thing aimed largely at technical guys. I downloaded the test scene that you provided, did some digging and remembered a parameter such as Ray Bias - this is the answer to your question i suppose. Turn off “Automatic Ray Bias” and try set the parameter to a higher value. 0.004 ray bias and 32 refraction limit gave more or less good results for me. This setting affects the quality of the final image tho, it will not be as realistic as it should be. So it's a balance that needs to be found.

[@cgforge]

Good to know, thanks for sharing. I've had similar issues with characters and refractive eyeballs getting weird because of the ray threshold parameter. I suppose, the thing about that, is that refraction has a good chance of getting wonky by default. There's no safety rails, which, isn't so bueno for the average artist.

[@Dyako_010]

i will pick arnold

[@karlisstigis]

Unfortunately I agree on most things. Still rooting for Karma.

[@user-op1tc5tt3e]

Next one.... KARMA VS ARNOLD!

[@dtmgfx]

One question in case i missed it, How many GPUs does karma support on a single PC per license? And how many extra render nodes do you get/ how much money per extra node. One advantage of houdini and by extension karma, is the dual license. I can still continue to work as another PC is rendering. also able to distribute rendering on my PCs is a plus. I believe houdini offers additional render licenses for free. and each additional one is relatively cheap?

[@cgforge]

Hmm that might be a good question for SideFX directly because I haven't given that a go yet. From what I understand, one license is = one computer. For example, when I was doing the cloud test with Yasser's dual GPUs, that did not take an extra license for both Karma or Redshift because it was just one machine at work.

[@pinkmoon5332]

...which is another way of saying that Maxon, when you have (rent) a license, redshift does not allow for having two renders on a workstation that has two GPU cards (or more). But I'm pretty sure that redshift-wise, if there are multiple redshift licenses, will accept multiple renders on a single workstation I haven't confirmed that however. Maybe someone else can.

[@dtmgfx]

@@cgforge i seem to recall that you can request 3 extra engine and render licences, which you can use with something like hqueue for distributed rendering or simulation. I never used them but that might be something to look at.

[@chr1st0pher]

With indie you get 2 karma licenses, and with FX/core you get 5, without paying any extra. For me as someone with 4 render nodes this is pretttty nice and saves me 1000/year on redshift licenses

[@cgforge]

So, I looked into it a bit more, and according to maxon, one Redshift subscription provides... "Multiple Instances up to 8 GPUs+ on a Single Computer -- Launch multiple instances of Redshift" which makes it a bit unclear as to whether or not that applies to multiple machines. It says up to 8 devices and that you can launch multiple instances of Redshift, but I'm not sure if that's limited to one computer or not.

[@VFXCentral]

wow! this made me knot want to use Karma. Quality and time didnt hold up in my opinion.

[@rennightmare]

why didnt you test both in Solaris which would make the comparison more logical? i enjoy rs but working with default rop nodes is too painful and for solaris i feel the lack of info about redshift cant' figure out how to make AOVs work properly lol, there are literally no info and the lack of documentation, no example files, literally nothing which is a big con for redshift, since for karma+solaris there are almost no things that are impossible to find and solve quickly

[@cgforge]

Hey @rennightmare , I did test using both solaris and via the rop context with RS. One reason why I went back and forth a bit is to highlight some of the pros/cons of solaris in general. With RS, you have the option of doing it the old fashioned way whereas in Karma, you'll probably be building your setups with LOPs. When it comes to AOVs, that's all found in the RS LOP node under output --> AOV manager, and then you can just follow the documentation here: help.maxon.net/r3d/houdini/en-us/#html/Intro+to+AOVs.html?Highlight=aovs And then once you have that, previewing AOVs in the viewport works just the same as with Karma by going to the little image plane button on the righthand toolbar.

[@rennightmare]

​@@cgforge oh I am sorry for my inattention then what about AOVs, light-related pases like diffuse, reflections, shadows etc work just fine for me, but when it came to cryptomatte pass i've spent like 5 hours to figure out how it works and kinda succeeded, i got my crypto pass rendered but it was not showing up in the viewport which isn't good; almost same problem with Motion Vectors pass, nothing in the viewport and also nothing in the render Also, for passes like Puzzle Matte i know that when rendering with default ROP you have to set up some stuff in RS object settings, like ID etc, but I have no idea how to set this up in Solaris I saw ID parameter in RenderGeoSettings LOP, i tried to use it with no success so I am really confused I guess there is a decent chance that i am missing something simple and obvious due to the lack of experience with both RS and Solaris but.. how do i find the missing bits of information if even an official dedicated documentation article about Solaris AOVs does not contain detailed information about nuances big thanks for your video and for your attention

[@cgforge]

Gotcha - so here's the deal there: Cryptomatte and motion vectors are special AOVs. They're special because you either need to enable bucket rendering to see them, or, in the case of cryptomatte, you might only be able to see it once it's rendered because it saves out a separate image for that pass. The reason I figured that one out is because I was cruising through the forums and found a conversation about it. In that way, Redshift's documentation also should be more clear about how that specifically works. But yeah - either switch over to bucket mode, and if that still doesn't work, then you might need to just shoot out a low resolution test frame to make sure it works when saving to disk.

[@rennightmare]

​@@cgforge ok, i found some time to dive in RS AOVs again and actually kinda solved most of problems i was facing before. My problem with motion vectors was nonexistent - the only reason i thought it's not working was my AOV appearing fully yellow since i came from engines which can actually display it properly. Once I figured that out by reading some reddit post I found on 10th google page everything came back to place. Finally figured out how to setup Puzzle Matte AOV but Crypto still feels like it works randomly. Gotta be missing something simple so hope it won't be a problem in my next projects.

[@vladyslavlavrenov9167]

incorrect comparison of glass in both, different settings, while karma does have darker shadows for refractive materials if you set up everything correctly they should not be that dark, and in redshift shadows are off by default which leads to that cleaner looking and some what fake transparent materials.

[@cgforge]

Well then, how is that going to impact the average artist? 99% of users are going to turn on transmission and not look out for anything else. If the default look performs faster with less problems, then that's a win for the average user, and advanced users can seek out the transparent shadows with RS if they're after more photorealism.

[@vladyslavlavrenov9167]

@@cgforge So, the average artist is a person who creates average and mediocre work right? Makes sense then. If you are not average, you need to know every single detail about a renderer because in the end that single detail affects the quality of the final image. Good video though, I think Karma has a very good potential, XPU currently is not that usable for anything other than personal projects, but very soon it will be a great renderer I believe, just needs a bit more time. XPU is the best for small scale VFX already, so soon will be great for other things

[@cgforge]

I would argue that software development should cater to the average user because that's primarily who is buying the product. Besides, even for advanced users, there is a constant learning curve with new features and systems that never end. Why make those features harder to use than they have to be? A render engine that makes great looking images by default makes everyone's lives easier at the end of the day. But anyway, it'll be interesting to see what happens over time with Karma / RS. Only time will tell.

[@vladyslavlavrenov9167]

@@cgforge I mean if we talking about this topic, both Karma and RS are pretty much "lowered to the most minimum settings possible" by default. And to actually get quality image you need to increase the limits, also Redshift is one of the most advanced GPU renderers out there, you need to know how to make it look good, it was always like this, and it's NOT one of the engines that look good by default. Renderers like Corona or Octane are like this, no settings just plug and play, there is even a large lack of features in Corona compared to other renderers so you don't need to bother at all.

[@cgforge]

I hear ya, but I think nowadays Redshift has gotten past the hacking stage when it comes to visual quality. It used to be the case that Redshift struggled hard when it came to SSS and volumes, for example. Now, however, I think it does a great job with those things, and it's faster than most other engines. Ease of use is sometimes correlated with lesser visual quality because it's more simple, but sometimes ease of use is also just about good / bad design choices from the developers. For example, if you were to take the most painful-to-use render engine out there, it's not like that render engine will always produce better looking results. Sometimes, it's just harder to use because of bad design. And, I go back to valuing the average artist - harder to use = lower quality results.

[@balazs.gyurics]

I'm up for a debate, but my personal opinion is: It is a no-brainer for an indie artist to use Houdini + Karma. Reasons: 1) do the mentioned "issues" really worth + 45 / month or +260 / year? I hardly doubt. 2) If you run out of Vram with Redshift you arrive to another dimension vs Karma offers CPU, GPU + XPU as options 3) Karma is a dedicated engine inside Houdini, if Houdini have an update, Karma will be sync with it immediately but it is not guaranteed for 3. party engines as RS.

[@cgforge]

Hey there, thanks for sharing your thoughts. If using karma is fun and it's enjoyable for you as an indie artist, then that's great! Even though redshift won in this comparison, it's not to say that it's the best option for everyone. We may agree to disagree on some of these ideas, but in my opinion, I do think it's worth the money as an indie artist. Even if you disregard speed entirely, the user experience portion and feature set is farther along than karma currently is at. If you're someone who needs to learn all the quirks for the first time, or if you're a user that wants to utilize some of the features that are not available in karma (such as a toon shader for example) then redshift would absolutely be worth the money. Redshift gives you the option for hybrid rendering that uses both your GPU and your CPU just like karma xpu does, and it currently does a better job at handling situations that blow past vram limitations then karma does. In these tests I often use both GPU and CPU at the same time with redshift. When it comes to compatibility, fortunately redshift is pretty quick to update anything new with each version of Houdini. Even though it is a third party render engine, the support thus far has been in good shape in my experience, but I understand it may become a risk in the future. But, all in all, as I said before, if you're enjoying karma then that's great 🙂👍

[@balazs.gyurics]

@@cgforge Thanks so much for Your answer! I also tried to compare a bunch of render engines and in some cases I experienced a little guess work by cycles GPU, Octane, Redshift and Renderman where Karma (H20+) was slower (XPU), but did not given up on defining the surface without guesswork. I can imagine that these results could be triggered due to setups. (of course I always disabled noise, dicing and such pre and post processes, to see raw results) We can see the same (above mentioned) scenario at 12:56: RS is noise free, faster, but I see the guesswork in angle connections. But it is always preference dependent, for someone who is rendering stylized animations, with smooth bending forms this behaviour is not a blocker. What was interesting in my tests that somehow Karma was using the most Vram compared to all others I tried to figuring out the reason, but still could not. Did you experienced such behaviour? It happened at pbr setups, I tested just pbr scenes I did not even bothered to test shader based visualization, shaders could react in different ways - it is also an important factor, but depends on shader usage, as vex based principle, Mtlx, modified Mtlx that is dedicated to Karma... all will generate different end results. You mentioned XPU. What I also realized that if in Karma I ran out of Vram due to XPU rendering IF I had been using a heavy scene, it always ended up in render time segments, that were close to pure CPU setups, and here we arrived to a point where pure CPU solution could mean versatile workflow - depends on the project, due to very heavy scenes pure CPU on a threadripper seems to give faster results vs a lower end consumer CPU paired with an RTX family card on XPU. But it is all scene dependent (even nowadays, in film industry pure CPU is the way, no matter if they are full of ADA 5000/6000 gpus, they are used just for lookdev - I can imagine that the reason behind it is the same) Of course we are talking about indie setups this time, but they can trigger the same challenges as big studios should face, but in smaller steps. I mentioned "Karma is a no brainer" if you are using Houdini also from financial perspective. I know that 260 euro/$ plus should not mean the end of the budget, but I meant here a mindset :) If you are buying a 260 $ engine on top of your in build render engine, than why not buying 3. party UV, retopo, mocap, sim tools, also every even asset that seems great, buying HDAs and so on and it can single handed kill a freelance based jump out - this is why I had been suggesting Karma for freelancer artists, simply by keeping our heads cool :) Its not like if Houdini would not have a render engine, or it is useless, RS is indeed an older and therefor more chiselled engine, but even with Karma anyone could bring any kind of idea till the end.

[@OhioNPC911]

In India average VFx artist makes £300/ month or houdini artist i believe £450-600 max for sure

[@cgforge]

Wow, that's really cheap. I don't live in India, so I probably don't know as well as someone who does. But, when I was looking up "Average Indian Salary" on google, I found that INR 9,45,489 per year was the average according to glassdoor / forbes. I used that to convert into $11,339 usd, or about £748/mo. I suppose it's possible that Indian VFX artists make less than the average, but I figured they would make about the average being that it's a higher skilled tech job.

[@DeanRockne]

I don't see how anyone can complain about Houdini's indie pricing. It's the best deal in CGI. Most freelancers spend more than $200/yr on their accounting software or doing their taxes.

[@cgforge]

I agree - by comparison, I was just looking up how much it cost to subscribe to Maya every year. And I believe that's up to about $1,800. So yeah, sidefx's pricing is pretty awesome.

[@jamesconkle9158]

Another title could be: Why to start using Octane ;)

[@montoyland]

Given the goals for your students, the clear candidate is Eevee in Blender.

[@cgforge]

I think Eevee is worth considering for beginners, but it'll struggle once you start getting into the weeds. The features aren't there compared to the other engines, and migration between Houdini and Blender can get dicey in complex scenes.

[@montoyland]

@@cgforge With the introduction of Geometry nodes, Blender has closed a significant gap with respect to Houdini. The critical issue that is paramount to developing one's skills, is the ability to quickly iterate, and quite honestly, Blender wins hands down in this respect. The introduction of Eevee Next will address some of its shortcomings, including real displacement, but even now there's Cycles to lean on when non-biased path tracing is required. With the introduction of AI-driven denoisers, I find I can typically get away by setting a relatively high noise threshold (0.1) and allow the denoiser to do the rest of the work, for acceptable results (especially for animation, where it's more forgiving than a still that'll be more closely scrutinized). Taking this into account, I find I can get satisfactory results in under 30 sec for an HD frame even with complex scenes with refraction and subsurface scattering. But the huge point in its favor is productivity. For a student, the best way to accelerate one's progress is to tighten the iteration loop from conception to execution and quite frankly, in this regard, Blender wins hands down. That skill can close the gap with the big boys (Maya, Houdini) has been amply proven by artists like Ian Hubert and Chris Jones, who have shown that it can scale well in capable hands producing professional results that are indistinguishable from its more expensive competitors. But the issue of price, as you have shown, is kind of moot, the true hidden cost to consider is time, not just for rendering, but for quickly getting results that one can respond to and in this regard, Blender shines as it's designed to be accessible and user-friendly for the novice. The Blender road map is quite impressive and the developers have shown that they understand how the tools are being used by the community, prioritizing substance over flashy features - for that there's a rich Addon market. They listen and consistently deliver on features with impressive speed. Even Manuel, from Entagma, who is a staunch Houdini advocate, extolled Blender's virtues in one of his "nerd rant" podcasts and is himself using Blender with his university students, precisely for the reasons I mention. For personal projects, I have recently made the shift to Blender from Houdini and won't look back. It's just the right tool for a lone artist and his laptop. Houdini is unparalleled for working within an established pipeline, but I don't think the lone 3D artist is the ideal fit.

[@cgforge]

Yeah, ya know, it all really depends on what you're trying to do. Houdini has a way of rewarding your efforts later on in your learning journey and blender does so towards the beginning in general. You will run into a significant number of limitations with Blender, however, and that can turn into big problems real quickly if you need to get exactly what you want at the highest possible quality. I often suggest people learn both because they often have opposite strengths and weaknesses. So, rather than looking at it as 100 percent this or that, it's often more interesting to combine the two depending on the situation. Another thing to consider is that If you render with a 3rd party engine like Redshift, you can use that engine consistently across multiple platforms. One of the problems with native render engines like Eevee and Karma is that you don't get that cross platform compatibility. That can make a significant difference if you're, let's say, freelancing with multiple pipelines to contend with. In that situation, you'll want to learn all the render engines, but it will probably be easier to deal with a 3rd party because of the cross platform compatibility. For example, I've run into a cinema pipeline that uses redshift and a Maya one that uses redshift. In both cases, I'm able to just do all my work in Houdini by exporting out proxies because it didn't really matter where everyone else wanted to be. But anyway, to make a long story short, I wouldn't recommend drinking the Eevee, Karma, or Redshift Kool aid and only doing that. The best answer really just depends on the specific situation, and a great 3d artist is going to learn as much as possible to provide the best custom solution for each situation

[@montoyland]

Excellent advice!

[@pinkmoon5332]

Good point about that. But for most projects, you always want to stay within gpu ram limitations, even when there's less of a speed penalty on the karma/gpu side. Users can quickly tailor their renders to be gpu only, and the format used (the .rs format) for redshift allows for over twice the amount of data before running out of gpu ram. Bottom line no one wants to render hybrid period avoid at all costs unless you have a huge CPU farm and you have a lot of money to spend

[@SaladFX]

One thing I'd like to point out is that redshift is faster in GPU only rather than CPU+GPU hybrid.

[@cgforge]

Yes, that might be a bit confusing with how I said that in the cloud demo. In that, I turned off hybrid rendering for Redshift, and that resulted in a faster bucket render due to CPU buckets not getting stuck.

[@dtmgfx]

True, hybrid mode tanks performance for me

[@cgforge]

I did find, however, that hybrid sped up the more lightweight scenes with RS. It only bogs it down if those CPU buckets get stuck. And, in that situation, you can probably get around it by changing your rendering mode to progressive.

[@Electricvfx]

Sadly for the first time I am disapointed in something Sidefx put out that is Karma XPU. I tried and tried but its just not working for me to many issues and too slow. I really wanted to cut down expenses and not get another piece of software.Maybe in the next major update it will be better.

[@vladyslavlavrenov9167]

It's a new renderer, and believe me it was created firstly for VFX, and it works a lot better than in Octane or Redshift, and Redshift only recently got decent Volumes. Karma XPU needs to work more on Motion Graphics side of things, but of course you cannot get everything at once, it's not that simple. The main problem right now with XPU is compiling and very long sampling, it's really hard to clean up the noise, it's like cycles renderer basically

[@JacKsCave]

If you want to use karma , you have to learn usd and solaris , and spend time to learn mtlx .

[@Electricvfx]

@vladyslavlavrenov9167 Yeah the clearing the noise has been tricky. Actually the only thing I found great to render in it is volumes/pyro.

[@vladyslavlavrenov9167]

@@Electricvfx Yes, and the point is it's the best GPU renderer for VFX. All other GPU renderers absolutely suck at volumes, all of them except for Karma

[@psclip3309]

or render with octane for blender its free

[@ChrisCharltonContact]

Good to see you back at it. Nice video. I feel some of the comparisons were a little unfair, as a lot of those features that you mention rely on using other features in Houdini to extend Karma, e.g. COPS, attributes, etc. I'm not a huge fan of Karma, but it is generally pretty solid, I have yet to update Houdini to the latest dispersion settings, which is one of my current issues with the version I am currently on, but I have definitely gotten a lot of the features you state it doesn't have (e.g. caustics). I would agree, Houdini doesn't do a good job of making it artist friendly, but this isn't an entry level software... as I know you are aware, where as redshift is a derivative of C4D, which I would say is a fairly entry level software (having started there myself). It would be great for them to bridge the knowledge gap, but devil is in the details. If you dumb down the artist workflow then you normally trade fidelity of control. But yes that recursive bounce refraction limit result... yeah they need to solve that.