nemesis schrieb:
> Agreed.  no_radiosity sounds perfectly clear and fitting with the other no_*
> keywords.  radiosity off is awkward though.  radiosity { collect on/off
> pass_through } would probably be better, but I guess it's also harder to
> implement?

Not really. That would be maybe 20 lines of quite boring standardized 
code in the parser (unless you want the effect to be different as well).

> The call for consistency doesn't sound right when there are several things that
> don't sound much logical within povray but are there anyway.  Diffuse and
> ambient terms meaning different things in the standard lighting model and the
> radiosity one comes to mind.  I mean, ambient in the standard model controls the
> amount of (constant) ambient lighting an object gets, while under radiosity it
> means how much it contributes!

I perfectly agree with you here. If it was my call, I'd go for a 
separate "emission" term or some such. (Maybe wrapped in a radiosity {} 
block, but I think that would be in the way in case someone decided to 
add an alternative to radiosity, which is actually just one of many 
possible algorithms to compute diffuse interreflections.)

 > Diffuse supposedly is the amount of diffuse
> reflection and object sends off, that's what should be used or at least sounds
> more logical to me.

There is some justification to the ambient term in a non-radiosity 
world, as it allows to tweak how much ambient light an individual object 
receives - to manually achieve exactly the same (well, within quite 
notable limitations) what radiosity promises to compute automatically.

However, it should therefore actually be an object property, not a 
finish thing. And it should be perfectly ignored for radiosity.


Speaking of which, how about a

     ambient COLOUR
     ambient radiosity

statement for the object block, to indicate whether ambient light should 
use a constant value, or be computed via radiosity instead?

Or it could also be a block, such as:

     ambient {
       radiosity on|off
       quick_colour COLOUR
     }

to specify whether it should be computed using radiosity (if switched on 
  globally), and what brightness level to use if radiosity is off.

(The quick_colour setting could also be taken into account when maximum 
radiosity recursion depth is reached. At present, the radiosity code 
presumes zero ambient input for such purposes, which is not the optimal 
solution.)

(Just quick drafts though.)

Post a reply to this message