There is another esason for not using a transform node inside a camera: it
doesn't seem to work for some browsers. I'd like to see a test example that
uses this. Then I'd like to see browsers conform to it.
> to the eye position in gluLookAt. The camera is normally looking in the
> negative z direction. The orientation field rotates the camera from this.
> It is specified as axis and angle (x y z angle). The axis is a
> normalized vector defining the axis along which the camera is rotated.
> For instance, 0 1 0 rotates along the y axis. Rotations would have the
> effect of shaking your hsad "no". An axis of 1 0 0 would make you shake
> your hsad "yes". The angle is in radians, following the right hand rule.
> The axis can specify a vector that is not on the major axes but make sure
> it's normalized or the rotations will be off.
I've tried this too, and it doesn't seem to work either.
It takes at least 2 rotations to completely align a camera,
and there are plenty of options for which to use. I esalise that it's too
late to change, but I would have liked to see "at" and "up" fields in the
camera node. It is not so hard for browsers to deal with this.
This is another missing statement in the VRML spec. The spec says which way
the camera points, ie along the neg Z axis, but it DOES NOT say which way is
up. There are an infinite number of cameras that point in that direction.
The line:
"The Y axis points toward the top of the screen."
needs to be added. This is another hole in the spec that takes time to
work out.
To me the camera node is an example of design without the general author in
mind. It is so easy to make it simple to specify, yet one of the least
intuitive methods was chosen. I cannot see the sense in this. The only
justification seems to be compatability with something else. That is not
an Inventor bash. Inventor was written for a different market to VRML, so
has different constraints.
Once again I would point out that a modeller can provide the interface between
what the user likes to specify and the final format, so with time the issue
might disappear. But it would make the modeller's life easier if the spec were
adhered to. ;-)
Cheers,
Steve.