"Christopher James Huff" wrote:
> As I said, a deficiency of the mappings. And it
> isn't that much work...at least, no more work
> than mapping an image texture onto a cylinder.

Which is quite some work that could easily make a user give up.

> A set of macros to automate the mapping (MapSphere()
> and MapCylinder() for example) might be useful

I don't see why it should be made so difficult for the user when the same
could be obtained by adding a new parameter (UV-mapping) to the HF macros
which could simply be set to true or false. If set to false they would work
as currently, if set to true they would take the data from the <0,0> to
<1,1> square. Can't be more simple than that.

What you propose would at the very least require the user to specify the
location/end points and radius twice, one time for the HF macros themselves
and again to make the mapping properly aligned. I think that's a bad
solution.

> it doesn't belong in the height field macros.

I disagree.

For the record I was asking for opinions and I've seen that dropping the
parse_string method is preferred and the HF names can also be kept. But I
have yet to see a good argument why the user should not be given the options
to use either UV mapping of the height data or not, with just a simple
switch.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message