animation settings

[epilectrolytics]

Please do not replace emitter objects with different kinds of lights, try to keep it as it.

BlendLuxCore warning:

Code: Select all

The scene contains a lot of light sources (1111), performance might suffer (each triangle of a meshlight counts as a separate light)

I don't know how light tracing actually works but it might be the case that trying to to render 1111 emitting triangles in 128 samples, even with direct light sampling cache, is impossible because every time another random subset is used.
I tried with BiDir and 128 samples and also PathOCL with all caches and 640 samples but couldn't get rid of the flicker (edit: with 2048 samples on GPU it is stable).

There is a BakeCPU engine in LuxCore that probably would be able to deal with such a setting, by baking caustics of many lights into diffuse emission materials and rendering later reflections only the result should theoretically be stable when animated, given the lighting does not change.
But BakeCPU is not accessible from Blender so that I cannot test it.

[daros]

Hi epilectrolytics, thanks for the tests and feedback!
We are testing the bake tools and we are progressing. One question: once we have the baked scene how do we can render it fast on luxcore? i mean how do we disable GI to save time and raytrace only transaprencies and reflections? Or is this supposed to be used only in external rendering engines?

[epilectrolytics]

As I said, I cannot test it since the current LuxCoreUI doesn't work on my Mac.

I can only quote what was said in the link I posted above:

5) once you have all maps, you can load "render-bakedallobjects.cfg" in luxcoreui to do the rendering with the created bake maps (i.e. with only one ray per sample).

Sorry for being of no help here, someone else needs to answer your question, maybe @CodeHD knows about it?

[daros]

Thanks epilectrolytics, let's see.

[CodeHD]

I don't have experience with the BakeCPU engine yet either, so unfortunately I can't give any specific advice on this topic.

[daros]

Hi, at the end we opted for a different solution to produce animations. Our requirement is to a achieve zero-set-up solution.
Precaluclated GI caching and so on need to much scene dependant tweaking while metropolis is too slow, GI baking is impossible on complex scenes.
So the we opted for an metropolis+AI solution for animations. We render one each 10 frames using bidir and interpolate the sequence using Dain Ncnn or IrfNet. In most scenes it gives us the highest quality and perfectly smooth and and flicker free animations while keeping 2k frames aroud 1 minute. I show you some results today or tomorrow.
But some scenes behave in wired way even under metropolis. In the following scene some frames show up much brighter as others! I was not expecting this from Metropolis...
Any idea what it could be?

Mp4
https://drive.google.com/file/d/1iZutWe ... drive_link

Sequence
https://drive.google.com/file/d/13-Zj6q ... drive_link

this are our metropolis settings:

light.maxdepth 64
path.maxdepth 128
sampler.metropolis.maxconsecutivereject 512
renderengine.type "BIDIRCPU"
sampler.type "METROPOLIS"
film.filter.type "NONE"
lightstrategy.type "POWER"
sampler.metropolis.largesteprate 0.4
sampler.metropolis.imagemutationrate 0.10000000000000001
film.filter.width 1.5
film.opencl.enable 0
path.forceblackbackground.enable 0
filesaver.renderengine.type "BIDIRCPU"
filesaver.format "TXT"
path.clamping.variance.maxvalue 2000000000000000000
scene.epsilon.min 0.00001
scene.epsilon.max 0.1
path.albedospecular.type "REFLECT_TRANSMIT"
path.albedospecular.glossinessthreshold 0.05

[FarbigeWelt]

So the we opted for an metropolis+AI solution for animations. We render one each 10 frames using bidir and interpolate the sequence using Dain Ncnn or IrfNet. In most scenes it gives us the highest quality and perfectly smooth and and flicker free animations while keeping 2k frames aroud 1 minute..
..
I was not expecting this from Metropolis...
Any idea what it could be?
..
this are our metropolis settings:

light.maxdepth 64
path.maxdepth 128
sampler.metropolis.maxconsecutivereject 512
..
lightstrategy.type "POWER"
..
film.filter.width 1.5
..
path.clamping.variance.maxvalue 2000000000000000000
..

What is your reason for different max depths?
Actually values around the default value 10 is enough.
For scenes with lots of glasses and mirrors or materials with specular or diffuse value about 80% or higher, large max depths make sense. You most probably know well.

Why do you use film filter? No filter may show better results with AI frame interpolation ..

Did you try different light strategy besides power too?

Lower path clamping should lead to lower noise.


You may find some good tips regarding resolving Metropolis temporal issues in this paper here:
https://www.mathematik.uni-marburg.de/~ ... opolis.pdf

[daros]

Hi Farbige welt, yes we use high ray depth values in order get even the most complex scenes right. Our users are not aware of render related issues so we want to give them a zero settings solution. For static rederings Bidir as we have it, works well.

LOG_POWER changes completely the lighting:
https://drive.google.com/file/d/1xIVhFV ... drive_link

Bidir with caustics photon GI enabled is almost identical to BIDIR only:
https://drive.google.com/file/d/1MJ0IVQ ... drive_link

Photon GI for diffuse and caustics is decent but i have to git rid of those persistent fireflies
https://drive.google.com/file/d/1x8antY ... drive_link

There are two types of fireflies here i belive: one i think has to do with the photon GI settings while the other with the clamping.

If i try to reduce them by reducing clamping the lighting is afftected too much:

Clamping 200000

Clamping 20000

It is probably better to eliminate those fireflies in a postproduction pass. No idea how to get rid off the caustics sploches since caustic GI already has 10.000.000 photons.

Still the most interesting solution would be to get bidir right but do not understand why two adiacent frames can have such a huge difference in luminance like in my animations. Bidir should be precise.

[daros]

the following frames have only a few mm camera translation but still the brightness variance is enourmous. BIDIR renderer

[daros]

It seems the fault of the brightness variations is to address to the metropolis sampler. Metropolis delivers frames with much less fireflies but with larger lighting discrepancies between frame and frame. If i use the random sampler this problem vanishes but the image starts to be full of fireflies.
So now i have to understand if there is a way to make metropolis converge without those huge lighting variations.