LED strip light problem shining through

[Alex_M]

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?

[Morne]

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

[Alex_M]

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

[Morne]

Shadow bias of 0.02

[Alex_M]

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.

[Morne]

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

[^Lele^]

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.

[LudvikKoutny]

It's worth noting that LightMTL in Corona is by default explicitly sampled light source, like regular CoronaLight, therefore it doesn't get clamped by MSI. LightMTL in V-Ray on the other side, is just self illuminated mesh sampled by GI only. To get identical result, you would have to enable "Direct illumination" checkbox in VrayLightMTL.

Do I understand it correctly that even with Direct illumination enabled, V-Ray will still clamp VrayLightMTL's illumination as long as MRI is on? To achieve same thing as VrayLightMTL with Direct Illumination off, you would have to use regular CoronaMTL with self-illumination enabled. Then, Corona applies MSI to it in the same way V-Ray does.

[^Lele^]

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

[LudvikKoutny]

Ah, makes sense. Thanks.

[Alex_M]

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.

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?

[^Lele^]

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:

https://docs.chaosgroup.com/display/...cingParameters

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

[Alex_M]

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?

[^Lele^]

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

[Alex_M]

Not if you set up the scene to be physically plausible, for both lights AND shaders.

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.

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.

I'm finding this too. Extreme and unrealistic values are indeed problematic to compute and produce "defects".

...moving away from LWF (which i consider a non-optional workflow, personally.).

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

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.

I'm eager to see your findings about this.

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

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