POV-Ray : Newsgroups : povray.general : Normal scaling bug(s) ? Server Time
1 Nov 2024 09:23:05 EDT (-0400)
  Normal scaling bug(s) ? (Message 1 to 6 of 6)  
From: Rune S  Johansen
Subject: Normal scaling bug(s) ?
Date: 8 Oct 1999 18:10:59
Message: <37fe6bf3@news.povray.org>
/*
I keep being confused by these normals!

I consider it a bug that the depth of a normal
doesn't always proportionally follow the scaling
affecting the normal.

I think the problem is quite serious. Again and
again I find myself unable to work effectively
with normals because the way they work (regarding
scaling) just isn't logic but on the contrary
strange and very inconvenient!

If you consider it a bug too I think it should be
fixed.

I know it would break a whole lot of scenes, but
wouldn't it be possible to make some kind of
switch so the user could switch between the old
wrong method and a new proper one? Maybe the
already existing #version switch could be used
for that?

Below the problem is described in details.

Please note that I've found out more about the
problem since my last posts regarding normals so
I'm not just saying exactly the same again...! :-)

There are four basic types of normals:

o Block pattern normals (checker, hexagon, brick).
o Bump maps.
o Specialized normals (bumps, dents, ripples,
  waves, wrinkles).
o The rest is continuous pattern normals.

When working with normals you can modify both the
scale of the pattern and the depth of the pattern.

When you apply a *specialized normal* to an object
and afterwards scale the object smaller or larger,
the depth of the normal pattern follows the scale
of the pattern proportionally as you would expect.

However, when you apply a *continuous pattern
normal* to an object and scale the object smaller
or larger afterwards, the depth of the normal
pattern *doesn't* follow the scale of the pattern.
That is, if you scale the object smaller the
normal seems to be too deep and if you scale the
object larger the normal seems to be too flat.

If you want to have the depth of a *continuous
pattern normal* to follow the scale of the pattern
proportionally you must multiply the depth of the
normal pattern with the same amount you scale the
object with. However, for some reason that only
works when scaling the object larger, not when
scaling it smaller.

Just to confuse you even more: If you have an
*continuous pattern normal* inside a *normal_map*
it works as if it were a *specialized normal*,
that is, the depth of the normal pattern follows
the scale of the pattern proportionally. That's
what I just found out and that makes it all even
more confusing and inconvenient!

Here's an example of it all:

Left spheres:  Normal depth of 1.
Right spheres: Normal depth proportional to "Scale".
Upper spheres: A plain crackle normal.
Lower spheres: Same normal but inside a normal_map.

Change "Scale" to other values to see the effects.
*/

#declare Scale=1;

camera{location -8*z look_at 0 orthographic  scale Scale}
light_source{<1,1,-1>*100,color 1 shadowless scale Scale}
#default{pigment{color rgb 1}}

#declare N1a=normal{crackle 1    }
#declare N1b=normal{crackle Scale}

#declare N2a=normal{bozo normal_map{[0 N1a][1 N1a]}}
#declare N2b=normal{bozo normal_map{[0 N1b][1 N1b]}}

sphere{0,2 normal{N1a}translate <-2,+2,> scale Scale}
sphere{0,2 normal{N1b}translate <+2,+2,> scale Scale}
sphere{0,2 normal{N2a}translate <-2,-2,> scale Scale}
sphere{0,2 normal{N2b}translate <+2,-2,> scale Scale}


Post a reply to this message

From: Bob Hughes
Subject: Re: Normal scaling bug(s) ?
Date: 9 Oct 1999 03:02:44
Message: <37fee894@news.povray.org>
Like the fool that I am I had rendered without making any change to the
scale.  I was quickly doing a copy&paste then render without looking first
so I thought you were "crying wolf".
I think it could easily be said to be a bug.  Not a error type thing though
but just a disfunctional sort.  I agree very much that it should scale in a
uniform manner and not switch around like that.  Guess it could be argued it
isn't a flaw but I can't see textures operating correctly as is currently.

