Page MenuHome

Improve NDOF navigation
Closed, ResolvedPublicDESIGN

Description

Recently there have been multiple users noticing NDOF (space-navigator) isn't working as they would expect.

See:

It seems most other software (including Space-navgator driver demo) works differently to Blender's defaults, making it seem as if something is broken.

This design task is collect these differences and update Blender to fit typical NDOF useage for other 3D software,
or - if there are good reasons to keep Blender working as-is, to support these features as preferences.


Key Differences

*Edit* this is the case for Blender 2.81, current master is being updated based on feedback from this task.

This list is based on user feedback may need updating, add comments if it misses anything.

  • Constraining Motion

    Blender: doesn't allow panning by default, instead modifier keys need to be pressed to pan for example.

    Other Software: doesn't constrain motion, similar to always being in walk-mode (without having to enter/exit walk mode).

    Open Topic: Would we orbit around the center of view (as with MMB orbit), or the view-point origin (as with walk mode). I'd assume we would default to orbiting around the view center.
  • Orbit Origin

    Blender: Orbits around the view center.

    Other Software: orbits the selection center.

    Note: Is this the case for most/all other 3D software with NDOF support?
  • Ability to transform objects

    Blender just doesn't support this at the moment, adding it to this list for completeness.

Event Timeline

Hi! I added 3Dconnexion support back in 2010/2011 and we got the same kinds of responses. Some people think everything is backwards, to others it feels right. Blender added options to customize direction/feel soon after that.

I've got several NDOF models & can help test.

Hey Mike, good to hear from you.

When I test my NDOF device it seems to work fine, so my impression is we might need to add preferences or change defaults.

I'm guessing free-navigation by default would be one of the main changes which could make it work as users coming from other software expect.

Since orbiting and zooming is easy enough with a mouse, that's the main reason to use NDOF.

Was there a reason it was done this way to begin with?

Hey lads.. i just got into blender and i also got one of these 3d connexion 3d-mouses and i had the same issue... so i started to look for an answer but did not find one. then i solved it.. i think.. all you need to do is change the transform view into any other example orbit view with zoom and it works... its a workaround cos you cant bind the movements.. ndof view navigate at orbit and view rotation trackball..

https://imgur.com/a/bgPsRMl

Hey lads.. i just got into blender and i also got one of these 3d connexion 3d-mouses and i had the same issue... so i started to look for an answer but did not find one. then i solved it.. i think.. all you need to do is change the transform view into any other example orbit view with zoom and it works... its a workaround cos you cant bind the movements.. ndof view navigate at orbit and view rotation trackball..

https://imgur.com/a/bgPsRMl

Here it´s not working. I would like that will be as smooth as in cinema or maya.

I would like that will be as smooth as in cinema or maya.

Can you clarify what you mean?

Is the motion slow or jirky, is this relating to redraw speed, or the way motion is interpreted? (not moving in the direcitons you expect)

J A (lazy) added a comment.EditedAug 14 2019, 7:28 PM

Hey mates.. i took a closer look at it and here's what i got..

There's nothing wrong with my workaround cos you get all axis and you can paint while moving.
In other programs including the trainer app the object is "in your hand" if you yaw rotate the object rotates. same as hitting r, z, in the object mode
In blender the object stays still and you move around it.
I dont know if this type of mode is available in blender, if not.. there's an intresting problem to solve =)

Actually i would like it to work like this...

nothing selected = free move
object selected = rotate mode and confirmation asks rotation stay/rotation old

Thanks.

Here it is a bit jerky, the rotational movements are reversed and doesn't move through the selection.

As suggestion; better than moving through the selection, it would be to move through a fixed point like in Catia. The middle mouse button is used to create a new center point of rotation. This option gives you more freedom to work.

A good example of proper NDOF device operation is in 3D Coat. Using a device such as 3DConnexion in that environment performs exactly as it would in the training examples/viewer application included with the drivers.

