LED strip light problem shining through

I’m having problems with lighting a ceiling with a LED strip. It looks like the light can’t shine trough the small space. I’m using BF+LC and most render settings are at default except I’ve disabled Probabilistic Lights. the LED strip is a polygon object used as Mesh Light. Here is how the light looks in the scene.

And here’s the result:

Increasing the power of the light doesn’t help. The result is just a noisier lighting:

If I render the same scene with Corona instead of Vray, the light has no problems shining through.

Is there a way to fix this?




What if you make it double sided as a test?

Anyway, this sort of thing renders much faster if you use VRayLightmtl with defaults, except tick “compensate camera exposure”. Multiplier between 1.5 and 4 usually work well

Thanks for the suggestions. I tried them but the result is the same.

Shadow bias of 0.02

You mean I should lower the shadow bias? I tried and still no luck. I also set the Cutoff to 0.00. If I hide the L-shaped ceiling profile that hides the LED strip, the light shines normally as can be seen from the region render below:

UPDATE:

I just replaced the mesh light with a regular rectangular vray light. The results are a million times better (and it rendered a lot faster too!):

So the problem seems to come from the mesh light which seems to tie in with another thread I posted here about them. So the question is, are mesh lights not up to par with the other light types? It always seemed to me that they are too tricky, noisy and slow compared to the standard vray lights.

Unfortunately the ceiling is organic shape so I can’t light it with rectangular lights.


If you have a complex setup with a lot of curves, you could use short VRay Plane Lights and clone them along a path

The difference is in how Corona and V-Ray apply their Mar Ray/Sample Intensity.
Corona skips, apparently, the lightMaterial, while V-Ray obeys it.
So it’s useless to raise the light power as it’s clamped by the max ray int.
Raise max ray int to the light multiplier (in scene units, not lumens) or turn it off entirely, and the light will behave as expected.

it’s clamping it correctly, as far as i can tell: the scene he refers to isn’t seeing much in the way of direct lighting from that fixture (which is inset, so most of it is at least one bounce off direct.)

I’m not understanding this part. Can you clarify the steps what exactly I should do?

BTW, Vlado mentioned in another thread of mine that there seems to be problem with the sampling of mesh light. Could this be the problem here?

The issue with mesh lights has to do with something else entirely.

In your case, it’s enough to turn off “Max ray intensity”, like shown here:

notice that because of it, your original setup had the light at REALLY high values, so you may want to recheck those too.

Thanks. Won’t this produce fireflies though that take long to clean? What do you advise, should one disable the max ray intensity parameter and if not, in which cases it should be enabled? It is on by default so I guess there’s a reason behind this?

Not if you set up the scene to be physically plausible, for both lights AND shaders.
Some corner cases will still try to resolve “glints”, or very convoluted, secondary caustic paths, and fail, leaving you with fireflies, but those are few and far apart, as Vlado added a number of optimisations to the sampling.

Of course, if the lights are overbright (in the laser range) and the shaders arbitrarily set up (and with an albedo a couple of times higher than the real life counterparts), energy will be difficult to dissipate, and those issues will be prominent, frequent, and nigh uncleanable.

If, however, one decides to not care about shaders and lights accuracy, and still wants to get rid of that excess energy, there are options, but out of choice they are off, as they tend to severely bias the results: clamping (of secondaries or primaries), sub-pixel mapping, and color mapping tricks (ie. Reinhard highlight/burn value lower than 1, or Corona’s wide gamut), all contribute to reduce fireflies, but will invariably lead to less accurate renders (in fact, i keep max ray intensity off, myself.), moving away from LWF (which i consider a non-optional workflow, personally.).

Hopefully i’m not too far off from publishing the albedo measurements i made with the VRScans, which will serve as a yardstick to verify what real values for textures and shader colours ought to be: that should provide for a few raised eyebrows, as perception of a colour and its real value are VERY different, and often perception exaggerates towards authoring them much brighter than they should be.

There’s an old monster thread lurking in the tips and tricks (sort the forum section by views, it should be the first of non-sticky ones, started in 2007…) about that specifically, as wehn the sun and sky were first introduced, they revealed shading inconsistencies which needed to be cured.
That was wholly eyeballed and absolutely not accurate, but it pointed, even back then, in the right direction.
It only took me ten years to validate those intuitions experimentally…

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”.

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

I’m eager to see your findings about this.

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

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. :wink: ).
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. :slight_smile:
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. :stuck_out_tongue:

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.

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 :smile: )

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 :slight_smile: )

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. :sweat_smile:

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 :slight_smile: )
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. :sweat_smile:
I have yet to see one stupid question in my life: there are only poor answers, in case. :wink:
So keep them coming.