Added the support for a new material property to enable/disable PhotonGI on a specific surface. Updated the first post with the property description.
Mostly useful for glossy nearly specular surfaces as explained here: viewtopic.php?f=5&t=840&start=30#p8885
PhotonGI cache
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Re: PhotonGI cache
The development is so fast I cannot keep up testing
ATM tweaking photon counts and the other parameters is quite tricky.
Will it be possible to automate them like adaptive/progressive photon mapping that stops when density is sufficient?
Also lookup.maxcount/radius/normalangle are difficult to estimate.
Do we need to become experts for those or will they work automatically "under the hood" later?
ATM tweaking photon counts and the other parameters is quite tricky.
Will it be possible to automate them like adaptive/progressive photon mapping that stops when density is sufficient?
Also lookup.maxcount/radius/normalangle are difficult to estimate.
Do we need to become experts for those or will they work automatically "under the hood" later?
Re: PhotonGI cache
Added a new property ("path.photongi.debug.type") to force the direct visualization of one of the cache. It helps to establish if a cache is "good enough".
For instance, not enough photons:
Good enough:
Updated the first post with this information.
For instance, not enough photons:
Good enough:
Updated the first post with this information.
Re: PhotonGI cache
Is it possible to show this while the cache is building, then switch to normal film mode when the render starts?
Re: PhotonGI cache
You mean, like showing it as visual progress of building the photon map before rendering starts? (like when vray shows previz when building lightcache)
Re: PhotonGI cache
It would have an (high) cost because I would have to trace (useless for photon mapping) eye rays to give the feedback.
I can move the cache creation from the pre-processing stage to the rendering with the benefits that the rendering can be stopped while pre-processing can not. If I do this, it should be possible to offer some feedback but it will look like a LIGHTCPU rendering:
Each traced photon will light up a single pixel, not a multiple "splotches" like in:
After, the caches creation is done, the film is reset and the normal rendering starts.
Re: PhotonGI cache
I think the need for this depends on how much trial and error is involved to find the right settings for the PhotonGI cache.
If you need a lot of trial and error, starting 10 renders or so until you found good setttings for photon count, radius etc., then it would be very good to have this pre-visualization.
On the other hand, if we manage to make this setting-finding process automatic or super fool proof, I think it would be ok to skip the pre-viz step.
If you need a lot of trial and error, starting 10 renders or so until you found good setttings for photon count, radius etc., then it would be very good to have this pre-visualization.
On the other hand, if we manage to make this setting-finding process automatic or super fool proof, I think it would be ok to skip the pre-viz step.
Re: PhotonGI cache
It depends a bit of where we will land at the end. I have some idea, after we have the photon tracing with Metropolis sampler and I have tried my idea for something like a BiDir photon tracing (i.e. firing photons form light sources and "visibility" particles from the eye) we should know more.B.Y.O.B. wrote: ↑Mon Jan 21, 2019 10:22 am I think the need for this depends on how much trial and error is involved to find the right settings for the PhotonGI cache.
If you need a lot of trial and error, starting 10 renders or so until you found good setttings for photon count, radius etc., then it would be very good to have this pre-visualization.
On the other hand, if we manage to make this setting-finding process automatic or super fool proof, I think it would be ok to skip the pre-viz step.