POV-Ray : Newsgroups : povray.unofficial.patches : MegaPov, normals, and a BUG Server Time
2 Sep 2024 12:13:14 EDT (-0400)
  MegaPov, normals, and a BUG (Message 1 to 3 of 3)  
From: Nathan Kopp
Subject: MegaPov, normals, and a BUG
Date: 15 Dec 1999 23:52:22
Message: <38587006@news.povray.org>
Yes, there IS a bug in MegaPov's normals.  The problem is that scaling an
object BEFORE putting the normal on it affects the normal adversely.  I
apologize for this problem and will release a correction soon (but I want to
coordinate the release with Smellenbergh for you Mac users).

Anyway, I want to post ANOTHER scene to clarify the fixes that I have
applied.  There appears to be mass confusion over this issue.  I know scenes
usually go in scene-files, but it seemes few people go over there to get the
scene, and it is small, so I'm going to paste it into this message.

The scene has a height-field created from a granite pattern, so it will only
work with MegaPov or the SuperPatch.

First the bugfix, then the new bug:

--------------- THE BUGFIX ----------------

There are two objects in this scene.  The one on the left is a height field
created from a granite pattern.  The one on the right is a flat box with a
granite normal applied.

The variable Size at the top sets the overall size of the scene.  All
objects are relative and changing Size will scale everything relatively.
So, if you change Size you should expect the scene to look exactly the same.
(This is my basic assumption, so if this is incorrect, please let me know!)

Now, the depth of the bumps of the height field will automatically follow
this assumption.  If you scale it twice as big, it gets twice as big in all
three directions: x,z, and y(which is the depth).

The goal of my changes in MegaPov is to make the surface normals mimic the
actions of the height field.  When rendered with MegaPov, both the flat
object with normals and the height field should look very similar and behave
the same way when Size is changed.

If this is rendered in official POV-Ray (with the height-field commented
out), then changing Size will not leave you with the same scene.  Scaling it
larger will leave you with a very flat box, while scaling it smaller will
leave you with huge fake bumps.

You can change the Depth variable, too.  The Depth variable scales the box
and height field along the Y axis, effectively changing the depth of the
bumps.  The height field and box should remain looking similar as Depth is
changed.  This has a limited range over which it looks believable, of
course, since the normal IS faked on the box.

--------------- THE BUG ----------------
Did you notice the line #declare ShowBug=false; at the top?  If you set that
to true, the normals on the box will look horrible.  That is because of a
bug which I am aware of.  The problem is the "scale".  It's a complicated
explanation.  If you really care, look at my most recent post in the
bugreports group.

Anyway, MegaPov does fix a real bug that was really giving the wrong result,
but also introduced a new very bad bug that also causes it to give the wrong
result.

-Nathan

-------------- THE SCENE --------------

#declare Size=100; // range most anything
#declare Depth=.3; // range 0.3 .. 2
#declare ShowBug=false;

#declare GraniteNormal=normal{
     granite .8
     slope_map
     { [0 <1,0>][1 <0,-1>] }
}

#declare GranitePigment=pigment{granite}

#declare NormalToUse=GraniteNormal
#declare PigmentToUse=GranitePigment

camera

  location -z*Size look_at 0 angle 35
}

light_source { <100,100,-100>*Size*0.2, 1 }

box{
#if(ShowBug)
  -1,1
  scale <1,.001,1>  // this scale affects the normal
                    // but it shouldn't :-(
#else
  -1*<1,.001,1>,1*<1,.001,1>
#end

  pigment{ rgb 1 }
  finish { specular .2 }
  normal{NormalToUse}

  /* depth controled by scaling y */
  scale <1,Depth,1>

  /* put in place */
  rotate x*120
  translate 1.6*x

  /* set relative size */
  scale .1*Size
}

height_field{
  pattern 150 150
    {
      hf_gray_16
      PigmentToUse
      scale <.5,.5,.5>
      translate <.5,0,.5>
    }
  smooth

  /* now make it look the same */
  translate <-.5,0,-.5>
  scale 2
  scale <1,.08,1>

  /* plain texture */
  pigment{rgb 1}
  finish { specular .2 }

  /* depth controled by scaling y */
  scale <1,Depth,1>

  /* put in place */
  rotate x*120
  translate -1.6*x

  /* set relative size */
  scale .1*Size
}


Post a reply to this message

From: Fabian Brau
Subject: Re: MegaPov, normals, and a BUG
Date: 16 Dec 1999 05:41:42
Message: <3858C27E.A6924F68@umh.ac.be>
Nathan,

I have play with your scene. Good job (as usual)!!

> --------------- THE BUGFIX ----------------
> 
> There are two objects in this scene.  The one on the left is a height field
> created from a granite pattern.  The one on the right is a flat box with a
> granite normal applied.
> 
> The variable Size at the top sets the overall size of the scene.  All
> objects are relative and changing Size will scale everything relatively.
> So, if you change Size you should expect the scene to look exactly the same.
> (This is my basic assumption, so if this is incorrect, please let me know!)
> 
> Now, the depth of the bumps of the height field will automatically follow
> this assumption.  If you scale it twice as big, it gets twice as big in all
> three directions: x,z, and y(which is the depth).
> 
> The goal of my changes in MegaPov is to make the surface normals mimic the
> actions of the height field.  When rendered with MegaPov, both the flat
> object with normals and the height field should look very similar and behave
> the same way when Size is changed.
> 
> If this is rendered in official POV-Ray (with the height-field commented
> out), then changing Size will not leave you with the same scene.  Scaling it
> larger will leave you with a very flat box, while scaling it smaller will
> leave you with huge fake bumps.
> 
> You can change the Depth variable, too.  The Depth variable scales the box
> and height field along the Y axis, effectively changing the depth of the
> bumps.  The height field and box should remain looking similar as Depth is
> changed.  This has a limited range over which it looks believable, of
> course, since the normal IS faked on the box.
> 

I think this is the correct behavior!!
And your scene show that this is good!
Ok with this Nieminen Juha?

> --------------- THE BUG ----------------
> Did you notice the line #declare ShowBug=false; at the top?  If you set that
> to true, the normals on the box will look horrible.  That is because of a
> bug which I am aware of.  The problem is the "scale".  It's a complicated
> explanation.  If you really care, look at my most recent post in the
> bugreports group.

I think that this is a bug and must be corrected
Ok with this Nieminen Juha?

> 
> Anyway, MegaPov does fix a real bug that was really giving the wrong result,
> but also introduced a new very bad bug that also causes it to give the wrong
> result.
> 
> -Nathan
> 

Go on Nathan! I think all will be ok quickly :)!

Fabian.


Post a reply to this message

From: Nieminen Juha
Subject: Re: MegaPov, normals, and a BUG
Date: 17 Dec 1999 05:49:25
Message: <385a1535@news.povray.org>
Now I am _really_ confused. I can verify your result. This confuses me.
But what confuses me the most are the results of my own experiment.
  In this scene changing the value of the 'Size' identifier scales the
whole scene. With povray the scene renders identically no matter what value
of 'Size' you set, as I expected. To my surprise megapov does it too! So now
it works fine! Now I am confused. What the **** is happening here? Why my
previous test scene, which I posted to p.b.images didn't seem to work? Can
someone explain me, please? :)
  Here is my test scene:

#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,1
  pigment { rgb x } finish { specular .5 }
  normal { bumps .5 scale .1 }
  scale 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

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