Warp schrieb:

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

I think your assertion that radiosity would work just about the same as 
photons makes clear enough how. Radiosity is /not/ photon mapping, and 
it is /very/ different. Both use a cache, but that's all - even the 
structure of the cache differs extremely.

There is no /exactly/ telling how this gives a wrong assumption, because 
  the main effect is that it will just /enhance/ a general vague feeling 
of "oh, radiosity and photon mapping, they're almost the same".


>   If I say "radiosity { emission off }", I think it's rather obvious and
> intuitive that this object will not emit any radiosity lighting.

Are you sure it doesn't just turn off the effect of this object's 
/ambient/ on radiosity?

That's what /I/ would possibly expect as a new user.

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

... or, as you /literally/ say, only the /storing/ of radiosity samples 
will be inhibited?


How about something like

illuminated_by {
   group_lights   yes
   global_lights  yes
   radiosity      yes
   photons        no
}
affects {
   radiosity      yes
   photons        no
   shadows        no
}

/That/ is something I'd call logical and obvious. But it would obviously 
involve changing more than just radiosity-related stuff, and require 
introduction of even more new keywords, and therefore I'd suggest to 
postpone that to POV-Ray 4.


>   "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?

It is /not/ confusing if you're familiar with the other "no_something" 
keywords.


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

How do you suggest to /implement/ that anyway? The radiosity sample 
cache and lookup algorithm rely on a spatial organization of samples, 
not on a per-object organization.

In the near future, I instead see applications for specific radiosity 
parameters in totally different areas. For instance, a radiosity setting 
for normal blocks, to override the "normal on" global setting.

And I'd also love to change the finish {...} syntax with regards to 
ambient, to root out the ugly mess it causes to radiosity, but that's a 
different story.


And yes, if the new settings would /configure/ the radiosity code, then 
I would definitely want to go for a "radiosity { ... }" syntax.

The "no_radiosity" keyword does /not/ configure the radiosity code at 
all - it configures the intersection testing code instead.


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

Well, maybe you should have shouted a bit louder back in May 2006, when 
the "radiosity no" statement (which prevents an object to be illuminated 
by radiosity) made its way into 3.7 in the first place. But why don't 
you discuss that with Thorsten Froehlich himself...

Post a reply to this message