PhotonGI cache

[Dade]

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

[epilectrolytics]

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?

[Dade]

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.

[B.Y.O.B.]

Is it possible to show this while the cache is building, then switch to normal film mode when the render starts?

[lacilaci]

Is it possible to show this while the cache is building, then switch to normal film mode when the render starts?

You mean, like showing it as visual progress of building the photon map before rendering starts? (like when vray shows previz when building lightcache)

[B.Y.O.B.]

Yes.

[Dade]

Is it possible to show this while the cache is building, then switch to normal film mode when the render starts?

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.

[B.Y.O.B.]

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.

[Dade]

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.

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.]

Agreed.