 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I recently had some toughts about POV-Ray's texturing system, and tried
to point out some incoherences and suggest some remedies. Please note
that I'm not whining, or requesting anything. These are just toughts
for a possible future. Read it, keep it, throw it, as you feel.
Here's the first of these toughts.
FINISH - Change in material structure
-------------------------------------
What's wrong with "finish"* ? "finish" is at the same hierarchic level
as
"pigment" and "normal", though it works very differently. "pigment" and
"normal" require a pattern and a map, while "finish" just has some
keywords.
Of course, "finish" could get some "finish_map", but since, anyway, a
pattern isn't *required*, it's still incoherent with "pigment" and
"normal".
So, my idea is to put "finish" at the same level as "texture", and
create
a "surface" entity to group both. Also, this require that, inside the
"finish" statement, finish properties are also grouped into separate
entities. Given the recent growth of the "finish" content (thanks to
MegaPOV), having all the keywords 'thrown' in a single statement became
annoying. This would, of course, allow the declaration of the finish
items : finish {reflection {Mirror1} highlights {VeryShiny} ..}
(*note to Warp : I didn't say 'What's wrong with Finnish ?' ;-))
Here is the proposed material structure :
material {
surface {
[pattern - surface_map]
texture {
[pattern - texture_map]
pigment {..}
normal {..}
}
finish {
[pattern - finish_map]
reflection {type .. min .. max .. exponent
..}
highlights {phong .. specular .. blinn ..}
iridescence {irid .. thickness ..}
light {ambient.. brilliance ..}
}
}
interior {
refraction {..}
media {..}
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
Very well put.
I like your ideas, and agree that the nontrivial complexity inherent to
complete declaration of materials was implemented here-to-fore in a vexing
and insipid manner.
I intend not to bash Pov-Ray, but to state as the growth of the program has
increased, old methods of handling things must be changed.
This vast syntax alteration will cause many incompatibilities, but is
logical relative to the present form.
ian
Fabien Mosen wrote in message <39D9C88D.C0ABE99D@skynet.be>...
>
>material {
> surface {
> [pattern - surface_map]
> texture {
> [pattern - texture_map]
> pigment {..}
> normal {..}
> }
> finish
> [pattern - finish_map]
> reflection {type .. min .. max .. exponent
>..}
> highlights {phong .. specular .. blinn ..}
> iridescence {irid .. thickness ..}
> light {ambient.. brilliance ..}
> }
> }
>
> interior {
> refraction {..}
> media {..}
> }
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shudder... I *guess* I could adapt... if it's for the best...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
>
> Shudder... I *guess* I could adapt... if it's for the best...
If a change is made towards something that is more logical, it's
easy to get used to it. "ior" going from "finish" to "interior"
was logical, and no one complained about it.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I like this new structure very much. I've only just come across the need for
a "finish map" (No, not a map of Finland!)
this would solve the problem nicely and is much more logical.
Mick
"Fabien Mosen" <fab### [at] skynet be> wrote in message
news:39D9C88D.C0ABE99D@skynet.be...
> I recently had some toughts about POV-Ray's texturing system, and tried
> to point out some incoherences and suggest some remedies. Please note
> that I'm not whining, or requesting anything. These are just toughts
> for a possible future. Read it, keep it, throw it, as you feel.
> Here's the first of these toughts.
>
> FINISH - Change in material structure
> -------------------------------------
> What's wrong with "finish"* ? "finish" is at the same hierarchic level
> as
> "pigment" and "normal", though it works very differently. "pigment" and
> "normal" require a pattern and a map, while "finish" just has some
> keywords.
> Of course, "finish" could get some "finish_map", but since, anyway, a
> pattern isn't *required*, it's still incoherent with "pigment" and
> "normal".
> So, my idea is to put "finish" at the same level as "texture", and
> create
> a "surface" entity to group both. Also, this require that, inside the
> "finish" statement, finish properties are also grouped into separate
> entities. Given the recent growth of the "finish" content (thanks to
> MegaPOV), having all the keywords 'thrown' in a single statement became
> annoying. This would, of course, allow the declaration of the finish
> items : finish {reflection {Mirror1} highlights {VeryShiny} ..}
>
> (*note to Warp : I didn't say 'What's wrong with Finnish ?' ;-))
>
> Here is the proposed material structure :
>
> material {
> surface {
> [pattern - surface_map]
> texture {
> [pattern - texture_map]
> pigment {..}
> normal {..}
> }
> finish
> [pattern - finish_map]
> reflection {type .. min .. max .. exponent
> ..}
> highlights {phong .. specular .. blinn ..}
> iridescence {irid .. thickness ..}
> light {ambient.. brilliance ..}
> }
> }
>
> interior {
> refraction {..}
> media {..}
> }
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This looks like it's more logical than the present syntax. How about making
it the syntax for POV 4.0, which will be a total rewrite?
Brendan
Fabien Mosen wrote:
> I recently had some toughts about POV-Ray's texturing system, and tried
> to point out some incoherences and suggest some remedies. Please note
> that I'm not whining, or requesting anything. These are just toughts
> for a possible future. Read it, keep it, throw it, as you feel.
> Here's the first of these toughts.
>
> FINISH - Change in material structure
> -------------------------------------
> What's wrong with "finish"* ? "finish" is at the same hierarchic level
> as
> "pigment" and "normal", though it works very differently. "pigment" and
> "normal" require a pattern and a map, while "finish" just has some
> keywords.
> Of course, "finish" could get some "finish_map", but since, anyway, a
> pattern isn't *required*, it's still incoherent with "pigment" and
> "normal".
> So, my idea is to put "finish" at the same level as "texture", and
> create
> a "surface" entity to group both. Also, this require that, inside the
> "finish" statement, finish properties are also grouped into separate
> entities. Given the recent growth of the "finish" content (thanks to
> MegaPOV), having all the keywords 'thrown' in a single statement became
> annoying. This would, of course, allow the declaration of the finish
> items : finish {reflection {Mirror1} highlights {VeryShiny} ..}
>
> (*note to Warp : I didn't say 'What's wrong with Finnish ?' ;-))
>
> Here is the proposed material structure :
>
> material {
> surface {
> [pattern - surface_map]
> texture {
> [pattern - texture_map]
> pigment {..}
> normal {..}
> }
> finish {
> [pattern - finish_map]
> reflection {type .. min .. max .. exponent
> ..}
> highlights {phong .. specular .. blinn ..}
> iridescence {irid .. thickness ..}
> light {ambient.. brilliance ..}
> }
> }
>
> interior {
> refraction {..}
> media {..}
> }
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39da341d@news.povray.org> , "Mick Hazelgrove"
<mic### [at] mhazelgrovefsnetcouk> wrote:
> I like this new structure very much. I've only just come across the need for
> a "finish map" (No, not a map of Finland!)
> this would solve the problem nicely and is much more logical.
You are aware that you can just use a texture_map, so except for consistency
reasons the current syntax should not limit you, or does it?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
>
> "Tony[B]" wrote:
> >
> > Shudder... I *guess* I could adapt... if it's for the best...
>
> If a change is made towards something that is more logical, it's
> easy to get used to it.
Logical to whom ?
> "ior" going from "finish" to "interior"
> was logical, and no one complained about it.
I did :)
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How about this? Notice that "map" replaces all the other maps (less typing),
"light" is now "lighting", and that interior has "fading {...}" now. You
like?
material
{
surface
{
[pattern - map]
texture
{
[pattern - map]
pigment {..}
normal {..}
}
finish
[pattern - map]
reflection {type .. min .. max .. exponent ..}
highlights {phong .. specular .. blinn ..}
iridescence {irid .. thickness ..}
lighting {ambient.. brilliance ..}
}
}
interior
{
ior
media {..}
fading {distance .. power .. color ..}
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes I am aware of that but I found that it was quite hard to control. Much
easier if there was one finish for the whole texture.
Mick
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:39da7513$1@news.povray.org...
> In article <39da341d@news.povray.org> , "Mick Hazelgrove"
> <mic### [at] mhazelgrovefsnetcouk> wrote:
>
> > I like this new structure very much. I've only just come across the need
for
> > a "finish map" (No, not a map of Finland!)
> > this would solve the problem nicely and is much more logical.
>
> You are aware that you can just use a texture_map, so except for
consistency
> reasons the current syntax should not limit you, or does it?
>
>
> Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mick Hazelgrove wrote:
>
> Yes I am aware of that but I found that it was quite hard to control. Much
> easier if there was one finish for the whole texture.
And quicker, because currently, if you use a texture-map, the pigment,
normal and finish are calculated more than once for each pixel.
If finish was at the same level as texture, the "underlying" texture
would be calculated just once, no matter the complexity of the "finish
map".
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Fabien Mosen wrote:
> > If a change is made towards something that is more logical, it's
> > easy to get used to it.
>
> Logical to whom ?
To many people, it seems. Given the explanation, don't you find my
idea more logical than the current implementation ?
> > "ior" going from "finish" to "interior"
> > was logical, and no one complained about it.
>
> I did :)
You are not part of "everyone", you're an exceptionnal being, Ken :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fabien Mosen" wrote:
> "finish" is at the same hierarchic level as "pigment" and "normal",
> though it works very differently. "pigment" and "normal" require a
> pattern and a map, while "finish" just has some keywords.
Pigment doesn't require a pattern and a map. In fact it's very common to
specify just a plain colour.
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).
> Of course, "finish" could get some "finish_map", but since, anyway,
> a pattern isn't *required*, it's still incoherent with "pigment" and
> "normal".
I disagree. 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.
I think finish_map should be implemented.
> So, my idea is to put "finish" at the same level as "texture", and
> create a "surface" entity to group both.
I think finish is no more different from pigment and normal than pigment and
normal are different from each other. I think they should be grouped
together in the texture statement like they currently are.
If you want to make a map that affects pigment and normal but not finish you
can already do that. You use a texture_map - but with the new features in
MegaPOV and the future POV-Ray 3.5 you can also simply predeclare a pattern*
and use that pattern in both the pigment and normal statement.
* or if that isn't possible you can use pigment_pattern.
That method also has the advantage that you can have a map affect the
pigment and finish but not the normal, or the normal and finish but not the
pigment.
I can think of situations where I want a map to affect the normal and finish
but not the pigment. Therefore I think that it is not logical to separate
the finish from the pigment and normal.
I don't have any really good arguments against separating finish from
pigment and normal; I just think it's unnecessary and that a new group is
redundant. Instead I would like to see some really good argument *for* the
separation, because I haven't seen any yet IMHO.
What I've written here are only my own thoughts (of course). I would like a
good discussion!
> Also, this require that, inside the "finish" statement, finish
> properties are also grouped into separate entities.
I think that's a good idea.
Greetings,
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:
> 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.
> 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 !
(that's also why it doesn't work well with non-gradient patterns, such
as checker).
> > Of course, "finish" could get some "finish_map", but since, anyway,
> > a pattern isn't *required*, it's still incoherent with "pigment" and
> > "normal".
>
> I disagree. 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. 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.
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.
> I think finish_map should be implemented.
Yes. That's the thing that got me thinking about that hierarchy
problem.
I would like to know WHY it hasn't been implemented yet. I suspect
that the answer would come back to the hierarchy problem.
> I don't have any really good arguments against separating finish from
> pigment and normal; I just think it's unnecessary and that a new group is
> redundant. Instead I would like to see some really good argument *for* the
> separation, because I haven't seen any yet IMHO.
See the global vs. local issue, above.
> What I've written here are only my own thoughts (of course). I would like a
> good discussion!
That's why we're here :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 Oct 2000 16:51:30 +0200, Fabien Mosen wrote:
> 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. 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.
Finish doesn't change with the point of view. The point of view is one
of the parameters that affects the appearance of a finish, but that's it.
> 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.
This is not a proof of what you think it is. The reason there's no way to
get teh finish value is because a given finish is the same everywhere.
>> I think finish_map should be implemented.
>
>Yes. That's the thing that got me thinking about that hierarchy
>problem.
>I would like to know WHY it hasn't been implemented yet. I suspect
>that the answer would come back to the hierarchy problem.
I suspect that the answer is that nobody's done it yet.
--
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:
>
> Finish doesn't change with the point of view. The point of view is one
> of the parameters that affects the appearance of a finish, but that's it.
More precisely : the resulting finish value of one point of an object
changes with the point of view. (while the pigment and normal don't)
I'm gonna make a diagram to make my point clearer.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 Oct 2000 17:08:43 +0200, Fabien Mosen wrote:
>Ron Parker wrote:
>>
>> Finish doesn't change with the point of view. The point of view is one
>> of the parameters that affects the appearance of a finish, but that's it.
>
>More precisely : the resulting finish value of one point of an object
>changes with the point of view. (while the pigment and normal don't)
Normal certainly does, at least as much as finish does. The terminology is
a bit sloppy, though.
--
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:
>
> >More precisely : the resulting finish value of one point of an object
> >changes with the point of view. (while the pigment and normal don't)
>
> Normal certainly does, at least as much as finish does. The terminology is
> a bit sloppy, though.
Normal does ??
let's say :
sphere {<0,0,0>,1 pigment {Red}
normal {bumps .1}
finish {reflection .5}
}
let's consider the surface of the sphere at <0,1,0> (top of it).
The pigment value returned for that point will be the same,
whatever the camera position is.
The "virtual" slope (normal perturbation) at that point will
always be the same, regardless of the camera position.
However, the finish value returned (coming from reflection,
in that example) will be different with a different camera.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>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.
--
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 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39DAF661.10825941@skynet.be> , Fabien Mosen
<fab### [at] skynetbe> wrote:
>> Yes I am aware of that but I found that it was quite hard to control. Much
>> easier if there was one finish for the whole texture.
>
> And quicker, because currently, if you use a texture-map, the pigment,
> normal and finish are calculated more than once for each pixel.
> If finish was at the same level as texture, the "underlying" texture
> would be calculated just once, no matter the complexity of the "finish
> map".
If I am not completely wrong this is not the case you should be able to put
your pigment and normal stuff in one texture layer and have as many finish
layers as you like in other texture layers.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen <fab### [at] skynetbe> wrote:
: Can you get the normal at that point ? Yes.
: Can you get the color variation caused by reflection at that
: point ? No !
You are comparing different things.
Yes, you can get the normal at that point, but you can't get the
color variation caused by the normal at that point.
In the same way, yes, you can get the finish value at that point but
you can't get the variation caused by the finish at that point.
Normal and finish are very similar.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen <fab### [at] skynetbe> wrote:
: No, I'm looking for the value BEFORE it's finally affected by the
: projection system.
You can't get a color caused by a reflection/refraction BEFORE the final
projection system is set. So you are asking for something that is impossible.
: Oh, BTW, interior {ior} depends on normal perturbation (it
: affects the refracted ray).
You made a wrong statement and then a true statement in parentheses.
The normal doesn't affect the ior because the ior is constant. Yes, the
normal affects the refracted ray. A reflected/refracted ray is affected
by many things.
: 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.
Since when finish has contained only view-dependant things?
: I can ask POV-Ray to retrieve it and put the rgb value on-screen,
: without even rendering !
No, you can't.
Well, you can, but without shading (due to light sources), shadows,
fog, media, radiosity... A kind of +Q0 image.
:> No, you can't see your pigment if there's no camera and light_sources.
It's perfectly possible to see a pigment without light_sources.
A scene without a camera doesn't make sense.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Since when finish has contained only view-dependant things?
That's part of the problem ! The MAIN purpose of finish is to set
these view-dependant features : reflection and highlights (which
are faked blurred reflections). The word "finish" implies that
its the "last" property of a surface : varnish,...
> : I can ask POV-Ray to retrieve it and put the rgb value on-screen,
> : without even rendering !
>
> No, you can't.
#declare RGBValue = eval_pigment (MyPigment,<x,y,z>);
#debug concat ("the rgb value at <x,y,z> is ",
str(RGBValue.x,3,3),str..,str..)
> Well, you can, but without shading (due to light sources), shadows,
> fog, media, radiosity... A kind of +Q0 image.
All right. That is the rgb value at that point, which is, "later",
modified by other elements.
> It's perfectly possible to see a pigment without light_sources.
> A scene without a camera doesn't make sense.
Thats for the sake of explaining how finish is different from
pigment and normal. Within some hours, I'll get that diagram
done, and I hope it will make things clearer.
(BTW, you could want to make a scene without a specific camera, just
to get the results of a particular algorithm that uses POV-Ray's
specific capabilities)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen <fab### [at] skynetbe> wrote:
: That's part of the problem ! The MAIN purpose of finish is to set
: these view-dependant features : reflection and highlights (which
: are faked blurred reflections). The word "finish" implies that
: its the "last" property of a surface : varnish,...
And why things like crand, ambient and diffuse are not this kind of things?
:> It's perfectly possible to see a pigment without light_sources.
:> A scene without a camera doesn't make sense.
: Thats for the sake of explaining how finish is different from
: pigment and normal.
Normal is not much different from finish. If you don't have any light
source nor reflection/refraction, applying a normal to a surface has absolutely
no effect. The normal has effect only in the final rendering pass, as well
as finish.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
> I like this new structure very much. I've only just come across the need for
> a "finish map" (No, not a map of Finland!)
> this would solve the problem nicely and is much more logical.
Hmm, I came up with this a long time back. I wanted to do a wood pattern,
and looking at the wood (balsa) I was working from, I noticed a series of
tiny lines perpendicular (or maybe parallel) to the grain that shine more
than elsewhere. Only way I could do it was a texture map where the pigment
and normal were the same, but the finishes were different. Having a
separate finish map to allow for finishes that vary over the surface while
the texture does not could be nice.
On the other hand, where textures are also varying, it requires two maps
with the same entry values (to do what used to be done), but I'm not sure
that's a good reason *not* to do it. Certainly making them independent
allows for a lot of new possibilties (ex: Textures vary based on granite
pattern, while finishes based on bump, or whatever)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No comments, thoughts, critiques?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien,
if I have understood you correctly you're saying that finish is
view-dependent, while pigment and normal are not. I have tried several times
to explain why that is not true, but apparently have failed.
I will now try to explain it using some clearer expressions. I will use
"property" contra "appearance". These should not easily be mixed up.
In the pigment you specify the colour(s) of your object. If you make a
sphere with a white pigment, then a property of the sphere is that it is
white. Even if your object is lit by a red light_source only, the colour
property of the sphere is *still* white. The *appearance* however, is *red*
(and very dark red where it is in shadow).
Note that the surroundings don't affect the property of the object, but they
do affect the appearance.
Now to the normal. A property of an object can be it's slope at a given
point. This slope is independent on the surroundings (lights, camera, etc.).
However, the *appearance* of the slope is dependent on many things which I
will not go into details with here.
In the finish you specify many properties of the object. Ambient, diffuse,
the amount of reflection, highlights, and many other things. The values you
specify are the properties of the object. They are independent of the
surroundings (view-independent). Only the *appearance* is dependent on the
surroundings.
When you want to measure the reflected rays for an object, that is related
to the appearance, not the property of the object.
So for the pigment you want to measure a property.
And for the normal you want to measure a property.
But for the finish you want to measure the appearance!!!
So as I have said many times before, you can't compare like that.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tony[B] wrote:
>
> No comments, thoughts, critiques?
Well, after having just read thru all the posts on this subject, all I
have to say is "How many Angles can dance on the head of a pin?"
Ken Matassa
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 07 Oct 2000 20:04:30 -0700, Ken Matassa wrote:
>Tony[B] wrote:
>>
>> No comments, thoughts, critiques?
>
>Well, after having just read thru all the posts on this subject, all I
>have to say is "How many Angles can dance on the head of a pin?"
That's acute question, but you're right. Maybe we're being too obtuse.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
