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

Tim Nikias <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> .t and .transmit should return the same component, no?

  't' does not mean 'transmit' even though 'transmit' starts with a
letter t. (The fact that it starts with t is just coincidence.)

-- 
                                                          - Warp

Post a reply to this message

> > .t and .transmit should return the same component, no?
>
>   't' does not mean 'transmit' even though 'transmit' starts with a
> letter t. (The fact that it starts with t is just coincidence.)

Hm. What does the "t" stand for then?

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

Post a reply to this message

Tim Nikias <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> Hm. What does the "t" stand for then?

  Nothing. It's just the common next dimension index denomination after
x, y and z.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Tim Nikias <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
>> Hm. What does the "t" stand for then?
>   Nothing. It's just the common next dimension index denomination after
> x, y and z.

If .t is the common next dimension index denomination after x, y, and z, 
it is likely that it stands for 'time'.  You know, the fourth dimension?

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Tim Cook <z99### [at] bellsouthnet> wrote:
> If .t is the common next dimension index denomination after x, y, and z, 
> it is likely that it stands for 'time'.  You know, the fourth dimension?

  Maybe it originates from the tensor metric of the GToR. Of course in
POV-Ray it doesn't make too much sense to call it "time", but just 't'. :P

-- 
                                                          - Warp

Post a reply to this message

Well, even though I've learned that ".t" is not the same as ".transmit",
there remains the mystery of 5d-Vectors returning a parse error when trying
to write the vector to to disk. Intended behaviour? Something to be fixed
for 3.7? :-)

Regards,
Tim

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

Post a reply to this message

"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> Well, even though I've learned that ".t" is not the same as ".transmit",
> there remains the mystery of 5d-Vectors returning a parse error when trying
> to write the vector to to disk. Intended behaviour? Something to be fixed
> for 3.7? :-)
>
> Regards,
> Tim
>
> --
> aka "Tim Nikias v2.0"
> Homepage: <http://www.nolights.de>

I think intended error.  5D vectors are automatically assumed to be colour
vectors which can't be written directly. 2D, 3D & 4D vectors can be written
directly as long as they haven't been declared as colour vectors.  If
declared as colour vectors, they too create an error. The reason for this I
don't know, perhaps the developers can answer that one.

Consider:

#declare Test1 = <1,2>;
#declare Test2 = <1,2,3>;
#declare Test3 = rgb <1,2,3>;
#declare Test4 = <1,2,3,4>;
#declare Test5 = rgb <1,2,3,4>;
#declare Test6 = rgbt <1,2,3,4>;
#declare Test7 = rgbf <1,2,3,4>;
#declare Test8 = rgbft <1,2,3,4,5>;
#declare Test9 = <1,2,3,4,5>;

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

Test1, Test2 & Test4 write fine as they are assumed to be regular vectors.
Test3, Test5, Test6, Test7 & Test8 create an error because they are
explicitly declared as colour vectors.  Test9 creates an error because it
is assumed to be a colour vector of the type rgbft.


-tgq

Post a reply to this message