PhotonGI cache

[Sharlybg]

There is good reasons why i'm still talking about that thing.

1__ It is good
2__ There is good interest from many artists to switch to Luxcore from big rendering names ( Redshift , Vray , Corona , E_cycles ...)
3__ Competition level increase With Eeevee now closing the gap to Cycles (Eeeve SSGI https://youtu.be/0_yJHuDACOQ )
Cycles being boosted with E_cycles.
4__ Animation is becoming a standard like 4k resolution requiring more computation power.
5__ raytracing is going in the realtime direction ( as opposed to offline)
6__ Cache-less solution are compatible with PGI wich mean exponential speed up
7__ there Should be a Strong performance difference for someone to completelly switch to a new renderer ( Reshading hundreds assets / shader library )
8__ We can't rely on the super power of PGi everywhere ( all animation with motion light/object).

Solution

Dade already explain why it isn't worth the effort to implement something that can't benefit GPU acceleration (GPU is the present/futur of rendering). And i believe that too. So after some research i found something we already talk about during PGI development phase.

Adjoint-driven Russian roulette sampling



There is a paper about that : https://cgg.mff.cuni.cz/~jaroslav/paper ... /index.htm
A video here : https://youtu.be/Kzey1d4Bl40
And it should be compatible with GPU requirement ( we are not forced to add the path guiding component wich is in reality a seperate method)

If there is an issue with this one correct me please.

[Sharlybg]

A bit confused after in deph reading
Look like Adjoint driven russian roulette splitting == photon Gi cahe
Is that true or i'm again in the clouds

[FarbigeWelt]

On nvidia‘s graphic transfer rate from RAM to VRAM is 14 GB/s. This is 32 times less than VRAM to GPU cache.

The slide is about CPU/SSD/etc. (any device attached to the PCIe bus) to GPU ram transfer rate. It can have a huge impact on some application.

In our case, it could highly increase the speed of "out of core" rendering.

In this case new SSD types like e.g.
Sabrant Rocket-4 could accelerate data transfers from large storage carriers to nvidia card‘s VRAM. I wonder if transfer rate could be increased of linked SSD if two of them are combined with RAID 0. The latter lead to about 14 GB/s.
How amazing if Textures, Mega polygons objects and generated pseudo Random number data streams found their way within fractions of a second to GPU caches/registers from deca+ cores CPU systems getting processed massive parallel on GPU shaders‘ units.

A nicely rendered 3D scene baked on its objects should impressively be real time. If there were any tricks to ray trace render moving or changing objects in the scene separately dependent on depth z and virtual z (bounced) computations could be saved and whole scene might be displayed UHD @ 60+ Hz, 10 bit.

Summary
Pre-rendered scenes combined with realtime active objects could lead soon to UHD games on average hardware based on soon common direct data transfer from fast storages or ram to vram (UHD games are actually what Microsoft and Sony claim for their next Gen consoles. At least Sony‘s memory concept for the PS5 on AMD silicon seems to point exactly in this direction.).

[Sharlybg]

I'm playing with this idea of having an RTX accelerated PhotonGI rendering. I'm not sure if I can pull it but it should be possible. I will check after I finished a couple of pending stuff.

Hi Dade ! do you have some side working build about that one ? i have found a method to use cache even object and light are moving and some speed up can really open door for more advanced animation (with cleaner sharper result).

My idea is to compute and save cache with only static object/light then the animation is done with all moving/animated item using pre saved cache.
It seem to work without flickering so i want to go deeper with it

[kintuX]

IDK, if it's been asked already or I have missed it, but is there a possibility to get a simple Indirect cache intensity (or exposure) multiplier?
I've noticed that Path engine tends to have darker interiors even with this enabled compared to BiDir no matter how many paths, bounces or photons there are.
Also I think it would be very beneficial for user, if by simply setting "Indirect Light Cache" brighter final image would render more pleasing to user's demand, closer to BiDir engine and most likely faster (?).

[Dade]

I've noticed that Path engine tends to have darker interiors even with this enabled compared to BiDir no matter how many paths, bounces or photons there are.

PGI has a specific max. bounces setting because it traces from light sources not from the camera. It is similar to BiDir. I have the feeling you have increased only the camera/eye max. bounces and not the light photon max. bounces

The default max. bounces for PGI is 4 and it is quite small compared to BiDir default.

[kintuX]

I've noticed that Path engine tends to have darker interiors even with this enabled compared to BiDir no matter how many paths, bounces or photons there are.

PGI has a specific max. bounces setting because it traces from light sources not from the camera. It is similar to BiDir. I have the feeling you have increased only the camera/eye max. bounces and not the light photon max. bounces

The default max. bounces for PGI is 4 and it is quite small compared to BiDir default.

Tested and it didn't show much difference.
But I realized what the issue was/is. Basically I was checking BiDir with newly added caustics cahe (SDS paths) on "pool tester scene" where discrapency showed. I found it is caused by single scatter Specular material. And of course BiDir engine shows it brighter since it traces both ways. To compensate that in Path engine I had to make shadows 2/3 transparent, but then BiDir also renders way brighter, so I guess until there's no multiscatter for Specular materials (glass, mirror, metal) results between BiDir & Path won't match.

Still, an Indirect Light Cache multiplier would come in handy. (In same way as does Exposure Value
Also then, Indirect Light Cache available for BiDir would make renders less noisy/faster.

PS:
This scene, using just CPU, already performs better with LuxCore PT 2.6 than with Corona 7.
Thank you.

[B.Y.O.B.]

I am against such a multiplier. Raising it above 1 sounds like it could easily break energy conservation without the user realizing it. Also, if there is a multiplier for indirect light, it should behave consistently between all render engines, and not just affect the PhotonGI cache - and this would mean it becomes very complicated.

If there are problems with certain situations rendering incorrectly, those problems should be fixed in the existing algorithms or new algorithms should be added to solve them. But it is not a good idea to tack on little hacks everywhere.

I do not think the benefits outweigh the negatives.

[kintuX]

I am against such a multiplier. Raising it above 1 sounds like it could easily break energy conservation without the user realizing it.

Basic user wouldn't even use it, unless it becomes necessary to brighten interior's GI. And that's already an advanced skill even for photographers. It only ads benefits for an advanced use.

Also, if there is a multiplier for indirect light, it should behave consistently between all render engines, and not just affect the PhotonGI cache - and this would mean it becomes very complicated.

If PhotonGI cache (Indirect Light) as is, is added to BiDir, then it shouldn't behave differently, but same as in Path... do note, there's already a discrepancy between engines w/o it, so nothing new is brought to the table (but less noise).

I do not think the benefits outweigh the negatives.

IMHO, as a mere occasional user/tester there are no negatives just positives (especially when compared to Corona), but fair enough, I respect your take on it.
Stay well.

[Dade]

But I realized what the issue was/is. Basically I was checking BiDir with newly added caustics cahe (SDS paths) on "pool tester scene" where discrapency showed. I found it is caused by single scatter Specular material. And of course BiDir engine shows it brighter since it traces both ways.

I'm not sure to understand what you mean with "single scatter Specular material": something like mirror (single scatter) Vs. glass (2x scatter, reflect and transmit) ?

Anyway it sounds like a bug in BiDir with some very specific type of path being rendered 2 times, I have to check.