Direct Light cache: how to avoid splotches?

[Sharlybg]

I like to think that it is just the starting point of LC part 1. So i think as time pass we should have as less as possible settings to do. hope we could find method to automated most of LC settings. It is also good for keeping Lux as simple as possible. the target of light cache is to gain time so user shouldn't use it to find the best combination of settings through a try error process ( we must avoid Vray error as much as possible ).
Anyway thanks you for the job done it is a pretty amazing features and hope to show why i say it asap. When i think you don't need a photton map for this i just want to clone you

[Dade]

This rendering explains the source of the problem:

Triangles have normal interpolation and, often, the line between "day" and "night" falls in the middle of a triangle and it is due to the interpolated normal starting to point "away" from the light source. Now, if DLSC picks the cache entry point on the "day" side of the triangle surface, it will see the light source while if it is picked on the "night" side, it will always in shadow (causing the black splotch).

This is the source of the problem: a DLSC cache entry cover all surfaces inside a sphere but the cache entry information is built using always the very center of the sphere and this can easy lead to some not correct (for all the sphere volume) information.

I have modified the code so it will now keep a list of all valid intersection points found inside the cache entry sphere. This set of points will be used to build the cache entry information instead of just the center. Indeed, the result is a LOT more accurate.

This is the same scene rendered with the new code:

There is a bit of "terminator" effect but the problem is pretty much gone. This is a rendering of the scene with indirect light illumination enabled:

It should be now very rare to have to tune DLSC parameters.

P.S. I have yet to check the scene at origin of this thread but this solution may help there too.

[lacilaci]

It should be now very rare to have to tune DLSC parameters.

That's some good news right there

[Sharlybg]

It should be now very rare to have to tune DLSC parameters.

No matter the condition. which kind of condition are cover by your fix.

[Dade]

It should be now very rare to have to tune DLSC parameters.

No matter the condition. which kind of condition are cover by your fix.

Sorry ?

[Sharlybg]

Sorry ?

Sorry just see that my sentence is completly bad


I mean according your explanation here user will not have to worry about such kind of scenario : hard to reach light or big scene (view) small scene (view).

Your a mostly going to face 2 types of problems when using DLSC:

1) some area can include a LOT of noise if it is not covered by a cache entry (note noise, not artifacts);

2) some area can be in shadow while it shouldn't if the cache entry has wrong list of visible lights attached;

The problem #1 can happen when you are rendering a scene with a scale significantly different from the one of the small room (the default cache entry radius is 0.15m, 15cm). For instance, if you are rendering a city, you will have to increase the radius a lot otherwise you will end with problem #1.

The problem #2 can happen when you are rendering some "hard" to find light source. The default number of samples used to establish if a light source is visible or not is 12 (aka the warmup parameter). It is a very low value, it can easily lead to false result. If you have problems like #2, just increase the value until when the artifacts are gone (indeed, this will increase the pre-processing time).

[Dade]

I mean according your explanation here user will not have to worry about such kind of scenario : hard to reach light or big scene (view) small scene (view).

This fix/improvement is more about the "normal angle" parameter and problems with light sources at glancing angles, in particular when there is normal interpolation.
It will also help a bit with hard to find light sources because instead of sampling always from the same point (where the light may be particularly hard to find) it will vary over the surfaces covered by the cache entry.

[Dade]

I have tried the latest version of the DLSC code with the Marcatore's scene:

The new code seems to handle well the carpet and other surfaces. There is something with the transparent curtain at the end of the room, direct light only rendering shows well the problem:

I haven't sincerely checked DLSC Vs transparent objects. I will.

[Sharlybg]

I have tried the latest version of the DLSC code with the Marcatore's scene:

Can't wait to test it

[lacilaci]

Hmm.. So apparently, corona's own new light solver (that helps with the same situations as this direct light cache should) is still not working 100% and is disabled by default. Cycles's lithttree is also still not implemented(I'm not even sure if it is being worked on still). So this makes me think if there is a fully working and tested solution for huge amount of lights..?