Karma default clouds versus Redshift Standard Volume

So in my challenge to start using Karma / Solaris more in Houdini I went and did some cloud tests one a cloud I modeled back for the guitar project. Same scale height and settings as close as I could get them. Karma volume settings are just default, no changes. I had to tweak the Redshift Standard Volume Shader a good deal to get it this far. Rendered both out at 1920x 1080. The Karma one looks more like a cloud though while the Redshift one still feels more like smoke to me. Karma on left, Redshift on right. Using Houdini 20.5.410 and Redshift 2025.1.1.

Quixel Bridge fix for Houdini/Redshift (Update)

New update to make Quixel behave better with Houdini and RedShift was just released on Denes Dankhazi's Blogfolio. Gotta love anyone with “dank” in their name you know. Get the RedShift fix Here.

Basically, Quixles textures come in wrong, especially the displacement and this fixes that. Wrong might be the incorrect way as it’s fine in Unreal, just a RedShift implementation in Houdini is odd I guess?

“The Quixel Bridge fix for Houdini/Redshift.
For Houdini, I changed the 3D Asset, the 3D Plants and the Surfaces part.

How to use it:

  • Install the latest update (4.5) for Houdini in Quixel Bridge
    The plugin path is something like this: Megascans\Library\support\plugins\houdini\4.5\MSLiveLink\scripts\python\MSPlugin

  • Download the files and replace the original ones: download

    • ImportSurface.py goes to the AssetImporters folder

    • Import3D.py goes to the AssetImporters folder

    • ImportPlant.py goes to the AssetImporters folder

    • Redshift.py goes to the MaterialsSetup folder

  • The changes are significant

    • Subdiv settings

    • Shader settings

    • and most importantly Color Management settings for the RS Texture nodes
      Without this you can’t render correctly anything.
      Now the colors are using sRGB and everything else is linear as it should be.

  • You still have to fix the Displacement EXR textures thou.

    • Open in Photoshop (for example)

    • You’ll see there is data only in the red channel

    • Copy that as an the RGB layer and merge (Ctrl+E)

    • Sometimes you still have to linearize the data, use the exposure adjustment layer with gamma 0.454

Cheers, D”

Houdini Doodles, Glass Floats

On the Oregon coast you can see a bunch of these glass floats at the antique shops and wanted to take a stab at recreating the glass. Fun to light as well.

More teasers

Just some more teaser images for some stuff coming out soon.

Houdini hair / fur with Redshift Render Engine

So I spent an insane amount of time last week trying to get hair / fur in Houdini to show up when using Redshift render engine. I was looking at all sorts of tutorials and not one of them mentioned this freaking setting to make it work. You have to toggle the Hair Generation from “Generate Geo in Mantra” to “Use SOP Geo”. BAM, everything works. Took me forever to find it. Hopefully, this saves you the same headache.

Houdini Doodles

Just playing around with simple clean sets here a bit. Want to work on bashing out a few sets a day to see what I can come up with.

Testing some more Shaders

Working on some more Redshift today trying to dial in some shaders. I reworked my thin film to be a bit more subtle and took a stab at some subsurface scattering gummy bears. Pretty happy with the results.

RedShift and the Adaptive Error Threshold (AET).

One of the most annoying things about RedShift is that the defaults for everything is pretty much shit. This means you gotta spend 5-10 minutes setting up everything correctly at the start of a project. Well yesterday I was rendering out some very reflective thin type with moving lights and was running into the flickering highlight problem. I recalled reading a bit about AET but forgot the gist of it but after a bit of googling I found this forum post about it. This pretty much sums it all up. Bookmark it…

“In the Unified Sampling there is also Adaptive Error Threshold (AET). "This parameter controls how sensitive the noise detection algorithm will be. Lower numbers will detect noise more aggressively which means that more rays will be shot per pixel and vice-versa. It is recommended that you use the ‘show samples’ feature to visualize the effect of this parameter. The default 0.01 value should work well for a variety of scenes. For production-quality results, we recommend lower settings such as 0.003." AET seems to work amazingly well with it not taking much more processing power to figure out which pixel needs more samples. Knowing this let's say we set US Min to 1 and Max to 512. As said in the first post 512 seems to give the best quality for some odd reason and lower render times. A higher US max does not seem to give better quality for some strange reason. Now we set BF rays at 16384 it's max. We do this because AET seems to also control BF samples. The more BF samples the better. Set Irradiance Point Cloud samples to 1. The AET is so powerful we can now control exactly how fast Redshift renders and with what quality with the one parameter. Doing it in this way makes AET into a single make it pretty slider. Values between 0 and 2147483647 work for this with the higher number giving less quality and 0 being the max quality. I found a value of 0.001 is the lowest it can go without being 0 and seems to be needed for some scenes. A value of 0 gives the best results if one wants to wait much longer. If doing animations a higher AET could be used with Randomize pattern every frame as the different samples can be smoothed between frames with great results. Now that I know this I'm kind of scratching my head wondering why Redshift didn't simplify it to the one slider. It really does work that well.”