Env. Light Visibility Cache

[Dade]

I'll try to isolate the problem but it crashes with every single production scene I tried without any error and using only 8-15 GB ram out of 32

I need the console log to know at what stage it crashes.

Also rendering region is pretty much useless now as it also crashes blender or throws an error about memory (after it fills it)

This has been explained here: viewtopic.php?f=5&t=1109&start=160#p14794

Also, why this happens?

Just increase the map resolution up to the point fireflies disappear. It happens because a visual map pixel cover multiple pixels of the HDR image and the sun is likely to be just one pixel large in the HDR.

This is a rendering with an HDR like yours and 128x64 maps (too low resolution):

and this with 512x256 (default values):

It has also been explained in my initial post that the best set up is to use a true sun light source + LDR than an HDR alone: viewtopic.php?f=5&t=1109&start=120#p14357 ("Best set up" paragraph). It is also an open scene instead of an interior.

[lacilaci]

shuts down right at the start of rendering (after compilation)

I will try to create an isolated case, probably when working on a new scene so I know for sure what in the scene is possibly broken...?

Not happy about the broken rendering region, hopefuly it can be fixed in the future.

On other hand. It does look like the artifacting is mostly gone, still a bit slower than portals but really much better than single map.

[Dade]

shuts down right at the start of rendering (after compilation)
exception.jpg

I will try to create an isolated case, probably when working on a new scene so I know for sure what in the scene is possibly broken...?

Try to check if it happens only with PATHOCL and not with PATHCPU.

[lacilaci]

shuts down right at the start of rendering (after compilation)
exception.jpg

I will try to create an isolated case, probably when working on a new scene so I know for sure what in the scene is possibly broken...?

Try to check if it happens only with PATHOCL and not with PATHCPU.

Ok so this is what happens on one of the bigger scenes - :
CPU mode crashes, the same as pathOCL+cpu

But when I use pathOCL and disable using cpu, blender freezes, then mouse cursor freezes then sound stops and it stays like that until I hard reset PC

I tried to replicate the crashes with a basic scene and I cannot get it to completely stuck, but this one does crash:

279_luxcore2.blend

(2.53 MiB) Downloaded 207 times

This happens when I add glass in the scene (note that when I added object with glass to new - fully open scene just with hdri, it didn't crash)

EDIT: this one actually does aswell lock up system when I disable cpu in OCL devices. Otherwise just crashes with exception. Both happen at "starting # native threads"

[Sharlybg]

My test On Direct light performance cycles portals vs Luxcore Env__Cache. ALL on CPU i7 4930k (avoid opencl/Cuda Delta performance diference on GPU)

Cycles Direct light set

Luxcore Direct light set

cycles portals 135scs

The attachment CYCLES__PORTAL__185scs.jpg is no longer available

Luxcore Env__Cache 135scs

The attachment LUXCORE__ENVCACHE__185scs.jpg is no longer available

As you can see the two render are pretty close with an edge for Cycles. Luxcore have some kind of black splotches that normally should vanish after longer render time(one isn't going to make render using such kind of condition "direct light" so indirect light will cover the unwanted splotches pretty quickly).

Some Cycles thoughts : I don't know if a dev can comfirm my observation but i always have the feeling while working with cycles that some kind of internal hard coded trick has been used by Devs to boost performance versus Visual quality.You can notice it by the overhall cartoonish looking mood that even realistic cycles render can produce.
It can also be observed in the highlight quality Luxcore produce over cycles.

A precedent of such kind of hard coded trick can be seen some other render engine. This is a statement by a corona dev (ONDRA) about a clash between Fstorm and Corona : https://corona-renderer.com/forum/index ... ic=17760.0

Quote from: Juraj_Talcik on 2017-10-10, 13:04:37

There is something happening differently in how it computes the light that results in more directional look. At the moment, it's not quite clear whether this comes from Direct light, GI (and possible clamp) or whether it's shader related (perhaps through its tweaked BRDF. But it is nonetheless there. I'll wait if one brave souls is willing to post screenshots from comparative tests, but if not, perhaps I might make some in future :- )


Please do tests for us From what we can gather, it clips GI a lot, resulting in direct light-dominated image. Direct lighting is of course more contrasty and dramatic.

BLEND FILE :

Luxcore__VS__Cycles.blend

(2.56 MiB) Downloaded 206 times

Note that to render with cycles you should enable the second layer with portals light

[Dade]

My test On Direct light performance cycles portals vs Luxcore Env__Cache. ALL on CPU i7 4930k (avoid opencl/Cuda Delta performance diference on GPU)

Material roughness has a huge impact on noise and the glossy materials used in Cycles and LuxCore are clearly different, are you using Disney material with the same settings ?

[Sharlybg]

Material roughness has a huge impact on noise and the glossy materials used in Cycles and LuxCore are clearly different, are you using Disney material with the same settings ?

You're right i decide to remake the disney shader look similar and result become closer but cycles still have a tiny edge (Wonder how E-Cycles will do) :

Luxcore__Envcache__185scs

The attachment LUXCORE__ENVCACHE__Disney185scs.jpg is no longer available

Cycles__Portals__185scs

Luxcore__VS__Cycles__disney.blend

(2.59 MiB) Downloaded 200 times

Blend__file

The attachment Luxcore__VS__Cycles__disney.blend is no longer available

For cycles make sure you have the second layer enable and match render time depending of your CPU performance on cycles.

[lacilaci]

Some Cycles thoughts : I don't know if a dev can comfirm my observation but i always have the feeling while working with cycles that some kind of internal hard coded trick has been used by Devs to boost performance versus Visual quality.You can notice it by the overhall cartoonish looking mood that even realistic cycles render can produce.
It can also be observed in the highlight quality Luxcore produce over cycles.

I think it has more to do with luxcore being more realisticaly setup from the get-go (like proper sun and sky power and clamping etc)

To get good gi and lighting contrast in interior in cycles you cannot use default sun and environment values. But that introduces a lot of noise in GI which you then have to compensate with limiting min. bounces and higher samples and in some custom builds you have dithered sobol with distance scrambling controls (e-cycles has also some cuda performance tweaks). Which can greatly boost performance but introduce some bias if used wrongly...

In other words you have to play a little with cycles to get results that are close to luxcore or other renderers.

[FarbigeWelt]

Luxcore__Envcache__185scs
LUXCORE__ENVCACHE__Disney185scs.jpg


Cycles__Portals__185scs
CYCLES__PORTAL__185scs.jpg

How do these pictures look like with 5 to 10 times more render time? How much noise will be gone and how will details (e.g. shadows on the spheres) develop and compare?

[Sharlybg]

How do these pictures look like with 5 to 10 times more render time? How much noise will be gone and how will details (e.g. shadows on the spheres) develop and compare?

Luxcore 270 samples instead of 27:

The attachment Luxcore__270__Envcache.jpg is no longer available

Cycles 640 samples instead of 64: