|
 |
"nemesis" <nam### [at] gmail com> wrote:
> It's a megapov patch based on path-tracing and reportedly very accurate. Very
> slow too, but more accurate no doubt than current radiosity.
Hehe - *current* radiosity is flawed, no doubt :)
Anyway: I guess I'll have a close look at that one, because it seems to be very
well suited to assess how a scene *should* look with radiosity.
I also think that some of the ideas may work well in radiosity, too.
Post a reply to this message
|
|
|
|
"triple_r" <nomail@nomail> wrote:
> The problem with MC-POV seems to
> be that some effects end up over-sampled while others are very noisy. I
> haven't figured out how to control this well, yet. Perhaps better portal setup
> would fix the problem, but at the moment I think radiosity is the horse to bet
> on for most scenes. You do get nice sharp shadows with path-tracing, though.
To get my eyes off radiosity for a moment:
The over-sampling of some areas vs. remaining noise in others might be not too
difficult to control. The key would be to stop using a uniform number of trace
iterations, and instead stop tracing a pixel as soon as you are confident that
it is good enough. Or, to stay in the MCPov paradigm, instead of shooting a
fixed number of rays per pixels in each pass, modulate the number depending on
how confident you are about them.
As a confidence indicator, you can keep track of a statistical parameter like
the standard deviation for each pixel. If it has been low so far, chances are
it will continue to remain low, so a lower sample count should suffice for
them.
A less memory-consuming approach to drive this would be the standard deviation
of a "pixel neighborhood": If the pixels in some area currently deviate a lot,
chances are this is due to noise, so you may want to spend more computing power
on this area.
This might also make an interesting concept for the collection of radiosity
samples: Ditch the fixed count, and instead modulate the number of rays based
on the standard deviation encountered in nearby samples. A first coarse pass
could do an extremely high number of sample rays, which might allow it to pick
up small light sources.
Keeping track of the standard deviation for different directions could refine
this approach.
Post a reply to this message
|
|
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> Very noisy, yes, but undoubtfully much more acurate.
>
> So, we have 2 options so far: noise and insane rendertimes or splotches and
> high rendertimes. Pick your poison. :)
No splotches and moderate render times, that's what I'm aiming at :)
Post a reply to this message
|
|