Bob

Rune S. Johansen <run### [at] inamecom> wrote in message
news:37fe6bf3@news.povray.org...
> /*
> I keep being confused by these normals!
>
> I consider it a bug that the depth of a normal
> doesn't always proportionally follow the scaling
> affecting the normal.
>
> I think the problem is quite serious. Again and
> again I find myself unable to work effectively
> with normals because the way they work (regarding
> scaling) just isn't logic but on the contrary
> strange and very inconvenient!
>
> If you consider it a bug too I think it should be
> fixed.
>
> I know it would break a whole lot of scenes, but
> wouldn't it be possible to make some kind of
> switch so the user could switch between the old
> wrong method and a new proper one? Maybe the
> already existing #version switch could be used
> for that?
>
> Below the problem is described in details.
>
> Please note that I've found out more about the
> problem since my last posts regarding normals so
> I'm not just saying exactly the same again...! :-)
>
> There are four basic types of normals:
>
> o Block pattern normals (checker, hexagon, brick).
> o Bump maps.
> o Specialized normals (bumps, dents, ripples,
>   waves, wrinkles).
> o The rest is continuous pattern normals.
>
> When working with normals you can modify both the
> scale of the pattern and the depth of the pattern.
>
> When you apply a *specialized normal* to an object
> and afterwards scale the object smaller or larger,
> the depth of the normal pattern follows the scale
> of the pattern proportionally as you would expect.
>
> However, when you apply a *continuous pattern
> normal* to an object and scale the object smaller
> or larger afterwards, the depth of the normal
> pattern *doesn't* follow the scale of the pattern.
> That is, if you scale the object smaller the
> normal seems to be too deep and if you scale the
> object larger the normal seems to be too flat.
>
> If you want to have the depth of a *continuous
> pattern normal* to follow the scale of the pattern
> proportionally you must multiply the depth of the
> normal pattern with the same amount you scale the
> object with. However, for some reason that only
> works when scaling the object larger, not when
> scaling it smaller.
>
> Just to confuse you even more: If you have an
> *continuous pattern normal* inside a *normal_map*
> it works as if it were a *specialized normal*,
> that is, the depth of the normal pattern follows
> the scale of the pattern proportionally. That's
> what I just found out and that makes it all even
> more confusing and inconvenient!
>
> Here's an example of it all:
>
> Left spheres:  Normal depth of 1.
> Right spheres: Normal depth proportional to "Scale".
> Upper spheres: A plain crackle normal.
> Lower spheres: Same normal but inside a normal_map.
>
> Change "Scale" to other values to see the effects.
> */
>
> #declare Scale=1;
>
> camera{location -8*z look_at 0 orthographic  scale Scale}
> light_source{<1,1,-1>*100,color 1 shadowless scale Scale}
> #default{pigment{color rgb 1}}
>
> #declare N1a=normal{crackle 1    }
> #declare N1b=normal{crackle Scale}
>
> #declare N2a=normal{bozo normal_map{[0 N1a][1 N1a]}}
> #declare N2b=normal{bozo normal_map{[0 N1b][1 N1b]}}
>
> sphere{0,2 normal{N1a}translate <-2,+2,> scale Scale}
> sphere{0,2 normal{N1b}translate <+2,+2,> scale Scale}
> sphere{0,2 normal{N2a}translate <-2,-2,> scale Scale}
> sphere{0,2 normal{N2b}translate <+2,-2,> scale Scale}
>
>
>
>
>


Post a reply to this message

From: Rune S  Johansen
Subject: Wrong documentation! was: Re: Normal scaling bug(s) ?
Date: 9 Oct 1999 08:21:54
Message: <37ff3362@news.povray.org>
Now we're talking about normals, here's something I fond in the POV-Ray
documentation:

"Blending Normals

