fg confusion again

[sjannuz]

I'm confused about final gather, as usual.
The question is: what triggers the tracing of rays to compute the fg map?
It is mi_compute_irradiance (or mi_compute_avg_radiance), I guess, which is at the same time the writer and later the reader of the fg map.
In all the standard xsi shaders, all the materials do not have a check for enabling/disabling the irradiance computation (talking about shaders, not visibility options). So, when having to compute the map, the shaders will send fg rays according to the global setting.
If this is correct, how many chances do I have to interfere with the fg setting per-object? I cannot ask the render boys to remove the current surface shaders (we use all sorts of illum nodes), and i cannot forbid the current shaders to call mi_compute_irradiance.
Tx

Stefano, Lumiq

[bart]

mi_compute_avg_radiance is a more modern version of mi_compute_irradiance with the factor of pi already computed into it, so that all you have to do is multiply its result by your diffuse color.

It also has the local override options which can be very handy. For FG, use it for local control of indirect illumination detail. Any settings here can override the global.

Note how the struct is used. It can be setup to inherit global FG options and only change the options you want to explicitly set. You could imagine a shader UI which has both a local override enable and the parameter, for each parameter that is settable.

[ctrl_studio]

Ehy Stefano :wink:

setting the radiance for the buildin materials to black, it will disable the irradiance call in xsi (but not generally for any mi_compute_irradiance function so..). if you're using custom shaders and you don't wanna touch the rendertree.. you can set up a userdata node and just update the code for the surface shader with mi_avg_radiance func that will take its settings from the data object... more or less, as francesca pointed out on the mr mailing list, as maya does. or to attach data to large objs sets you can use a geo shader that will build up common data settings and maybe a list of objs that have to obey that. if your users need custom ctrl over single objects, the userdata could be a minimun effort to do that as the node could be seen just as applying a generic obj property like approximation and so on. if you need more a td intervent to speed up some already established scenes, you can simply use a geoshader to 'spread' fg settings over your objects and simply modify the existing surface shader to let it read'em, that means that apart adding the geoshader you'll need not to re.edit the scene (obj materials).

max

[sjannuz]

We don't usually use custom material shaders.
I can surely edit the rendertrees, but I can't replace the factory materials.
In the factory materials, I suspect mi_compute_irradiance is still in use, since they did not expose the per object parameters.
As you say though, setting the radiance color to black stops the fg computation, so I'll do my own irradiance node (vie mi_avg...) and add it to the factory material by a mixer.
Yet again, what does the radiance color have to do with the irradiance computation...

tx for all the answers

[zap andersson]

Here's something to try.

If all you want to do is control the FG options of some other shader, take advantage of the fact that the same FG point isn't stored twice.

Create a shader which does *nothing* but call mi_compute_avg_radiance w. your selected options.

Then, either have this shader evaluate the "actual" shader you want to use as a sub-shader (with something like mi_call_shader_x) OR simply put them after eachother in a shader list.

The 1st call SHOULD be the one that gets to actually store the FG poitn, the 2nd SHOULD be redundant and do nothing.

I cannot guarantee this will work but it's definiteily worth a try.

/Z

[igsiv_]

I wrote "shader-connector" for adjust FG (GI, caustic) on material basis and it's work fine in 3ds max.

I'm trying use different approach - save origanal state, temporarily change state when ray hit material for disabling FG at all, calculate direct and secondary lightning (using standart material shaders) then change state again and call mi_compute_avg_radiance with new FG parameters (GI, caustic), after that restore original state, combine direct and indirect components in final result and return him. The main idea is to use material shader but disable built-in irradiance part and replace her calling mi_compute_avg_radiance with new FG parameters in state.

This approach allow use that shader as "shader-connector". Connector assigned for surface slot of any material, then any material shader can be assigned to "material" slot of that shader-connector. So, any existing material shaders (standart or not) can be used without modifying. One drawback is necessity to duplicate diffuse color of material shader for irradiance calculations.

If my approach are interesting I can post here full code of that shader-connector (may be later, during day or two).

[ctrl_studio]

also a couple of points should be mentioned to get things clear about 'fg cycle' as you mentioned 'gi cycle' in the mailing list.

pratically, the radiance param in the material ctrls how much finalgather will be shown on the material itself.
to ctrl instead the emission of that material you generally will have to catch the fg rays and pass something there. we're going to check what rays are caused by finalgather samples, in other words.. the contribution the point being shaded will bring to the global illumination.

max