[Bf-committers] NDOF: patch for spin/roll rotations
sfogoros at att.net
Fri Aug 10 06:22:29 CEST 2007
I understand there are problems with the current implementation. In fly
mode, the rotations Rx and Ry are rotated by the current Rz angle. This
creates a problem when the view is TOP (translate is effected too). I
plan to correct this soon where the behavior is a first person view of
the scene in all orientations.
In turntable mode, I never could figure out how the implementation
'should' behave and couldn't fix it (which is why I wrote fly mode).
Anything you can do to make this mode work better will be great.
Regarding a Zoom axis, I hope to convince everyone that zoom is a
function of a camera lens and not of viewpoint movement. I would like to
make what is currently called and implemented as zoom become translate
along the current view axes (what the mouse wheel should do).
I looked at some other 3D software and found predominantly turntable
type rotations (centered on the screen center) and translations. I
didn't find a fly or first person mode in Maya. Terms for movement and
rotation are commonly misused too.
Briefly, in cinematography, Pan is a rotation about the camera's (or
viewpoint) Z axis. Tilt is rotation of the X axis and Oblique (or Canted
Angle, Dutch Tilt) is rotation of the Y axis in a Z up coordinate
system. Dolly is a movement toward or away from the subject and truck or
crab is sideways movement. In the early days there wasn't much use of
changing the camera height and the only term I found was crank, as in
'crank' the camera up or down. Later, the term Crane became widely used
to indicate vertical movement.
As some filmmakers became computer animators, these terms continued to
be used. I asked a local university that offers a degree program in
animation and game design what terms they teach in their curriculum. One
zoom: fov (field of vision)
for artists (as in apps like 3ds max):
pan instead of translation
zoom now is actually interpreted as a eye-vector translation, with a
seperate field of vision operation.
(SteveF Note: yaw/pitch/roll are aviation terms (vehicles of flight
rotations) and I was surprised to see them referenced in an animation
and game design curriculum.)
(SteveF Note 2: two months ago I was incorrectly using yaw/pitch/roll
while writing code for Blender; sorry. The information I am sharing here
is a result of research on correct terminology)
I've noticed the term Pan used in 2D drawing programs to indicate
scrolling the screen in X and Y. Since it's not a camera movement
description, it may be a correct use of the term (but not currently in
Blender is many graphical tools. As an animation tool, I think it is
important to respect the historical terms and set the standard for
correct use of animation and camera movement and rotation terms. I
suspect in the future, the old cinematography terms will fall into
disuse and computer animators without a cinematography background will
use the terms translate and rotate to describe camera and viewpoint
movements. This seems to already be true of game designers. I think the
other 3d applications' misuse of terms is due to programmers who decided
what to name the application's view rotation and movement functions and
did not have a background in animation or film.
The important issue at hand is the term Zoom. Zoom is a camera lens
setting. Any function of moving the camera or viewpoint position
relative to the scene should be described in film or math terms (like
dolly or translate). It's confusing because the desire to 'get closer'
to the subject feels like a zoom movement. Zoom should effect the field
of view. Getting closer to the subject with a 'zoom' effect requires
translating along the current view rotation and there is typically no
film term for that. That's probably why we [incorrectly] call it zoom.
In the early days of cinematography it wasn't possible to move the
camera that way. Today, with a SteadyCam or crane, it's possible to
'dolly to subject' but I don't know what term to use for that movement.
What I do feel is that Zoom is not the correct term in this case.
I think the way zoom is implemented in Blender may have a lot to do with
how the 3dView code was written (and difficult to understand). The use
of G.vd->dist and it's many obfuscations to give a zoom effect during
editing could be removed from the code base by implementing the two
functions separately; zoom effects the camera's perspective view only
and is a lens behavior. Getting closer to the subject is a translate
along the current view rotation.
Luc, I've been working on a draft article of terminology for the wiki
but thought to speak up here and get some feedback and influence.
p.s. I've also written on 3dConnexion's forum on terminology used in the
driver configuration panels. I've suggested they not use application
specific terms or mix up and misuse aviation and film terms to describe
the device axes. I recommended they generalize to the math terms Rx, Ry,
Rz, Tx, Ty, Tz, and generic button terms. Each application that supports
their input devices should provide mapping from their generic axes terms
to the application's terms of each axis. That way an animation
application can map Rz to Pan and a flight simulator can map Rz to Yaw.
Setting up application specific axis labeling would be nice if done
correctly. At the minimum, the USB HID report should use generic terms.
Ettore Pasquini wrote:
> I don't know if anybody noticed but the rotations currently performed with
> our NDOF devices are wrong in Blender. To realize this, let's use a
> CAD-style Zoom axis (i.e. parallel to the device base (blue setting in the
> pref pane):
> Go to Top View in turntable mode and slightly tilt the view so the world's
> Up blue axis points down. If you do a Spin motion on the device everything
> _seems_ ok. Now tilt back so the Up axis points up. Oops, the rotation is
> now inverted. Now, if you spin and tilt the view at the same time, bringing
> the Up blue axis from pointing up to pointing down, you'll notice a "bump"
> when it crosses over. Not good.
> The full issue is that if you are looking down (Top view) you are using the
> Spin axis on the device to rotate around the Up axis, although the axis
> parallel to the Up-axis is the Roll axis on the device. It is not
> consistent. If the seen Up axis is parallel to the zoom axis, you should
> use a Roll motion only. When you start to tilt, moving from Top to Side
> view, Spinning will increasingly become more relevant while the Roll
> component should decrease. When a full Side view is reached, rotations
> around the world's Up axis are achieved with a Spin motion only.
> In other words the control of the spinning around the world's Up axis should
> move from the device's Spin axis to the device's Roll axis depending on the
> orientation of the world's Up axis relative to the screen.
> I hope my explanations were clear enough. I suppose it's much easier to just
> apply the patch and see for yourself:
> The patch above makes all the rotations consistent with your zoom settings.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers