clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> > 
> >   Compare the situation to how it would be with photons. What is clearer and
> > less confusing, this:
> > 
> >     photons off
> >     no_photons
> > 
> > or this:
> > 
> >     photons { collect off }
> >     photons { pass_through }

> Ut is moot to argue about which would be clearer, because the latter is 
> how it /is/, and it is /ok/.

  I don't understand how your argument makes sense. Just because something
has been implemented in a certain way doesn't automatically make it "ok".
A syntax doesn't become "ok" if it gets implemented.

> - I'm obviously /not/ advocating the former, because that's photon stuff 
> and we're discussing radiosity stuff.

  From the user's point of view they are very similar concepts. Both are
related to lighting, and in both cases the syntax is used to say something
about how the object should behave with respect to that lighting technique
in particular.

  You write like photon mapping and radiosity had nothing in common, and
thus using similar syntax in both makes no sense. On the contrary, they
are extremely similar in concept, and thus a similar syntax does make a
lot of sense.

> - I'm /not/ simply advocating "no_radiosity" either - I'm instead 
> advocating to /keep/ it as it is.

  Those are the exact same thing.

> - Your statement fails to acknowledge that the I've presented /more/ 
> arguments than just "it's done that way in megapov". You may not /agree/ 
> with them, but they /are/ additional reasons.

  I don't see something like "it requires implementing additional syntax"
to be any reason of any kind. The purpose is to make POV-Ray easier to use,
not to save a half hour of the life of a source code programmer.

> I /am/ advocating to /keep/ "no_radiosity" as it /is/ implemented (in 
> genuine POV-Ray!) right now, for the simple reason of /lack of a better/ 
> solution.

  You insist that "there is no better solution" for no good reason. You
don't even aknowledge that the current solution is poor, and thus you don't
even seem to think a better solution is needed. No wonder why you think that
there's a lack of a better solution.

> And no, I will /not/ acknowledge "radiosity { collect no|off emit on|off 
> }" as a good solution: Both terms are purely technical ones, that make 
> sense in the context of photon mapping alone, and only for someone who 
> knows how photon mapping works - outside of that domain they're just 
> plain nonsense (in real life, if I heard something about an object 
> "collecting" photons, I would probably think of phosphorescence or the 
> like). And in the context of radiosity they make no sense either - worse 
> yet, they may lead to wrong assumptions about how radiosity works (there 
> exist enough such wrong assumptions already), implying that there would 
> be any similarity with photon mapping.

  Exactly how does it give the wrong assumption about how radiosity works?

  If I say "radiosity { emission off }", I think it's rather obvious and
intuitive that this object will not emit any radiosity lighting. If I say
"radiosity { collect off }", I think it's rather obvious that radiosity
samples are not "stored" for this object, in other words, radiosity lighting
will not illuminate this object.

  Why would this give the wrong assumption about how radiosity works? That
*is* how radiosity works.

  "no_radiosity" is confusing. Does it mean that the object is not illuminated
by radiosity lighting? Or does it mean that it won't emit radiosity lighting?
What about "radiosity off"? Which one does that mean? How are those two things
different?

  Those keywords are not descriptive. The only way you can know what they do
is to either associate them with other keywords and make an assumption, and
wild-guess the meaning of the other one.

  And as I already said, if in the future new per-object radiosity settings
are added, what do you suggest should be done about that? Invent some new
keywords to be used in the object definition main block? How many such
keywords must be added before it becomes too much?

  Let's assume (just hypothetically) that we want to add support for
changing the number of radiosity samples on a per-object basis. How do
you suggest we do that? Add a new 'radiosity_samples' keyword? What if
we want to change the error_bound on a per-object basis? Add a new
'radiosity_error_bound' keyword? (And please don't start nitpicking on
technical details about whether it's feasible to do this with the current
radiosity algorithm. These were just *examples*.)

  We quickly see that using a per-object "radiosity {}" block is called for.

  Better to add it *now*, when backwards compatibility is not an issue,
than try to hack it in years from now, when it will be too late.

-- 
                                                          - Warp

Post a reply to this message