Hi there!

Somehow I got the impression that the brief list of changes btw. 
versions 3.5 and 3.6. on http://www.povray.org/download/features/ might 
possibly be not too exhaustive...

OK, here's what I observerd: I am using POV-Ray for Windows as external 
rendere for some kinda Myst-style 3D adventure game experiment. To this 
end, I created a landscape based on a height field which uses the agate 
pattern as underlying function (actually I more or less copied the code 
from the scenes/advanced/landscape.pov demo file). I also randomly 
placed a bunch of ellipsoids ("pebbles") onto the landscape. The 
pebbles' x- and z-coordinates are created randomly, and the 
corresponding y-coordinates are calculated by using the trace() function 
in order to determine the height field's actual height at the pebbles' 
x- and z-positions. To circumvent the need for going through the 
time-consuming pebble creation process over and over again, I calculated 
the pebble positions only once and stored them into an include file.

Now after switching from version 3.5 to 3.6 the pebbles suddenly began 
to hover over the ground! Looks sort of mystic, but that's not what I 
actually intended... ;-)

When re-running the pebble position calculation under 3.6, everything is 
fine again -- the pebble's y-coordinates, however, really have changed 
when compared to the include file created with 3.5!

So does anyone know what might be the reason for the observed 
discrepancy? A change in how the agate function gets calculated? How 
height fields get smoothed? Or how the trace function determines 
intersections?

I wouldn't mind sticking with version 3.5 for now, it's just for the 
sake of curiousity...

Thanks for any comments --

	Torsten

Post a reply to this message

Torsten Crass wrote:
> Hi there!
> 
> Somehow I got the impression that the brief list of changes btw. 
> versions 3.5 and 3.6. on http://www.povray.org/download/features/ might 
> possibly be not too exhaustive...

You are probably using noise_generator 3, see:

Subject: Re: Changed media
Date: Sun, 13 Jun 2004 11:55:51 +0200
From: Christoph Hormann <chr### [at] gmxde>
Newsgroups: povray.binaries.images

Apart from that i am not aware of any significant differences in 
patterns.  If you post the code a more definite answer would be possible.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> You are probably using noise_generator 3

I'm curious, has it been discussed or explained why noise_generator 3
was changed in POV-Ray 3.6? And why isn't it in the list of changes?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Apr 27**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> I'm curious, has it been discussed or explained why noise_generator 3
> was changed in POV-Ray 3.6? And why isn't it in the list of changes?

This changed quite late in 3.6 development, probably as an unintended 
side effect of a different change.  Note that NG 3 was always considered 
as experimental (and still is) due to the regularities and the sad thing 
is we now have an incompatibility without fixing this problem.

I assume it might be possible to track down the relevant change and 
restore the previous behaviour (but don't take my word on this) but 
since 3.6 is now released this would just introduce additional 
confusion.  My suggestion would be not to use NG 3 at the moment.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Hi Chris,

> You are probably using noise_generator 3, see:

well, I didn't actually change the global noise_generator setting, so it 
should be type 2 (the default, at least according to both 
documentations) in either case, shouldn't it?

> Apart from that i am not aware of any significant differences in 
> patterns.  If you post the code a more definite answer would be possible.

OK, here comes some sample code (instructions below):

---8<---

// Set this to 1 to recalculate pebble positions and
// to store pebble definitions in "pebbles_test.inc";
// set to 0 to re-use previously generated pebbles file.
#declare recalculatePebblePositions = 1;

#include "transforms.inc"
#include "strings.inc"

// agate-based height field object
#declare Terrain =
height_field {
   function 200,200 {
     pigment {
       agate
       color_map {
         [0.0 color rgb 0.0]
         [0.3 color rgb 0.2]
         [0.7 color rgb 0.8]
         [1.0 color rgb 1.0]
       }
       scale 0.5
       turbulence 0.1
     }
   }
   smooth
   texture {
     pigment { color rgb <0.2, 0.8, 0.0> }
   }
   translate <-0.5, 0, -0.5>
   scale <10000, 1000, 10000>
   translate <-500, 0, 0>
}

// This macro creates ellipsoids located randomly
// at the height-field's surface and stores their
// definitions in a file named "pebbles_test.inc"
#macro makePebbleFile()
   #fopen F "pebbles_test.inc" write
   #local randSeed = seed(1);

   // make 3000 pebbles
   #local i = 0;
   #while (i < 3000)

     // the height field's surface normal at the
     // intersection point; simultaneously a flag
     // for "intersection found" according to
     // documentation of trace function
     #declare intersectionNormal = <0, 0, 0>;

     // a parameter combining the height field's height
     // and slope at the intersection point
     #declare heightSlope = -1;

     // randomly create the pebble's x- and z-coordinate
     #local pebbleX = (rand(randSeed) - 0.5)*10000;
     #local pebbleZ = (rand(randSeed) - 0.5)*10000;

     // calculate intersection of a ray originating at the pebble's
     // x- and z-coordinates and propagating into y direction with
     // the height field
     #declare intersectionPoint = trace(Terrain, <pebbleX, 0, pebbleZ>, 
y, intersectionNormal);

     // if an intersection was found, intersectionNormal should
     // contain the height field's surface normal at the intersection point
     #if (vlength(intersectionNormal) !=0)

       // calculate "degree of horizontalness"; s is
       //   0 at a horizontal plateau,
       //   1 at a vertical wall,
       //   2 at a horizontal overhang
       #local s = 0.5*(vdot(-intersectionNormal, y)+1);

       // relative height of intersection point
       #local h = intersectionPoint.y/800;

       // combination of horizontalness and height;
       // is low if both horizontalness and height are low.
       #declare heightSlope = s + 0.8*h;
     #end

     // if not too high and not too steep...
     #if ((heightSlope >= 0) & (heightSlope < 0.25))

       // set size to random values
       #local pebbleSizeX = rand(randSeed)+0.2;
       #local pebbleSizeZ = rand(randSeed)+0.2;

       // ensure the pebble is not higher than wide
       #local pebbleSizeY = rand(randSeed)*(min(pebbleSizeX,pebbleSizeZ));

       // combine individual size values into scaling vector
       #local pebbleSize = <pebbleSizeX, pebbleSizeY, pebbleSizeZ>;

       // now write to file the definition for a sphere scaled to size 
