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

[Ettore Pasquini]

Actually I just re-read my email and found it a little bit harsh: it wasn't
really my intention (I was just writing quickly), so it's me apologizing,
really. :)

Fly mode is great to have and it was great to see it implemented otherwise
I'd have had to do it! Your remarks made sense and yeah, terminology IS
confusing. I used the terminology I use inside 3Dconnexion just because I am
used to it on a daily basis... But we should agree on a common base.
Probably it would be useful to have a related wiki page.

Ettore 


On 8/13/07 6:26 PM, "sfogoros" <sfogoros at att.net> wrote:

> Hi Ettore,
> 
> 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,
> 
> SteveF
> 
> 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
>> 
>> 
>>> 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
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

-- 
http://www.3dconnexion.com/