[Bf-committers] NDOF: patch for spin/roll rotations
sfogoros at att.net
Tue Aug 14 03:26:33 CEST 2007
I hope you didn't feel like I was critical of your post.
I'm very new to Blender development and don't actually have any standing
to make declarations of how things should be, including terminology. I
did take an opportunity off of your post to try and sell my own agenda
of how things should be and elicit a response from the developers and
have my ideas considered as improvements for the future.
I am thankful for the support you and your company have offered,
Ettore Pasquini wrote:
> On 8/9/07 9:22 PM, "sfogoros" <sfogoros at att.net> wrote:
>> 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.
> I was mainly talking about turntable mode, but now that you make me think
> about it, I think the RY and RZ rotations are inverted in fly mode. I didn't
> notice the problem you described.
>> 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.
> In fact my fix addresses the turntable mode rotations, which are clearly not
> consistent. Anybody tried the patch yet?
>> 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.
> Did you see Google SketchUp? (BTW it's windows/mac only, sorry.) There's no
> turntable mode (just full 6DOF) and there is a camera fly mode. I think the
> implementation there is pretty good.
>> 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.
> Sorry about the confusion of terms. I think it's kind of inevitable when
> different disciplines cross over (blends into ;) each other. I hope what I
> wrote was clear enough. However, I think I was consistent: I always referred
> to the terminology used in the 3Dconnexion Control Panel.
>> 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