The issue I experience in Blender is that when the settings are corrected to perform like it does in the driver examples, you must hold shift to pan. Ideally you would be able to navigate without the use of modifier keys.

Another key thing to note is that in 3D Coat and the Viewer application, the device will create a pivot point for rotation in the scene:
In 3D Coat, a pivot is created wherever the cursor lies on an object's surface, and remains persistent even when the cursor moves away from the object, only updating when it returns to a surface.
In the Viewer application, it appears to update periodically to a surface or a point in space. This point appears to be at a predefined distance.

The system 3D Coat uses would be perfectly adequate, although preference options around how the pivot point should perform may be a worthy inclusion.

Hi everyone, i spent the complete day yesterday trying to fix the inverted axis issue when you try to edit under your model, if i am on top of the model everything work as expected but going under orbit is inverted making it impossible to work.

My navigation style is free&turntable, someone on blender artists told me to use trackball instead but it is unusable since it is moving erratically with very low precision, i tried adjusting every possible setting but it is a no go.

Then i saw another thread on stack exchange mentioning using orbit with turntable but you need to press a keyboard key to pan so this is defeating the purpose of having a 3d mouse!

I come from 3ds max and i didn't have any issue there so for us migrating to blender it's counter productive having to fight for this to work!

Another guy on stack exchange said the following code could easily fix this issue so i paste it here so a programmer can validate if it is indeed a fix:

At the declarations in the viewmove procedure add:

float firstvec[3], newvec[3], dvec[3];
float oldquat[4], q1[4], si, phi, dist0;
int firsttime=1;
short mvalball[2], mval[2], mvalo[2];
int reverse; //<----------------------------add this line and down
reverse=1;
if (G.vd->persmat[2][1] < 0)
reverse*=-1;

Then in the turntable declaration add:

QuatMul(G.vd->viewquat, q1, oldquat);

/* rotate around z-axis (mouse x moves) */

phi= 2*(mval[0]-mvalball[0])*reverse; //<-----add the “*reverse”
phi/= (float)curarea->winx;
si= sin(phi);
q1[0]= cos(phi);
q1[1]= q1[2]= 0.0;
q1[3]= si;

Many of us are having RSI issue and many more will eventually get RSI issues so i think that this will help people if it get the required attention.

Thank for considering my post.

Hi all, I'm actually quite happy with the behavior of orbit mode in general save for the necessity of using a modifier key in that mode and the resulting inability to pan / rotate simultaneously. Patched up view3d_edit.c locally to see if I could get it working, and it came off just fine from my perspective:

Given lines 1434-1447 of view3d_edit.c, in the ndof_orbit_zoom_invoke function:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);

  if (has_zoom) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, false, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

I just changed it as follows, et voila, works gloriously:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_translate = NDOF_HAS_TRANSLATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);
  
  if (has_zoom || has_translate) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, has_translate, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

Hi all, I'm actually quite happy with the behavior of orbit mode in general save for the necessity of using a modifier key in that mode and the resulting inability to pan / rotate simultaneously. Patched up view3d_edit.c locally to see if I could get it working, and it came off just fine from my perspective:

Given lines 1434-1447 of view3d_edit.c, in the ndof_orbit_zoom_invoke function:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);

  if (has_zoom) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, false, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

I just changed it as follows, et voila, works gloriously:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_translate = NDOF_HAS_TRANSLATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);
  
  if (has_zoom || has_translate) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, has_translate, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

Hello.. thx for this patch. tryed it myself, pan works now in orbit mode, but if it is there any for example rotation detected, pan stops instantly.

