dark juice

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.
wasd
Posts: 319
Joined: Tue Apr 24, 2018 7:20 pm

Re: dark juice

Post by wasd »

Sharlybg wrote: Sun Aug 18, 2019 6:39 pm Before making tricky code modification. Is there on earth a valid and non-biased way to make a juice look just normal like in real life ? i mean without hack.
From what I found: Unbiased Photon Gathering is great, but unable to do SDS paths. Connection-based alghorithms can do SDS, but are biased. And there where Practical Path Guiding for Efficient Light-Transport Simulation by Thomas Müller, Markus Gross, Jan Novák on CGI tech news box thread, which claims to be unbiased and able to do SDS paths, if I get it right.
CPU Bidir + Metropolis | Core i5-4570
User avatar
Mango3
Posts: 32
Joined: Sun Oct 28, 2018 7:09 pm

Re: dark juice

Post by Mango3 »

From what I found: Unbiased Photon Gathering is great, but unable to do SDS paths. Connection-based alghorithms can do SDS, but are biased. And there where Practical Path Guiding for Efficient Light-Transport Simulation by Thomas Müller, Markus Gross, Jan Novák on CGI tech news box thread, which claims to be unbiased and able to do SDS paths, if I get it right.
That is correct what you state.
Some remarks about biased vs. unbiased algorithms. All render engines allow to introduce bias, even for unbiased algorithms. Intensity clamping to avoid fire flies or enforced path length limits are doing just that. One should not confuse it with accuracy. Some biased methods deliver far more accurate solutions than unbiased methods at equal render time. For instance, all photon mapping methods are biased but importantly also consistent. At every stage there is bias in the form of blurring artifacts (due to the density estimation process). But that bias will tend toward zero as render time progresses.

Apart from unbiased photon gathering, Pixar's RenderMan has a unified integrator with these algorithms implemented and selectable.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: dark juice

Post by lacilaci »

This endless requesting of "unbiased" is doing nothing for anyone:
https://www.chaosgroup.com/blog/the-tru ... -rendering

In the end you're rendering polygons, you're using limited path depths for bidir as well, bidir can'd do sds even with metropolis, the moment you use denoiser you're introducing bias and literally a guesswork of a trained denoiser...

We need physically plausible results, consistent, convincing looking and efficient to render. We need flexibility for both artistic and optimization purposes. Even people at next limit allow maxwell render to do dirty tricks like hiding objects from shadow rays or reflections etc because it is simply unacceptable and sometimes impossible to render complex scenes.

Look at corona for example, full of features that allow tricks for optimizations and yet at the same time show me another renderer that can do caustics+sds with such ease? You can't do such things even with bidir and it won't be ever possible until people stop being religious about "unbiased" not even understanding there is no such thing. It's fucking polygons.

Take for example this problem we're having with glass... Normal glass has extremely limited uses in luxcore because it just won't let direct light through.
With this potential feature Dade mentioned you can suddenly use it for everything that is glass and it's a much better and more realistic "fake" than architectural glass... So I don't understand why some people get triggered hearing about features that allow such optimizations.

I would "ban" the word unbiased cause it makes people fanatical :lol:
wasd
Posts: 319
Joined: Tue Apr 24, 2018 7:20 pm

Re: dark juice

Post by wasd »

lacilaci wrote: Mon Aug 19, 2019 4:48 am We need physically plausible results, consistent, convincing looking and efficient to render. We need flexibility for both artistic and optimization purposes. Even people at next limit allow maxwell render to do dirty tricks like hiding objects from shadow rays or reflections etc because it is simply unacceptable and sometimes impossible to render complex scenes.
lacilaci wrote: Mon Aug 19, 2019 4:48 am You can't do such things even with bidir and it won't be ever possible until people stop being religious about "unbiased" not even understanding there is no such thing.
You want fakes and at the same time you don't want fakes. Which is it?
CPU Bidir + Metropolis | Core i5-4570
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: dark juice

Post by lacilaci »

wasd wrote: Mon Aug 19, 2019 10:39 am
lacilaci wrote: Mon Aug 19, 2019 4:48 am We need physically plausible results, consistent, convincing looking and efficient to render. We need flexibility for both artistic and optimization purposes. Even people at next limit allow maxwell render to do dirty tricks like hiding objects from shadow rays or reflections etc because it is simply unacceptable and sometimes impossible to render complex scenes.
lacilaci wrote: Mon Aug 19, 2019 4:48 am You can't do such things even with bidir and it won't be ever possible until people stop being religious about "unbiased" not even understanding there is no such thing.
You want fakes and at the same time you don't want fakes. Which is it?
How did you come to the conclusion that I "don't want fakes" :D
Fox
Posts: 437
Joined: Sat Mar 31, 2018 11:17 am

Re: dark juice

Post by Fox »

Speaking of the dark areas, in juice / hetero volume.
Now my setup with bidirvm is:
startradius 0.05
alpha 0.25
lightpath.count 65536 (note here with 256 to 1024 the caustics are much sharper, but sss effects weaker when radius is small).
Light setup is hdr map with gamma 1 + 2'th copy with gamma 0.8.

There is no question sss is slow and tricky to tune. My render started very biased at radius 0.05, blurry and very bright yellow (even 1 hour in render). First it went brighter, but then slowly it started going darker, now i know i may need to tune material little more.

I don't understand how radius reduction works, it seems not to move along with the passes printed in the bottom of ui.
(0.25 power of 2600) * 0.05 = radius at pass 2600 is close to 0. It's more like the small radius passes don't contribute anything to remove initial bias :roll:

