 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Wed, 04 Oct 2000 18:10:40 +0200, Fabien Mosen wrote:
> >The "virtual" slope (normal perturbation) at that point will
> >always be the same, regardless of the camera position.
>
> But the appearance of the surface due to that perturbation will vary with
> camera position and lighting.
As is the appearance of the pigment, whose perception is influenced
by the normal of the surface, the lights...
> >However, the finish value returned (coming from reflection,
> >in that example) will be different with a different camera.
>
> Not true. Only the appearance of the surface due to the finish will vary.
> The finish itself is constant.
The *definition* of the finish is constant troughout space, but
the resulting finish value, the one that will contribute to the
final aspect, varies with the camera position.
Imagine a scene without a camera. Can you get the pigment value
of a suface's point ? Yes. Can you get the normal at that point ?
Yes. Can you get the color variation caused by reflection at that
point ? No !
As I said earlier, pigment and normal needs a pattern (plain color
pigment being a case where the color_map has an unique value), while
finish isn't based on patterns.
That's why I think that pigment and normal belongs to the same
level, as they have similar workings, but finish is a different
beast.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fabien Mosen" wrote:
> Rune wrote:
>
> > Pigment doesn't require a pattern and a map. In fact it's
> > very common to specify just a plain colour.
>
> The plain color case is an exception in the syntax.
> It's not very annoying, but there might be a better way to do it.
So you're saying, "a difference between pigment and finish is that pigment
requires a pattern, except when it doesn't".
> > Normal doesn't require a pattern and a map either. The default
> > is a plain normal (which is usually achieved by simply not
> > specifying the normal).
>
> No. A "plain normal" can't exist, as a normal is a variation !
Wrong. The normal is a vector which points away from the surface and is
perpendicular to it. When you specify a normal with a pattern, POV-Ray
artificially modifies this normal vector. But it's there no matter if you
modifies it or not!
> > Pigment and normal doesn't require a pattern - on the other
> > hand, if finish_map was implemented, pigment, normal, and finish
> > would indeed be very coherent.
>
> No. Pigment and normal values rely on the position of the texture's
> point in space, while finish rely on the normal value, light positions
> and other objects positions.
There is no such thing as a pigment value. There are colour vectors that are
controlled by the pigment statement.
There is no such thing as a normal value. There are normal vectors that are
controlled by the normal statement.
There is no such thing as a finish value. There's the ambient value, the
diffuse value, the phong, reflection, brilliance, and metallic values, and a
whole lot of other values. None of those values are dependent on light
positions or other objects' positions or anything. (If I specify reflection
to be 0.6, then it is 0.6 independent on other objects.)
> Put otherwise, pigment and normal are "global" properties
> (doesn't change with the point of view), while finish
> is a "local" (change with the point of view) property.
> They do not belong to the same hierarchy level.
I think what you mean is that the *appearance* of the finish is dependant on
lights, objects, etc.
But the appearances of the pigment and normal are also dependent on those
things. If I make a pigment with a white colour it will look red if I have a
red light_source only. If I make a bumpy normal I can't see the bumps if the
object is in shadow.
So you see, everything is dependent on each other, not just the finish.
> A proof of that ? With MegaPOV, you can obtain the value of a pigment
> at some point with "eval_pigment", but there's absolutely no way to
> get the finish value of a point in space.
As I said, there is no such thing as a finish value.
Besides, you can't obtain the normal vector at some point either, so you
have no "proof".
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 1)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fabien Mosen" wrote:
> Imagine a scene without a camera. Can you get the pigment value
> of a suface's point ? Yes. Can you get the normal at that point ?
> Yes. Can you get the color variation caused by reflection at that
> point ? No !
You can't compare like that! Either you must compare the *values* of
pigment, normal, and finish. *OR* you must compare the *appearance* of
pigment, normal, and finish.
You can't compare the *values* of pigment and normal with the *appearance*
of finish. That doesn't make sense.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 1)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> > No. A "plain normal" can't exist, as a normal is a variation !
>
> Wrong. The normal is a vector which points away from the surface and is
> perpendicular to it. When you specify a normal with a pattern, POV-Ray
> artificially modifies this normal vector. But it's there no matter if you
> modifies it or not!
I meant that the normal {..} can't be plain. I wasn't speaking of
the general normal of a surface, but of the perturbated normal
obtained by the normal {..} statement.
Thus, the default is rather "no perturbation".
> There is no such thing as a pigment value. There are colour vectors that are
> controlled by the pigment statement.
There IS ! It is the rgbft value of the color at a given space point
(that value being determined by the pattern, color_map, and
transformations).
> There is no such thing as a normal value. There are normal vectors that are
> controlled by the normal statement.
There IS ! It is the slope value at a given point of a surface.
(that value being determined by the pattern values at adjacent points of
the surface, and transformations).
> There is no such thing as a finish value.
Guess what ? There IS ! It is the rgb value of the color that will
be added to the others texture elements at a given point of a surface,
that value being determined by the finish definition (amount of
reflection, etc..), the normal of the surface at that point,
AND the camera, lights, objects positions.
> There's the ambient value, the
> diffuse value,
> Ambient and diffuse are
> the phong, reflection, brilliance, and metallic values, and a
> whole lot of other values. None of those values are dependent on light
> positions or other objects' positions or anything. (If I specify reflection
> to be 0.6, then it is 0.6 independent on other objects.)
That is the DEFINITION, not the resulting value !!
(and, BTW, ambient and diffuse shouldn't be in finish, since they are
view-independent)
When POV-Ray searches the finish value for a pixel, it doesn't search
the "0.6", since it *already* knows that, it searchs for the color of
the reflected ray, which will be multiplied by 0.6 before being
"incorporated" with the pigment and normal values.
> But the appearances of the pigment and normal are also dependent on those
> things. If I make a pigment with a white colour it will look red if I have a
> red light_source only.
> So you see, everything is dependent on each other, not just the finish.
The finish is MORE fundamentally dependant on those things, since it
needs camera/lights/objects data to give its value for some point of
a surface. Pigment and normal have an independant value, which is,
later,
affected by environment. So, finish RELY on environment, while pigment
and normal are AFFECTED by environment.
> Besides, you can't obtain the normal vector at some point either, so you
> have no "proof".
You could obtain the normal at some point of a surface. It's not
availiable, but it's possible (you "just" have to interpolate
the values of adjacent points on the surface).
In fact, a simple macro using 'trace' and 'eval_pattern' could give
you that value, but it's impossible (or tell me how) to get the
equivalent
finish information.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> You can't compare the *values* of pigment and normal with the *appearance*
> of finish. That doesn't make sense.
I compared values with values. See my previous post to see what
is, to me, the value of a finish.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fabien Mosen" wrote:
> > None of those values are dependent on light positions or other
> > objects' positions or anything. (If I specify reflection to be
> > 0.6, then it is 0.6 independent on other objects.)
>
> That is the DEFINITION, not the resulting value !!
> When POV-Ray searches the finish value for a pixel, it doesn't
> search the "0.6", since it *already* knows that, it searchs for
> the color of the reflected ray, which will be multiplied by 0.6
> before being "incorporated" with the pigment and normal values.
So what you're looking at is the resulting value; in other words the colour
value seen by the camera.
In that case, in order to compare, you also have to see at the resulting
value for the pigment and for the normal.
The problem is, it doesn't make sense. You can't separate the resulting
colour of pigment, normal and finish from each other, because they're all
dependent on each other and on external conditions.
> (and, BTW, ambient and diffuse shouldn't be in finish, since
> they are view-independent)
Well there you go. Where should they go then, if not in the finish? And what
about brilliance? And what is it anyway that makes you think that finish =
view-dependent?
> The finish is MORE fundamentally dependant on those things, since it
> needs camera/lights/objects data to give its value for some point of
> a surface.
No. A pigment has a colour no matter if there's any light_sources (or
cameras) or not. But you can only see it if there's light and camera.
Similarly, a finish has a reflection value etc., no matter if there's any
light_sources (or cameras) or not. But here too, you can only see it if
there's light and camera.
They're very coherent.
> Pigment and normal have an independent value, which is,
> later, affected by environment.
No, you can't see your pigment if there's no camera and light_sources.
> So, finish RELY on environment, while pigment
> and normal are AFFECTED by environment.
Your arguments just don't make sense.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 1)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> So what you're looking at is the resulting value; in other words the colour
> value seen by the camera.
No, I'm looking for the value BEFORE it's finally affected by the
projection system.
> The problem is, it doesn't make sense. You can't separate the resulting
> colour of pigment, normal and finish from each other, because they're all
> dependent on each other and on external conditions.
finish value depends, amongst other things, on normal (normal of the
object's surface + normal {..} perturbation). That's the only
inter-dependance. They don't "depend on each other". Pigment and
normal are independant from each other and from finish, and finish
is independant from pigment.
Oh, BTW, interior {ior} depends on normal perturbation (it
affects the refracted ray). Would you, because of that, put
the "interior" statement inside the "texture" statement ?
> > (and, BTW, ambient and diffuse shouldn't be in finish, since
> > they are view-independent)
>
> Well there you go. Where should they go then, if not in the finish?
Good question. Historically, "finish" has been fed with many
features that didn't fit elsewhere. "crand" is an example of
that. ambient, diffuse and brillance might go into a separate
statement, (maybe "lighting") which describes how the surface
reacts to light.
You know, I don't intend to criticize, and the current system
works fine, but some design flaws are there, and are worth
discussing, especially in the perspective of future enhancements.
> And what is it anyway that makes you think that finish =
> view-dependent?
I explained myself in great lenghts about that.
> No. A pigment has a colour no matter if there's any light_sources (or
> cameras) or not. But you can only see it if there's light and camera.
I can ask POV-Ray to retrieve it and put the rgb value on-screen,
without even rendering ! I can do the same (with a macro) for the
normal perturbations. However, I can't do it for finishes. If
you can, tell me how.
> Similarly, a finish has a reflection value etc.,
A reflection AMOUNT, which, with a camera, light, and object, can
result into a rgb value at a given point.
> > Pigment and normal have an independent value, which is,
> > later, affected by environment.
>
> No, you can't see your pigment if there's no camera and light_sources.
See above. I can retrieve the value.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 Oct 2000 22:56:40 +0200, Fabien Mosen wrote:
>
>I can ask POV-Ray to retrieve it and put the rgb value on-screen,
>without even rendering ! I can do the same (with a macro) for the
>normal perturbations. However, I can't do it for finishes. If
>you can, tell me how.
Using a feature that doesn't exist. Just because it doesn't exist
doesn't mean it's not possible.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Wed, 04 Oct 2000 22:56:40 +0200, Fabien Mosen wrote:
> >
> >I can ask POV-Ray to retrieve it and put the rgb value on-screen,
> >without even rendering ! I can do the same (with a macro) for the
> >normal perturbations. However, I can't do it for finishes. If
> >you can, tell me how.
>
> Using a feature that doesn't exist. Just because it doesn't exist
> doesn't mean it's not possible.
Nor the opposite ;-)
Retrieving the normal value is not an availiable feature, but I can
do it (without a camera anywhere) by using the surface's normal
and the normal pattern.
If you think that "retrieving the finish value at some point of
a surface, without a camera", is possible please explain me
(basically) how. (even if it implies non-availiable features,
I'm just interested by the theorical principle).
By "finish value", I mean the rgb value that contributes to the
final material aspect at a given point. Imagine a Red sphere,
with a white phong highlight. The "finish value" is different for
points "covered" by the highlight, and for points that are
"outside" the highlight. (though the "finish parameters" are constant).
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 Oct 2000 23:26:38 +0200, Fabien Mosen wrote:
>By "finish value", I mean the rgb value that contributes to the
>final material aspect at a given point. Imagine a Red sphere,
>with a white phong highlight. The "finish value" is different for
>points "covered" by the highlight, and for points that are
>"outside" the highlight. (though the "finish parameters" are constant).
Your definition of "finish value" is basically meaningless. You also can't
get the final color of a pigment without knowing where all the light sources
are.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
