In article <3c778848@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> Should they take the input height data from a standard 2d square from <0,0>
> to <1,1> (like UV mapping and like the height_field object works) or should
> they take the height data from the points in 3D space where the surface is
> (just like a solid texture works)?

I designed them to operate this way for a reason. They are most often 
going to be used with built-in patterns and user defined functions, 
taking the points in space allows them to be done without seams, and in 
the case of the sphere, without "pinching" at the poles. If the <0, 0> 
to < 1, 1> range is used, this will be impossible without using 
image_maps with specially generated images. This way, you can easily 
adapt images simply by using the existing mappings (an extra keyword and 
number), but don't have to go through any extra work to get a clean 
fully-procedural object.
They aren't tied to images like the built-in primitive originally was, 
there is no reason to force them into the <0, 0> to < 1, 1> range.


> If the latter is decided, I think they should be named to something 
> else than HF_*, as it is inconsistent with the basic concept of the 
> height_field object. It's more like displacement mapping.

I do not see how it is inconsistent with the idea of a height field. 
They are still "height fields", they are objects in which the height 
varies...they take their heights from a function, but image data is not 
necessary for the definition. They operate slightly differently from the 
height field object, because they aren't subject to the same 
constraints, but the differences are well documented.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message