vector...
       #write (F, "sphere { 0 20 texture {pigment { color rgb <1.0, 0.8, 
0.5>} } scale ",VStr(pebbleSize))
       // ...rotated around y axis for a random angle...
       #write (F, " rotate y*",str(rand(randSeed)*360,0,0))
       // ...ensure it lies flat on a sloped surface...
       #write (F, " Point_At_Trans(",VStr(intersectionNormal))
       // ...and translate to determined intersection point
       #write (F, ") translate ",VStr(intersectionPoint)," + 
y*",Str(pebbleSizeY),"/2 }\n")

       // another pebble has been placed
       #local i = i + 1;

     #end
   #end

   #fclose F
#end

// introduce height field into scene
object {Terrain}

// if requested, re-calculate pebble positions
#if (recalculatePebblePositions)
   makePebbleFile()
#end

// include previously calculated pebble positions
#include "pebbles_test.inc"

// blue sky
sky_sphere {
   pigment {
     gradient y
     color_map {
        [0.5 color rgb <0.8, 0.9, 1.0>]
        [1.0 color rgb <0.5, 0.8, 1.0>]
     }
     scale 2
     translate -y
   }
}


// we are standing somewhere in the landscape,
// looking south-south-east
camera {
   location  <-2000, 200, 0>
   up        y
   right     x*4/3
   look_at   <-1000, 0, -2000>
   angle 80
}

// main light
light_source { <100000, 100000, -100000>
   color rgb 1
}

// additional ambient light
light_source { <-100000, 100000, 100000>
   color rgb 0.5
   shadowless
}

---8<---

To reproduce the "hovering pebbles" effect, do the following:

1. Set recalculatePebblePositions to 1 (line 4)
2. Run the script using PovWin 3.5
3. Change recalculatePebblePositions to 0
4. Re-run the script using PovWin 3.6

See what I mean? ;-)

Regards --

	Torsten

Post a reply to this message

Torsten Crass wrote:
> Hi Chris,
> 
>> You are probably using noise_generator 3, see:
> 
> 
> well, I didn't actually change the global noise_generator setting, so it 
> should be type 2 (the default, at least according to both 
> documentations) in either case, shouldn't it?
> 
>> Apart from that i am not aware of any significant differences in 
>> patterns.  If you post the code a more definite answer would be possible.
> 
> 
> OK, here comes some sample code (instructions below):

That is more likely a difference in the way the function image type 
works.  Since your heightfield is realtively low resulution such a 
difference shows up more strongly than usual.  You could try using an 
isosurface instead and see if it also leads to a difference - probably not.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> That is more likely a difference in the way the function image type 
> works.  Since your heightfield is realtively low resulution such a 
> difference shows up more strongly than usual.  

I see. Still funny it's not mentioned in the "changes from 3.5 -> 3.6" 
list since it apparently isn't a mere bug fix or speed improvement.

> You could try using an 
> isosurface instead and see if it also leads to a difference - probably not.

Yep, I will try this, thanx. I hope it won't render significantly slower...?

	Torsten

Post a reply to this message

Torsten Crass wrote:
>> That is more likely a difference in the way the function image type 
>> works.  Since your heightfield is realtively low resulution such a 
>> difference shows up more strongly than usual.  
> 
> 
> I see. Still funny it's not mentioned in the "changes from 3.5 -> 3.6" 
> list since it apparently isn't a mere bug fix or speed improvement.
> 

I don't remember the details but it probably is a change to make the way 
function images work more consistent.  I would not call it a bugfix 
although IIRC there have been complaints that function images don't work 
as expected in the past.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cb9jqa$6gk$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Torsten Crass wrote:
>>> That is more likely a difference in the way the function image type
>>> works.  Since your heightfield is realtively low resulution such a
>>> difference shows up more strongly than usual.
>>
>>
>> I see. Still funny it's not mentioned in the "changes from 3.5 -> 3.6"
>> list since it apparently isn't a mere bug fix or speed improvement.
>>
>
> I don't remember the details but it probably is a change to make the way
> function images work more consistent.  I would not call it a bugfix
> although IIRC there have been complaints that function images don't work
> as expected in the past.

No, you are wrong here:  We fixed a long-existing bug in height-field
smoothing that is mentioned in the release notes (iirc).  In short,
height-field smoothing did not work correctly before and thus now is looks
"different" compared to older versions of POV-Ray because those versions
were simply buggy.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> No, you are wrong here:  We fixed a long-existing bug in height-field
> smoothing that is mentioned in the release notes (iirc).  In short,
> height-field smoothing did not work correctly before and thus now is looks
> "different" compared to older versions of POV-Ray because those versions
> were simply buggy.

That does not sound reasonable to me, the smoothing change would only 
influence the normal vector returned by trace(), not the intersection 
point.  The difference Thorsten Crass observed is in the intersection 
points and not only in the normals.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message