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