clipka <ano### [at] anonymousorg> wrote:
> 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.

  I honestly can't understand your continuous argument of "since the mistake
has been done in the past, we should keep doing the same mistake again".

  Why do you want to perpetuate bad choices?

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

  And the photons{} block of an object affects how the object affects the
illumination of other objects. So what?

  Basically what you want is to dump every per-object radiosity-related
setting to the main object definition block, rather than having a clear
'radiosity' block inside it where all the radiosity settings are grouped.

  We have a photons block, a finish block and so on. What would be the
problem with a radiosity block? Resistance to change is not a good argument.

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

  Says who? It fits perfectly in because it affects how radiosity calculations
are performed with respect to that object in question.

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

  Your comparison makes absolutely no sense whatsoever.

  Replicating bad syntax choices is not a good idea (especially when there
is no backwards compatibility to worry about in this case). You can argue
all you like, but you won't change that simple fact.

-- 
                                                          - Warp

Post a reply to this message