Hi, I've had an issue since I originally started using Luxrender around version 1.4 of original Lux where, when trying to render grass with flat texture cards, the particularly dense areas where the "alpha" of the grass cards overlap turns black.
The weird part about this is that it doesn't happen in the trees, which have many overlapping leaves, but it does happen in the grass. I have tried increasing the maximum light depth, but it doesn't seem to resolve the issue.
Does this have to do with using a particle system to place the grass, or is it just because there are so many layers of grass? Any assistance is greatly appreciated.
Issue With Too Many Alpha Textured Meshes
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Issue With Too Many Alpha Textured Meshes
Calling all Linux users: check out the new LuxRender 1.7 Flatpak! https://github.com/rrubberr/Flatpak-LuxRender
Light transport enthusiast - www.rrubberr.com
Light transport enthusiast - www.rrubberr.com
Re: Issue With Too Many Alpha Textured Meshes
Can you show your material node setup?
Are you using the opacity socket or still the old "mix with null"? The opacity socket is a lot faster.
If I remember correctly, it should also not be dependent on the path depth, however in a quick test I can reproduce a darkening effect that appears weakly when stacking 16 planes behind each other and grows stronger when more planes are added, eventually leading to a black area.
It might be a bug in LuxCore.
I opened an issue: https://github.com/LuxCoreRender/LuxCore/issues/124
(These were all rendered with path depth 1):
Are you using the opacity socket or still the old "mix with null"? The opacity socket is a lot faster.
If I remember correctly, it should also not be dependent on the path depth, however in a quick test I can reproduce a darkening effect that appears weakly when stacking 16 planes behind each other and grows stronger when more planes are added, eventually leading to a black area.
It might be a bug in LuxCore.
I opened an issue: https://github.com/LuxCoreRender/LuxCore/issues/124
(These were all rendered with path depth 1):
- Attachments
-
- opacity.blend
- (894.98 KiB) Downloaded 170 times
-
- opacity_LuxCore.zip
- (539.96 KiB) Downloaded 169 times
Re: Issue With Too Many Alpha Textured Meshes
I was using the mix with null method, but I will update all of my transparencies to use opacity instead. Thank you for the tip.B.Y.O.B. wrote: ↑Sat Jul 28, 2018 9:16 am Can you show your material node setup?
Are you using the opacity socket or still the old "mix with null"? The opacity socket is a lot faster.
If I remember correctly, it should also not be dependent on the path depth, however in a quick test I can reproduce a darkening effect that appears weakly when stacking 16 planes behind each other and grows stronger when more planes are added, eventually leading to a black area.
It might be a bug in LuxCore.
I opened an issue: https://github.com/LuxCoreRender/LuxCore/issues/124
(These were all rendered with path depth 1):
No way to solve it though, currently?
Calling all Linux users: check out the new LuxRender 1.7 Flatpak! https://github.com/rrubberr/Flatpak-LuxRender
Light transport enthusiast - www.rrubberr.com
Light transport enthusiast - www.rrubberr.com
Re: Issue With Too Many Alpha Textured Meshes
I think I have already described this problem some time ago It isn't exactly a bug but a quite complex problem.
Long story short: the code needs an undefined and unbounded number of random variables to handle multiple layers of transparent objects however it receives only one single random variable from the sampler (because it can only generate a bounded number of variables).
So, the only solution was to generate a new random variable starting from the previous one, when new layer of transparent surface is found. The problem is that this operation requires more and more numerical precision each layer you find. With only 32bit floating point numbers, it runs out of "bits" after few layers (ending probably to generate always 0.0 as value).
However, in the mean time, I had the same problem when I re-wrote the volume rendering code and I used there a new solution, one that doesn't suffer from the numerical precision problem.
Now, I have applied the same solution used for heterogeneous volume rendering, to the generic scene intersection code and it seems to works fine and to solve the above problem:
Long story short: the code needs an undefined and unbounded number of random variables to handle multiple layers of transparent objects however it receives only one single random variable from the sampler (because it can only generate a bounded number of variables).
So, the only solution was to generate a new random variable starting from the previous one, when new layer of transparent surface is found. The problem is that this operation requires more and more numerical precision each layer you find. With only 32bit floating point numbers, it runs out of "bits" after few layers (ending probably to generate always 0.0 as value).
However, in the mean time, I had the same problem when I re-wrote the volume rendering code and I used there a new solution, one that doesn't suffer from the numerical precision problem.
Now, I have applied the same solution used for heterogeneous volume rendering, to the generic scene intersection code and it seems to works fine and to solve the above problem:
Re: Issue With Too Many Alpha Textured Meshes
Thank you for the quick fix.
Calling all Linux users: check out the new LuxRender 1.7 Flatpak! https://github.com/rrubberr/Flatpak-LuxRender
Light transport enthusiast - www.rrubberr.com
Light transport enthusiast - www.rrubberr.com
Re: Issue With Too Many Alpha Textured Meshes
Wow just like black magic. Like listen the best of Mozart. You are an artist i think.playing with line of code like that is just mind blowing.Now, I have applied the same solution used for heterogeneous volume rendering, to the generic scene intersection code and it seems to works fine and to solve the above problem:
Thank you.