On 16 Nov 1998 12:05:54 -0500, par### [at] my-dejanewscom (Ron Parker)
wrote:

>On Sun, 15 Nov 1998 06:10:38 -0800, Ken <tyl### [at] pacbellnet> wrote:
>>Dan Connelly wrote:
>>
>>> I respectfully disagree.  The documentation is incredibly clear.
>>> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>>> so trivial there is no reason to change the source code.
>>>
>>> --
>>> http://www.flash.net/~djconnel/
>>
>>I respectfully disagree with your respectful disagreement.
>>Your simple example is 28 characters long. That's a lot
>>of simple typing. Nor does it redily explain the ambiguity.
>
>I respectfully disagree with your characterization of the
>situation as an ambiguity, since it's consistent among things
>that use images.  The real question is why image maps are on 
>the x-y plane and height fields on the x-z plane.  I also 
>respectfully disagree with your contention that it's 28 
>characters... "translate -.5" is only 13.

I have also wondered why image ,maps and height fields were located on
two different planes. It always bothered me to add the extra code
required to place an image map over a height  field. It could have
been *so* much simpler, if they were both on the same plane.

My other pet peeve about image maps is not having an option to
automatically maintain the original aspect ratio of the image. It
would be cool to set the x or y dimension to "1" and let POV
automatically scale the other dimension to keep the aspect ratio
intact. Something like "constrain_x" or "constrain_y" added to the
image map statement would be one possible syntax.

Later,

Post a reply to this message