The behaviour of normals when applying scaling to them has been changed
in megapov. Nathan says that it fixes a bug in the official povray. Indeed,
there is a bug in povray about scaling normals, but the "fix" in megapov
is just in the wrong way. Instead of fixing the part that is wrong in
the official povray to work as the parts that are right, now everything
works in the wrong way.
  Let me explain:

  A normal pattern actually simulates a heightfield. A heightfield would
have differences in height and differences in the orientation of the normal
vector (with respect to the average normal vector of the whole surface).
A normal modifier modifies just the normals (this is often enough when
the differences in height are insignificant).
  Thus, a normal modifier should work as a heighfield works.
  If you scale uniformly a heighfield, everything gets bigger or smaller,
but the normals (ie. the slopes of the heightfield) don't. They stay
unmodified. If the slope at a certain point was 1 (ie. 45 degrees), after
scaling the heightfield by 5 the slope at that point will still be 1.
The heightfield gets 5 times deeper, but note that it also gets 5 times
wider, so the slope stays the same.
  You can think it this way: If you scale a triangle uniformly, the angles
of the sides do not change.
  This means that (supposing that we have a light source very far away) the
shading of the heightfield does not change if you scale it by 5 (or by 10 or
by anything).
  Thus, the slopes of a surface do not depend on its scale (if we are scaling
uniformly).

  Now, the normals in (the official) povray usually work this way, ie. they
work as the heightfield: If you scale the object (uniformly), the slopes do
not change. This is the right way.
  However, there is a bug in povray. If you put the normal modifier inside
a normal_map block and then scale, the slopes will be scaled too (for some
reason). For example, if you scale the object by 5, the slopes of the
normal modifier will be scaled be 5.
  To get the same behaviour with a heightfield you would have to
scale it by <5,25,5>. This way the slopes will be scaled by 5, but as we
can see, it's not an uniform scale anymore. The heightfield gets 25 times
deeper while only 5 times wider. The same thing happens with the normals:
The apparent depth gets 25 times larger instead of just 5.
  This, of course, is a bug. I, among anothers, have noticed and discussed
this bug. It has some serious implications, as you can imagine. It's like
having tiny holes in your objects and when you scale the object by 5 the
holes get 25 times deeper. It's just plain wrong.

  Now, the megapov "fixes" this bug, but it fixes it in the wrong way!
Instead of making the normals inside a normal_map block not to change their
slope when scaling, it scales all the slopes everywhere. So instead of
eliminating a bug that affects a special case, the bug has been widespread
to affect everything.
  Nathan says that this is the behaviour he expects. Sorry Nathan, but you
are wrong. I hope you understand it.
  If you scale the slopes by 5 when scaling the object by 5, the apparent
depth of the surface gets scaled by 25. This is just wrong.
  I truely hope that you fix this wrong behaviour.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Again I didn't know which of megapov of povray is right
because I haven't check. But All that it is said here is right. So 
if megapov don't do this, megapov is wrong.
This is espacially explicit :

>   If you scale uniformly a heighfield, everything gets bigger or smaller,
> but the normals (ie. the slopes of the heightfield) don't. They stay
> unmodified. If the slope at a certain point was 1 (ie. 45 degrees), after
> scaling the heightfield by 5 the slope at that point will still be 1.
> The heightfield gets 5 times deeper, but note that it also gets 5 times
> wider, so the slope stays the same.
>   You can think it this way: If you scale a triangle uniformly, the angles
> of the sides do not change.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I just add. The length of its side change but not the angle between
them.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>   This means that (supposing that we have a light source very far away) the
> shading of the heightfield does not change if you scale it by 5 (or by 10 or
> by anything).
>   Thus, the slopes of a surface do not depend on its scale (if we are scaling
> uniformly).

Suppose you look the surface of a heightfield not from above but from
the side 
(I hope you understand). Suppose that the surface is like a triangle
(this 
could be anithing else it is just a pedagogic example :)), like in the
following 
image (sorry for this tiny binary but I think it is important). Aplha is
the 
slope (or tan(alpha) is you prefer). If I scale my triangle, alpha don't
change.
The length of the side change, so my heightfield will be bigger, but the
slope of 
any point of the surface doesn't change!
This behavior must be the same for normal in texture block.

Now if Megapov already do this like this, so I am sorry for this spam!

Fabian.

