Rune wrote:
> 
> I have some questions on which approch to take with the HF macros.
> 
> Should they keep the current string input or take functions directly as
> input? Taking functions directly is how the macros were originally intended,
> but the string method makes it possible to also use macros as input which
> makes some things possible that can't be done with functions.

Although there are some things where macros could be useful, the ugly
ParseString() construction is reason enough to use only functions IMO.

> 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)? 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 think at least for the cylinder both versions have their advantage, for
sphere, the 'displacement mapping' style is probably more useful and for
square it's just a matter of scaling.  Maybe adding an uv-mapping
parameter would be good.

Another thing that should be changed: The files generated with
'OutputToFile' have no line breaks which makes it difficult to edit them
manually.  There should be one after each triangle i think.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message