First of all: I _really_ like Nathan's improvements for povray's radiosity.
I have always been a bit jealous to other rendering programs like radiance,
bmrt, etc. which can make very good-looking radiosity quite fast and with
very little effort from the user. Povray's radiosity has always been slow
and good results have been very hard to achieve. But now with Nathan's
modifications one can get very good results very fast and very easy. Thanks.

  Now, to the problem:
  This problem happens with surface normals and radiosity. (Man, this is
the third bug regarding normals I have found; I'm starting to get tired...)
I think that it's not an uvpatch-specific problem. I have not tested it but
I think that the same problem appears in the official version.
  The problem is that surface normals are not taken into account in
radiosity calculations.
  Usually radiosity makes visible the surface details that are not illuminated
by calculating light reflected from other surfaces. This means that if you have
a white sphere in a white room and the sphere is not directly illuminated,
it will be completely invisible without radiosity, but with radiosity it
becomes visible.
  This, however, is not true for surface normals. If the changes in the
surface of an object are achieved by a normal modifier, they will not appear
nor they will be colored according to radiosity.

  The following scene (for uvpov) demonstrates this. There are (again) two
gaps in the wall. The left one is a real gap and the right one is a "fake"
gap made with a normal modifier.
  When rendered, we can notice two things:
  1) The upper part of the left gap that is not directly illuminated becomes
visible by the effect of the radiosity while the right gap stays invisible.
  2) The illuminated part of the left gap is tinted with the color of the
walls (left wall is red and right wall is blue) while the right gap is gray.

  This has caused me serious problems before, but I didn't study this problem
carefully until now.

//---------------------------------------------------------------------------
global_settings
{ ini_option "+QR"
  ini_option "Preview_Start_Size=8"
  ini_option "Preview_End_Size=4"
  radiosity
  { count 80
    nearest_count 5
    error_bound 1
    recursion_limit 4
    low_error_factor .5
    gray_threshold 0.0
    minimum_reuse 0.015
    brightness 1.5
    max_sample 2
    adc_bailout 0.01/2
  }
}

camera { location <-1.99,0,-1.99> look_at z*2 angle 40 }
light_source
{ <1.99,.99,-1.99>, 1
  spotlight point_at <0,-1,2> radius 15 falloff 15
}

difference
{ box { <-2,-1,-2><2,1,2> inverse }
  box
  { <-.1,-.9999,-.1><.1,.9999,.1>
    rotate y*45 scale <1,1,.5> translate <-.5,0,2>
  }
  pigment { rgb 1 }
  normal
  { gradient x 1 slope_map { [0 <0,1>][.1 <1,1>][.1 <1,0>][1 <1,0>] }
    scale 1.8
  }
}
box { <-1.999,-1,-2><-2,1,2> pigment { rgb x } }
box { <1.999,-1,-2><2,1,2> pigment { rgb z } }
//---------------------------------------------------------------------------


-- 
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

This is not bug, not even an ovesight IMO. I once mentioned the same thing, and
someone (Ron?) gave the following reason:
Radiosity values are not calculated for every pixel, therefore basing the
calculation on the perturbed surface normal could give erratic, unpredictable
results. (As you know, normal maps are mainly used to simulate small-scale
surface features)
It must be said though that I have gone to very high quality settings
(especially with Nathan's version) where this reasoning might not apply. So what
you suggest might be considered as an option. But not, I think, as a default.

Margus

Post a reply to this message

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).

	This is a really useful method for rendering "view independent"
lighting.  Calculating just the AMBIENT contribution is just basic "bare
bones" radiosity.

	Now, if you check out Henrik Wann Jensen's web page at
<http://www.gk.dtu.dk/home/hwj/welcome.html>, you'll see that he's the
inspiration for Nathan's photon patch.  And you'll see that that same
photon map is calculating direct lighting, caustics, and radiosity at
the same time, and doing a better job than "plain jane" POV.

	There are two easy fixes as far as I see.
	1) Somehow use both "Raw_Normal" and "LayNormal" in 
	   "Compute_Ambient".  You need to use "Raw_Normal"
	   so the computed rays won't go through the surface,
	   but "ra_reuse" uses the normal to figure out the
	   contributions from the nearby octree nodes.  So,
	   if you used "LayNormal" there, that would influence
	   the surface illumination in the right way.

	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!

	Until that Day,
	Ben

Post a reply to this message

> 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