"Edouard" <pov### [at] edouardinfo> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > clipka <ano### [at] anonymousorg> wrote:
> > > (A) There is nothing I actively /want/ - In case you didn't notice, this
> > > is how it /is/ implemented right now. The one who /wants/ a change is /you/.
> >
> >   The question is about clarity and flexibility. The current solution is
> > confusing (as demonstrated by the original post) and inflexible.
> >
> >   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 }
> >
> >   You are basically advocating the former, for the sole reason that someone
> > made the poor choice of using that syntax in megapov.
>
> I've got to say, as a user, the no_radiosity keyword was immediately obvious,
> and followed clearly in the same model as no_shadow, no_reflection, etc. The
> mental model I have is that all objects use all the rendering features, but you
> have the option to turn specific ones off with the no_* keywords. Also
> no_bump_scale follows this pattern.
>
> Radiosity has to turned on globally, but then it affects everything just like
> shadows and reflection do.
>
> Photons have to be turned on per object, which differs from the other rendering
> effects.

Agreed.  no_radiosity sounds perfectly clear and fitting with the other no_*
keywords.  radiosity off is awkward though.  radiosity { collect on/off
pass_through } would probably be better, but I guess it's also harder to
implement?

The call for consistency doesn't sound right when there are several things that
don't sound much logical within povray but are there anyway.  Diffuse and
ambient terms meaning different things in the standard lighting model and the
radiosity one comes to mind.  I mean, ambient in the standard model controls the
amount of (constant) ambient lighting an object gets, while under radiosity it
means how much it contributes!  Diffuse supposedly is the amount of diffuse
reflection and object sends off, that's what should be used or at least sounds
more logical to me.

BTW, I realize now why povray doesn't get more patches and evolves so slowly...

Post a reply to this message

nemesis schrieb:
> Agreed.  no_radiosity sounds perfectly clear and fitting with the other no_*
> keywords.  radiosity off is awkward though.  radiosity { collect on/off
> pass_through } would probably be better, but I guess it's also harder to
> implement?

Not really. That would be maybe 20 lines of quite boring standardized 
code in the parser (unless you want the effect to be different as well).

> The call for consistency doesn't sound right when there are several things that
> don't sound much logical within povray but are there anyway.  Diffuse and
> ambient terms meaning different things in the standard lighting model and the
> radiosity one comes to mind.  I mean, ambient in the standard model controls the
> amount of (constant) ambient lighting an object gets, while under radiosity it
> means how much it contributes!

I perfectly agree with you here. If it was my call, I'd go for a 
separate "emission" term or some such. (Maybe wrapped in a radiosity {} 
block, but I think that would be in the way in case someone decided to 
add an alternative to radiosity, which is actually just one of many 
possible algorithms to compute diffuse interreflections.)

 > Diffuse supposedly is the amount of diffuse
> reflection and object sends off, that's what should be used or at least sounds
> more logical to me.

There is some justification to the ambient term in a non-radiosity 
world, as it allows to tweak how much ambient light an individual object 
receives - to manually achieve exactly the same (well, within quite 
notable limitations) what radiosity promises to compute automatically.

However, it should therefore actually be an object property, not a 
finish thing. And it should be perfectly ignored for radiosity.


Speaking of which, how about a

     ambient COLOUR
     ambient radiosity

statement for the object block, to indicate whether ambient light should 
use a constant value, or be computed via radiosity instead?

Or it could also be a block, such as:

     ambient {
       radiosity on|off
       quick_colour COLOUR
     }

to specify whether it should be computed using radiosity (if switched on 
  globally), and what brightness level to use if radiosity is off.

(The quick_colour setting could also be taken into account when maximum 
radiosity recursion depth is reached. At present, the radiosity code 
presumes zero ambient input for such purposes, which is not the optimal 
solution.)

(Just quick drafts though.)

Post a reply to this message

Warp schrieb:
>> 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.
> 
>   I'm talking about the user's point of view (which seems something you
> are unable to grasp). It doesn't matter how different the implementation
> is inside the source code.

But that's exactly the point I'm trying to make: The user's perception 
of radiosity is somewhat skewed in general, and using photon-alike 
keywords would really not improve that situation at all.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> > radiosity { emission on/off }
> > radiosity { collect on/off }

> I agree with having a radiosity{} block instead of no_radiosity.
> "no_radiosity" and "radiosity off" sound like two ways of saying the same
> thing, which they definitely aren't.

