*I have this huge, photon emitting geometry that´s making
my renders blow out when I enable FG, what do I do?
Well, most likely enable falloff and set it to something in the
0-10 sceneunitrange, to hide the "scaling" effect away (mostly) and
limit the FG effect to blending between the splotches resulting
from the GI calculation (as most tutorials suggest to use FG for)
or maybe even have the emitting geometry (the photonic whitecard)
excluded from FG altogether and just once more live with the lacks again.
Thanks again for the insights, I hope there´ll be a more physical approach
some day - as the big advantage is - it´s easy to grasp the laws of physic
but quite painful to find out all the caveats of the "optimized solution".
Oh, can you also (re)enable the fastpath material? Even if it´s brute-force?
It could prove a handy way to first create a (low-sampled) but
somewhat more physically accurate calculation (to get an idea)
then recreate or optimize the effects using faster methods. e.g.:
"I have this huge scene, show me how my light would travel. Ah, o.k.!"
For now, I´ll allways just have a reference-sized whitecard in scene from
which I can directly read the effects of filter, sampling and falloff and translate
that to the actual lightrig,somewhere like: "Ah, that one *can´t* show it´s
effect..."
Cheers
tim
----- Original Message -----
From: "Halfdan Ingvarsson" <hingvars(at)Softimage.COM>
To: "Tim Leydecker" <BauerOink(at)gmx.de>; <XSI(at)Softimage.COM>
Cc: "Daniel Rind" <daniel.rind(at)chello.at>
Sent: Thursday, February 01, 2007 2:23 AM
Subject: RE: FG calculation falloff/scale bugs?
No biggie.
The first thing to realise in CG, especially rendering, that everything is basically
a hack that is intended to get an effect quicker than would be possible if natural
laws were simulated more exactly (compare and contrast with Maxwell render times,
which tries to approach full realism).
Photon mapping was developed as a response to the immense render times of brute-force
monte-carlo sampling (path tracing) and the gigantic calculation and memory
requirements of radiosity approaches. For that, photon mapping has its limitations
which people should be aware of and which the mental ray manuals do an extremely poor
explanation of.
Final gathering is another hack that was invented to simulate the *diffuse*
interaction component of photon mapping. In all of your example scenes, you were
trying to apply final gathering as a specular reflection effect, which is completely
not what it was designed for. It is purely intended as a simulation of interaction
between diffuse surfaces, of mostly similar intensity, since the colour is only
supposed to change smoothly and gradually between final gather points, and not
strongly like your examples require.
We'll have a look at enabling surfaces to be photon emitting but I suspect that's
done in Max/Maya via geometric lights, which I guess we'll then have to finally
relent and implement :)
- ½
________________________________
From: Tim Leydecker [mailto:BauerOink(at)gmx.de]
Sent: Wed 31-Jan-07 19:00
To: XSI(at)Softimage.COM
Cc: Daniel Rind; Halfdan Ingvarsson
Subject: Re: FG calculation falloff/scale bugs?
So,
first off, thanks alot guys!
In response to Daniel´s mail I must admit I had gotten the
conceptual approach for FG wrong, by expecting FG rays
to be emitted based on the intensity of a surfaces´ color.
In a way thinking of FG as a similar approach to GI/photons
emitted by light...
So, to cover one of the problems that come with the sampling
nature of FG, the filterattribute (for being set above 0) cuts in
to "mask out" the increasing splotchiness that comes with the
distance the FG ray travels. Or as Halfdan put it in another email:
"Welcome to the joys of probabilistic sampling and solid angles :)"
After doing numerous renderings I´d humbly say I don´t like the
brute force of the Filter effect and will most likely just keep it turned off.
The second bit, the effect of a compareably large surface getting
exponentially more wheight in the FG result is also graspable by
Daniel´s and Halfdan´s explanation, I may not like it as it isn´t
"real" but I guess I can´t expect a better (indirect) illumination
model any time soon, so I´ll hereby just politely ask (again)
for a photon emitting material shader for a futur XSI/mR version,
hoping that a "light" emission based on intensity may produce better results.
Until then, I´d like to thank you again, for both the calm explanation
and great insights, not to forget the lead to using a seperate Irradiance node,
here´s a scenefile for XSI 6.0 (_watch for lensshader) Modify freely at will:
http://www.hafenlola.com/downloads/ley_irr_gamma.zip
Cheers
tim
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
