I have a slight problem with MaterialX transmission acting as if there was an interpenetration between two meshes, where one has transmissive and the other --- opaque MtlX Standard Surface. I've checked up the geometry left and right, but meshes do not cross each other anywhere. I can get rid of the black areas by separating those two meshes even more, but this breaks the asset design.
Refraction rays are set to 8. I'm rendering with Karma XPU, but CPU behaves identically. In the shader I'm using "Transmission" parameter only (no advanced transmission features), which according to documentation is already implemented.
Out of curiosity I prepared a quick scene in Blender, rendered it out with Cycles and there are no black areas anywhere to be found.
This leaves me scratching my head. Is there a minimum distance that transmissive geometry must be from an opaque one in order to render properly? Or is it something else?
ajz3d This leaves me scratching my head. Is there a minimum distance that transmissive geometry must be from an opaque one in order to render properly? Or is it something else?
Isn't that true of all raytracing? It's called raybias. When sending rays, a small gap is made so that the ray doesn't collide with the point it came from. Cycles probably just has a smaller default ray bias.
Thanks. Indeed, it is. And lowering it produced the correct result.
Unfortunately I can't compare the default value of ray bias with Cycles, because apparently I couldn't find it in Blender. Perhaps it's not exposed, or is dug in somewhere under a different name.
ajz3d Unfortunately I can't compare the default value of ray bias with Cycles, because apparently I couldn't find it in Blender. Perhaps it's not exposed, or is dug in somewhere under a different name.
I wonder if someone finally solved the issue (of needing ray bias in the first place).
Nice find. I guess this indeed explains the absence of such parameter in Cycles. In fact, the paper also mentions that they (NVIDIA) have used this method in "Iray rendering system for more than a decade". And this must be true, seeing that Iray integrated into Substance Painter calculates bias automatically.
So, considering that a robust automated solution for ray bias calculation already exists, perhaps it could be integrated into Karma? This whole manual bias tweaking feels somewhat antiquated. Unless it also serves some other purpose.
The NVidia solution is far from ideal. We found that it broke down in many trivial cases (eg large ground plane, object far from the origin, etc...)
NVidia acknowledges limitations in their article, and propose some workarounds. eg, "...note that huge translation or scaling values in instancing transformations will result in larger offset values as well... This phenomenon leads to a general quality issue because all lighting, direct and indirect, will be noticeably “offset” as well, which becomes apparent especially in nearby reflections, even leading to artifacts. To tackle this problem, we recommend storing all meshes in world units centered around the origin (0,0,0). Further, one should extract translation and scaling from the camera transformation and instead include them in the object instancing matrices..."
Such intrusive changing of transform matricies is difficult for us to do in Karma (eg hydra, nested instancing, etc...). We found that a simple ray-bias seems to handle itself surprisingly well when tweaked accordingly. Although I am of the opinion it should be a per-geometry-property (rather than a global render setting).
In saying all this, it is something we'd like to work on in future versions of Karma. KarmaCPU does have an experimental alternative implemented, to activate set ray-bias to zero.