Hmm. I'm not able to reproduce the pan failure whilst rotating - I find it works more or less as I expected. For instance, with the patch as written above and in Orbit mode, I held my SpaceMouse in a more-or-less-constant rotation, and then slowly panned downwards (-Z). The results were as expected - the viewport camera continued to spin around the selection, while the view slowly moved downwards simultaneously. What you're describing sounds like you may have your SpaceMouse set up in "Dominant" mode, which is a value managed by the 3DConnexion setup application, not Blender. Open that up while you have the Blender window active, then go to "Advanced" and make sure "Dominant" is not checked. Failing that, I admit it is difficult to really get a sense of the pan+rotation movement if you're panning along an axis perpendicular to the axis of rotation (e.g. when panning left/right while rotating left/right), but as best I can tell it *does* work. For clarity, these are the settings I'm using for my SpaceMouse: Mode: Orbit + Turntable; No Orbit axes inverted; No pan axes inverted; Zoom not inverted; Helicopter mode on; Lock horizon off. In my 3DConnexion settings for Blender, I have all axes active, though My z-axis rotation and pan up/down axes are reversed there. Under the navigation header, Pan / Zoom and Rotation are both checked, Dominant is unchecked. My Zoom Direction is set to Up / Down.

Hi all, I'm actually quite happy with the behavior of orbit mode in general save for the necessity of using a modifier key in that mode and the resulting inability to pan / rotate simultaneously. Patched up view3d_edit.c locally to see if I could get it working, and it came off just fine from my perspective:

Given lines 1434-1447 of view3d_edit.c, in the ndof_orbit_zoom_invoke function:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);

  if (has_zoom) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, false, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

I just changed it as follows, et voila, works gloriously:

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
  const bool has_rotation = NDOF_HAS_ROTATE;
  const bool has_translate = NDOF_HAS_TRANSLATE;
  const bool has_zoom = (ndof->tvec[2] != 0.0f);
  
  if (has_zoom || has_translate) {
    view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, has_translate, has_zoom);
    xform_flag |= HAS_TRANSLATE;
  }

  if (has_rotation) {
    view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
    xform_flag |= HAS_ROTATE;
  }
}

Hello.. thx for this patch. tryed it myself, pan works now in orbit mode, but if it is there any for example rotation detected, pan stops instantly.

I tried this, had the same problem as Raffael Ley. And no the Dominant is not checked for the space mouse. I found a change to that seems to fix the problem.
It involves switching the order of the view3d_ndof_pan_zoom() call and the view3d_ndof_orbit() call in Jeremy Hollands modification.
i.e.

else if ((U.ndof_flag & NDOF_MODE_ORBIT) || ED_view3d_offset_lock_check(v3d, rv3d)) {
    const bool has_rotation = NDOF_HAS_ROTATE;
    const bool has_translate = NDOF_HAS_TRANSLATE;   
    const bool has_zoom = (ndof->tvec[2] != 0.0f);

    if (has_rotation) {                            
      view3d_ndof_orbit(ndof, vod->sa, vod->ar, vod, true);
      xform_flag |= HAS_ROTATE;
    }

    if (has_zoom || has_translate) {                    
      view3d_ndof_pan_zoom(ndof, vod->sa, vod->ar, has_translate, has_zoom);
      xform_flag |= HAS_TRANSLATE;
    }
  }

Settings are important:
Preferences->Input->NDOF->NDOF view navigate=Orbit
Preferences->Input->NDOF->NDOF view rotation=Trackball
Preferences->Navigation->orbit method=Trackball
Preferences->Navigation->orbit around selection=checked
Preferences->Navigation->View Navigation=fly
I find I have to reverse all pan/zoon and rotation controls on space mouse

EDIT - figured it out by following the straightforward instructions at https://wiki.blender.org/wiki/Building_Blender/Windows ... now my space navigator works like a dream in Blender! Now, can someone make a pull request or something to get this code into the regular codebase??

  • original message --

Sorry for my ignorance as I'm not a Blender developer, just a regular user who found this page through Google after searching for a reason why Blender requires you to hold down Shift in order to pan while rotating when using a spacemouse... seems very stupid to me, apologies for being harsh.

How do you implement the above patch code into Blender to make it work? Does it require building Blender from the source code? Is it a long and difficult process, or can it be done by following step by step instructions?

