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