Found 200 posts.
Search results Show results as topic list.
Technical Discussion » Karma Gold . pyro geo light
- dlee
- 418 posts
- Offline
Volume geometry lights aren't supported in XPU (https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html [www.sidefx.com] see 'Lighting' section for more detail)
Technical Discussion » Karma stuck frames when VDB's have animated transforms
- dlee
- 418 posts
- Offline
Hi. Can you try daily build 20.0.582 (or newer)? It contains fixes to the bug mentioned in that thread.
Technical Discussion » Can we please have a proper round edge shader?
- dlee
- 418 posts
- Offline
Solaris and Karma » Primvar/attributes not being recognised in karma cpu
- dlee
- 418 posts
- Offline
Yes, CPU is strict about matching type signature (float to int, vector to float, etc). I don't think MaterialX spec mentions how the conversion should be applied (if at all) on geomprops, but at the very least XPU and CPU should behave the same and we will definitely investigate.
Solaris and Karma » Volume Velocity blur - karma cpu vs xpu
- dlee
- 418 posts
- Offline
Hi. XPU's volume velocity blur implementation is somewhat different from CPU's. Due to performance considerations XPU does eulerian blur where field lookup points are modified by velocity, but this limits the blur to where velocity field exists. This is acceptable for pyro/smoke animations (which was our primary consideration), but the differences from CPU and field boundaries boundaries start becoming more apparent in cases like your set up where velocity scale is set to 100x.
Solaris and Karma » Split SSS per LPE
- dlee
- 418 posts
- Offline
Ah, I think you've come upon a bug. Not with Karma XPU specifically but with Karma Standard Render Vars LOP - it's generating the wrong LPEs (legacy expressions that are not supported by XPU) when 'Split per LPE tag' is enabled for SSS AOV. Can you please file a bug and link this forum thread? Thank you!
Technical Discussion » Light color temperature 19.5 vs 20
- dlee
- 418 posts
- Offline
jsmack
Where do you find a reference implementation of the blackbody spectra?
It's the same Planckian Locus approximation that MaterialX uses, though I think we ended up going with the same implementation as MDL's because MaterialX's has much higher lower bound temperature.
jsmack
How? does it require an XYZ to RGB transform be defined in the config? What if you have a 1.0 config that doesn't have one? Is it using hardcoded keywords to look for ACEScg or sRGB in the scene_linear role? Does the white point take into account the white point of the color space? ie ACEScg at D60 vs sRGB at D65?
No need to define XYZ to RGB in OCIO - we internally transform into rec709 space first (not gamut clamped) then convert to whichever role defined as scene linear. No special consideration for whitepoints needed.
atv3d
Hello, forgive me for insisting, the problem with the lights is related to hue. If you use an HDR image for light there is a noticeable change, without touching the color temperature. There is no continuity between the lights of 19.5 and 20 hue
Ah, is this for XPU? The fact that light color is not being multiplied color temperature output was a bug which was addressed in 20.0.
Technical Discussion » Light color temperature 19.5 vs 20
- dlee
- 418 posts
- Offline
Hi. Actually this is intentional change in 20.0. Previously it was using internal UT_Color implementation but now uses a more standard normalized blackbody implementation that matches other 3rd party renderers (namely PRMan), is OCIO colour managed, and maximum temperature clamped to match usd spec.
Solaris and Karma » Displacement XPU/CPU difference?
- dlee
- 418 posts
- Offline
Crosby
I do understand that the engines are different. I noticed that with XPU I hade to connect the MtlxNormal to the normalmap node and disconnect it for CPU to get the correct result.
Does XPU need more RAM to calculate displacement vs CPU? Nnoticed that I run out of RAM quicker with XPU in this scene.
That's bizarre! You shouldn't have to wire in Mtlx Normal (unless you need to feed in different normals or in different space) but more importantly CPU and XPU shouldn't interpret it differently. Can you please file a bug with an example scene? Thanks!
As for memory requirement... displacement on XPU *can* require more system RAM depending on how many per-point/vertex attributes the base mesh has, but if that's not the case the discrepancy is likely coming from elsewhere (or perhaps innocuous virtual memory usage).
Houdini Lounge » can't get background plate to render (Houdini 20)
- dlee
- 418 posts
- Offline
Hi. The background LOP assumes that the elements will be rendered separately and tweaked/composited in comp, hence why the slapcomp only happens in IPR for previewing. But if you wish to render out what you see in the viewport you can certainly do so: place "Render Settings Edit" node after "karmarendersettings" LOP, under Karma->Global->Image, change "Use Background" property to "On"
Solaris and Karma » Subd not working?
- dlee
- 418 posts
- Offline
That's bizarre! The two shouldn't be related. Can you please file a bug along with the json package (and the scene if possible) please? Thank you!
Solaris and Karma » Subd not working?
- dlee
- 418 posts
- Offline
Houdini Lounge » How to render AOVs inside refracted object in karma?
- dlee
- 418 posts
- Offline
I'm also curious why the "beauty" renders in the first image is white on black instead of blue.
For holdout matte, it's not possible with secondary rays since they're part of lighting contributions and not related to pixel coverage. That said you could make a makeshift matte via LPE - for example, writing out all light paths containing objects with certain LPE tag and dividing it by beauty pass in comp.
H20.0 adds 'background' event to LPE so it's possible to write a custom alpha AOV that's based on transmission throughput instead of opacity, which might also serve your needs.
For holdout matte, it's not possible with secondary rays since they're part of lighting contributions and not related to pixel coverage. That said you could make a makeshift matte via LPE - for example, writing out all light paths containing objects with certain LPE tag and dividing it by beauty pass in comp.
H20.0 adds 'background' event to LPE so it's possible to write a custom alpha AOV that's based on transmission throughput instead of opacity, which might also serve your needs.
Solaris and Karma » Solaris Subdivision Level
- dlee
- 418 posts
- Offline
Karma does share diced mesh across instances whenever possible, based on the closest instance to the camera.
Support for explicit subd level will be added in the next major release of karma but not available in 19.5 and prior.
Support for explicit subd level will be added in the next major release of karma but not available in 19.5 and prior.
Solaris and Karma » UV "smoothing" with subdivision meshes
- dlee
- 418 posts
- Offline
It's hard to say without inspecting the mesh, but there was a bug that manifested in a similar manner prior to 19.5.563. If you're on an older build please updating and see if it fixes your issue.
Houdini Lounge » Odd behavior with Karma CPU
- dlee
- 418 posts
- Offline
Andy_23
I may add to this and am too having unexpected behavior with Normals using MaterialX standard surface.
I, too, find, that XPU gives me the expected results, while CPU there are obvious artifacts.
This happens with even the most simple geometry like grids.
Any help is much appreciated.
Running 19.5.640 — Apple Silicon M2 or Win 10
Can you please file a bug with the scene? Thank you!
Solaris and Karma » rayhit scope parameter
- dlee
- 418 posts
- Offline
Solaris and Karma » Karma/Solaris Crash W Pyro
- dlee
- 418 posts
- Offline
Solaris and Karma » Mtlx Std Surface transmissive only but still reflective?
- dlee
- 418 posts
- Offline
Hi. You're likely seeing internal reflection which is contributed by transmission lobe via fresnel factors, so they can still appear even if you disable specular. There is no clear separation of tasks for transmission bsdfs for total internal reflection (which we want) vs other internal reflections (which we don't want). This is something that we will address in upcoming major release, but currently there is no plan to backport to 19.5 and earlier due to compatibility/look preservation.
Solaris and Karma » Issues with karma cryptomatte and import in cops
- dlee
- 418 posts
- Offline
Hi. Are you referring to the checkerboard appearance? RGB channels are only for preview and uses checkerboard to indicate selection. Alpha channel contains the output mask. Please see https://www.sidefx.com/docs/houdini/nodes/cop2/cryptomatte.html [www.sidefx.com] for more detail.
-
- Quick Links