Normals can be layered similar to pigments but the results can be
unexpected. Let's try that now by editing the sphere as follows.

  sphere { <0,0,0>, 1
    pigment { Gray75 }
      normal { radial frequency 10 }
      normal { gradient y scale .2 }
  }

As we can see, the resulting pattern is neither a radial nor a gradient. It
is instead the result of first calculating a radial pattern and then
calculating a gradient pattern. The results are simply additive. (...) "

As far as I know both pigments and normals overwrite each other when layered
and a test I made confirmed that.

Has this "doc bug" already been reported? Will it be fixed for the next
version?

Greetings,

Rune S. Johansen

---
Updated October 7: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!


Post a reply to this message

From: Rune S  Johansen
Subject: Re: Normal scaling bug(s) ?
Date: 9 Oct 1999 08:21:57
Message: <37ff3365@news.povray.org>
Rune S. Johansen wrote:
>Just to confuse you even more: If you have an
>*continuous pattern normal* inside a *normal_map*
>it works as if it were a *specialized normal*,
>that is, the depth of the normal pattern follows
>the scale of the pattern proportionally. That's
>what I just found out and that makes it all even
>more confusing and inconvenient!

But... unfortunately the normal is much more blurred!

Here's a story:

I was working with the texture of the walls in my scene "Dripstone Cave". I
used a single crackle normal with the depth multiplied with "SceneScale"
which is the same amount that the pattern was scaled up afterwards.
Simplified it looked like this:

normal {
   crackle 0.15*SceneScale
}

I wanted to put the crackle normal inside a normal_map so I could use more
normals. I now removed the multiplication with SceneScale:

normal {
   average
   normal_map {
      [crackle 0.15] // not multiplied with SceneScale!
   }
}

Now the normal had the same scale AND the same depth as before BUT IT WAS
MUCH MORE BLURRED! That made it useless, and therefore I'm still looking for
a solution. :-(

Greetings,

Rune S. Johansen

---
Updated October 7: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!


Post a reply to this message

From: Buckaroo Bill
Subject: Re: Wrong documentation! was: Re: Normal scaling bug(s) ?
Date: 9 Oct 1999 08:39:01
Message: <37ff3765@news.povray.org>
Rune S. Johansen <run### [at] inamecom> wrote :
>
>   sphere { <0,0,0>, 1
>     pigment { Gray75 }
>       normal { radial frequency 10 }
>       normal { gradient y scale .2 }
>   }
>
>
> As far as I know both pigments and normals overwrite each other when
layered
> and a test I made confirmed that.
>

    Not quite over-writes... try adding a scale to the first normal.

 sphere { <0,0,0>, 1
    pigment { rgb 0.75 }
      normal { radial frequency 10 scale 2.0 }
      normal { gradient y scale .2 }
  }

    But the document does not seem to be correct.


Post a reply to this message

From: Rune S  Johansen
Subject: Re: Wrong documentation! was: Re: Normal scaling bug(s) ?
Date: 9 Oct 1999 17:27:44
Message: <37ffb350@news.povray.org>
Buckaroo Bill wrote:
>Rune S. Johansen <run### [at] inamecom> wrote :
>>
>>   sphere { <0,0,0>, 1
>>     pigment { Gray75 }
>>       normal { radial frequency 10 }
>>       normal { gradient y scale .2 }
>>   }
>>
>>
>> As far as I know both pigments and normals overwrite
>> each other when layered and a test I made confirmed that.
>>
> Not quite over-writes... try adding a scale to the first normal.
>
> sphere { <0,0,0>, 1
>    pigment { rgb 0.75 }
>      normal { radial frequency 10 scale 2.0 }
>      normal { gradient y scale .2 }
>  }
>
> But the document does not seem to be correct.

OK, it seems like I didn't study the problem carefully enough.
Now I'm even more confused and can't find out how it works...
To me it seems that the pattern of the first normal hasn't any
influence at all; only the scale. Is that right or how does it
work?

Greetings,

Rune S. Johansen

---
Updated October 7: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.