Detecting Finalgather preprocessing phase in a shader

[bart]

I thought this had been mentioned in this forum, by me or Zap, but I didn't find it in a search. It is a bit tricky to detect whether you are in the FG preprocessing phase. Basically, it is encoded in the answer to whether or not a material shader is in tile rendering phase.

Remember that the FG phase happens before the tile rendering phase, but may call material shaders at each FG point that is being processed.

To detect, use the miQ_TILE_* queries. It is hard to find, but if you look hard enough, it is actually in the manual. From the doc, under the description of mi_query:


The miQ_TILE_* codes are supported by mental ray 2.1.34.107 or later. They describe the location and size of the currently rendered image tile. The returned values are in the order xlow~~xhigh~~ylow~~yhigh. The sampled area may be larger than the tile due to filtering and jittering. These codes may be used to detect if a shader is called in the finalgather precomputing stage: for finalgather precomputing the return value is miFALSE as no tile exist.

So, for example you check the condition
!(mi_query(miQ_TILE_PIXELS, state, 0, &dummyint)) to see that the material shader is in FG preprocessing.

So why not use the miQ_FINALGATHER_STATE? Well, because it only says whether or not this material shader calculation is a result of an FG ray, in a secondary FG ray, ie a child or grandchild of an FG ray. Since FG rays are put out by the mi_compute_avg_radiance/mi_compute_irradiance functions in your material, there are times one may wish to detect this phase before the FG ray is sent out.

So if one really wanted to optimize during FG preprocessing, detect the FG preprocessing phase and don't do any direct lighting loop or ray trace reflection or refractions, and only call the mi_compute_avg_radiance/mi_compute_irradiance function.

There are also a couple other advanced tricks one can do with FG when detecting this phase.

For example, one could use this phase to store a custom kd-tree holding a glossy cache. A cache of any glossy reflections sent out by the shader.[/b]

[sbo]

Hi,

I've been trying to program a custom finalgather, so I first had to detect the fg precomp phase (thanks for the tip).

However, I don't know how to deal with the "extra" fg points, which are added during the "rendering phase" (after the fg precomp).

Since the mi_compute_irradiance does all these process by itself (detecting if more fg rays must be sent, send them, and interpolate), I can't find the way to intercept the fact that more fg points need to be computed at a given point, so that I can call my custom FG function again during the rendering phase.

If I set state->options->finalgather_rays to 0 when the fg precomp phase is finished, then I loose some points which would really need to be calculated....and if I don't, then some fg points are computed with my custom finalgather and some others with mr's one. In both cases the flicking is ugly....

I guess I need some help :?

Thanks,
Seb

[bart]

So, are you using mr 3.5?

Some of the new modes for FG can limit FG to just the pre-computing phase.
In fact, only the new modes use the new finalgather rays option.

Which mode are you using?

I am working on a new 3.5 FG tips page.

[sbo]

...That's good news.

No for now I'm still using mr 3.4, but I'll have mr 3.5 in a couple of months so I'll just have to wait I guess :D

Looking forward to seeing your tips page

Thanks,
Seb

[bart]

In the meantime with 3.4, try increasing the fg point density during the fg precomputing phase, saving out an fg map. Then, setting the density back for the rendering phase reusing the fg map.

Do you have standalone version of 3.4?
In that there is also a hidden option, -finalgather_rebuild deepfreeze,
which will guarantee no extra fg points are created at render time.

[sbo]

Do you have standalone version of 3.4?
In that there is also a hidden option, -finalgather_rebuild deepfreeze,
which will guarantee no extra fg points are created at render time.

No I don't have standalone neither, but as I said I'm now setting state->options->finalgather_rays to 0 after the fg precomp phase, so I can avoid extra fg points.
The problem is that I would need those extra points :roll: cause I'm now having some flicking on my object's edges.

But I'm just realizing there's something else.. I see that the fg interpolation is done even between different objects. I naively thought the fg points were "per object"....

So since my custom fg computes fg points which depend on the object's material (with even color informations, etc..., cause here I can't just multiply the Irradiance by a diffuse color like in mr finalgather), then I have weird colorations at the object's edges....

Anyway I'm sure the new modes in mr 3.5 will help me
Thx

[bart]

Keep in mind that the interpolation area is within the 3d radius specified by max radius. But that there is a heuristic to throw out FG points for points further than the FG min radius. The points between objects might meet these constraints to throw out the points.

This could actually cause the lack of FG points in an area of geometric detail or on a face parallel to the viewing angle. For that, you may want to try increasing the FG point density.

(This could be locally controlled by a material, or in Maya the local FG object data is passed to the Mayabase materials.)