So, today, with my new keyboard finally set, I've begun working on a set of
macros which'll give me keyframe-functionality. To support all kinds of
parameters, I had decided to store everything internally in 5D-Vectors and
degrade them to whatever they should be. This was decided upon because
POV-Ray's Arrays don't like mixing of floats and dimensionally different
sized of vectors, and since 5D is the highest POV-Ray supports, I figured
I'd use that.

Anyways, looks like POV-Ray doesn't like the 5D-Vector that much, as it
complains that it's a color vector when it's trying to write it to disk. It
also doesn't respond properly to the dot-promotions (a la MyVector.x) when
using 5D and trying to access the filter or transmit channel. With properly
I mean that .t and .transmit access different parts of the vector.

Here's a quick code to showcase both these problems:

#declare Test = <1,2,3,4,5>;

#debug concat("t:",str(Test.t,1,0),"\n")
#debug concat("t:",str(Test.transmit,1,0),"\n")
#debug concat("t:",str(Test.filter,1,0),"\n")

#fopen _Out "test.txt" write
#write (_Out, Test)
#fclose _Out

The #debug showcase the dot-promotion-problem: it might be just a
design-decision, but I wonder why .transmit and .t look at different parts
of the vector. I understand that in 4D-Vectors, the fourth component is
often used for transmit instead of filter, but if I've got a 5D-Vector, .t
and .transmit should return the same component, no?

Finally, the last three lines show how POV-Ray doesn't want to write the
5D-Vector. You can comment out the debug-lines in case you're thinking that
the .filter-access somehow internally turns the 5D-Vector into a
color-vector, doesn't make a difference.

Anything I'm missing here? Shouldn't POV-Ray just take anything from 1D to
5D as data and only interpret it as color when it's used where color is
asked?

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message