It's not a major issue, since the next release is probably going to be 4.0, but
I just noticed that translate doesn't discriminate between 2d and 3d vectors. I
don't know if this is an intentional behavior or not.

I was trying to figure out why turning off ambient reflection in my finish
blocks was blacking out my scene, and didn't notice the missing comma in my
light_source location vector:

#declare ft = 12;

// before
light_source {
     0*x
     rgb 1
     translate <20.0, 50.0 -75.0>*ft
     }

// after...
light_source {
     0*x
     rgb 1
     translate <20.0, 50.0, -75.0>*ft
     }

oops...

I suspect that the reason this doesn't give an error is because of
vector-promotion, but shouldn't there be cases where vectors aren't promoted, or
is it too difficult to promote scalars, but disallow 2d vectors?

without digging through the code myself to see how the promotion is handled, I
couldn't say.

Although I must admit that, even if I can't see a reason to use a 2d vector in a
translate statement, that one doesn't exist.  Feel free to enlighten me.

regards,
A.D.B.

Post a reply to this message

Anthony D. Baye wrote:

> I suspect that the reason this doesn't give an error is because of
> vector-promotion, but shouldn't there be cases where vectors aren't promoted, or
> is it too difficult to promote scalars, but disallow 2d vectors?

It's probably more of an issues to having to decide where 2d vectors
are allowed based on context. Generally there may be situations where
it is useful, as in code that does random object placement in 2d, you
can then directly use the 2d vectors to translate in x-y plane and
rotate as needed.

Personally I'd prefer the stricter method of requiring to enter
the z (or blue) component even if 0 or use explicit syntax to convert
2d vector to 3d vector (v2 = <a,b>; v3 = <v2,0>?) and have better
protection against missing comma errors, but that would of course
break existing code (although only for beta users if it requires
#version 3.7 directive).

Post a reply to this message