primary secondary and -tertiary- gi engines?

[super gnu]

doing a little thought experiment here and i want somebody to tell me why it isnt a good idea.


i think i understand pretty well the gi process in vray, with the secondary bounces approximating the scene lighting, and the primary engine casting a single scattered bounce into that secondary solution to calculate actual pixel values for the gi.


therefore (and this is where i start thinking for myself, so i could be way off) this explains why we can use BF/LC or to a lesser extent imap/LC for animated scenes despite the lightcache being a per-frame, noisy, relatively low quality solution.

its never directly visualised in the scene, and the primary bounces take many hundreds of samples of random parts of the lc and averages them to produce a single pixel value.

since the values of the lc can vary in both a positive and negative direction ( simplifying here) when many points in it are averaged together, the averaged result has less variation.

this means the variation in values in the BF or imap is significantly less than the LC it is based on.


continuing this thought process, would a third (fourth/fifth) gi pass basing its values on the result of the previous (as now with primary and secondary) not produce progressively more stable, flicker free results?



obviously even if this is the case, it would remain to be seen if it was any more efficient time-wise than simply doing a higher quality primary and secondary...


thoughts?

[vlado]

since the values of the lc can vary in both a positive and negative direction ( simplifying here) when many points in it are averaged together, the averaged result has less variation. this means the variation in values in the BF or imap is significantly less than the LC it is based on.

This is perfectly accurate, yes.

continuing this thought process, would a third (fourth/fifth) gi pass basing its values on the result of the previous (as now with primary and secondary) not produce progressively more stable, flicker free results?

This is kind of what the "retrace" option does for the light cache - if V-Ray decides that a light cache sample is too big or unsuitable to approximate the GI at a given point, it will replace it with a brute force calculation.

In any case, the light cache is already a multi-bounce solution that approximates all bounces simultaneously, and it's very good at that. It's only drawback is that the samples change places and vary a little bit as objects and/or the camera move around. If we found a way to have a GI solution with consistent samples from frame to frame (while still being adaptive and taking into account object distances and GI variation), then I guess things would be a lot more stable. One of our developers here spent a few months researching that before the 3.0 beta, but it looks to be a difficult task, so it's still an open topic.

For the moment BF+light cache+retrace seems to be the best way to go.

Best regards,
Vlado

[super gnu]

thanks for the reply. from your description im not sure retrace does exactly what im thinking of, since in your words "it replaces the lightcache with brute force" - unless by this you mean it does a single bounce of BF in that area, in effect coming -between-the lc and primary bounce.


im thinking basically of taking the result of a pri/sec bf/imap and lc calculation, and using that final result as the secondary, with another bf/imap as a single bounce primary "on top" basing its values on what would previously have been our final solution.



on a related note, since both imap and lc are view-dependent, what happens when, after the lc has been calculated, the imap is doing its thing, and some of the rays it fires go into parts of the scene not covered by the lc? does it do a bf calc there instead?

[super gnu]

just to clarify, im not talking about doing anything to increase the bounce depth, this is incidental.. im thinking more about another pass reducing variation between samples even further than the 2 pass system we currently have, simply due to the aforementioned effect:

"since the values of the lc can vary in both a positive and negative direction ( simplifying here) when many points in it are averaged together, the averaged result has less variation. this means the variation in values in the BF or imap is significantly less than the LC it is based on"

[vlado]

thanks for the reply. from your description im not sure retrace does exactly what im thinking of, since in your words "it replaces the lightcache with brute force" - unless by this you mean it does a single bounce of BF in that area, in effect coming -between-the lc and primary bounce.

This is exactly what it does, yes.

im thinking basically of taking the result of a pri/sec bf/imap and lc calculation, and using that final result as the secondary, with another bf/imap as a single bounce primary "on top" basing its values on what would previously have been our final solution.

It won't help too much I think; at one point even if the samples themselves are very high quality, the fact that they shift around is enough to cause flickering.

on a related note, since both imap and lc are view-dependent, what happens when, after the lc has been calculated, the imap is doing its thing, and some of the rays it fires go into parts of the scene not covered by the lc? does it do a bf calc there instead?

V-Ray will do its best to use the available information from the light map; it will not attempt to fill in the missing information, as this will cause additional flickering. So the result might be slightly wrong, but it will be consistently wrong.

Best regards,
Vlado

[vlado]

just to clarify, im not talking about doing anything to increase the bounce depth, this is incidental.. im thinking more about another pass reducing variation between samples even further than the 2 pass system we currently have

At some point the sample variation stops being a problem; it's the fact that the samples move from frame to frame that is a bigger concern. The variation is easy to solve (just needs more samples), but the other problem doesn't have a good solution right now.

Best regards,
Vlado

[super gnu]

ive realised i was making a pointless suggestion, since of course, any multibounce solution (such as lc, as you mentioned) does this process already, and all im suggesting (as pointed out) is doing another bounce.

However led me to another thought (possibly also pointless)

the time-interpolation in animation mode is only done on the primary engine (imap) would there be any benefit to time-interpolating the lc -before- doing the imap pass?