Nieminen Juha wrote:
> 
>   The behaviour of normals when applying scaling to them has been changed
> in megapov. Nathan says that it fixes a bug in the official povray. Indeed,
> there is a bug in povray about scaling normals, but the "fix" in megapov
> is just in the wrong way. Instead of fixing the part that is wrong in
> the official povray to work as the parts that are right, now everything
> works in the wrong way.
>   Let me explain:
> 
>   A normal pattern actually simulates a heightfield. A heightfield would
> have differences in height and differences in the orientation of the normal
> vector (with respect to the average normal vector of the whole surface).
> A normal modifier modifies just the normals (this is often enough when
> the differences in height are insignificant).
>   Thus, a normal modifier should work as a heighfield works.
>   If you scale uniformly a heighfield, everything gets bigger or smaller,
> but the normals (ie. the slopes of the heightfield) don't. They stay
> unmodified. If the slope at a certain point was 1 (ie. 45 degrees), after
> scaling the heightfield by 5 the slope at that point will still be 1.
> The heightfield gets 5 times deeper, but note that it also gets 5 times
> wider, so the slope stays the same.
>   You can think it this way: If you scale a triangle uniformly, the angles
> of the sides do not change.
>   This means that (supposing that we have a light source very far away) the
> shading of the heightfield does not change if you scale it by 5 (or by 10 or
> by anything).
>   Thus, the slopes of a surface do not depend on its scale (if we are scaling
> uniformly).
> 
>   Now, the normals in (the official) povray usually work this way, ie. they
> work as the heightfield: If you scale the object (uniformly), the slopes do
> not change. This is the right way.
>   However, there is a bug in povray. If you put the normal modifier inside
> a normal_map block and then scale, the slopes will be scaled too (for some
> reason). For example, if you scale the object by 5, the slopes of the
> normal modifier will be scaled be 5.
>   To get the same behaviour with a heightfield you would have to
> scale it by <5,25,5>. This way the slopes will be scaled by 5, but as we
> can see, it's not an uniform scale anymore. The heightfield gets 25 times
> deeper while only 5 times wider. The same thing happens with the normals:
> The apparent depth gets 25 times larger instead of just 5.
>   This, of course, is a bug. I, among anothers, have noticed and discussed
> this bug. It has some serious implications, as you can imagine. It's like
> having tiny holes in your objects and when you scale the object by 5 the
> holes get 25 times deeper. It's just plain wrong.
> 
>   Now, the megapov "fixes" this bug, but it fixes it in the wrong way!
> Instead of making the normals inside a normal_map block not to change their
> slope when scaling, it scales all the slopes everywhere. So instead of
> eliminating a bug that affects a special case, the bug has been widespread
> to affect everything.
>   Nathan says that this is the behaviour he expects. Sorry Nathan, but you
> are wrong. I hope you understand it.
>   If you scale the slopes by 5 when scaling the object by 5, the apparent
> depth of the surface gets scaled by 25. This is just wrong.
>   I truely hope that you fix this wrong behaviour.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Attachments:
Download 'graphique1.jpg' (9 KB)

Preview of image 'graphique1.jpg'

Thanks for your support.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

>   A normal pattern actually simulates a heightfield.

Am I missing something here ?

As far as I know a normal has no releationship to a height field in any
way what so ever. The models are entirely different.

When you apply a normal to a surface it's properties are controlled
explicitly by two parameters. The first is the float value after the
pattern type i.e. normal { bumps 1 } which sets the normal depth. The
second is the scale of the pattern which only effects the scale of the
pattern itself and not the depth of the normal pertubation. Scaling the
normal will not affect the depth of the normal pertubation and was never
intended to. It may effect the depth of the pattern but it will not
change the depth or height of the pertubation itself. If you want this
value to change then you must change the float value after the pattern
type and not rely on the scale value to do this for you. Any other model
for the normal would not be correct.


-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

This is more than a support, and thus not exactly a support :). 
I just say what I think (and I know it is correct because it seems 
to me that this is simple math, I do more complicated one each day 
(I making a thesis in physics)). 
O do not politics :).This is not at all an attack to somebody!!! 
Nathan is really great and I say thanks thanks thanks again to him!
But if Megapov don't calcuate correctly scaling of normal, this must 
be changed, it's all.

Fabian.

Nieminen Juha wrote:
> 
>   Thanks for your support.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:>   A normal pattern actually simulates a heightfield.

: Am I missing something here ?

: As far as I know a normal has no releationship to a height field in any
: way what so ever. The models are entirely different.

  I think that you are a bit confused... :)
  The normal modifier indeed simulates a heighfield by just changing the
normal vectors like a heightfield would (but it doesn't change the actual
shape of the object). This affects the shading of the surface. If shadows
are not calculated, then the shading of a heightfield would be identical
to the shading of an equivalent normal modifier (at least if we are looking
from up).
  The idea behind the normal modifier is that when the changes in the shape
of an object is small enough (like a rough surface) we only need the shading
and the actual shape is not important. The normal modifier is cheaper to use.

