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