The image should explain the problem quite good:



Both scenes rendered with same tonemapping: Camera!
Very interesting is the bright specular reflections on the top of the glass!!!!
MLT + BiDir was used for both renderings.



here are both materials:

Basic jam


SSS jam

Could it be that SSS creates more engery loss in the light rays, resulting in a darker image? Instead of just plain absorption and reflections?

its on you to answer this.... I'm not a employee of Glare

This also was reported multiple times yet, the last one I remember was with meelis' blood material (see the comments)
Ono...?
Oh and btw, what about this bug, maybe this is related?

Nice list of links spidey

I remember about this issue being mentioned...
But as nothing happened since this time and I just had a "proof of bug scenario" here, I posted it
I hope this one here will find its way into the bugtracker now -.-

I wonder, is the SSS version lighter with ray nudge -4 if u used default -5 before.
Because image gets brighter the more u render, and i just noticed it's bad to use -6 for specular because i just cant see other objects through it, even after 50 hours. But using default ray nudge i can see through and the image brightness increases with larger steps.

Soo if it's time u need and SSS slows it down then even if image doesn't look noisy u can see there aint made soo mutch work on it.

Just a note: ray nudge distance can not be negative, and default applies because wrong values can MESS with renders.

This said Meelis you mentioned one possible explanation for this "bug", let me explain how I understand this. I want to be corrected by experts but there's some logic behind the reasoning.

You said that scenes were going brighter while converging; this is always true because more light as been cast. Now, what is SSS doing in the scene ? Basically, each ray entering the medium can bounce into the material an arbitrary number of times.

In that case of internal scattering, obviously each computation is not contributing to the scene lighting, and that's correct in regard with a finite computing power, as opposed to in reality. Furthermore, each bounce weakens the ray.

Non uniform SSS is the slowest to render and you know that already

Does that make sense ?

This is somewhat comparable with how Oren-Nayar is looking darker with higher sigma, because energy distribution has changed over the surface; with SSS, energy distribution is changed over the scene*.

As Meelis suggested it should converge as expected, it's not a bug but the result of a finite computing power Acting on this would induce some bias/issues for sure.

e: Best work-around I think: compensate paths not contributing to the scene lighting with film sensivity.

* in unbiased renderers, when you change one material you are changing the energy balance of the whole scene.

My bad, i shortened from the x 10^-5
For me, CTZn explanation seems correct.

i'm not sure if this is a bug. like soup said: due to the sss, more light gets absorbed.

so if I put a big pot of Strawberry Jam in a room photos of it get darker and also light get dimmer...
You telling me that SSS in Indigo has the same characteristics like a black hole?

compared to RL this is a Bug for sure!

Maybe light loves too mutch Strawberry Jam.
How about dewberry jam.

Hm but compared to RL you have inf. spp there...
Try and let your image render to eternity (see CTZn explanation), eventually it will come out the same brightness then? ( )

no it shouldn't... the sss material absorbs here ~15% of the light... also sample count drops.
With more agressive SSS settings sample count goes down to some few hundreds and image gets nearly black.

SSS has a black hole feature

It's not only black hole.
metropolis, bidirectional, camera, aperture diffraction


Test it:----->

<?xml version="1.0" encoding="utf-8" ?>
<scenedata>
<medium>
<name>Device</name>
<precedence>1</precedence>
<basic>
<ior>2.44947</ior>
<cauchy_b_coeff>0.1</cauchy_b_coeff>
<absorption_coefficient_spectrum>
<regular_tabulated>
<start_wavelength>3.5201e-007</start_wavelength>
<end_wavelength>7.4587e-007</end_wavelength>
<num_values>18</num_values>
<values>4.6923 4.6733 4.661 4.6541 4.6453 4.6332 4.6204 4.6075 4.5951 4.5834 4.5728 4.5631 4.5539 4.5447 4.535 4.5244 4.5126 4.5004</values>
</regular_tabulated>
</absorption_coefficient_spectrum>
<subsurface_scattering>
<scattering_coefficient_spectrum>
<uniform>
<value>10</value>
</uniform>
</scattering_coefficient_spectrum>
<phase_function>
<henyey_greenstein>
<g_spectrum>
<uniform>
<value>0.9</value>
</uniform>
</g_spectrum>
</henyey_greenstein>
</phase_function>
</subsurface_scattering>
</basic>
</medium>
<material>
<name>Device</name>
<specular>
<internal_medium_name>Device</internal_medium_name>
<transparent>true</transparent>
<layer>0</layer>
</specular>
</material>
</scenedata>

Interesting. It may be due to MLT initialisation struggling on the trickier case of SSS, and estimating the average path luminance incorrectly.