 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> There is some point to that - but that choice has been made much, much
> earlier, when "no_shadow", "no_image" and "no_reflection" were
> introduced. Fix those to be more flecible, and I'll happily agree that
> the no_radiosity feature should fall in with them in that more flexible
> syntax.
I honestly can't understand your continuous argument of "since the mistake
has been done in the past, we should keep doing the same mistake again".
Why do you want to perpetuate bad choices?
> There's another difference you're missing here:
> no_radiosity does not affect the radiosity illumination calculation for
> /this/ object - it affects the calculations for /other/ objects. (Just
> like no_shadow affects whether a shadow is seen on /other/ objects, and
> no_reflection, too, affects the effective color seen on some /other/
> object).
And the photons{} block of an object affects how the object affects the
illumination of other objects. So what?
Basically what you want is to dump every per-object radiosity-related
setting to the main object definition block, rather than having a clear
'radiosity' block inside it where all the radiosity settings are grouped.
We have a photons block, a finish block and so on. What would be the
problem with a radiosity block? Resistance to change is not a good argument.
> If ever the radiosity code would be parameterized on a per-object basis
> (and why should it? shouldn't that be part of the material properties?),
> still the "no_radiosity" object flag wouldn't properly fit in.
Says who? It fits perfectly in because it affects how radiosity calculations
are performed with respect to that object in question.
> > The advantage of using a per-object "radiosity {}" block now is that in
> > the future it will be much easier to add new features to it.
> >
> > "Well-established" means absolutely nothing if it's a poor choice. It makes
> > no sense to deliberately drag bad choices.
> It does.
> If you were to program an extension module to a spacecraft control
> software natively working with feet and miles, it would be a bad idea to
> try rewrite the whole smash to use metric units. And it would be
> probably just as bad to insist on writing your module to use metric
> units and convert back and forth.
Your comparison makes absolutely no sense whatsoever.
Replicating bad syntax choices is not a good idea (especially when there
is no backwards compatibility to worry about in this case). You can argue
all you like, but you won't change that simple fact.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> Basically what you want is to dump every per-object radiosity-related
> setting to the main object definition block, rather than having a clear
> 'radiosity' block inside it where all the radiosity settings are grouped.
Let's get some things straight here:
(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/.
(B) We're not talking about "every per-object radiosity-related setting"
- we're talking about /one/ individual flag: "no_radiosity".
(You also want to talk about the "radiosity off" flag, but as far as
that is concerned, I'd actually even advocate moving that into the
finish block and making it a float. Wasn't my call though.)
As for a dedicated radiosity block for future increased flexibility of
radiosity use: Where should it go? The object block? The material block?
The texture block? The finish block?
There might be valid reasons for any of these, so until the time comes
that radiosity /will/ be configurable at a per-whatever basis, just
picking one of those spots more or less at random isn't good advice either.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
I understand how not adding new keywords is desirable, and how the photon model
is more logical, but I think the problem is that the two paths have already
been laid in POV (no_* and the photon {} block). The Megapov patch simply chose
the more "popular" and simple option, and as I said before, it makes immediate
sense to a user. And that's not mentioning "shadowless" which is yet another
way POV has already gone in terms of keywords.
Perhaps, if POV wishes to move more in the photon block direction, there could
be a transitional period that uses both forms - i.e. "no_reflection" and
"reflection { off }". no_shadow, no_image and shadowless don't fit that quite
as well though, but I'm sure something could be thought up that's both clear
and logical.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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/.
> You are basically advocating the former, for the sole reason that someone
> made the poor choice of using that syntax in megapov.
Argain, you're oversimplifying my actions and motivations:
- I'm obviously /not/ advocating the former, because that's photon stuff
and we're discussing radiosity stuff.
- I'm /not/ simply advocating "no_radiosity" either - I'm instead
advocating to /keep/ it as it is.
- 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 /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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
