Variation of brightness during animation

[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 we would have two classes of rays from the the same emitter.

BR

[lighting_freak]

Hi all,

this are the proposed results.
Doing simply the same renderings with a different random seed leads to this:
- still strange bright/dark variations
- which frame is bright and which is dark changes
- noise pattern vary (as expected)

This are the first 9 frames as single images as comparision.
They are ordered in the same way:

This are the belonging animations

Also disableing the camera volume doesn't resolve the issue:

BR

[kintuX]

Further observations:

- Again & again... "Camera Clipping" smaller range (up to the distance when object "really" became visible) felt, looked, computed better & much faster! As if camera transformation was somewhat wrong or broken. Also, there's no flickering during animation.

- Giving PMMAs different Volume Priorities changed their behaviour:

Front plate with Lower or Equal Priority

Front plate with Higher Priority

- Made a Maxwell~Render to get "second opinion".

All this felt like precision issue caused by some minor inconsistency, which i wasn't able to figure out. The main suspect was the camera. But even newly made showed same symptoms. So i sanitized the scene: Unit Scale set to 1, added World Volume Air @ STP where needed, checked & un-triangulated geometry, replaced Edge Split Modifiers by setting Normals, set Camera Focal length to 100mm & Sensor Size to 22mm (to better fit the frame) .

Rendering with 500 Samples + OIDN turned out as following:

Path w/ Light Tracing (video @ streamable)

BiDir (video @ streamable)

Modified Scene

Brightness_Variation_During_Animations.blend

(2.3 MiB) Downloaded 187 times

[lighting_freak]

Hi,

I've tested the scene with disabled camera clipping.

The result seems to be the same:

Again the belonging *.blend file with it's settings:

Brightness_Variation_During_Animation3.blend

(2.43 MiB) Downloaded 176 times

Changing the material settings is not an option for me - finally the real part will be made from this material with it's properties.
The issue seems to remain!

BR

[wasd]

Hello all,

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?

I don't know, but if you don't disable camera volume something like this may happen:
viewtopic.php?f=4&t=1160
viewtopic.php?f=4&t=805&p=8899#p8899

[lighting_freak]

Hi,

I don't know, but if you don't disable camera volume something like this may happen:

Thanks for this links.
It doesn't really explain why that happens, does it?
Since everthing I do is CPU based, all GPU driver related issues can be denied.
Toying around with the camera volume may lead to results in some cases (not in mine) seems to be illogical.

I've finished the last investigation that was recommended - so I've simplified the light source a lot.
Now its a plain emitter face per LED that directly emits into air. The result looks the same:

Brightness_Variation_During_Animation4.blend

(2.44 MiB) Downloaded 171 times

I've also created a little video with the different animations in direct comparision.
You see the flashing happens on different frames.

Comp.zip

(2.78 MiB) Downloaded 178 times

Could it be that there might be a bug in linear tone mapping somehow.
Since I'm using this results as HDR sources that will be combined in a postprocessing step usually I'm forced to use the EXR output.
Does that create some of those issues?

Thanks a lot.

[B.Y.O.B.]

Hm, have you tried rendering these frames until they are fully converged (noise-free)? Could the problem be caused by having not enough samples?

[lighting_freak]

Hi,

this is the result with half resultion and doubled samples:

The overall quality should is raised regarding noise - but the problem remain!

BR

[FarbigeWelt]

Hi,

this is the result with half resultion and doubled samples:

ncnvbxpa.gif

The overall quality should is raised regarding noise - but the problem remain!

BR

You said, render on CPU only. Is it BiDir? Do you use Metropolis? Have you tried Random? Avoid Sobol in your case.

[lighting_freak]

Hi,

You said, render on CPU only. Is it BiDir? Do you use Metropolis? Have you tried Random? Avoid Sobol in your case.

Yes, it's BiDir and it's always Metropolis... I'll try random but I'm afraid it wouldn't change anything.
Additionally I'll try rendering without lux tonemapping - I'll postprocess those images later (hope in blender composter helps).

By the way; does anybody know a tool that allows me to read the stored luminance from an exr file.
I'd like to check the values behind my input images. Thanks in advance.

BR