Page MenuHome

3D Mouse (NDOF) frozen in Camera view w/ lock view to camera (WIN32+64)
Closed, DuplicatePublic

Description

System Information
i5, Windows7 home, 64bit. 12GB Ram, GTX 980
Threadripper 12Core 1gen, Windows10pro, 64bit. 32GB Ram, GTX 980

Blender Version
Broken: Blender 2.8 64bit, Alpha, Alpha 2, Beta still persistent in Hash: 91a155833e59
Worked: Blender 2.79 64bit still working in Hash: 49e3f08815af
(I hope the hashes are correct, everything freshly tested - 10.01.2019)

3D Mouse (SpaceNavigator) not working in Cam mode

Exact steps for others to reproduce the error
3D Mouse works in normal view mode (object mode) +edit mode +sculpt mode +vertex paint +weight paint +texture paint.
3D Mouse is frozen still in following mode:

  • Set a hook for "Lock Camera to View" to enable view navigation within camera view.
  • Press "0" to switch to camera = 3D Mouse not responding/Frozen.

Event Timeline

Campbell Barton (campbellbarton) triaged this task as Needs Information from User priority.Dec 11 2018, 1:44 AM

@Jonathan (Batty) tested this on Linux with a49fdbcc674fe80af2f6cacc8c23d18a5fdbbd97 and it's working properly.

The hash 3f3eaae675aa isn't known.

Could you test this again?

Campbell Barton (campbellbarton) renamed this task from 3D Mouse frozen in Camera view, lock view to camera to 3D Mouse (NDOF) frozen in Camera view w/ lock view to camera.Dec 11 2018, 1:45 AM
Jonathan (Batty) added a comment.EditedDec 11 2018, 6:26 PM

First: I just found this post, which seams to be related to mine, I just don't know how to add it here: T59199

Actualisation+added testing: the hashtag of the current version I tested on is -d475b5c7b85- as seen on the Splashscreen of today's Version.

Going out of Camview it moves as it should, but in "Lock view to camera" cameraview - it doesn't. I recognised only minor movement of about a pixel in all directions or sometimes (not sure why) no movement at all.
Goind from object mode into edit mode, then sculpt mode... same behaviour on Win 10 pro/64bit. Directly compared to version 2.79 - the behaviour is as expected in normal mode as well as im camera mode: movement normal.

To add: the movement was frozen in 2.80 before Alpha as well. Then it was changed in summer, but only in normal mode. Since then Cameramovement is still frozen on the 3d mouse.

Jonathan (Batty) added a comment.EditedDec 11 2018, 6:28 PM

I had tested on my earlier machine.
I had it in Windows 7/64bit as well, in the same manner as in Windows 10 now.

Thanks for Blender Pro!, I love what you all have done there :)
When the first money is earned, we'll start donating for sure.

Could someone experiencing this error give "exact steps" to redo it, what you expect, what happens etc.

From my own tests 3D-mouse moves the camera when "Lock Camera to View" is enabled.

@Jonathan (Batty), you mention mode switching and difference to 2.79, but I need to have a set of steps that worked in 2.79 and fail in 2.80.

This comment was removed by Jonathan (Batty).

@Jonathan (Batty) ok, from your video it's simply not working for you. I was thinking maybe you were doing something different that made it fail.

The camera-locking code isn't OS spesific, so it's quite strange that this fails for you and works for me.

It would be good if someone else could check if they can redo the error.

Jonathan (Batty) added a comment.EditedDec 12 2018, 1:39 PM

And it's even more strange, that in version 2.79 of blender 64-bit, there is no error and the camera is moving correctly. On the same system.
Thanks, for looking into this. I really hope it can be solved, as this is very much breaking our pipeline, or at least slowing it down significantly.

Campbell: I'm in need to completely reinstall our PC. I'll put Blender 2.80 on it as soon as Windows is installed fresh and give you feedback, if that changes anything. Do you want me to test anything specific additionally?

Jonathan (Batty) added a comment.EditedDec 21 2018, 1:15 PM

After installing a new Windows 10 Pro, the 3D Mouse behaves generally the same as before. I now have installed Win10, Firefox then Blender (just downloaded a few minutes ago) and tested. Not even the 3D Mousedriver from 3D Connection itself has been installed. Only what windows does on it's own.
I'll put a film on youtube about it soon.

Jonathan (Batty) added a comment.EditedDec 21 2018, 9:09 PM

https://youtu.be/8UTm8vnbN68
This is the link as promised.
As you can see in this video, there is a little more movement of the 3D mouse, very erratic. It increases even more, when continuously pressing space bar. But nonetheless, it's unusable. After additionally installing the software from 3D connection for space navigator, the little movement that was present (as seen in the video), is completely killed of. Only here and there there is some movement of about one pixel to all directions but mostly none at all. It is behaving just like it did before installing Windows completely a new, with a virgin installation of blender 2.80

I assume that this possibly happens with all Windows computers, using space navigator.

