Re: FG calculation falloff/scale bugs?

["Tim Leydecker" <BauerOink(at)gmx.de>]

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