11h, 2600passes, bidirvm, oidn 40% + 60% undenoised
11h, 2600passes, bidirvm, oidn.jpg
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: dark juice

Post by lacilaci »

Fox wrote: Mon Aug 19, 2019 11:37 am Speaking of the dark areas, in juice / hetero volume.
Now my setup with bidirvm is:
startradius 0.05
alpha 0.25
lightpath.count 65536 (note here with 256 to 1024 the caustics are much sharper, but sss effects weaker when radius is small).
Light setup is hdr map with gamma 1 + 2'th copy with gamma 0.8.

There is no question sss is slow and tricky to tune. My render started very biased at radius 0.05, blurry and very bright yellow (even 1 hour in render). First it went brighter, but then slowly it started going darker, now i know i may need to tune material little more.

I don't understand how radius reduction works, it seems not to move along with the passes printed in the bottom of ui.
(0.25 power of 2600) * 0.05 = radius at pass 2600 is close to 0. It's more like the small radius passes don't contribute anything to remove initial bias :roll:

11h, 2600passes, bidirvm, oidn 40% + 60% undenoised
11h, 2600passes, bidirvm, oidn.jpg
You're just torturing luxcore at this point :lol: to properly render this, something like UPBP is needed:
https://rmanwiki.pixar.com/display/REN/PxrUPBP or pathguiding maybe idk.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: dark juice

Post by Sharlybg »

That is correct what you state.
Some remarks about biased vs. unbiased algorithms. All render engines allow to introduce bias, even for unbiased algorithms. Intensity clamping to avoid fire flies or enforced path length limits are doing just that. One should not confuse it with accuracy. Some biased methods deliver far more accurate solutions than unbiased methods at equal render time. For instance, all photon mapping methods are biased but importantly also consistent. At every stage there is bias in the form of blurring artifacts (due to the density estimation process). But that bias will tend toward zero as render time progresses.

Apart from unbiased photon gathering, Pixar's RenderMan has a unified integrator with these algorithms implemented and selectable.
I'm very aware of all that. my bad for poor language.
When i'm talking about biased vs unbiased i'm mostly trying to refer to the way a given code will change user interraction with engine. Most of the time i don't like code that allow to much trickery because they tend to create a culture of cumbersome settings for simple things.

The reason why i don't even try caustic cache. Most of time artist wish are clearly exposed :

___I want my juice to look like real life juice in glass.

___ If a sampler or any kind of thing give that result without hardcoded trickery it is the way to go.

Example :

Dispersion node in cycles :
Image

Dispersion in luxcore :
disper.jpg
disper.jpg (9.3 KiB) Viewed 4191 times
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: dark juice

Post by lacilaci »

Sharlybg wrote: Mon Aug 19, 2019 1:07 pm
That is correct what you state.
Some remarks about biased vs. unbiased algorithms. All render engines allow to introduce bias, even for unbiased algorithms. Intensity clamping to avoid fire flies or enforced path length limits are doing just that. One should not confuse it with accuracy. Some biased methods deliver far more accurate solutions than unbiased methods at equal render time. For instance, all photon mapping methods are biased but importantly also consistent. At every stage there is bias in the form of blurring artifacts (due to the density estimation process). But that bias will tend toward zero as render time progresses.

Apart from unbiased photon gathering, Pixar's RenderMan has a unified integrator with these algorithms implemented and selectable.
I'm very aware of all that. my bad for poor language.
When i'm talking about biased vs unbiased i'm mostly trying to refer to the way a given code will change user interraction with engine. Most of the time i don't like code that allow to much trickery because they tend to create a culture of cumbersome settings for simple things.

The reason why i don't even try caustic cache. Most of time artist wish are clearly exposed :

___I want my juice to look like real life juice in glass.

___ If a sampler or any kind of thing give that result without hardcoded trickery it is the way to go.

Example :

Dispersion node in cycles :
Image

Dispersion in luxcore :

disper.jpg
You're comparing apples to oranges.

What you are showing is not a cycles dispersion node, it's a user made "hack" cause cycles simply allows for some crazy node setups which is actually a big strength of cycles. Cycles isn't able to do spectral rendering on demand like luxcore so someone did this fake trick, on their own. That's it.

When it comes to this "glass issue" every single popular renderer, even "unbiased" ones, allow for hiding certain rays either through rayswitch materials or object property/flags so that you can do fast interiors with thick glass or curtains or artificiall lightging aids etc...

In no renderer it is an inherent default behavior, but a feature that you can use if you need it. And since luxcore now has very little or near no such features, you can easily end up in situation where you cannot optimize rendering or some things cannot even be rendered to look right!
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: dark juice

Post by Sharlybg »

What you are showing is not a cycles dispersion node, it's a user made "hack" cause cycles simply allows for some crazy node setups which is actually a big strength of cycles. Cycles isn't able to do spectral rendering on demand like luxcore so someone did this fake trick, on their own. That's it.
This is what i'm saying (i'm also a cycles user). i know it is User hack (see here :
trickery because they tend to create a culture of cumbersome settings for simple things.
When it comes to this "glass issue" every single popular renderer, even "unbiased" ones, allow for hiding certain rays either through rayswitch materials or object property/flags so that you can do fast interiors with thick glass or curtains or artificiall lightging aids etc...

In no renderer it is an inherent default behavior, but a feature that you can use if you need it. And since luxcore now has very little or near no such features, you can easily end up in situation where you cannot optimize rendering or some things cannot even be rendered to look right!
X do it like this doesn't mean we have copy X blindly. My point is that if this can be made in a more simple a natural way i will always go for it.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
Post Reply