LuxCoreRender Forums

Can there be some cache filtering for reflections?

Wanted to test older scenes wigh gi cache but there is no way I'm going through all materials and deciding if they need to have photongi disabled.
And probably every complex scene will have a ton of glossy materials that won't work with gi caching because of the reflections.

I don't know what vray's retracing does though In a scene like the office I made, pretty much 75-80% of what's on screen is reflective enough that I have to disable photonGI for materials, this leaves at best only walls to be able to use the photonGI and while it does gives some benefit still.. It's just not worth all the work on deciding and testing wether or not I can or can not use photon gi per material.

This is not good as I'd rather take slower solution than have one more thing to worry about that could go wrong. Especially for complex interiors with a ton of stuff, and not mentioning having an database of ready to render assets, that need revisiting in case they need to be used with photonGI.

And one suggestion for blender addon. The lower limit for photon cache settings seems to be 1000. Wouldn't it make sense to have a [number field] and letter "K" behind it? Suggesting this is numer x 1000 so that users don't input numbers like one hundred million ? Or do you think it would look messy in the UI? Maybe just a tooltip that the numbers are in thousands? I just feel silly counting the number of zeroes so that I don't accidentaly use billion of photons

So far my observations (correct me if I don't understand something right please..)

Photon count needs to be much higher than cache size, if they are the same number not much of photon count is gonna end up in cache.
cache size don't have to be big if lookup radius covers enough space, in my tests 20-30cm is just great.
photon depth is extremely low by default, cache looks like trash in parts of scene that rely on heavy gi
lookup max count is also too low and makes cache look terrible, seems like even number of 4096 doesn't impact cache precalc. too much.

so basicaly a high quality and clean cache seems much more important than dense cache.

these settings took 1 sec. of processing and there are no leaks and renders fast! It is a very simple scenario though!
30 sec. of rendering + 1sec preprocess

lacilaci wrote: ↑Sat Feb 09, 2019 6:26 am And one suggestion for blender addon. The lower limit for photon cache settings seems to be 1000. Wouldn't it make sense to have a [number field] and letter "K" behind it? Suggesting this is numer x 1000 so that users don't input numbers like one hundred million ? Or do you think it would look messy in the UI? Maybe just a tooltip that the numbers are in thousands? I just feel silly counting the number of zeroes so that I don't accidentaly use billion of photons

Very good idea!
___

This looks all very encouraging and exciting!
I wanted to do more animations, but maybe I better join in PGI testing, it seems usable now.
Lil' Splotchie has grown up so fast...
I'm somehow confident Dade will figure out a solution for glossy filtering too.

another test, with similar settings.
Small cache, large radius and depth and lookup.

The monkey and the balls are lit up by sunlight reflected off opposing wall, notice it also casts a shadow behind it!
balls are actually using photonGI cache! It kinda works cause cache is mostly clean(no dark spots or small photons) It would still require some sort of filtering for reflection rays.

Just as previous test it looks like cleaner cache is much more important than small and dense photons. It is also faster as big cache seems to render slower

I would try higher photon depth but it caps at 64

I seem to have problems with large spaces, like the office where I need to use huge lookup radius(2m) which slows down rendering a LOT.
Or insane amount of photons to fill the space up.
Seems that larger photon depth helps with this. Is there a reason for max 64?
EDIT: actually no, in larger scene lower photon depth is better... wtf

Made my own test scene now and it looks promising.
With a large cache rendering gets memory constrained and slows down. This should get better on GPUs with faster VRAM.

path v cache ^

I think some good stresstest would be
Skylight only (or with sun)
Large space with several openings
filled with random objects some matte, some glossy, metal, and glass.

I got good performance and results from all test scenes.
But no good results from my "first steps" and "office" project as both scenes couldn't fill the scene with enough photons no matter what.

Will try to create some stresstest scene if I find time.

Sometimes in my experiments, i have a fireflies.

zuljin3d wrote: ↑Sat Feb 09, 2019 10:31 am Sometimes in my experiments, i have a fireflies.

Try to enable caustic cache, you have specular surfaces so you can have caustics. Otherwise just use variance clamping and/or denoiser to keep them under control as with normal path tracing.

lacilaci wrote: ↑Sat Feb 09, 2019 6:26 am I don't know what vray's retracing does though

I have the strong feeling V-Ray "retrace" is my fall back to normal path tracing solution. I use a comparison between ray length and cache look up radius, they may use the provided user parameter instead but I have the feeling it is the same trick.