"sooperFoX" <bon### [at] gmailcom> wrote:
> > Well, except for one thing: That "render until I like it" feature with interim
> > result output would currently be an issue. Nothing that couldn't be solved
> > though. For starters, high-quality anti-aliasing settings might do instead of
> > rendering the shot over and over again.
>
> As I understand it, the idea of rendering the shot over and over again is the
> only way that it *could* work. Each pixel of a 'pass' follows a diffuse bounce
> in a 'random' direction (which could have a small bias, eg portals) and the
> more times you repeat those random passes the more 'coverage' of the total
> solution you get. Kind of like having an infinite radiosity count, spread out
> over time. That's why it starts out so noisy...

No, *basically* the only important ingredient for montecarlo raytracing to work
is that each *pixel* is sampled over and over again. That this is done in
multiple passes is "only" a matter of convenience. A single-pass "render each
pixel 1000 times" rule, which madly high non-adaptive anti-aliasing settings
would roughly be equivalent to, would qualify just as well.

I do agree of course that doing multiple passes, giving each pixel just one shot
per pass, and saving an interim result image after each pass, is much more
convenient than doing it all in one pass, giving each pixel 1000 shots before
proceeding to the next. No argument here.

> > Adding blur, like in MCPov, would be an extra gimmick that in my opinion
> > might be of interest for standard POV-Ray scenes anyway.
>
> That is just a natural side effect of the multiple passes - each pass takes a
> randomly different reflection or refraction direction, and when you average
> them all together you get a blurred result. This is also why you get perfect
> anti-aliasing.

Well, it is not a natural side effect of the multiple passes - it is a natural
side effect of multiple rays being shot per pixel *and* some jittering applied
to the reflection.

You can achieve the same effect with standard POV by using anti-aliasing (the
multiple-ray-shooting component) with micronormals (exploiting the "jitter" in
the initial rays to pick a more or less random normal from a bump map).

That's why I don't consider this an integral trait of a montecarlo extension to
POV-Ray.


> > The "diffuse job" could be fully covered by radiosity code, by just bypassing
> > the sample cache, using a low sample ray count and high recursion depth, and
> > some fairly small changes to a few internal parameters. That, plus another
>
> Yes, I think so. You probably don't even need that high a recursion depth, maybe
> 5 or so. And it's not so much recursion as it is iteration, right? You don't
> shoot [count] rays again for each bounce of a single path?

Well, if using the existing radiosity mechanism (just bypassing the sample
cache), it would actually be recursion indeed: The radiosity algorithm is
*designed* to shoot N rays per location.

(If I'm not mistaken, it is recursion anyway all throughout POV-Ray, whether it
is reflection or refraction (or diffusion, in which case the radiosity code may
add some recursive element); the only exception are straight rays through
(semi-) transparent objects. Maybe not a wise thing to do, but what the
heck...)

I guess it is the same with MCPov, too - after all, it allows you to specify the
number of rays to shoot per diffuse bounce as well. Which is not bad because it
reduces the need to trace the ray from the eye to (almost) here as often.


>
>
> > thing that has already made its way onto the radiosity agenda: The radiosity
> > sample ray pattern would have to be able to use certain hints in the scene
> > about bright areas (MCPov's "portals"); and for monte-carlo tracing it would
> > have to be truly random.
>
> Could it just be any object with finish ambient > 0? There is also
> bi-directional path tracing and Metropolis Light Transport systems, but I think
> they are significantly more complicated to implement..

Bi-directional path tracing only works if you have point lights, or can
approximate the light sources with point lights - maybe by picking random
points on glowing objects' surfaces for each path. This can be done with
meshes, and some other primitives as well, because it is easy to pick a random
point on their surface with a uniform random distribution; but when it comes to
isosurfaces or some such, getting the random distribution right or modulating it
with the proper factor to compensate for non-uniform distribution will be
difficult at best.

What *can* be done is bi-directional path tracing using classic light sources.
This would in fact be the result if the classic diffuse lighting term would be
left activated, and the specular highlighting "synchronized" with (diffuse)
reflection - or if photon mapping would be used for the whole scene.

Of Metropolis Light Transport I know nothing.


> > Scattering media would remain a problem, unless one would go for full volumetric
> > monte-carlo scattering simulation. Which, for highly scattering media, might be
> > veeeeeery slow.
>
> Yes, but it would be *correct*, and the results would be unbeatable. It could be
> turned on/off though for people who don't want to wait weeks for a decent result
> ;)

Yep. I already mused that such a thing - integrated into POV-Ray - could provide
me with reference shots for the SSLT code, to verify that it's doing just as
good in faster time ;)

Same goes for monte-carlo tracing in general, which would provide me with
reference shots for radiosity. MCPov is unsuited in this respect because it
cannot co-operate with conventional lighting.

Post a reply to this message