The FG preview is simply cooked up tiles based on the FG data being calculated at the time. It's purely transient stuff. Those tiles never pass through the framebuffer pipe, where gamma and other things are applied.
If you want a more obvious/softer FG, you'll have to apply the FG separately in the render tree by using a "Photon_Irradiance" node piped through a "Color_Correction" node. You can then add the output of your surface shader ("Phong" or whichever) and pipe that into the surface of the material. Just make sure you set the "Irradiance" color of the surface shader to black. Do this on the FG sampling surface (ie. not the white card!)
Then you can twiddle with the gamma in the color correction node to your heart's content.
It's best not to confuse how the FG process works and what shaders do with the result of it. The shaders utilise the results of the FG sampling but the FG sampling is as indifferent to how to treat the colour input as it gets. It is exactly as Daniel described.
- ½
-----Original Message-----
From: Tim Leydecker [mailto:BauerOink(at)gmx.de]
Sent: 31-Jan-07 14:54
To: XSI(at)Softimage.COM
Cc: Halfdan Ingvarsson
Subject: Re: FG calculation falloff/scale bugs?
Hey Halfdan,
I checked it using Maya8 (using the architectural.dll) from Max9,
where you can specify the Main Framebuffergamma and map
the rendering Camera´s gamma using the mia_simple_exposure
independently.
http://www.hafenlola.com/downloads/ley_gammamod.jpg
I guess I mixed this up with Softimage XSI6´s way of handling
the framebuffer and FG calculation, where you can´t map the
tonal ranges independently (to expand the lit area).
But I must also add that during FG calculation preview, at least
for Maya (in the above flavour) it is truely noticeable that the
range the FG rays land in doesn´t change and therefor is
indeed calculated without taking Gamma into account
_but then mapped using as specified gamma.
I was asking for ways to influence that tonal mapping in XSI
independently from the other framebuffer calculations, to be
able to *smooth out* hotspots resulting from a fixed formula
as found in XSI, e.g. whatever I do, I´ll allways end up with
more or less ultrabright blotch in a fixed10XSI unit radius from
the emitting object, which I could prevent elegantly by stretching
the gamma to a softer tonalrange for FG only.
I´ll also answer Daniel´s e-mail in the next three hours but I´d
allready like to add that I am just trying to provide feedback
that may eventually lead to a better way of lighting things.
Intuitive, transferable knowledge across the board.
Cheers
tim
----- Original Message -----
From: "Halfdan Ingvarsson" <hingvars(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Wednesday, January 31, 2007 1:43 PM
Subject: RE: FG calculation falloff/scale bugs?
Gamma has no effect on the FG calculation. The FG calculations are completely
independent of the framebuffer settings. You should be using a color picker in
photoshop to check this out rather than relying on your eyes.
- ½
________________________________
From: owner-xsi(at)Softimage.COM on behalf of Tim Leydecker
Sent: Wed 31-Jan-07 07:06
To: XSI(at)Softimage.COM
Subject: Re: FG calculation falloff/scale bugs?
Hi Daniel,
thanks alot for looking into this, I´m a bit in a hurry today
and won´t be able to give a detailed response until late
tonight but could you be so kind to also try sending
e.mail to tim_at_hafenlola.com for the sake of getting through?
Ah, and please give me a hint if you have access to 3DSMax9
(the demo does fine) and Maya8 for comparison renderings.
I wrote Halfdan about another, imho, distracting connection
between FG gamma and scenegamma that can be better
illustrated using Maya/3DSMax due to XSI6´s disabled
gamma controls (except for a lensshader).
In a nutshell, changing gamma changes the FG calculation,
or better, maps it to different min-max ranges.
Instead, again, imho, _if there is a gammacorrection desired
at all, it should just influence the perceived light falloff between
black and white. Obviously, I´ll have to first supply a sample*.scn.
Thanks again,
Cheers
tim
P.S: Putting a gobo infront of a light should indeed block
the appropriate bits of lightrays from going any further.
----- Original Message -----
From: "Daniel Rind" <daniel.rind(at)chello.at>
To: <XSI(at)Softimage.COM>
Sent: Tuesday, January 30, 2007 5:30 PM
Subject: Re: FG calculation falloff/scale bugs?
> Hi!
>
> This is in response to Tim's mail and example scenes posted on the XSI mailing
> list.
>
> I'm sending this directly to the list as well as to Tim and Halfdan, since for some
> reason the listserver happily eats my mails without them ever showing up on the
> list. If this mail also gets devoured, please be so kind as to post it for me to
> the mailing list.
>
> The short version: Everything is fine, Final Gathering is working exactly as it
> should.
>
> The long version:
>
> First of all, Final Gathering is a gathering pass, which means for every final
> gather point, mental ray tries to estimate the amount of incoming light by looking
> at the rest of the scene. It does this, by basically rendering a hemispherical
> picture from every final gather point, using as many rays as you allow it through
> the "Number of Rays" parameter. To avoid doing this for every rendered pixel,
> mental ray employs an adaptive error metric and a caching method, so that it can
> compute those expensive final gather points as sparsely as possible, and then
> interpolate them during rendering to yield a visually pleasing result.
>
> So, probably everyone knew that, but I just wanted to restate it.
>
> Now to the two problems Tim wrote about:
>
> 1) Final Gather brightness is related to the scale of the object.
>
> It has to be like this. Final Gathering probes the environment, trying to get a
> "feeling" for the amount of illumination coming in at the current final gather
> point. After it finishes it's probing (basically, rendering a picture, like I said
> above), it averages the generated sample values together to give a final
> illumination amount. Final Gathering doesn't know any specifics of how the samples
> were generated - Was it a brightly lit wall? Was it an environment shader? Was it a
> light card with a really bright self illuminated material on it? Maybe the sample
> ray passed through a tiny slit in a wall and hit a huge reflection card on the
> other side?
>
> All that matters is the sample value returned by the ray, and the total number of
> rays cast. So, if your current final gathering point is very close to a light card,
> and a lot of rays hit that card, and all of them return pure white (1, 1, 1), then
> of course your final illumination value for that point will be very "white". If the
> final gather point is far away from that card, then only very few samples will hit
> it, very few will contain pure white, and the final illumination value will be
> rather dark.
>
> This is the way the real world works - the brightness will shrink as inverse square
> of the distance. Twice as far away will mean one quarter of the brightness. And if
> you want to move twice as far away from your light source, and still get the same
> amount of illumination, you will either have to make your light source four times
> as bright, or increase it's area by four times (twice as large in each dimension).
>
> Tim proposed that the final gather algorithm should scale the intensity with the
> size of the light source, so that two light cards with the same material but
> different sizes create the same amount of illumination.
>
> As an illustration of why that wouldn't work as expected, take a look at this
> picture:
>
> http://animus.brinkster.net/temp/FG_Lights.jpg
>
> There are three light cards here, illuminating a ground plane. The three strips of
> illumination on the floor are actually separated by big barrier grids, which are
> invisible and only block final gather rays, so the light cards don't influence each
> other.
>
> The left two grids apparently are of the same size, creating identical amounts of
> illumination. The right grid is twice as large (four times the area), and is
> therefore creating twice as much illumination. All three grids have the same
> material.
>
> What you can't really see is, that the center grid is exactly as large as the right
> one, but with a blocker card in front of it that has a hole the size of the left
> grid.
>
> What should final gather do in such a case? Scale the illumination of the two big
> grids down, so that they create as much light as the left one? If it would do that,
> then the left and right strips would be identical, but the central one would be
> darker, since 3/4ths of the illumination are lost behind the blocker.
>
> Now the second problem:
>
> 2.) XSI limits the range of final gather samples.
>
> Actually, it doesn't. Here is what happens:
>
> While the Final Gather method of sampling your environment might sound very nice
> and robust, it actually isn't. The "images" generated through this sampling are
> incredibly coarse. Even using overkill settings like 2000 samples per point will
> only generate light probes of roughly 45 pixels square - for an entire hemisphere.
> In a high quality scenario like that, every "ray" has to represent an area of about
> 4° by 4° square. However, Final Gathering rules through numbers - there are
> thousands of final gather points in each image, and when you blend enough of them
> together, noone will notice that the illumination value each single final gather
> point represents is actually very, very wrong.
>
> I did another image to illustrate the situation. This time, it's of a Cornell
> Box-ish setup. Here's the normal view:
>
> http://animus.brinkster.net/temp/FG_Box.jpg
>
> And here's what a camera placed at the back wall, where one of the FG points might
> be located, sees:
>
> http://animus.brinkster.net/temp/FG_Box_SampleHigh.jpg
>
> This image is 494x494 pixels, and would therefore correspond to a final gather
> sample number of about 244000. It was rendered with 1000 final gather samples, so
> what one final gather point would see is more like this:
>
> http://animus.brinkster.net/temp/FG_Box_Sample.jpg
>
> Not very detailed. What you also can't see here is, that the light source in the
> roof is using accurate inverse square falloff, and is actually extremely bright
> (intensity is at 600).
>
> When we render out an image with Final Gathering, we expect the image to be smooth
> even at low sample rates - 1000 is not low, and you saw with how little information
> mental ray has to work even at that rate. With only 100 (or 10) samples however, a
> single very bright sample can have huge influence on the final illumination for the
> final gather point.
>
> Imagine a very bright light source (for example, a bright red with (10, 0, 0)),
> very far away, and final gathering with e.g. 10 samples. Most of the final gather
> samples won't hit the light source - they will all be black (sum (0, 0, 0) ten
> times, divide by ten -> black). However, every now and then, a single final gather
> sample will hit the light source, turning the whole final gather point bright red
> (sum (0, 0, 0) nine times, then add a single (10, 0, 0) sample and divide by ten ->
> (1, 0, 0)).
>
> Now, to get rid of that, mental ray has the Final Gather Filter Size parameter. The
> default value is 1. What this means is, that after taking all final gather samples,
> mental ray will try to remove single, overly bright samples that totally turn
> around the end result of the final gather point. In our example, mental ray would
> suppress the one bright red sample, and we would get an even, dark solution. If set
> to 0, the filter is disabled. If set to two, mental ray would try to make the
> solution even smoother, and even when two samples would hit our light source,
> mental ray would remove them both.
>
> Now in the example scene that Tim provided, what this means is, that after a
> certain distance, there won't be enough sample points to overcome the Final Gather
> Filter, and the bright single samples will be thrown away. To remove that, simply
> set the filter size to 0.
>
> Here's the sample scene rendered with the standard settings, at frame 100, but with
> filter size at 0:
>
> http://animus.brinkster.net/temp/FG_Tim1.jpg
>
> Here again, this time with only 100 samples, and the "Points" parameter set to 1
> (so no interpolation between final gather points takes place):
>
> http://animus.brinkster.net/temp/FG_Tim2.jpg
>
> Here again with 100 samples and 1 point, but with filter size at 1 again:
>
> http://animus.brinkster.net/temp/FG_Tim3.jpg
>
> This explains why the distance the illumination spreads is seemingly limited.
>
> So, I hope this helped explain things a bit, and I also hope the listserver has a
> good day and lets my message pass - if not, please be so kind as to forward it.
>
> Ciao, Daniel!
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
