I'm about to try my hand at some outdoor scenes, where I'd like rolling
hills.

Any tips on the best way to get a fast-rendering scene (for use in
animations)
height fields,  isosurfaces, bicubic patches,  one of the above then
converted to meshes ?


I'm guessing my biggest mistake with povray is always wanting to model an
entire continent rather than just  the area in the field of view ahead of
me.

Post a reply to this message

"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:40148bb3@news.povray.org...
> I'm about to try my hand at some outdoor scenes, where I'd like rolling
> hills.
>
> Any tips on the best way to get a fast-rendering scene (for use in
> animations)
> height fields,  isosurfaces, bicubic patches,  one of the above then
> converted to meshes ?

I personally like using patterns as functions in height_fields:
Note how fast this scene renders:


#include "colors.inc"


camera
{
 location <0, 2, 0>
 rotate 30*x
}


sky_sphere
{
 pigment
 {
  gradient y

  color_map
  {
   [0.5 rgb <1, 1, 1> ]
   [1 rgb <0, 0, 0> ]
  }
 }
}


light_source
{
 <-100, 100, -100>
 color White
}


#declare f_hills =
function
{
 pattern
 {
  bumps

  scale <0.1, 0.1, 0.1>
 }
}


height_field
{
 // Incease your resolution here if you need to.
 function 256, 256 { f_hills(x, y, z) }
 smooth

 pigment
 {
  color rgb <1, 1, 0.8>
 }

 translate <-0.5, 0, -0.5>
 scale <10, 0.5, 10>
}

#include "colors.inc"


camera
{
 location <0, 2, 0>
 rotate 30*x
}


sky_sphere
{
 pigment
 {
  gradient y

  color_map
  {
   [0.5 rgb <1, 1, 1> ]
   [1 rgb <0, 0, 0> ]
  }
 }
}


light_source
{
 <-100, 100, -100>
 color White
}


#declare f_hills =
function
{
 pattern
 {
  bumps

  scale <0.1, 0.1, 0.1>
 }
}


height_field
{
 // Incease your resolution here if you need to.
 function 256, 256 { f_hills(x, y, z) }
 smooth

 pigment
 {
  color rgb <1, 1, 0.8>
 }

 translate <-0.5, 0, -0.5>
 scale <10, 0.5, 10>
}

Post a reply to this message

"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:40148bb3@news.povray.org...
> I'm about to try my hand at some outdoor scenes, where I'd like rolling
> hills.
>
> Any tips on the best way to get a fast-rendering scene (for use in
> animations)
> height fields,  isosurfaces, bicubic patches,  one of the above then
> converted to meshes ?


iso's just seem the right thing for me, except it does have the pitfalls of
getting it to look right. By that I mean the surface deformations together
with a texture.

HF's are nice sometimes but you would have a more difficult time getting
both a fast and good surface due to the parse times demanded of higher
resolutions. I'd think meshes would also suffer the same fate, since by
animating you don't preserve the mesh in memory like a copy of it in a
still.

Here's a quick example of rolling hills made with a iso having a simple bump
pattern. Rendering 16 frames of it at 160x120 pixels and with default AA
takes a mere 24 seconds on my P4 2 GHz notebook. Even though it would get
slower as more detail were added it could be easiest to work with and
animate. My opinion anyway.

[oh good, I see now that Dan P replied with a HF example which
renders more than twice as fast as my iso here. Although, I get an artifact
on its horizon for some reason.]

#declare RollingHills=
function {
 pigment {bumps}
}

isosurface {
 function {
  y-RollingHills(x,y,z).gray*0.5
 }
 contained_by {
  box {-<10,1,10>,+<10,1,10>}
 }
 threshold 0
 accuracy 0.01
 max_gradient 1
 pigment {rgb <0.4,0.9,0.5>}
}

-- 
Bob H.
http://www.3digitaleyes.com

Post a reply to this message

