 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>
> I see radiosity being more akin to photon mapping than to things like
> no_image and no_reflection.
Um... no.
Radiosity is actually just cached diffuse reflections, nothing else.
It's the forward-raytracing component that places photon mapping
seriously off the grid.
There is no such thing as a "collect on|off" or "emission on|off" in the
specular (inter-)reflection block, so why should there be such a thing
for diffuse interreflection?
> 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.
It isn't a poor choice from my seat, for the reasons already explained,
and in that light I do think that the syntax of a well-established
unfficial patch should be favored over an otherwise equally good but
newly invented syntax.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Warp schrieb:
> >
> > I see radiosity being more akin to photon mapping than to things like
> > no_image and no_reflection.
>
> Um... no.
>
> Radiosity is actually just cached diffuse reflections, nothing else.
> It's the forward-raytracing component that places photon mapping
> seriously off the grid.
>
> There is no such thing as a "collect on|off" or "emission on|off" in the
> specular (inter-)reflection block, so why should there be such a thing
> for diffuse interreflection?
>
> > 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.
>
> It isn't a poor choice from my seat, for the reasons already explained,
> and in that light I do think that the syntax of a well-established
> unfficial patch should be favored over an otherwise equally good but
> newly invented syntax.
this is my irrelevant view...
But photons and radiosity in "global_settings" are already very similar!
Making radiosity syntax more similar to photons (outside "global_settings")
would not be all bad...
I find that the idea of Warp is slightly better that syntax "no_..." for
radiosity.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >
> > I see radiosity being more akin to photon mapping than to things like
> > no_image and no_reflection.
> Um... no.
> Radiosity is actually just cached diffuse reflections, nothing else.
> It's the forward-raytracing component that places photon mapping
> seriously off the grid.
It doesn't matter how radiosity is implemented internally. From the syntax
point of view the important thing is how the user perceives it.
> There is no such thing as a "collect on|off" or "emission on|off" in the
> specular (inter-)reflection block, so why should there be such a thing
> for diffuse interreflection?
Because radiosity settings are a whole lot more complicated than some
specular settings and thus deserve their own block, just like photons.
> > 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.
> It isn't a poor choice from my seat, for the reasons already explained,
> and in that light I do think that the syntax of a well-established
> unfficial patch should be favored over an otherwise equally good but
> newly invented syntax.
It is a very poor choice. Do you know why? Because it's rigid and hard
to expand.
If in the future support for new per-object radiosity settings is added,
what are you going to do? Add new keywords to be used in the main object
definition?
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>> There is no such thing as a "collect on|off" or "emission on|off" in the
>> specular (inter-)reflection block, so why should there be such a thing
>> for diffuse interreflection?
>
> Because radiosity settings are a whole lot more complicated than some
> specular settings and thus deserve their own block, just like photons.
No, actually for any particular surface or object, the radiosity
settings are even simpler than the diffuse settings (because they take
part of the information from there).
In contrast to the photons algorithm, which /needs/ per-object settings
to be anywhere close to performant, there's virtually only one single
reason for the per-object or per-material settings currently implemented
- and that's the same as for the no_reflection, no_shadow or no_image:
Pure artistic choice.
> It is a very poor choice. Do you know why? Because it's rigid and hard
> to expand.
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.
> If in the future support for new per-object radiosity settings is added,
> what are you going to do? Add new keywords to be used in the main object
> definition?
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).
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.
Maybe a "visibility {}" block would be a proper container for those flags.
> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
