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

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

Nieminen Juha wrote:
> 
>   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.
> 

It does have the shortcoming of doing no energy balancing, so you have to tweak
a lot to have physically correct results. So it's not as suitable for
architectural lighting studies (not meant to be, I know) OTOH, it gives you more
freedom.
So if we don't get 'no stinking true radiosity', I can live with that.

Margus

Post a reply to this message

Nieminen Juha wrote:
> 
>   I think Nathan is doing/has done a save_file command for radiosity.
> 

But POV's radiosity is somewhat view dependant, so I'm not sure how useful this
will be - except of course in re-rendering stills.

Margus

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote...
> It does have the shortcoming of doing no energy balancing, so you have to
tweak
> a lot to have physically correct results. So it's not as suitable for
> architectural lighting studies (not meant to be, I know) OTOH, it gives
you more
> freedom.
> So if we don't get 'no stinking true radiosity', I can live with that.

What do you mean by 'no energy balancing'?  The monte-carlo approach can
give very physically correct results without lots of tweaking.  My changes
to radiosity greatly reduce the number of variables that the user has to
mess with to get reasonable results.  And it now ignores 'ambient' settings,
so if you set the ambient to zero, then use a brightness of 1.0, you will
get physically accurate results.

On the other hand, it does require a good deal of processor power (although
so does true radiosity).  And, like Nieminen Juha mentioned, it is view
dependent.  A totally view-independent solution might not be totally
possible, but if you keep re-loading the data and then adding to it (and
expire old nodes), it could save time.

-Nathan

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote ...
> Ben Birdsey <cla### [at] netscapenet> wrote:
> : 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).

Warp speaks the truth.  The KD tree is not good for radiosity, since you
cannot add new nodes to the kd-tree.  Plus, there aren't usually too many
nodes in the radiosity octree, so searching it is farily fast.

Directly visualizing a photon map as a solution for indirect diffuse
lighting generally produces very splotchy results and takes much longer than
the current method.  However, it should be possible to use data from a
"global photon map" to achieve good results in a radiosity scene (using the
current method) while using fewer samples.  I have tried this with not much
success, but I'll probably try it again now that I've made a few of my bug
fixes in POV's radiosity code.

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> What do you mean by 'no energy balancing'?  The monte-carlo approach can
> give very physically correct results without lots of tweaking.  My changes
> to radiosity greatly reduce the number of variables that the user has to
> mess with to get reasonable results.  And it now ignores 'ambient' settings,
> so if you set the ambient to zero, then use a brightness of 1.0, you will
> get physically accurate results.

Well, I cannot be entirely sure all (true) radiosity implementations do energy
balancing, but i know for a fact that some, like BMRT, do. I'm probably
lecturing to someone whose knowledge on this matter is superior to mine, but
I'll go ahead and do it anyways :)
As you know, the radiosity engine divides surfaces into discrete patches with a
certain amount of energy (i.e. light) absorption and emission. Energy
transmission is then calculated until it can be said, within specified
confidence limits, that all energy emitted into the scene has been absorbed. The
Monte Carlo method doesn't really provide for this, at least not in an effective
manner.
I agree though, POV's radiosity gives reasonable results that are good enough
for most applications. Certainly good enogh for me.
And you should by no means think that I'm not appreciating your work :)

Margus

Post a reply to this message

Ron Parker wrote:
> 
> 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.

You did, Ron. In fact you squashed a bug that we had overlooked :)

-Hans-

Post a reply to this message

Margus Ramst wrote:
> 
> 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 :)

Thank you, Sir. %-))

> 
> Margus

Post a reply to this message

By the way:
For an inter-reflection model to be considered physically correct, for one it
would have to be able to treat diffuse and specular reflection as one, i.e. it
should also be able to model inter-reflections of semi-diffuse surfaces. While
forward Monte Carlo tracing could _theoretically_ do this, I see no way of doing
it with a manageable number of samples.
AFAIK, POV's radiosity can do recursion because its sample rays are always
distributed around the surface normal, so it can terminate recursion for the
current ray when this ray hits an already-calculated sample. With specular
properties, the bias of the new sample rays would start to depend on the
direction of the incoming ray. So old samples could not be reused - they would
be taken from a different direction.
I'm wondering if backward tracing, like photon mapping, could overcome this
problem...
If I'm not mistaken, Radiance can do it. But Radiance uses the wavelet method,
which is completely alien to me. I don't know if (true) radiosity can model
non-diffuse reflection. For some reason, I doubt it.

Margus

Post a reply to this message

Btw, if you haven't seen me pov3.1g vs. uvpov6 radiosity speed
comparison yet, see my post in p.b.images.
  The difference in speed is marvelous.

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

> 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 explained how to do this in the thread "UVPov alpha 6" in case anyone feels
like doing it.  Unfortunately time doesn't permit me to it myself right now.

-Mike

Post a reply to this message