 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> 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.
It's quite simple:
You want to change something? Then /you/ must provide a reason which is
sufficiently /stronger/ than any arguments to keep it.
You want to /keep/ something? Then you only need to provide a reason
which is about as strong than any arguments to change it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>> - 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.
And /again/ it seems that /you/ try to define what /my/ arguments are -
or you're not even reading them. Either way, it is /no/ way to discuss!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> 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.
The way 3.7 is going, I halfway expect it to be renamed 4.0 around beta 50. :-D
Snarky one-liner aside, I'd say that introducing this into 3.7 - and then
deprecating the old syntax for 4 - would probably be the best way to handle it.
Just because we're looking down the barrels of a major version number change in
the (hopefully not too distant) future doesn't mean that introducing new items
to the syntax needs to hold off (god knows enough stuff gets introduced at
non-x.0 versions with new and/or different syntax).
My (probably unwanted) opinion, your mileage may and will vary depending on
radiation pressure on your windshield, etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
