Hi.

The tutorial for the height_field primitive makes the user generate a sample
height field by rendering a trivial scene with a plane and a wrinkles
pattern.

I often felt the need of such a purely random height field, to serve as a
natural floor for a scene. I find the need for an external file somewhat
annoying: the file must either be carried around with the scene, or
re-generated, it is cumbersome.

I just found that patterns and pigments could be programatically queried
through the use of user-defined functions. Something like:

#declare height = function { pattern { wrinkles } }

This opens the possibility to use it directly as a height field, either with
an iso_surface (function { y - height(x, z, 0) }) or by building a mesh
(less elegant, but seems to be faster).

Are there drawbacks in doing so? Or more elegant solutions to this problem?

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> I often felt the need of such a purely random height field, to serve as a
> natural floor for a scene. I find the need for an external file somewhat
> annoying: the file must either be carried around with the scene, or
> re-generated, it is cumbersome.

> I just found that patterns and pigments could be programatically queried
> through the use of user-defined functions. Something like:

> #declare height = function { pattern { wrinkles } }

  Read the documentation more carefully. You can create a height_field
from such a function without the need for an external image file.

-- 
                                                          - Warp

Post a reply to this message

Warp  wrote in message <45732d8c@news.povray.org>:
>   Read the documentation more carefully. You can create a height_field
> from such a function without the need for an external image file.

There is indeed something directly in the height field, thanks for pointing
it.

But it is not in the doc. The doc says:

# HEIGHT_FIELD:
#     height_field{
#       [HF_TYPE]
#       "filename"
#       [HF_MODIFIER...]
#       [OBJECT_MODIFIER...]
#     }
# HF_TYPE:
#     gif | tga | pot | png | pgm | ppm | jpeg | tiff | sys | function
# HF_MODIFIER:
#     hierarchy [Boolean]  |
#     smooth               |
#     water_level Level
(copypasted from http://www.povray.org/documentation/view/3.6.1/279/)

And the keyword "function" is nowhere to be seen in the explanation. After a
look in the source code, I find that the correct syntax is something like
that:

height_field {
  function 200, 200 { height(2 * x - 1, 2 * y - 1, 0) }
  pigment { Cyan }
  scale <2, 1, 2>
  translate <-1, 0, -1>
  translate dist * z
}

With the 200, 200 being the size of the height field. Please note that it is
not conform to the documented syntax, since the "filename" field is said to
be mandatory.

I believe there is a problem in the documentation about this feature.

Post a reply to this message

Wasn't it Warp who wrote:
>Nicolas George <nicolas$george@salle-s.org> wrote:
>> I often felt the need of such a purely random height field, to serve as a
>> natural floor for a scene. I find the need for an external file somewhat
>> annoying: the file must either be carried around with the scene, or
>> re-generated, it is cumbersome.
>
>> I just found that patterns and pigments could be programatically queried
>> through the use of user-defined functions. Something like:
>
>> #declare height = function { pattern { wrinkles } }
>
>  Read the documentation more carefully. You can create a height_field
>from such a function without the need for an external image file.

Here's a comparison of using an isosurface vs using height_field with a
function.

http://www.econym.demon.co.uk/isotut/patterns.htm#hf

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> I believe there is a problem in the documentation about this feature.

  That may indeed be true. The function feature is a quite new addition
and the documentation is not always up-to-date.

-- 
                                                          - Warp

Post a reply to this message

Mike Williams  wrote in message <GMT### [at] econymdemoncouk>:
> Here's a comparison of using an isosurface vs using height_field with a
> function.
> 
> http://www.econym.demon.co.uk/isotut/patterns.htm#hf

This whole page is quite interesting. Regarding isosurface vs. height_field,
it says pretty much what should be expected: height_field is faster but
requires more memory, but isosurface is more detailed and
resolution-independent.

Post a reply to this message

> Nicolas George <nicolas$george@salle-s.org> wrote:
>> I believe there is a problem in the documentation about this 
>> feature.
> 
> That may indeed be true. The function feature is a quite new addition
>  and the documentation is not always up-to-date.
> 
In the "Quick Reference" I think it's well described (from
http://www.povray.org/documentation/view/3.6.1/528/)

[...]
HEIGHT_FIELD:
     height_field { HF_IMAGE [HF_MODIFIERS] }
HF_IMAGE:
     FUNCTION_IMAGE | [HF_TYPE] FILE_NAME
HF_TYPE:
     gif | tga | pot | png | pgm | ppm | jpeg | tiff | sys
[...]

So indeed the filename is optional with a function image. Maybe the
Quick Reference gets updated more often...

The function image is in fact not described under heightfield but rather
under Textures->Patterns here
http://www.povray.org/documentation/view/3.6.1/379/

I know it was in there because I used it once and I would never have
figure it out without the docs ;-)

Regards

-- 
Vincent

Post a reply to this message