My muscle memory is completely used to the way Maya beautifully implemented spacemouse functionality, so it makes using a spacemouse in Blender pretty much non-viable for me. So I would really like to implement this patch no matter what. Thank you very much!

@San Tokki (santokki) Nice!! I've no idea how to build or insert code changes to make my own version but it's really good to hear that seems to be working.
Would you be able to drop a .zip of your build I can try out? I'm using the 3D Connexion Spacemouse Wireless, just to check everything works across different models.
If this works, seeing it committed to master would be a godsend for all of us using NDOF navigators.

Thanks for the feedback, committed two changes: rB6288dbffb6c1: NDOF: support panning when orbiting

  • You can pan while orbiting.
  • Orbit is now the default (load factory settings).

I didn't experience the issue where orbit prevented panning (using SpaceMouse Pro).

It would be great if users could confirm that this now works as expected.

@Campbell Barton (campbellbarton) Brilliant!!
Which branch/build was this? Loaded blender-2.82-4659fa547166 (built today) and orbit didn't load as default on factory reset. Using a 3D Connexion Spacemouse Wireless on Windows 10.

@Campbell Barton (campbellbarton) Brilliant!!
Which branch/build was this? Loaded blender-2.82-4659fa547166 (built today) and orbit didn't load as default on factory reset. Using a 3D Connexion Spacemouse Wireless on Windows 10.

It will be in tomorrows build

Cheers! Tested the latest build and mostly works as expected. Turning on "orbit around selection" seems to cause some serious lockups in the panning....with this setting off, everything is quite fine.
Additionally, some axis are reversed by default. This setting configuration had the Spacemouse Wireless working just as it would in 3D Connexion's viewer application:

@Logan Preshaw (WickedInsignia) thanks for the feedback.

Inverting the options you suggest feels strange to me, would be interested to know if others find inverting these axes to be an improvement (which should be applied by default for everyone).

@Campbell Barton (campbellbarton) Thanks Campbell! Can confirm that works now and the 3D Mouse Menu refurbish is very welcome.

The way 3D Connexion axes are set up is designed to emulate the way you would hold an object in your hands. So when you twist the dial left, the object rotates right as it would if you were handling it in the real world. When you push the dial right, the view pans left as if you are pushing the object to the right away from you.
It's counter-intuitive until it's not....which is very quick, taking a day or so to become accustomed.
The point is that the training materials included with the device are designed to reinforce this method, and you learn how to navigate this way off the bat. Leaving the defaults as the opposite will conflict with those who have learned the "intended" way of using the device, and other software such as 3D Coat use this default method of navigation.

If the opposite settings prove more popular, it's not at the intention of the manufacturer. The intended default is indeed the method I've mentioned above and are as far as I know the industry standard.

@Logan Preshaw (WickedInsignia) enabled the invert options by default rBe9dd2abaef72: NDOF: invert axes by default

Note that inverting Z was needed when set to fly-style orbit.

Thanks a ton for your work on this @Campbell Barton (campbellbarton) !! I'll continue testing for any lockups, inconsistencies, etc.
Very exciting that we finally have this working as intended in Blender!

Could other users please check the current behavior and confirm this is an improvement over previous behavior (2.81 and older).

@Campbell Barton (campbellbarton) Just gave it a spin - while my own preference is the non-inverted orbit, it was supremely easy to change w/ the popover, and in every other respect is a vast improvement over the existing 2.81 behavior. Thanks a million!

@Jeremy Holland (awebneck) Even if you personally prefer some changes to this default, can you confirm the current settings works as you would expect?

@Campbell Barton (campbellbarton) very much so - feels entirely natural to me now, and I haven't encountered a situation yet in which I was surprised by some behavior or noticed something missing that I've come to expect from the NDOF integration in other packages.

Great, unless anyone has further suggestions I think this task can be closed.

Campbell Barton (campbellbarton) closed this task as Resolved.EditedFeb 7 2020, 1:56 AM

No feedback in some time, closing.