Any News on this?
Is there another way to at least snap the camera to the current view or get the coordinates of the current view to put into the camera x,y,z fields + rotation somehow?

I can confirm this is an issue with Blender at least with windows 10 home. If you wiggle the controls it will begin to move slightly then stop.

Campbell Barton (campbellbarton) raised the priority of this task from Needs Information from User to Confirmed, Medium.Jan 8 2019, 1:06 PM
Campbell Barton (campbellbarton) renamed this task from 3D Mouse (NDOF) frozen in Camera view w/ lock view to camera to 3D Mouse (NDOF) frozen in Camera view w/ lock view to camera (WIN32).
Jonathan (Batty) renamed this task from 3D Mouse (NDOF) frozen in Camera view w/ lock view to camera (WIN32) to 3D Mouse (NDOF) frozen in Camera view w/ lock view to camera (WIN32+64).Jan 10 2019, 2:33 AM
Jonathan (Batty) updated the task description. (Show Details)
Jonathan (Batty) updated the task description. (Show Details)

Hi
With blender blender-2.80.0-git.e57ee5934a30-windows64 in a windows 7 64bits with the driver of 3dconexion 10.5.12 (lastet) the same issue
Thanks

Confirmed this issue.
Tested with 2.8x (built today) on windows, navigation works but locking the camera to the view doesn't, as reported.


Note, if you have the camera selected and look at the number buttons, you can see there is some small movement being applied. 0.01 or so.

I tried scaling the NDOF speed to 40 but it doesn't make a noticeable difference.

Yay. Thanks, Campbell. But please tell me that this will be fixed in April this year. Production needs to start.

I came to report this one, but found this already listed as a bug. Windows 10 64 bit. Using the latest version of the 3DConnexion drivers that still supports the old Space Pilot device. I was having trouble flying my camera in Fly/Walk navigation mode. Movement slows to a crawl near the scene origin. I thought I'd try moving the camera using Lock Camera to View instead, but ran into this issue. Like others I can see that there is some movement, but it's insignificant. While googling around I found T28373 from 2011. Sure enough, when I tried the same thing in Blender 2.79 is worked flawlessly. I'd love to see this fixed in 2.8.

Yay. Thanks, Campbell. But please tell me that this will be fixed in April this year. Production needs to start.

+1

Yes, I understand that jazz about 2.8 being beta etc, but this is really an unfortunate bug, because locked camera is especially tricky to navigate well without 3d mouse.
So I wanted to stress the importance of it as well.

Otherwise, keep up the good work!

Did a clean reinstall and installed some windows updates, (btw, may them windows updates be the cause of the problem?) but still, the problem persists.
Any estimations, or suggestions for fixing that problem on my own, or is it just some developer mixup?

Reverting these commits fixes:

Looked into simple fix but don't have a proper win32 dev environment setup.

Hi Campbell
With blender-2.80-ffa29194bbe7-win64 and the last drivers of 3dconnexion works fine ¡¡¡ Thanks for all the work and your time .
Thanks

Comfirmend: working in Win10 64bit, as expected. Thanks a lot Campbell :)

It's just a wish, but in the line of making all things in Blender 2.8 better than in the prevois versions:
recording the movement of 3D Mouse into the timeline would perfect it ;)
...just saying - posted in wishlist already. :p

Comfirmend: working in Win10 64bit, as expected. Thanks a lot Campbell :)

It's just a wish, but in the line of making all things in Blender 2.8 better than in the prevois versions:
recording the movement of 3D Mouse into the timeline would perfect it ;)
...just saying - posted in wishlist already. :p

+1

You can do this using walk/fly mode.

  • Enable auto-keyframe.
  • Enter camera view.
  • Lock the camera to the view.
  • Play animation.
  • Use NDOF.

what a great job Campbell ¡¡ Now it is really useful to have a mouse3D and be able to combine both hands for work.
Congratulations

Thanks, Campbell for your answer.
I have tried similar in Blender 2.79 without any success.
Now I have tried this as exact as I could, I also watched Tutorials for Autokeyframe in 2.80 - but it looks like it does not work for recording a Camera via NDOF.
It doesn't write any keyframe, via NDOF.
I pressed the record button in Lock Cam to View - switched to Camera, being in the Animation timeline.
I pressed play, moved the Camera with the 3D Mouse (NDOF). No Keyframe is being written.
I switched back to 3d view and moved the camera by marking and moving it by pressing "G" on the Keyboard. It recorded that movement as Keyframes in the timeline as expected.
NDOF is not being transfered into Keyframes this way.

After this i have tried to switch back to camera view and move it with NDOF while playing (Recoding) and it started to twitch like crazy - but didn't move away from the current location.
It looked like it tried to move to the NDOFs direction, but was ripped back instantly, like about 12 times per second.

This is excactly the same behavior I encountered in Blender 2.79
So it doen't work as of yet. :(
Should this become it's own bug report?