Experiment: Karma ROP vs Solaris Karma

Berk Erdag
4 min readFeb 1, 2024

--

This time I decided to see if using Solaris with Karma makes a difference in render time. Previously I used the regular method for rendering which is to put down a Karma ROP in the out context and adjusting the values to render everything out, just like using Mantra ROP. But this time I used the stage context and made a comparison.

Short Answer

If you are here for the short answer here it is = Both methods gave the same render times.
But for more details keep reading.

What I did?

This time I worked with a FLIP ocean sim that was extended with Houdini’s standard tools. I used Karma CPU to render the ocean because as far as I know XPU (Houdini 19.5) can’t render that default ocean material Houdini has. See below the documentation from SideFX, it says ocean material only works with Karma CPU.

https://www.sidefx.com/docs/houdini/nodes/lop/karmaocean.html

Solaris (especially the stage context) has always felt a bit confusing for me, however, the karma ocean node in stage is pretty useful and easy to understand. It captures all the required masks, spectras, creates the materials, gives you the detailed options like dicing. So you don’t have to bring in your ocean sim with a SOP Import and do all manual works.

I also added a canoe RBD element, a Mutant that rises out of the ocean and whitewater which were all rendered with Karma XPU and they obviously were a lot faster than the ocean render. Here is the result of the overall render.

Render Layers

In Karma I realized that adding mattes or phantom objects add a lot of time to the renders (of course it is based on the complexity of the scene) but it feels the secondary effects of matte objects affect the render times substantially compared to some other renderers. The ocean is the one that is rendered with the white water being a matte, the mutant and the canoe being phantom objects. The render settings can be seen below. (the settings that are not written below are left default)

Resolution: 1920x1080
Primary Samples: 34
Min Secondary Samples: 1
Max Secondary Samples: 8
Screendoor Samples: 2
Volume Step Rate: 0.1
Refraction Limit: 5
Color Limit: 6
Russian Roulette Cutoff Depth: 3

These values did not give me the best result, that’s why I used the denoising tools in the img context inside Houdini. If you haven’t tried the denoise options here (Denoise AI and Denoise TVD nodes in the img context), you should, it gets rid of grain and doesn’t blur the view much. I can’t say I used a lot of denoising tools but Houdini’s denoising option is one of the best I’ve ever seen.

While comparing I kept all the settings the same and the result seemed same to me also. And the experiment was done only for the ocean layer.

Render times were not always exactly the same so I decided to do 3 renders for each context. Regular Karma ROP in the out context gave me 8:02, 8:00 and 7:58 averaging at 8:00 for the same frame. Stage context showed 7:58, 8:09 and 8:06 which averages to 8:04. Here the PC specs come into play a lot obviously which can be seen below:

i7 9700F 3.0GHz
32GB RAM
RTX 2060

And some nerdy values =
Ocean Polycount: 1,335,254
FLIP Particle Count: 13,543,481
FLIP Sim Time: 18 hours
FLIP Meshing Time: 2,5 min per frame
Total Number of Frames: 335

After testing this, I had the curiosity to try exporting the ocean mesh as a USD and importing it into stage and rendering that way. Because I thought maybe using a reference node to bring the USD and not a SOP Import in stage might make things faster. To my surprise using a USD made things a bit slower which is weird. So importing a USD into Stage and rendering was 10 seconds slower. Of course these are again all dependent on PC specs, maybe a faster Hard Disk might read the USD more efficiently and start the render earlier making this method the fastest of all.

Lighting

In case you are wondering, the lighting is pretty basic. There is just one HDRI light and two distant lights. One of the distant lights have sharper shadows, the other softer, that’s all.

Comparison with Mantra

I know that Mantra is old now but since the setup is already there I decided to give Mantra a try. It is nearly impossible to get the same quality of course but I did my best to get similar results. For Mantra the average time was 7:28.

Final Thoughts

This one was a surprising and unpredictable experiment. Before writing this article, I was confident that the stage context would give me faster render times. However, the timings were nearly equal. Still I am happy with Karma even though I wish the CPU option would render faster. About using USDs, I am still not very comfortable with them but I guess it is the future so I should better get used to it. Also Mantra surprised me, I was thinking it would be a lot slower compared to Karma. Of course the graininess would be easier to check with an animation but still even a still frame test showed a 30 second speed difference. Apparently even though Mantra won’t be getting any updates or new feautres it is still a viable renderer.

--

--

Berk Erdag
Berk Erdag

Written by Berk Erdag

VFX artist writing about mostly the business side and a bit about the artistic side and some technical experiments of the VFX and CG Sector.

No responses yet