Direct Light cache: how to avoid splotches?

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Direct Light cache: how to avoid splotches?

Post by Dade »

marcatore wrote: Tue Apr 02, 2019 3:09 pm @Dade
I think that DLSC should have more love. Using it together with PGI is a nice combo to take down rendertime but, in my opinion, should be developed further to correct splotches.
Yes, I have somewhat the problem to decide which route to take: I could integrate DLSC into PGI with many benefits. DLSC information can be extracted from PGI building process without any additional computation. And DLSC would be improved in the process too. This is big plus however the drawback would be to not be able to use DLSC without PGI (while I like the modular approach).

I'm also not happy of PGI caustic cache. They are pretty the 2 only topics left from my point of view to consider the v2.2 done.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Direct Light cache: how to avoid splotches?

Post by lacilaci »

Dade wrote: Tue Apr 02, 2019 3:37 pm
marcatore wrote: Tue Apr 02, 2019 3:09 pm @Dade
I think that DLSC should have more love. Using it together with PGI is a nice combo to take down rendertime but, in my opinion, should be developed further to correct splotches.
Yes, I have somewhat the problem to decide which route to take: I could integrate DLSC into PGI with many benefits. DLSC information can be extracted from PGI building process without any additional computation. And DLSC would be improved in the process too. This is big plus however the drawback would be to not be able to use DLSC without PGI (while I like the modular approach).

I'm also not happy of PGI caustic cache. They are pretty the 2 only topics left from my point of view to consider the v2.2 done.
Well having to use PGI to have good DLSC is always better than current (almost useless) DLSC. If the pgi+newdlsc would work well that would be pretty amazing.

As for caustic cache, it is so slow and somewhat unpredictable that I think you need to find diferent approach. I've read somewhere that the new corona caustics are also photon based. But that Also might mean some sort of pathguiding that might not be doable on gpu, in corona's case it doesn't matter as it is cpu only anyways though...
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: Direct Light cache: how to avoid splotches?

Post by epilectrolytics »

Dade wrote: Tue Apr 02, 2019 3:37 pm I'm also not happy of PGI caustic cache.
Me too, but I think it is not urgent.
Maybe better to take a break from it, read some more papers and wait for some ideas.

From what I gather users want now:
- principled shader
- 2.8 Luxblend version
- PGI animation

I'd suggest to implement PGI animation, finalize 2.2 and move to 2.3 with better materials.
If DLSC integration in PGI is not too complex it should be done now.
however the drawback would be to not be able to use DLSC without PGI
Maybe if all materials were excluded from cache then PGI could be used for DLSC only but render like simple path, meaning no cache lookup in render but for direct light sampling only?
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Direct Light cache: how to avoid splotches?

Post by lacilaci »

epilectrolytics wrote: Tue Apr 02, 2019 6:05 pm
Dade wrote: Tue Apr 02, 2019 3:37 pm I'm also not happy of PGI caustic cache.
Me too, but I think it is not urgent.
Maybe better to take a break from it, read some more papers and wait for some ideas.

From what I gather users want now:
- principled shader
- 2.8 Luxblend version
- PGI animation

I'd suggest to implement PGI animation, finalize 2.2 and move to 2.3 with better materials.
If DLSC integration in PGI is not too complex it should be done now.
however the drawback would be to not be able to use DLSC without PGI
Maybe if all materials were excluded from cache then PGI could be used for DLSC only but render like simple path, meaning no cache lookup in render but for direct light sampling only?
In terms of "what the users want now" the list is too big... At the same time it would be good to compile a list that is based on research rather than opinions, cause I have my own opinions of what would be the best now but it might not cover all the new potential userbase.

On other hand.... My 2 cents:

2.8 is becoming painfully repeating as a request and I personally just want to avoid 2.79 for multiple reasons.
Principled shader should be taken a bit slowly though, as even cycles's principled shader is criticized a little bit for some lacking features and if luxcore would have an ubershader it should be done properly as it would be the first think to break legacy scenes if changed (as far as I remember this happened few times with corona and people cried)!!!

PGI animation, while an important issue and also relates to Dade's plan for 2.2.. It is globally less important than usability and user experience of luxcore in blender, where most userbase resides now, but then again that's B.Y.O.B's domain.

Overall, luxcore has a very good pace going on and even if I myself jump back and forth from cycles to luxcore and I'm very angry sometimes on luxcore, I still hope all the shortcomings will go and luxcore will become what it's potential is. Because while I like working with cycles, rendering with luxcore is just faster and better.
marcatore
Donor
Donor
Posts: 463
Joined: Wed Jan 10, 2018 8:04 am

Re: Direct Light cache: how to avoid splotches?

Post by marcatore »

Dade wrote: Tue Apr 02, 2019 3:37 pm Yes, I have somewhat the problem to decide which route to take: I could integrate DLSC into PGI with many benefits. DLSC information can be extracted from PGI building process without any additional computation. And DLSC would be improved in the process too. This is big plus however the drawback would be to not be able to use DLSC without PGI (while I like the modular approach).

I'm also not happy of PGI caustic cache. They are pretty the 2 only topics left from my point of view to consider the v2.2 done.
In my opinion (but it just an opinion) the integration of DLSC with PGI is more than welcome.
It seems that you'll catch a bingo cause:
- DLSC will be improved as result and you should reduce the preprocess calculation time
- you reduce the rendering setup complexity solving one of the main critique about Luxcore (or Luxrender that many people still remember)

If anyone want a super mega slow rendering should always disable the new DLSC+PGI and wait to become older in front of the monitor :)

About what Dade (and everyone involved) should develop I think that the poll did some months ago is fine to make a roadmap.
In my opinion, it's better to make solid the base (rendering algorithms) and then everything that run over that base (like materials, animation options and so on).
About the Blender 2.8 support I'd like to have it too but I can truely understand the BYOB position.
If I'm in his position I'll wait at least the end of the Beta hoping that the API will become stable.
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: Direct Light cache: how to avoid splotches?

Post by kintuX »

Honestly, i would just stick with a plan until planned stuff is working well and is documented! There's still lots of work and not many working on it. Last thing anyone needs is more confusion.
Post Reply