> 2) Talk to Nathan really nicely and see if he would
>    rewrite the radiosity code to use a kD tree and
>    photon map.  Now that would be cool!


What I would prefer is for someone to add to POV the ability to derive the
scene into polygons (possibly ouputting to .3DS or something) and
calculating a real radiosity solution for the scene, instead of this
MonteCarlo stuff that's so slow.

Post a reply to this message

I made the modification on POV 3.1g, and you can definitely see the
perturbed normals.  Who knows how photo realistic it is, though.

	In Him,
	Ben

Post a reply to this message

Could you post an image in povray.binaries.images to show us, please?

Ben Birdsey wrote:

>         I made the modification on POV 3.1g, and you can definitely see the
> perturbed normals.  Who knows how photo realistic it is, though.
>
>         In Him,
>         Ben

--
Samuel Benge

STB### [at] aolcom

"And you can fly
 High as a kite if you want to
 Faster than light if you want to
 Speeding through the universe
 Thinking is the best way to travel"

          -The Best Way to Travel, The Moody Blues

Post a reply to this message

Ben Birdsey <cla### [at] netscapenet> wrote:
: 	Right now, radiosity is just a way of calculating the AMBIENT light at
: different points.  This is the same reason the slope mapped texture
: doesn't show with ambient light either.  ( turn the radiosity off and
: crank up the "ambient_light" in "global_settings" and check it out).

  I think that you are a bit wrong here.

  You are right when saying that radiosity (or whatever it should be called)
is used for calculating ambient light. But that's more than just calculating
the brightness of the scene in a certain point. It actually calculates how
light bounces from surfaces and how does it illuminate the current point.
This means that the color and the angle of incidence of the surfaces affect
the color and the brightness of the reflected light.
  If we have a sphere in the shadows, the part of the sphere which is facing
the bright white wall will be more illuminated that the part of the sphere
which is perpendicular to the wall.
  Plain ambient light would just apply a constant brightness to the whole
sphere.

  In the example scene I posted there are two gaps in the wall. None of them
is visible in the shadowed part without radiosity, regardless of how high
we set the ambient_light.
  With radiosity the left gap becomes visible because its surface normals
are different from the wall. The surface of the gap that is facing the red
wall will be slightly tinted red while the other surface will be slightly
tinted blue. The gap will also be a little bit darker than the wall because
it receives less light.
  Now, the other gap is almost exactly identical to the first one. The only
difference is that the normals of the gap are created in a different way.
Instead of being surface normals they are patterned normals. Povray treats
both gaps almost identically when calculating regular lighting. I don't
understand why should it treat them differently when calculating radiosity.

: 	2) Talk to Nathan really nicely and see if he would
: 	   rewrite the radiosity code to use a kD tree and
: 	   photon map.  Now that would be cool!

  I think that Nathan has already tried using photon mapping for radiosity.
AFAIK it's a pretty inefficient way of doing it (most photons will be shot
and stored although their contribution to the lighting is almost none).
The stochastic method is much more efficient (at least in the way Nathan
has made it).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

TonyB <ben### [at] panamaphoenixnet> wrote:
: What I would prefer is for someone to add to POV the ability to derive the
: scene into polygons (possibly ouputting to .3DS or something) and
: calculating a real radiosity solution for the scene, instead of this
: MonteCarlo stuff that's so slow.

  Actually the montecarlo approach is pretty fast and efficient (when done
right, like Nathan has done).
  Nathan's improvements are just marvelous. A scene which takes several hours
to render with povray's regular radiosity at recursion level 2 takes only
about 10 minutes with Nathan's modifications at recursion level 4 and the
result is much better.
  IMHO, we need no stinking "true" radiosity.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

<VOICE FROM="Star Wars Episode I" CHARACTER="Viceroy">I... was not aware of
such improvements.</VOICE>

>  IMHO, we need no stinking "true" radiosity.


It would be nice if we could get it precalculated for the whole scene and
then you could just render and render without having to figure it out again
for each and every frame.

Post a reply to this message

TonyB <ben### [at] panamaphoenixnet> wrote:
: It would be nice if we could get it precalculated for the whole scene and
: then you could just render and render without having to figure it out again
: for each and every frame.

  I think Nathan is doing/has done a save_file command for radiosity.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hi!

Sorry to intervene here, I'm one of the slope patch authors, you know
;-)

Ben Birdsey wrote:
> 
>         You're right, it doesn't take the normal into account.
> 
>         Right now, radiosity is just a way of calculating the AMBIENT light at
> different points.  This is the same reason the slope mapped texture
> doesn't show with ambient light either.  ( turn the radiosity off and
> crank up the "ambient_light" in "global_settings" and check it out).

  Using the latest slope patch based on 3.1g I cannot reproduce what you
describe. A slope dependant texture on a bump mapped sphere shows
quite well, even with pure ambient light (radiosity off). Of course,
the bumps are invisible then, but the texture is. (And it follows the
perturbed normals, not only the pure geometric normal.)

  But maybe it's different with the superpatch.

-Hans-

Post a reply to this message

On Tue, 16 Nov 1999 15:12:22 +0100, Hans-Detlev Fink wrote:
>  But maybe it's different with the superpatch.

If it is, it should be fixed.  My intent was to keep your original
code as intact as possible.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Hans-Detlev Fink wrote:
> 
> Hi!
> 
> Sorry to intervene here, I'm one of the slope patch authors, you know
> ;-)
> 

I think Ben meant the slope_map...
I love your patch, btw :)

Margus

Post a reply to this message