In the documentation for MacMegaPOV, it says "Now, whenever you scale a 
normal pattern or an object that has a surface normal, the depth 
(amount) of the normal will scale proportionally.".

Now, for most cases, this is fine, but what does it do when the normal 
is unevenly scaled? Like if you scale it by scale < 1, 5, 3>. How is the 
depth of the normal affected in this case?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

I believe any normal is going to be surface-only dependant.  So uneven
scaling will probably average out, maybe.  Like <1,5,3>=3 perhaps for the
"depth".  The person to answer decisively of course would be the author of
that particular change.

Bob

"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-3DE868.23043612121999@news.povray.org...
> In the documentation for MacMegaPOV, it says "Now, whenever you scale a
> normal pattern or an object that has a surface normal, the depth
> (amount) of the normal will scale proportionally.".
>
> Now, for most cases, this is fine, but what does it do when the normal
> is unevenly scaled? Like if you scale it by scale < 1, 5, 3>. How is the
> depth of the normal affected in this case?
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

The depth is scaled unevenly.

The bugfix does not actually scale the 'amount' property of the normal.
Instead, it rearranges the order of some events that happen.

You see, to determine a normal from a pattern (using a non-normal pattern),
the gradient of the pattern must be found.  To determine this gradient, four
sample points are used.  The location of those points and their distance
from the original center point will have a great affect on the apparant
depth of the bumps.

The problem was when POV-Ray applied warps (including turbulence and
transformations).  Did it do this before choosing the four sample points or
after?  The truth was that sometimes it did it before, sometimes after.  Any
transformations applied to the deepest-level normals would get done after
choosing sample points.  Any other transformations (such as to parent
patterns) would get done before.

Example:
normal{
  average
  normal_map{
    [1 crackle 1 scale 2 ]
  }
  scale 10
}

Here's the order of events (original point is called P):
1) inverse-scale P by 10
2) choose 4 sample points, s1,s2,s3,s4
     all 0.02 POV-units away from P
3) inverse-scale s1,s2,s3,s4 by 2
4) determine the gradient using s1,s2,s3,s4

So, in this case, the 'scale 10' in the outer pattern would increase the
apparant depth of the bumps by a factor of 10, while the inner 'scale 2'
would only stretch out the pattern without affecting the apparant depth.

I changed it so that the order of events will be consistent.  In MegaPov,
the above sequence would look like this:
1) inverse-scale P by 10
2) inverse-scale P by 2
3) choose 4 sample points, s1,s2,s3,s4
     all 0.02 POV-units away from P
4) determine the gradient using s1,s2,s3,s4

-Nathan

Chris Huff <chr### [at] yahoocom> wrote...
> In the documentation for MacMegaPOV, it says "Now, whenever you scale a
> normal pattern or an object that has a surface normal, the depth
> (amount) of the normal will scale proportionally.".
>
> Now, for most cases, this is fine, but what does it do when the normal
> is unevenly scaled? Like if you scale it by scale < 1, 5, 3>. How is the
> depth of the normal affected in this case?
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

As I wrote in p.b.i I think that evenly scaling a normal modifier should
not change its slope. This is because if we replace the normal modifier
with a heighfield, scaling it uniformly will not change its slope either.

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

After running a few tests, I realize now that the previous implementation was
actually wrong...
You can run this little script and see that in Megapov the cube aspect doesn't
change for different values of sc. In regular POV, it behaves a little
strangely, to say the less.
#declare sc=1; //#declare sc=100;
camera{ location  20*<1,1,-1>   direction sc*z   right     4/3*x   look_at 0}
background{color rgb 1} light_source{1000*<1,1,-1> color rgb 2}
box{-1,1 texture{pigment{rgb <0,1,1>} normal{crackle 1}} scale 5/sc}

However, I'm a little bit concerned about the fact that, unless I'm mistaken,
the normal bug fix is changing the way all the scenes that include scaled
normals are now appearing. There is a serious problem of backward
compatibility here because fine-tuning again the normals of every previous
scene to obtain the same result as before is not something people will
spontaneously enjoy... Perhaps there should be something in global_settings to
make it easier.

G.

Nieminen Juha wrote:

>   As I wrote in p.b.i I think that evenly scaling a normal modifier should
> not change its slope. This is because if we replace the normal modifier
> with a heighfield, scaling it uniformly will not change its slope either.
>
> --
> 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

Gilles Tran wrote:

> However, I'm a little bit concerned about the fact that, unless I'm mistaken,
> the normal bug fix is changing the way all the scenes that include scaled
> normals are now appearing. There is a serious problem of backward
> compatibility here because fine-tuning again the normals of every previous
> scene to obtain the same result as before is not something people will
> spontaneously enjoy... Perhaps there should be something in global_settings to
> make it easier.

...or perhaps the version directive can keep the functions seperate. I too
would be hard pressed to reproduce some of my earlier textures that are
heavily dependant on surface normals.

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

Ok.  Due to popluar demand, in the next version of MegaPov, you will be able
to use #version 3.1 to revert (mostly) to the old buggy surface normals.
The normal rotation bug will still be fixed, though (I think... I must test
that more).

- Nathan

Ken <tyl### [at] pacbellnet> wrote...
>
>
> Gilles Tran wrote:
>
> > However, I'm a little bit concerned about the fact that, unless I'm
mistaken,
> > the normal bug fix is changing the way all the scenes that include
scaled
> > normals are now appearing. There is a serious problem of backward
> > compatibility here because fine-tuning again the normals of every
previous
> > scene to obtain the same result as before is not something people will
> > spontaneously enjoy... Perhaps there should be something in
global_settings to
> > make it easier.
>
> ...or perhaps the version directive can keep the functions seperate. I too
> would be hard pressed to reproduce some of my earlier textures that are
> heavily dependant on surface normals.
>
> --
> 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

Wouldn't a good solution to make a translator program that tweak the
settings to get the same scene? It could also make other adjustments like,
old style color_maps, blobs, radiosity, adding ";" and perhaps even convert
halo to media.
I know this isn't a new idea. I know it is probably quite a work (and maybe
even impossible for halos). But I think it is one of the best solution for
this kind of backward compatibility problems. And, er, an idea (maybe a
stupid one) the translation could be done by patched POV itself, using the
parser but outputting a POV file rather than / together with the image file.
And this would keep everything in one place.
Please don't flame me. I have no idea how hard or unintelligent this is, I
am no programmer.
And many thanks to everybody who made and make POV the wonderful renderer it
is.


Povingly


Philippe

Post a reply to this message

Philippe Debar <phi### [at] hotmailcom> wrote:
: Wouldn't a good solution to make a translator program that tweak the
: settings to get the same scene?

  Your idea is good. However it shouldn't be necessary because the behaviour
of megapov is wrong while the behaviour of povray is right (except for
normal_maps).

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

Thanks Nathan !
G.
Nathan Kopp wrote:

> Ok.  Due to popluar demand, in the next version of MegaPov, you will be able
> to use #version 3.1 to revert (mostly) to the old buggy surface normals.
> The normal rotation bug will still be fixed, though (I think... I must test
> that more).
>
> - Nathan
>

Post a reply to this message