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

Jerome M. BERGER <jbe### [at] enstfr> wrote:
: But when you scale a normal
: by 5, the way pov does it is equivalent to scaling by <5, 1, 5>

  Wrong. The slope doesn't change. Thus, the apparent depth is scaled by 5,
not by 1.
  To really scale the apparent depth by 1 instead of 5, the slopes would
have to be scaled by 1/5. Povray does not do this. This is easy to test:
Make an object with a normal modifier. Scale that object 100 times larger
and move the camera and the light source 100 times farther away. If what
you say was true, now the slopes would be 1/100 of the original and the
apparent depth would have not changed, so the normal modifier should be
almost invisible. This, of course, is not so. The slopes are not changed
and the apparent depth gets scaled by 100 too.
  Now make this same test in megapov. What happens is that megapov will
scale the _slopes_ by 100 as well, which means that the apparent depth
of the surface would be 10000 after scaling.

-- 
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:
> 
> Jerome M. BERGER <jbe### [at] enstfr> wrote:
> : But when you scale a normal
> : by 5, the way pov does it is equivalent to scaling by <5, 1, 5>
> 
>   Wrong. The slope doesn't change. Thus, the apparent depth is scaled by 5,
> not by 1.
	No, the slope *does* change... Try it.

>   To really scale the apparent depth by 1 instead of 5, the slopes would
> have to be scaled by 1/5. Povray does not do this. This is easy to test:
> Make an object with a normal modifier. Scale that object 100 times larger
> and move the camera and the light source 100 times farther away. If what
> you say was true, now the slopes would be 1/100 of the original and the
> apparent depth would have not changed, so the normal modifier should be
> almost invisible. This, of course, is not so. The slopes are not changed
> and the apparent depth gets scaled by 100 too.
	I did precisely this test and if the normal is inside a normal_map I
get what you said, but if the normal is on its own it *is* almost
invisible...

>   Now make this same test in megapov. What happens is that megapov will
> scale the _slopes_ by 100 as well, which means that the apparent depth
> of the surface would be 10000 after scaling.
	I just did the test with megapov 0.2 and the scene was the same no
matter what scale factor I used...

		Jerome
-- 
*******************************

* 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

Jerome M. BERGER <jbe### [at] enstfr> wrote:
: 	I did precisely this test and if the normal is inside a normal_map I
: get what you said, but if the normal is on its own it *is* almost
: invisible...

  Well, I did the same and the apparent depth of the surface doesn't change
at all. All the images render identically no matter what value of 'Size' you
specify here:

#declare Size=1;
#debug concat("Size=",str(Size,1,0),"\n")

camera { location -z*4*Size look_at 0 angle 35 }
light_source { <100,200,-150>*Size, 1 }
sphere
{ 0,Size
  pigment { rgb x } finish { specular .5 }
  normal { bumps .5 scale .1*Size }
}


-- 
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:
> 
>   Well, I did the same and the apparent depth of the surface doesn't change
> at all. All the images render identically no matter what value of 'Size' you
> specify here:
> 
	I've just seen a post by Nathan saying that standard pov already
handled properly normals such as bumps and waves... I used a crackle for
my tests, which wasn't correct.

		Jerome
-- 
*******************************

* 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

Jerome M. BERGER <jbe### [at] enstfr> wrote:
: 	I've just seen a post by Nathan saying that standard pov already
: handled properly normals such as bumps and waves... I used a crackle for
: my tests, which wasn't correct.

  So the answer is: Some pattern types work fine, others don't.
  This definitely should be fixed.

-- 
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