Karma Sink
· Houdini MOC · Karma renderer ·
Environment variables
Disabling devices for more details
| Variable | Effect |
|---|---|
KARMA_XPU_OPTIX_CURVE_OPT_LEVEL = 1 |
Memory consumption on OptiX devices can be reduction (with some performance loss)1 = low-mem, 2 = mid-mem (default), 4 = high-mem |
KARMA_XPU_DEVICES=optix |
Use only Optix devices |
KARMA_XPU_DISABLE_OPTIX_DEVICE = 1 |
Karma XPU will not use any Optix GPU devices |
KARMA_XPU_DISABLE_EMBREE_DEVICE = 1 |
Karma XPU will not use any Embree CPU devices |
KARMA_XPU_DISABLE_DEVICE_n = 1 |
Karma XPU will not use device number n. For example, to disable device 3 in a multi-GPU setupKARMA_XPU_DISABLE_DEVICE_3 = 1 |
HOUDINI_TEXTURE_DISK_CACHE |
Set texture caching location "dir=D:/Temp/houdini_rat" |
KARMA_XPU_OPTIX_HQ_LINEAR_FILTERING |
Default OFF. Force Karma XPU Optix device to do high-quality linear filtering (which will come at a performance cost) |
KARMA_XPU_OPTIX_FORCE_CONSTANT_FOLDING |
Default OFF. This will force XPU to hardcode parameter values directly into shader code. It can improve performance of rendering by ~20%, but will mean shader compilation will be more frequent and take longer. |
XPU Compiling
Compile cache location is C:\Users\Keerah\AppData\Local\NVIDIA\OptixCache\Houdini21.0
Sampling
Pre-compiling benefits interactivity and first pixel time
Adaptive sampling video
My notes on rendering Pyro with Karma
These checkpoints will make your render experience wayyyy moooore easier and snappy!
-
Use the Pyro Postprocess SOP node to cull the Vel volume by the Density, it saves a humongous amount of disk space (and performance) when caching volumes! Monitor the volume primitive sizes in info panel and you'll see that the Vel volume can be many folds bigger than the Density. Most of the time I also convert VDBs into 16 bit, all these options are present in that node.
-
When importing those volumetrics into Solaris always limit the Volume LOP explicitly to the volume primitives you really need to save (a lot of) VRAM. There is a field where you can specify the primitives. You might not need the Vel volume at all if you render with no motion blur.
-
USD cache all the things, this will bring your First Pixel time in hashtag#Karma to nearly zero! Especially when you have the "Render with single process" option on (then Karma caches the entire scene prior the rendering, and it can take pretty long)
-
I encountered a strange USD time sampling behavior when the volume was updating fine while inside Houdini but was frozen in the external renderer. A quick workaround is to USD cache it too. USD volume cache is very compact, since it does not contain the actual VDBs, but simply references them instead.