> But I think we need clearer keywords than emission and collect. As clipka
> says, an object only "emits" if it has a positive ambient value. If an
> object A reflects radiosity from object B onto object C, I wouldn't say
> object A is "emitting" anything.

  I chose keywords primarily because they are existing ones (and thus
wouldn't require adding new keywords to the parser) and because they were
the first ones which came to mind. I don't have any objection in something
even clearer being used. My point was, however, the idea of making the
radiosity settings be in its own block, similar to how photon, pigment,
finish and normal settings are. This makes it more flexible and expandable
in the future.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> 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.
> > 
> >   I'm talking about the user's point of view (which seems something you
> > are unable to grasp). It doesn't matter how different the implementation
> > is inside the source code.

> But that's exactly the point I'm trying to make: The user's perception 
> of radiosity is somewhat skewed in general, and using photon-alike 
> keywords would really not improve that situation at all.

  You fail to explain why does it matter if the user has no full knowledge
of the internal details of radiosity.

  Most users don't know the exact formula to calculate, for example,
the 'granite' pattern. That doesn't stop then from using that pattern
effectively.

-- 
                                                          - Warp

Post a reply to this message

clipka schrieb:

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

Well - since i have originally chosen the SDL syntax for this feature in 
MegaPOV i thought i'd put in my 2 cents.

I have no issue with either of these two ways per se.  I however think 
that both Warp's and clipka's arguments are not particularly convincing.

My choice was simply for the IMO most obvious way from my perspective as 
a programmer and POV-Ray user given the state of the SDL in 3.6.  This 
does not make it a perticularly good choice from a broader perspective 
of course.

The SDL is - due to the repeating addition of new features - 
inconsistent in many parts.  Some aspects of this have been mentioned in 
this thread, others have not.  Using the photons syntax is not 
necessarily a better idea than the no_* syntax - radiosity is different 
from photons both the way it works technically as the way it is used. 
OTOH the reuse of keywords is a good idea and the possibility to extend 
the syntax with new features is as well.

This is not about choosing the good way as opposed to the bad way.  Both 
syntax versions bear inconsistencies (heck even skipping this feature 
completely would).  If you cannot come to an agreement simply flip a 
coin... ;-)

BTW i think the no_radiosity implementation in MegaPOV is in fact 
incompatible with POV-Ray 3.6 since no_image in 3.6 implied no_radiosity 
and in MegaPOV it does not.  I am not completely sure about this any 
more though.

As a side note one somewhat related feature i have missed occasionally 
is something like a no_image flag that maintains the objects 'ability' 
to hide other surfaces (other objects or other surface parts of itself) 
from direct view.  Combined with alpha channel output this could be used 
to render individual layers of certain features of a scene.

-- Christoph

Post a reply to this message

Warp schrieb:

>   You fail to explain why does it matter if the user has no full knowledge
> of the internal details of radiosity.
> 
>   Most users don't know the exact formula to calculate, for example,
> the 'granite' pattern. That doesn't stop then from using that pattern
> effectively.

Say, just how many parameters does the "granite" pattern have for 
performance tuning?

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> The SDL is - due to the repeating addition of new features - 
> inconsistent in many parts.  Some aspects of this have been mentioned in 
> this thread, others have not.  Using the photons syntax is not 
> necessarily a better idea than the no_* syntax

  I would like to make it clear that I didn't suggest a block syntax for
radiosity settings because photon settings have that too, or because I thought
that radiosity was similar to photons. In fact, I wasn't thinking about the
photon mapping feature at all when I made the suggestion. It was only later
in the thread that I came up with the comparison with photon mapping.

  The basic idea was to use a block syntax to group different radiosity
settings consistently and clearly. The photon settings are a good example
of this (but, as I said, not the reason why I suggested it in the first
place).

  If there was one single per-object radiosity setting, then "no_radiosity"
would be ok. However, there are already two, and it isn't completely
unthinkable that in the future perhaps more will be added. Thus it would
be a good idea to take that into account now, when it's still possible.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> > 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.

Most of wich actually ended in POV-Ray due to previous smaller MegaPOV 
patches being applied without enough thought (in part my fault there, of 
course). Much better than a "no_something" would be a "something [on]" 
as default and users then using "something off".

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

But not a 3.6 feature, and in the beta it can be changed, and should be 
changed if it turns out to be unsuitable.

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

Well, I have to admit I prefer Warp's suggestion to keep this in a 
radiosity block per object similar to interior, media, photons, etc.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Well, I have to admit I prefer Warp's suggestion to keep this in a 
> radiosity block per object similar to interior, media, photons, etc.

  I don't know if it's a good idea, but one possible compromise is to keep
the "no_radiosity" keyword as it is now, and add everything else to a
"radiosity {}" block.

  But maybe that introduces a logical inconsistency.

-- 
                                                          - Warp

Post a reply to this message