LED strip light problem shining through

[^Lele^]

I'm trying whenever I can. Sometimes though I need to exaggerate a bit to accomplish some artistic affect and I guess this throws off the physical correctness.
I'm finding this too. Extreme and unrealistic values are indeed problematic to compute and produce "defects".

That's the general issue, in fact.
It stems from trying to achieve non-physical results from within a Physically based "sandbox" (Which we'll call, for simplicty, V-Ray. ).
It would be analogous, in photographic terms, to trying to alter reality before taking the picture, so to exceed the capabilities of the camera.
While it's dead obvious that it's not a task one would achieve all too well when picturing wildlife, or natural landscapes (even in studio settings, there are quite precise limits: you'd rather not light your subject with a gigawatt laser...), in CG there is a lot more latitude available.
Stress on "available": it's not there because it HAS to be used, but rather because it CAN be (blame engineers writing software and having fun at it! Ups. ^^).
In the real world, one sets a capture up as best as one can, and all of the artistic latitude, and vagaries, and added taste and value, are added AFTER the picture has been taken, in the development and print stages.
I still fondly remember my enlarger and my endless attempts at varying exposure on the film while moving my cupped hands around the lightbulb, so to beam light just where i needed, a long, long time ago.
Today, we call all of that "Post", and we have a number of tools available (what i did above was, technically, MASKING, go figure.) to facilitate the task.
In the viz world it's often overlooked, or thought of as too complex, or a step too many, or belonging to VFX.
I beg to differ: if you look at VERY old posts on the forum, you will find people were loving "S-Curves" in photoshop (not that different from Filmic tonemapping, for shape and results. It was just the buzzword of the time for selective contrast across an image brightness domain.), and getting very pleasant results out of what was essentially, even back then, a (near!) realtime post session.
Today, with the amount and power of free compositing software (Fusion, to name one. and there are more), i find unthinkable to not tap into all that goodness, especially as the concepts, for most of the usual image manipulation tasks, are very simple, and quite easy to learn in any package.

TL, DR: Don't try to change reality before taking a picture: change the picture instead.

Can you kindly expand on this? Why do you move away from LWF? You've piqued my interest now.

All linear workflow does is to ensure that whatever value you insert in your DCC app UI will be exactly reproduced by the render.
For example, max ray intensity is a form of bias, which however becomes apparent only after the set value is reached: any (secondary) intensity value above the one set in there will be clamped to it.
You will, as such, not notice any difference as long as your (bounced) lighting is dim, but as you experienced in the scene in question, it becomes impossible to get strong bounce lighting if that's active.
That, in effect, breaks the linearity between how intense you set a light, and how intense the renderer is allowed to represent it.
The same, if in slightly different fashion, happens with the other methods i cited above: your graph, after all the gammas and inverse gammas are applied, will not be linear, and somewhere something will break.
Rendering you image in LWF, and then moving it (with assorted render elements) to Post will however allow you much the same results, but without the need for a rerender, and most of all it won't send you to an Asylum trying to make the render do what -in effects- you instructed it not to.

I'm eager to see your findings about this.

That's two of us: the new VRScans are a LOT, and i only peeked at a few of the results (for example a SNOW-white cloth with at best 70% reflectivity, or rubber with less than 10% reflectivity at grazing angles, and so on).
Soon, now.
I am the only limiting factor, as of this afternoon. :P

Interesting, never knew this was the case with initial implementation of sun & sky.

It wasn't so much the sun and sky's fault, back then (2005 or thereabout, gosh.).
It was the fact that we all came from lighting with low-intensity fixtures some overbright shaders.
The sun intensity being around 300 float at midday exacerbated the limits of that heritage workflow, and prompted a change of approach.

[Alex_M]

Ah, thanks for the thorough explanation, Lele. You've always got something interesting to say. (albeit somestimes doing it in such a long-winded fashion that I lose your train of thought and have to re-read something twice )

I'm still not sure what you meant to say about LWF. Do you propose that ideally we shouldn't be using gamma 2.2 in Max? Can you please "dumb it down" a bit for people like me. (sometimes I'm a bit "slow", haha )

And since you're the expert, here's a question. Isn't using a gamma curve a sort of cheating to light the dark areas in a render without having to compute many light bounces and shoot a lot of rays? Isn't the ideal case to use gamma 1.0 and let the renderer trace the necessary amount of bounces in order to light the surfaces further away from the light source? So to summarize, isn't it possible to work in gamma of 1.0 and just have the lights produce the nice falloff that we get with gamma 2.2? Sorry if my question is stupid.

[^Lele^]

(albeit somestimes doing it in such a long-winded fashion that I lose your train of thought and have to re-read something twice )

Ahah, that makes two of us, more ofthen than not. ^^

I'm still not sure what you meant to say about LWF. Do you propose that ideally we shouldn't be using gamma 2.2 in Max? Can you please "dumb it down" a bit for people like me. (sometimes I'm a bit "slow", haha )
And since you're the expert, here's a question. Isn't using a gamma curve a sort of cheating to light the dark areas in a render without having to compute many light bounces and shoot a lot of rays? Isn't the ideal case to use gamma 1.0 and let the renderer trace the necessary amount of bounces in order to light the surfaces further away from the light source? So to summarize, isn't it possible to work in gamma of 1.0 and just have the lights produce the nice falloff that we get with gamma 2.2?

The fault is partially with the data, out there in the wild.
It's REALLY easy (image shamelessly ripped off the first google result for "gamma correction").


That above is Linear Workflow in a nutshell: your monitor has a skew (called Gamma) due to historical and technical limitations, and we coded that (and a few other things besides) as a standard, sRGB, so sucky as the monitors may be in not expressing values linearly, at least they'd all suck in the same way, and we could correct that issue elsewhere, always in the same way (that's often also the definition of a standard.).
That's the bottom, red, solid line: it can't be changed, other than with mis-calibration out of the sRGB standard, so let's assume that as the one issue we do not have to deal with: our monitor is properly calibrated.
The gray line in the middle, is how computers (and V-Ray, and Post software worth its name) use data: 0.5 is twice 0.25, and four times 0.125, and so on.
But because of said Monitors' behaviour, what we see, isn't what we would want: 0.5 is shown to be a much lower value, when displayed, of 0.218.
So, we have to compensate for that issue, and we do so with an inverse Gamma: the top, dotted, red curve.
We'd like to have it all straight and neat, but we don't (monitors), and we have to correct.

Max Ray intensity, baked Colormapping tricks (Reinhard with lower than 1.0 burn) Corona's wide gamut, act on the GRAY line: they stop the renderer from using the line as a straight one in the first place (albeit, like for max ray int., only after the set value).
They are REALLY bad ideas, because what happens to the gray line is then completely unknown to the user, and there is no easy, or none at all, way back from that.

The Max gamma settings act on the red dotted line, and should stay at 2.2, as one can assume you're using the sRGB standard, and it's for that one you want to compensate.

Any POST will act on the same curve: you left the renderer act linearly, and after it all, you can skew and tweak as much as you please, but you always have a chance to revert those changes, without re-rendering.

Finito. ^^

Sorry if my question is stupid.

I have yet to see one stupid question in my life: there are only poor answers, in case.
So keep them coming.