[Bf-committers] NDOF: patch for spin/roll rotations

[sfogoros]

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 
professor responded:

    rotation: yaw/pitch/roll
    pan: translation
    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 
any dictionary).

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.

SteveF

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):
> http://cubelogic.org/blender/zoom-axis-setting.png
> 
> 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:
> http://cubelogic.org/blender/spin-roll-control.patch
> 
> The patch above makes all the rotations consistent with your zoom settings.
> 
> Ettore
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>