: When you apply a normal to a surface it's properties are controlled
: explicitly by two parameters. The first is the float value after the
: pattern type i.e. normal { bumps 1 } which sets the normal depth. The
: second is the scale of the pattern which only effects the scale of the
: pattern itself and not the depth of the normal pertubation. Scaling the
: normal will not affect the depth of the normal pertubation and was never
: intended to. It may effect the depth of the pattern but it will not
: change the depth or height of the pertubation itself. If you want this
: value to change then you must change the float value after the pattern
: type and not rely on the scale value to do this for you. Any other model
: for the normal would not be correct.

  Here you are completely right.
  As I said, scaling uniformly an object does not change the slope in any
part of its surface. Thus, the slope of the normals stay unmodified.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabian Brau <fab### [at] umhacbe> wrote:
: This is not at all an attack to somebody!!! 

  You are completely right here.
  I'm sorry if I gave the impression that I was attacking Nathan or anyone
else. The wording of my articles are not always as polite as they could be.
Please understand that my intention was not to be aggressive.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Here is another example:

suppose you have a heightfield. Now close to it, you take a piece of 
plane and you play with normal (you look from above). After lot of work,
your piece of plane look exactly like the heightfield (of course if you 
look from the side, you see the elevation of the heightfield but 
the plane is, of course, still flat!). You cannot say which is the 
heightfield. You calculate one image, say height.tga. Now if you scale 
both the heightfield and the piece of plane by the same factor x, and 
if you modify the camera in a proper way, the piece of plane will still
look exactly like the heightfield. Moreover, if you calculate the image,
say 
height2.tga, you get the same image than height.tga (perhaps if one
choose
a good heightfield (simple), it is possible to get with normal the same 
thing. Atfer this one make the test with scaling.
This could be a interesting test for MegaPov)

Fabian.

Ken wrote:
> 
> Nieminen Juha wrote:
> 
> >   A normal pattern actually simulates a heightfield.
> 
> Am I missing something here ?
> 
> As far as I know a normal has no releationship to a height field in any
> way what so ever. The models are entirely different.
> 
> When you apply a normal to a surface it's properties are controlled
> explicitly by two parameters. The first is the float value after the
> pattern type i.e. normal { bumps 1 } which sets the normal depth. The
> second is the scale of the pattern which only effects the scale of the
> pattern itself and not the depth of the normal pertubation. Scaling the
> normal will not affect the depth of the normal pertubation and was never
> intended to. It may effect the depth of the pattern but it will not
> change the depth or height of the pertubation itself. If you want this
> value to change then you must change the float value after the pattern
> type and not rely on the scale value to do this for you. Any other model
> for the normal would not be correct.
> 
> --
> Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
> Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

I never doubted about this :)!

Fabian.

Nieminen Juha wrote:
> 
> Fabian Brau <fab### [at] umhacbe> wrote:
> : This is not at all an attack to somebody!!!
> 
>   You are completely right here.
>   I'm sorry if I gave the impression that I was attacking Nathan or anyone
> else. The wording of my articles are not always as polite as they could be.
> Please understand that my intention was not to be aggressive.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I haven't tried with megapov, but what you're saying is that in
standard pov, the bug is with normal_maps... Well it isn't: I've just
tried rendering a file with two identical normals, one inside a
normal_map and the other outside and sure enough when I scale the whole
scene up, the one inside the normal_map doesn't change while the one
outside looks completely different...

	Now, here's how I understand things: when you scale a height_field by a
constant value (say 5), what pov does is promote the 5 to <5, 5, 5>
therefore the height_field is 5 times deeper as well as 5 times wider
(which keeps the slope unchanged, I agree). But when you scale a normal
by 5, the way pov does it is equivalent to scaling by <5, 1, 5> (I
haven't looked at the code, so I'm not sure why it's that way, but
that's what the result look like) which does change the slope...

	Bottom line: I believe that your reasoning is sound, but that your
conclusion is false: if Nathan has changed it so that it always behaves
as if it was in a normal_map, then he has indeed the right of it.

		Jerome

PS: If anybody is interested in wild speculations, here's how I would
explain the bug in the official version. Keep in mind that I haven't
looked at the code so this might be completely stupid...

I'll assume we're speaking about a plane { y, 0 } with a normal. When
you scale it by 5, it gets promoted to <5, 5, 5> but the y component
doesn't matter since the plane is flat. Then pov computes the normals:
it evaluates the pattern to determine the relative amount of
perturbation, then uses the depth given as a float parameter to
determine the total amount of perturbation. The problem is that the
values returned when evaluating the pattern don't take scale into
account (the scale only affects the point at wich the pattern is
evaluated, *not* the returned value) and this value is akin to the depth
of the height field so it should have been scaled too... That's what I
mean when I say that the result is similar to a scale <5, 1, 5> as far
as the normal is concerned.

-- 
*******************************

* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message