Warp schrieb:
>> There is no such thing as a "collect on|off" or "emission on|off" in the 
>> specular (inter-)reflection block, so why should there be such a thing 
>> for diffuse interreflection?
> 
>   Because radiosity settings are a whole lot more complicated than some
> specular settings and thus deserve their own block, just like photons.

No, actually for any particular surface or object, the radiosity 
settings are even simpler than the diffuse settings (because they take 
part of the information from there).

In contrast to the photons algorithm, which /needs/ per-object settings 
to be anywhere close to performant, there's virtually only one single 
reason for the per-object or per-material settings currently implemented 
- and that's the same as for the no_reflection, no_shadow or no_image: 
Pure artistic choice.

>   It is a very poor choice. Do you know why? Because it's rigid and hard
> to expand.

There is some point to that - but that choice has been made much, much 
earlier, when "no_shadow", "no_image" and "no_reflection" were 
introduced. Fix those to be more flecible, and I'll happily agree that 
the no_radiosity feature should fall in with them in that more flexible 
syntax.

>   If in the future support for new per-object radiosity settings is added,
> what are you going to do? Add new keywords to be used in the main object
> definition?

There's another difference you're missing here:

no_radiosity does not affect the radiosity illumination calculation for 
/this/ object - it affects the calculations for /other/ objects. (Just 
like no_shadow affects whether a shadow is seen on /other/ objects, and 
no_reflection, too, affects the effective color seen on some /other/ 
object).

If ever the radiosity code would be parameterized on a per-object basis 
(and why should it? shouldn't that be part of the material properties?), 
still the "no_radiosity" object flag wouldn't properly fit in.

Maybe a "visibility {}" block would be a proper container for those flags.

>   The advantage of using a per-object "radiosity {}" block now is that in
> the future it will be much easier to add new features to it.
> 
>   "Well-established" means absolutely nothing if it's a poor choice. It makes
> no sense to deliberately drag bad choices.

It does.

If you were to program an extension module to a spacecraft control 
software natively working with feet and miles, it would be a bad idea to 
try rewrite the whole smash to use metric units. And it would be 
probably just as bad to insist on writing your module to use metric 
units and convert back and forth.

Post a reply to this message