Firstly, we sure could use a beta suggestion group, couldn't we?  :-)  This
is off-topic here as long as things are geared toward problems and bugs in
the programming.

I think this could be questionable because of the expected default of up y
happening to be the POV-Ray way of things, and if you didn't use a pure
single axis for any other up direction it might get more complex than just
accomodating the flipping via script workarounds.  Take for example up
<1,0,1> or up <0.1,0,0.9> or any other non-singular axes.  sky is just
trying to remain at the default instead of adhere to all sorts of other
possibilites unless you specifically tell it otherwise (the point of having
sky).  Although it could be argued how up and right would not typically be
non-perpendicular in the first place, but sky is supposed to be the variable
for "up", not a duplicate of 'up'.  Don't know if I'm being logical or
rational about it, just my limited observation.  The actual workings of
camera aren't extremely well-known to me.
I could imagine there might be some way of automating the different
coordinate systems but likely more to it than sky alone involved.



bob h

"Greg Smith" <gsm### [at] alumniuwaterlooca> wrote in message
news:3C7C3BFA.87E7B214@alumni.uwaterloo.ca...
> I just started working with a scene-centric coordinate system (z =
skywards;
> xy is level plane; see the following camera) and found that small
horizontal
> motions of look_at cause the camera to roll over. A look through the docs
> turns up the 'sky' vector; if I put  sky <0,0,1> ahead of the look_at, it
works
> fine.  My suggestion is that the default 'sky' should point in the same
direction
> as 'up', rather than in 'y' direction. The set of old scenes which would
be
> broken by this change is likely very small (those which point the 'up'
vector
> somewhere other than +y, and don't set a 'sky', but use look_at).

Post a reply to this message