Here's a modification of Daniel's code.  Why is there a distortion in x but
not z??


#include "colors.inc"

#include "functions.inc"

camera
{
 location <0, 2, -10>
 rotate 90*y
}



light_source
{
 <-100, 100, -100>
 color White
}


#declare f_hills =
function
{
 pattern
 {
  bumps

  scale <0.1, 0.1, 0.1>
 }
}

#declare blah=10;
#declare f_hills2=function{f_noise_generator(x,y,z,2)}


height_field
{
 // Incease your resolution here if you need to.
 function 256, 256 { f_hills2(x*blah, y, z*blah) }
 smooth

 pigment
 {
  color rgb <1, 1, 0.8>
 }

 translate <-0.5, 0, -0.5>
 scale <10, 0.5, 10>
}

Post a reply to this message

"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:40187a33$1@news.povray.org...
> Here's a modification of Daniel's code.  Why is there a distortion in x
but
> not z??

I was "flattening" the landscape by scaling Y. Otherwise, it was too hilly.

Post a reply to this message

"Greg M. Johnson" wrote in message news:40187a33$1@news.povray.org...
> Here's a modification of Daniel's code.  Why is there a distortion in x
> but not z??

If you use (x*blah, y*blah, z) instead of (x*blah, y, z*blah) you get what you 
expect to see. The question is: Why? Is f_noise_generator right-handed?

Post a reply to this message

"Tim Riley" <tim### [at] netscapenet> wrote in message
news:401a93a3$1@news.povray.org...
> "Greg M. Johnson" wrote in message news:40187a33$1@news.povray.org...
> > Here's a modification of Daniel's code.  Why is there a distortion in x
> > but not z??
>
> If you use (x*blah, y*blah, z) instead of (x*blah, y, z*blah) you get what
you
> expect to see. The question is: Why? Is f_noise_generator right-handed?

It's a matter of style for me. I like to set things up so that I can easily
modify them later. I find tacking on a scale on the end is easier to
comprehend, for me, than changing the parameters to the function. But, I'm
kindof a dimwit, and you can always tell that in my code (cough, production
code, Warp :-) ) because if I don't make it readable, I can't read it later
and I stop enjoying writing code. Think of me as a painter who loves to
paint but would never cut his ear off. That's why I enjoy reading these
newsgroups because everybody on it is more clever than I and I learn more
from that than reading documentation.

Post a reply to this message

news:401a93a3$1@news.povray.org...
> "Greg M. Johnson" wrote in message news:40187a33$1@news.povray.org...
> > Here's a modification of Daniel's code.  Why is there a distortion in x
> > but not z??
>
> If you use (x*blah, y*blah, z) instead of (x*blah, y, z*blah) you get what
you
> expect to see. The question is: Why? Is f_noise_generator right-handed?

The reason is that function n,n works as an image_map, which exists in the
x,y plane (and from top to bottom in the y direction IIRC). The z in this
case isn't taken into account.

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> The reason is that function n,n works as an image_map, which exists in the
> x,y plane (and from top to bottom in the y direction IIRC). The z in this
> case isn't taken into account.

Ah, now it makes sense. I couldn't find a reference to it in the help file 
earlier, but I just looked again and there it was - "6.7.11.16  Function Image". 
My computer must have been experiencing a temporal reference breach; I doubt if 
it had anything to do with the fact that I was searching for it at 2am.

Post a reply to this message

"Tim Riley" <tim### [at] netscapenet> wrote in message
news:401e9eeb$1@news.povray.org...
> Ah, now it makes sense. I couldn't find a reference to it in the help file
> earlier, but I just looked again and there it was - "6.7.11.16  Function
Image".
> My computer must have been experiencing a temporal reference breach; I
doubt if
> it had anything to do with the fact that I was searching for it at 2am.

Sorry, I misunderstood the question :-) Thanks for the save, Gilles.

Post a reply to this message