Variation of brightness during animation

[lighting_freak]

Hi,

I've rendered this object from different perspectives.
The results looks like the light becomes more bright in some frames randomly.
The estimated result ist a constant fall off for the side perspectives, but not such flash light.

This is the belonging blend file:

Brightness_Variation_During_Animation.blend

(2.43 MiB) Downloaded 195 times

Thanks for your help.

BR

[B.Y.O.B.]

Can you upload some of the frames where it occurs (+ one before and one after, for comparison) and does it always happen at the same frames (if yes, which ones exactly)? Or is it random each time you render?

[wasd]

The results looks like the light becomes more bright in some frames randomly.

Try to disable camera volume.

[kintuX]

Hi,

I've rendered this object from different perspectives.
The results looks like the light becomes more bright in some frames randomly.
The estimated result ist a constant fall off for the side perspectives, but not such flash light.

Animation.gif

This is the belonging blend file:
Brightness_Variation_During_Animation.blend

Thanks for your help.

BR

It's precision issue.

Preview


Original gif

The attachment brightess_variation.gif is no longer available

You have Camera Clipping End set too high (1km) causing precision issues. Simply lower it (1m is enough). It'll also render faster

& simply keep in mind - single float precision - safe range is ~ 7 digits (ie. 1 - 1 000 000)

specifically:
"All integers with 6 or fewer significant decimal digits, and any number that can be written as 2n such that n is a whole number from -126 to 127, can be converted into an IEEE 754 floating-point value without loss of precision." - Single-precision floating-point format (wiki)

[CodeHD]

I don't think this is the correct solution. because his camera is 2 meters from the object, so 1m clipping is obviously too short (although I wonder why it still renders then...)

[CodeHD]

I am beginning to think the whole problem you have with this scene might come from the Volumetrics of the AirTo Silicone object. It is only a plane in your case, which could lead to some issues, even though it seems otheriwse correct with the emmiter having its exterior defined as silicone. However, I can't turn it into a consistent result either by changing things...

[kintuX]

Well, visually it works.

I don't know better or why. Didn't took time to optimize & set the scene ideally to 1 BU (it's 0.001 now).
Knowing Blender, this ain't good - units on display are just there as psychological, mental helpers.
Which is why I also have a long lasting doubt about dimensions transformation between Blender & Lux, causing quite a lot of precision issues.
I have no doubts about Lux, but transformational consistency is not something Blender is known for. IIRC there is/was a bug when scaling an object to extremes corrupted the whole scene.

PS
All of the mentioned "solutions" have been tested.

[lighting_freak]

Hello all,

Thanks to all your reply.

Can you upload some of the frames where it occurs (+ one before and one after, for comparison) and does it always happen at the same frames (if yes, which ones exactly)? Or is it random each time you render?

I'm about to rerun the complete animation with a different random seed. It will take until tomorrow to see the result.

Try to disable camera volume

What does happen internally while deactivating the auto detection and simply don't enter anything in that appearing menu? Do all my rays start in silicone then, the light- and eye path?

You have Camera Clipping End set too high (1km)

I thought the camera clipping is for viewport only?

I am beginning to think the whole problem you have with this scene might come from the Volumetrics of the AirTo Silicone object.

Well, using exact volume descriptions is one of USPs of luxcorerender, isn't it? I know that this enlarges calculation time, but my approach is to create most realistic results which means as detailed as possible even in light source.

Which is why I also have a long lasting doubt about dimensions transformation between Blender & Lux, causing quite a lot of precision issues.

Since especially the volume properties (absorption and diffusion) are dependent on the real dimensions this transformation must be done.

Thanks a lot, I'll send my results tomorrow in the morning (CET)

BR

[B.Y.O.B.]

You have Camera Clipping End set too high (1km) causing precision issues. Simply lower it (1m is enough). It'll also render faster

Camera clipping settings should have no impact on precision in LuxCore.
These problems only arise in rasterizers that use a depth buffer with limited precision, with range from near to far clipping plane, for example the OpenGL renderer drawing the Blender viewport. But LuxCore traces rays in world space, not camera space.
Are you sure the effect you observed was caused solely by the clipping settings and not something else?

I don't know better or why. Didn't took time to optimize & set the scene ideally to 1 BU (it's 0.001 now).
Knowing Blender, this ain't good - units on display are just there as psychological, mental helpers.
Which is why I also have a long lasting doubt about dimensions transformation between Blender & Lux, causing quite a lot of precision issues.
I have no doubts about Lux, but transformational consistency is not something Blender is known for. IIRC there is/was a bug when scaling an object to extremes corrupted the whole scene.

I am currently fixing this during the 2.8 port.
For details of my plan see https://github.com/LuxCoreRender/BlendLuxCore/issues/97

What does happen internally while deactivating the auto detection and simply don't enter anything in that appearing menu? Do all my rays start in silicone then, the light- and eye path?

The rays will check if the material they hit has an exterior volume set and use that as their assumed starting volume.

Note: auto-detection of the camera volume is only robust if your volume setup is immaculate (which is sometimes hard to achieve).
It might be better to assign the camera volume manually in an animation.

I thought the camera clipping is for viewport only?

If the checkbox above it is enabled, it is used by Lux. Otherwise, it is used by Blender's OpenGL viewport only, but not by Lux.

[lighting_freak]

Hi,

lighting_freak wrote: ↑ What does happen internally while deactivating the auto detection and simply don't enter anything in that appearing menu? Do all my rays start in silicone then, the light- and eye path?
The rays will check if the material they hit has an exterior volume set and use that as their assumed starting volume.

What will happen to rays that emit from the source while using BiDir?
I mean in my setup are rays that see through the silicone resin and will be set to air or silicone (the exterior is air in that case, but the beam has been emitted in silicone) Further more if an emitted ray hits the LED body first it will be in silicone since this surface is being defined as having exterior volume silicone. In that case I were would have two classes of rays from the the same emitter.

BR