#camera roll not wanted
3 messages in this thread
This quaternion (quanternion?) math thingie is why the "rotation" of Cameras
and Spotlights are called "Roll" instead of "Rotation." The angle of Roll is
the angle away from that needed to keep a line that starts at the center of the
Camera (or Spotlight) and passes through it's "bottom center" to keep pointing
straight down. It's not the same thing as either an X, Y, or Z Rotation.
Remember, Cameras and Spotlights have Targets. Objects don't. You don't
Rotate such things because that would affect the positioning of the Targets.
This is why I've been suggesting adding "Object Cameras" ever since the
WishList freeforall for Release "4." An Object Camera would look to the
Renderer as a Camera, but to the Keyframer as an Object (or, more properly, a
Dummy). Its visual representation in the Keyframer and 3D Editor screens would
be a dashed box (like a Dummy) that is Camera-blue, with a marking of some sort
in the center of one face (a circle, perhaps) representing the "lens." It
would NOT have a Target and thus would not have Roll keys. Instead, it would
have Rotate keys just like any other Object or Dummy. Instead of the Scale
keys, it would have FOV keys because in that respect it is still a Camera. It
could act as a Parent in heirarchies, with its Children inheriting Position and
Rotation just as if it were a Dummy. Perhaps any Objects linked to it would
inherit Scale based on the FOV such that they would appear to remain the same
size to the Camera as the FOV changed.
Such an Object Camera would not have the quaternion singularity movement
problem, and could be Keyframed like any other Object. It would not be useful
for tracking Objects while changing its position relative to them — for that,
you would use the regular Camera. But it would be useful for, say, the
viewpoint of a pilot of a plane when the plane is traversing a complex path
involving Rotations and Path Follow Banking, yet the pilot also sometimes looks
to the left or right etc. relative to the direction of travel.
<<This is why I've been suggesting adding "Object Cameras" ever since the
WishList freeforall for Release "4." >>
Your camera object idea sounds like the most logical solution to the problem.
Since Gary did *mention* that cameras will be handled differently in R5 we can
only hope <g>.
At the barest minimum, 3DS could allow you to specify a provisional "up" vector
for the camera, so that 3DS doesn't have to calculate it itself. Instead it
could use the provisional "up" vector to calculate the exact "up" vector used
by the camera. This would prevent all these quaternion singularity problems
since allowing you to explicitly specify where "up" is for the camera means
you can control the camera roll exactly as you want.
DaviD "Fragile: This way UP" GouID
"Object Cameras" would not REPLACE the current "Camera/Target Quaternian
Roll Cameras" that 3DS currently has, but rather be a new type of Camera that
SUPPLEMENTS the existing type, just as we now have both Omni and Spot Lights.
Which Camera type you use would be based on the types of Camera animation you
need to perform on a per-Project basis (and, of course, you can have multiple
Cameras per Project).
Most of the code for this is already present. An Object Camera would seem to
the KeyFramer to be precisely the same as a Dummy. It would be drawn as a Dummy
(dashed-line box) but colored the same shade of Blue that the regular Cameras
are. A circle or dot in the center of one face of the blue Dummy Box would show
where the lens is, while a square within another face 90 from the lens face
would show where the bottom of the Camera is. Given those two, the orientation
of the camera would be apparent. The Renderer would see this as similar to a
regular Camera located at the center of the pseudo-Dummy cube, with its Target
positioned at the dot on the "lens" face of the cube, and its Roll set so that
the bottom points to the center of the bottom face of the cube.