To summarize:

Changes between 3.7.beta.13 and 3.7.beta.14
--------------------------------------------
Added radiosity on/off flag for objects.


Changes between 3.7.beta.32 and 3.7.beta.33
-------------------------------------------
Added no_radiosity keyword, as known from MegaPOV:
Specifying "no_radiosity" in an object block makes that object invisible
to radiosity rays, ...

What are the differences?

- A test with no_radiosity:
Insert > Scene templates > Radiosity scene
With:

  sphere {
    <0,1,0>, 1
    no_radiosity
  }

I do not know any difference.
Instead "radiosity off" is ok.
I am wrong?

Post a reply to this message

Carlo C. schrieb:
> 
> Changes between 3.7.beta.13 and 3.7.beta.14
> --------------------------------------------
> Added radiosity on/off flag for objects.
> 
> 
> Changes between 3.7.beta.32 and 3.7.beta.33
> -------------------------------------------
> Added no_radiosity keyword, as known from MegaPOV:
> Specifying "no_radiosity" in an object block makes that object invisible
> to radiosity rays, ...
> 
> What are the differences?

Unless I perfectly goofed it up, "radiosity off" prevents an object from 
*receiving* diffuse interreflection (aka radiosity), while 
"no_radiosity" prevents an object from *emitting* diffuse interreflection.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Unless I perfectly goofed it up, "radiosity off" prevents an object from
> *receiving* diffuse interreflection (aka radiosity), while
> "no_radiosity" prevents an object from *emitting* diffuse interreflection.

I have a (little) confusion in my mind...
Now I understand.
Thank you, clipka.

Maybe, just maybe, it might be useful to combine these three options in a single
keyword even with alphanumeric values?

Just a small idea, with no pretensions.
Of course, I'm already so happy. :-)

Post a reply to this message

Carlo C. schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> Unless I perfectly goofed it up, "radiosity off" prevents an object from
>> *receiving* diffuse interreflection (aka radiosity), while
>> "no_radiosity" prevents an object from *emitting* diffuse interreflection.

(I just checked whether it indeed does what I thought it does after 
having seen the code - it does do right that :-))


> Maybe, just maybe, it might be useful to combine these three options in a single
> keyword even with alphanumeric values?
> 
> Just a small idea, with no pretensions.
> Of course, I'm already so happy. :-)

The syntax for "no_radiosity" was chosen to (a) match the megapov 
syntax, and (b) fit into the family of no_shadow, no_reflection and 
no_image keywords, which all basically say, "for the sake of 
[shadow/reflection/image/radiosity] rays, this object does not exist", 
to be consistent there (which was also probably the motivation for the 
megapov syntax).

The "radiosity off" syntax already existed at that time, so it was just 
left unchanged. It's a bit "dangling" I think.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Carlo C. schrieb:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Unless I perfectly goofed it up, "radiosity off" prevents an object from
> >> *receiving* diffuse interreflection (aka radiosity), while
> >> "no_radiosity" prevents an object from *emitting* diffuse interreflection.
>
> (I just checked whether it indeed does what I thought it does after
> having seen the code - it does do right that :-))


Ach komm, das gibt's doch nicht! :-)


> The syntax for "no_radiosity" was chosen to (a) match the megapov
> syntax, and (b) fit into the family of no_shadow, no_reflection and
> no_image keywords, which all basically say, "for the sake of
> [shadow/reflection/image/radiosity] rays, this object does not exist",
> to be consistent there (which was also probably the motivation for the
> megapov syntax).
>
> The "radiosity off" syntax already existed at that time, so it was just
> left unchanged. It's a bit "dangling" I think.


I fully understand the reasons.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Unless I perfectly goofed it up, "radiosity off" prevents an object from 
> *receiving* diffuse interreflection (aka radiosity), while 
> "no_radiosity" prevents an object from *emitting* diffuse interreflection.

  It feels quite confusing. How about reusing existing keywords for a
clearer syntax:

radiosity { emission on/off }
radiosity { collect on/off }

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   It feels quite confusing. How about reusing existing keywords for a
> clearer syntax:
> 
> radiosity { emission on/off }
> radiosity { collect on/off }

How about sticking to the established megapov syntax, hm?

Post a reply to this message

clipka wrote:
> Warp schrieb:
>>   It feels quite confusing. How about reusing existing keywords for a
>> clearer syntax:
>>
>> radiosity { emission on/off }
>> radiosity { collect on/off }
> 
> How about sticking to the established megapov syntax, hm?

Compatibility to MegaPOV should be of *no* concern when porting a patch or 
feature over to official POV-Ray. Consistency and avoiding new keywords when 
reasonable should be the primary conditions for syntax decisions.

	Thorsten, POV-Team

Post a reply to this message

Thorsten Froehlich schrieb:
> Compatibility to MegaPOV should be of *no* concern when porting a patch 
> or feature over to official POV-Ray. Consistency and avoiding new 
> keywords when reasonable should be the primary conditions for syntax 
> decisions.
> 
>     Thorsten, POV-Team

Though I generally consider this a reasonable position, in this 
particular case there was a reason for the MegaPOV patch to use this 
particular syntax and not a different one, touching one of the very 
points mentioned: Consistency, in this case with the other 
"no_something" keywords.

So using any other syntax as that used in MegaPOV would have meant...:

- breaking consistency among the "no_something" family of keywords

- having to invent a new syntax from scratch

- with not much of a precendence case to orient on

- and with the syntax "radiosity off" already being in use for another 
very different feature.

Plus, as already mentioned, sacrificing the opportunity to use a syntax 
already familiar to the users of a very famous POV-Ray patch - which of 
course would not be sufficient alone, but I think it quite well rounds 
off the whole thing.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Though I generally consider this a reasonable position, in this 
> particular case there was a reason for the MegaPOV patch to use this 
> particular syntax and not a different one, touching one of the very 
> points mentioned: Consistency, in this case with the other 
> "no_something" keywords.

  Just because "no_something" is used for some features doesn't mean the
syntax is sound for all possible such features.

  Take, for instance, photon mapping. There's no "no_photons" keyword.
There is "photons { pass_through }" and "photons { collect off }", and
for good reasons.

  I see radiosity being more akin to photon mapping than to things like
no_image and no_reflection.

> - breaking consistency among the "no_something" family of keywords

  Photon mapping already "breaks consistency". Except that it doesn't.
Artificially forcing a feature to the same mold as some other feature
is not always a good idea. With photon mapping the different syntax is
justified, and IMO so it is with radiosity.

> - having to invent a new syntax from scratch

  I fail to see how that is a bad thing. If the new syntax is *better*
and easier to understand, it's definitely a *good* thing, not a bad one.

> - with not much of a precendence case to orient on

  Wrong. See photon mapping.

> Plus, as already mentioned, sacrificing the opportunity to use a syntax 
> already familiar to the users of a very famous POV-Ray patch - which of 
> course would not be sufficient alone, but I think it quite well rounds 
> off the whole thing.

  Just because an unofficial patch has made poor choices in syntax doesn't
mean those same poor choices must be replicated in the official version.

-- 
                                                          - Warp

Post a reply to this message