PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Speed without Cache

Post by 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

Image

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.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by 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 :| :arrow:
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: PhotonGI cache

Post by FarbigeWelt »

:ugeek:
Dade wrote: Thu Sep 03, 2020 10:55 am
FarbigeWelt wrote: Thu Sep 03, 2020 8:17 am 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.).
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg »

Dade wrote: Sun Aug 30, 2020 5:39 pm 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 ;)
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: PhotonGI cache

Post by 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 (?).
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

kintuX wrote: Mon Jun 07, 2021 11:48 pm 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.
Support LuxCoreRender project with salts and bounties
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: PhotonGI cache

Post by kintuX »

Dade wrote: Tue Jun 08, 2021 12:01 am
kintuX wrote: Mon Jun 07, 2021 11:48 pm 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.
pool_tester_SDS-LXC2.6(BiDir-VS-PT).png

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.
8-) Thank you.
Last edited by kintuX on Tue Jun 08, 2021 11:28 am, edited 1 time in total.
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI cache

Post by 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
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: PhotonGI cache

Post by kintuX »

B.Y.O.B. wrote: Tue Jun 08, 2021 11:28 am 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.
B.Y.O.B. wrote: Tue Jun 08, 2021 11:28 am 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).
B.Y.O.B. wrote: Tue Jun 08, 2021 11:28 am 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.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

kintuX wrote: Tue Jun 08, 2021 11:20 am 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.
Support LuxCoreRender project with salts and bounties
Post Reply