3D Connection space navigator - zooming and initialisation

[pludikar]

Hi,

I have a space navigator that is exhibiting two separate issues

1. when I start F360 after my computer starts up, more often than not I have to unplug and replug the navigator to get F360 to work with the navigator.  It seems to work 2nd and later f360 startups.

2.  Navigation often becomes very sluggish after manipulating anything more complex than a cube.  It feels like a buffer has filled up, and swamps the real-time incoming control messages.  More often than not, I zoom out when it gets sluggish (it takes a while to get the image to move) - once it is zoomed out, navigation response goes back to the expected level, but usually doesn't last long before it gets sluggish again.

Any thoughts or suggestions?  Let me know if you need any more details

Regards

Peter

I have two side by side displays:

Main display: 

[GPU Information]
GPU Device: NVIDIA GeForce GTX 1070
GPU RAM: 8192 MB
GPU Driver API: DirectX 11.0
GPU Driver Version: 1.4.501
GPU Driver Date: 09/01/2016

[Graphics Effects Settings]
Anti Aliasing: On
Ambient Occlusion: On
Object Shadow: Off
Ground Shadow: On
Ground Reflection: Off
Selection Display Style: Normal
Transparency Effect: Better Display

[Limit effects to optimize performance]
Off

secondary display: 

Intel(R) HD Graphics 530

Report Date: Monday, February 13, 2017
Report Time [hh:mm:ss]: 10:36:34 PM
Operating System: Windows* 10 Home (10.0.14393)
Default Language: English (United States)
Physical Memory: 32611 MB
Video BIOS: 1033.0

Processor: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Processor Speed: 4008 MHz
Processor Graphics in Use: Intel(R) HD Graphics 530
Shader Version: 5.1
OpenCL* Version: 2.0

* Microsoft DirectX* *
Runtime Version: 12.0
Hardware-Supported Version: 12.0

* Devices connected to the Graphics Accelerator *

Active Displays: 1

* Digital Display *

Display Type: Digital
Serial Number: 11237JA021005
DDC2 Protocol: Supported
Gamma: 2.2
Connector Type: DisplayPort
Device Type: Monitor

Maximum Image Size
Horizontal Size: 13.39 inches
Vertical Size: 10.63 inches

Supported Modes
640 x 480 (60p Hz)
640 x 480 (67p Hz)
640 x 480 (72p Hz)
640 x 480 (75p Hz)
720 x 400 (70p Hz)
800 x 600 (56p Hz)
800 x 600 (60p Hz)
800 x 600 (72p Hz)
800 x 600 (75p Hz)
832 x 624 (75p Hz)
1024 x 768 (60p Hz)
1024 x 768 (70p Hz)
1024 x 768 (75p Hz)
1280 x 1024 (75p Hz)

[Phil.E]

Hi,

First make sure you have the latest 3Dconnexion drivers:

http://www.3dconnexion.com/service/drivers.html

#1. This sounds like a common 3Dconnexion problem. On win 10 the device gets confused because Fusion uses multiple app windows. The data panel is run by Inventor Home (that's what it says on the 3Dconnexion control panel). So customers are finding it difficult at times to bring "focus" back to the Fusion 360 application process that runs the majority of the program (the modeling window).

So when you unplug and plug in the spacemouse, really it's probably just a matter of time before it recognizes Fusion entirely. 

Please try this: Start Fusion. Close the data panel. Close Fusion. Open 3Dconnexion driver settings. Open Fusion. 

Result: the 3Dconnexion settings should show the "active" app. You should see it go from whatever was open (Chrome, outlook, etc.) to either Fusion 360, or Inventor Home.

What happens for you?

#2. This could be one of two issues, or both happening at once. 

First check your camera settings in the Display Settings tools at the bottom center of the screen. Make the camera Orthographic.

Does the sluggishness go away?

Next, ensure that you are using the NVIDIA card and not the onboard graphics chip. I'll try to find the article that explains how to force it. 

Another thing you could try is only using one monitor and shutting down all graphics effects just to see if it makes a difference.

If none of this works, try switching graphics drivers in Fusion Preferences > General. Use DX9 instead of DX11.

Thanks and let us know please how it goes and what you tried that made a difference, or not.

Regards,

[TheCADWhisperer]

---

@pludikar wrote:

2.  Navigation often becomes very sluggish 

---

Couple of other things to try.

Unplug Navigator.

While holding the two buttons (and continue to hold for 15 seconds) - plug the Navigator back in.

Right click on the Control Panel icon and select Calibrate.

(Caution: Sometimes the calibration screen comes up behind the running app, you might restore down window so that you can see it.  Do not touch the Navigator while the lights are flashing (calibrating)).  I calibrate every morning.

[pludikar]

Hi Phil,

I can confirm that I have the latest 3DConnexion driver - 10.4.8

#1- I tried  "Start Fusion. Close the data panel. Close Fusion. Open 3Dconnexion driver settings. Open Fusion."  Indeed 3DConnection driver shows that it has found Fusion 360 app, but... there's no control (up/down, left/right or zoom in/out), until I disconnect and reconnect the 3D navigator.  This ONLY happens after I've rebooted the computer - once the mouse connection is established it works thereafter.

#2 - I'm trying to find a way to consistently reproduce the sluggishness.  I generally get a good response from the 3D navigator, so I don't expect calibration to be an issue - I've had the mouse for almost 2 years, and I'm familiar with setting it up.  I've experienced this sluggishness problem for a while, and I mentioned it on this forum about a month ago when I was trying to resolve another F360 issue.  I was just experiencing the problem again, and I thought it was about time I did something about it.  It seems that something triggers the issue, but I'm not sure what.  I'll be working and navigating away, when suddenly the grid becomes very dense, and pan and tilt stop working, zoom is the only navigational element that works, but very sluggishly.  Once I zoom out far enough, pan and tilt work again.  

F360 Graphics diagnostics reports that I'm using NVIDIA - I have a wide screen that is driven directly off the NVIDIA card, which is where I run F360.  The other screen is an older and smaller screen that I use for my browser and anything I want to see when I'm on F360.  The smaller screen has a VGA connector, which isn't supported by the NVIDIA card, hence it uses the motherboard on-board GPU.  Once I find a way of consistently reproducing the issue, I'll try it with just the NVIDIA - If I disconnect the second screen while F360 is running, F360 inevitably crashes - it doesn't like changes to the video while it's running.  

I was originally using DX9, and then changed to DX11 because I was getting some instability - per some instruction I found on this forum.  

PS - I'm able to spend as much time helping resolve this as you need.  I'm not using F360 in any critical timeline, I'm personally not bound by any timeline either.

Regards

Peter

[pludikar]

#1 - 1st use of 3D navigator not working.  After a bit more focused playing around - I just wanted to report that this has the characteristics of a 3DConnexion driver issue, and not with F360.  I predominantly use the 3D navigator with F360, and I didn't realise that it's doing the same on all applications (sketchup and 3D navigator home applications).  So, we can drop this part of the thread and I'll work with 3DConnexion.

Peter

[jeanchris]

Hello!

Just for information, I also use a spacenavigator with fusion 360 + win 10 and it's works "well". Just sometimes at startup fusion it does not work normally... Disconnecting the spacenavigator or ALT+TAB in fusion and it's ok (for me).

Jean-Christophe

[pludikar]

Hi Phil,

Just to bring you up to date.  I now have both my monitors working off the same GTX 1070 graphic card, and I've disabled the on-board graphic processor.  That should eliminate any unknowns over dual GPU driver conflicts.  I was trying hard to force the sluggishness by manipulating a relatively complex model, and it did fail on me, but I have no idea what I did up to that point.  When it became sluggish, I couldn't zoom or tilt, but zoom worked using my mouse scroll button.  Once I zoomed out far enough the 3D navigator clicked back into operation and I've not been able to repeat the problem again - although I will keep trying.  I was in perspective with ortho faces camera mode.  I personally don't like orthographic mode, it makes it more difficult to navigate because the further away something is the bigger it appears - it's easy to get confused because the perspective is unnatural.  Nevertheless, I will try this mode too.

I have 32Gb of RAM and 237Gb of SSD as my primary storage - So, I don't think that data transfer is a contributor either.

Peter

[Phil.E]

@pludikar

Please try orthographic camera. The reason is an old graphics problem with perspective camera. 

The zooming method in Fusion has trouble with perspective camera. We found and fixed this a long time ago, but some factors can aggravate it. So perhaps we should revisit the issue.

It has to do with the level of detail showing when you zoom in. It is supposed to reach the limit (where it doesn't want to zoom in farther) more quickly and force a new "level of detail" calculation more smoothly so you either don't notice the transition, or it is very slight. I think you have a model and/or hardware combination that makes this calculation more difficult. It depends mostly on hardware, but I can imagine a more complex model might affect the hardware too. 

Why it goes away is part of how we fixed it. Once it forces the calculation it should remember it. So things go smoother after that. But since hardware is involved there is a lot of variability we may need to consider.

I appreciate all of your time to give us this feedback. Can you let us know how Orthographic camera works for you, and if using the dedicated GPU also helps? Please tell us if you can consistently produce this bad effect with perspective camera (more than just a slight pause).

Regards,

[pludikar]

Hi Phil,

I seem to be able to reproduce the zoom issue by just zooming rapidly in and out to the max limit (ie when zoom stops).  I have a relatively busy model which has a network of grooves in a 4x8 sheet that results in over 1000 raised squares each with chamfered edges (it's a vacuum table!).  This is in perspective with ortho faces.

I have also been trying with Orthographic camera mode - it doesn't behave exactly the same but I think experienced the navigation control misbehaving.  Similarly zooming in and out to max level it's really, really hard to keep control of position.  Navigation at max limit is highly precarious - in an instant you can looking at the flip side of your model - the problem is that you not only have no visual cues in orthographic mode, but what you see is totally unnatural - far away edges appear to be bigger than those closer in. However, I don't think it was my imagination, although I can't be certain, it appeared that once or twice I managed to get the yaw/pan control to flip (pressure on the left side of the navigator caused the model to move left! it should have gone right).  Problem is that navigation is hair trigger sensitive at high zoom levels, and along with the lack of visual cues, it makes controlling the view point very challenging.  As there's a lot going on at the same time it's possible that imagination got the better of me - but, I do remember vividly saying to myself "Wow, that wasn't supposed to happen!" in response to trying to centre, and keep centred, a feature while zooming in.

Overall, Orthographic mode is near impossible to use with 3D navigation, so I'd humbly suggest it's important to fix the issue in perspective mode.

My GTX-1070 graphics card is supposed to be one of the first of the next generation cards and scores well with Unigine Heaven benchmark (if that's helpful!).  It completes the benchmark with a hiccup.

  Unigine Heaven Benchmark 4.0

FPS:	140.7
Score:	3545
Min FPS:	37.0
Max FPS:	304.2

System

Platform:	Windows NT 6.2 (build 9200) 64bit
CPU model:	Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4007MHz) x4
GPU model:	Intel(R) HD Graphics 530 20.19.15.4501/NVIDIA GeForce GTX 1070 21.21.13.7849 (4095MB) x1

Settings

Render:	Direct3D11
Mode:	2560x1080 fullscreen
Preset	Custom
Quality	High
Tessellation:	Disabled

I noticed that there's a similar thread "3DConnexion SpaceMouse freezes", which seems to be related to the same or similar issue.  For some reason I missed finding it before I initially posted this issue.  My accidental misspelling of 3DConnexion, probably didn't help.  Sorry about that.

Peter

[Phil.E]

@pludikar

Thanks for the details and explanation of your workflows. This is good feedback for spacemouse.

Regards,

[pludikar]

Hi @Phil.E,

I just thought I'd share with you a couple of screen captures that illustrate how confusing using the 3D navigator is in orthographic camera mode.  The 1st grab is with perspective and ortho faces.  It looks like a runway.  If you tilt the navigator forward the far end comes up and you naturally compensate by pulling back on the navigator if you've gone too far.

 

The capture below shows the same model in orthographic, more or less the same view.  Now it looks (and it's probably an exaggerated optical illusion) that the real near end is actually further away.  The natural action if you're "flying" into this runway, is to tilt the navigator forward to "dive" in, but what it does is actually the opposite.  I'd suggest you try "flying" this model and see how challenging it is - it is definitely not a natural way of navigating.

One thing I noticed is that the navigator "locks up" more frequently in sketch mode.  The background grid suddenly becomes extremely dense (see capture below - the grey is actually the grid!).  In this particular case I had the grid in "Adaptive mode", but it also happens in "fixed mode" too.  It feels like something happens to confuse the grid calculation, and that then overwhelms the image processing.  The navigator was "flying" normally for several minutes before the grid snapped. 

I have also been able to capture the moment the navigator freezes on screencast.  The last 15 seconds are the most interesting.

I hope this is useful information

Peter

[pludikar]

@Phil.E

For some reason my screencast link didn't upload properly.  Here it is http://autode.sk/2lvOU81

Peter

[pludikar]

@Phil.E

BTW - I just managed to lock up the navigator in orthographic camera mode.  You need to be sketch  - the grid suddenly becomes dense, but it takes a while for the density to be similar to perspective with ortho faces mode.  It took longer to achieve lock-up than in perspective mode.  I also saw a warning for "slow performance"

Peter

[Phil.E]

This is starting to sound like the "forced" recalculations for graphics are failing. The LOD is not updating as you zoom in and the grid is not adjusting as you zoom in.

What happens when you turn the grid off?

[pludikar]

@Phil.E

It looks like it's grid related.  If I get the navigator to lock-up when the grid goes dense, and then I turn off the grid - manoeuvrability appears to return.  I haven't yet been able to make the navigator lock-up without the grid - although I have had a few instances where the image has paused for a noticeable period, but then recovers (usually on the other side of the model!).  

I just tried locking the navigator up with a new, blank, design with just a sketch and enabled grid - it locked up!

I am trying hard to push the limits, but I usually don't need to before I precipitate a lock up.

I hope that helps.

Peter

[pludikar]

hi @Phil.E,

Further to my last comment - the lag or hesitation as you zoom in is actually quite bad.  I managed to get a screencapture ( http://autode.sk/2lV3Ay6 ) that shows the point when the lag starts and the resulting overshoot.  I think what happens is you put extra pressure on the navigator to compensate for the image zoom slowing down, and when the zoom speeds up again, its so fast that you can't compensate.  This is in perspective with ortho faces mode.  Pure Ortho mode doesn't obviously suffer the same problem, but as you'll see below - it's a challenge to use it with the 3d navigator.

I thought I'd also share with you a quick clip of me trying to "fly" in ortho camera mode.  I promise you that I'm not trying to exaggerate anything - just trying to fly normally.  You'll see that it's a lot jerkier than my other screencapture (above) http://autode.sk/2lUUrWc

I'm away for the next couple of weeks - I may or may not be able to respond (if there's anything to respond to).  I hope this helps

Peter

[Phil.E]

@pludikar

Thanks for the update. At some point I may need to get access to your data, just to perform apples to apples comparison and get a properly reproducible case. It may be that your data is key.  For now the question is out about how this can be worse in some cases. I suspect that your model may present a more unique case that we need to support. A lot of graphics calculations are based on proportions, for instance. For now I'll try to reproduce it on my own, by imitating your design. 

[Phil.E]

There is definitely something associated with data like this. It must be the proportions. (a large plate). I've sent everything you showed me to the team that handles this part of graphics. They are now aware.

Thanks,

[pludikar]

Hi @Phil.E

i suspect it may actually be a bit deeper -

the vacuum table comprises .25 x .25" grooves that criss cross the 48 x 96 sheet.  There are 49 equally spaced vertical grooves and 26 horizontal ones resulting in 1.75" squares, IIRC.  I could not use sketch to draw the grooves (using patterns) because performance virtually ground to a halt, f360 couldn't handle it.  I then attempted to cut feature patterns directly into the sheet model, but that also became a performance hog.  The only way I could get my model up and running was to create a mesh of the groove network and then use it as a tool to cut into the sheet.  The performance is useable, but no way what I would have expected.

If the graphics is having issues with the large sheet, There's a chance that this is related to the data handling of a large number of small details in the context of a large area.  I specifically upgraded my computer to the latest and greatest to give it the computing power needed to handle the extremes, but my computer still has a challenge handling it.  I am still surprised at how much memory f360 uses up when it's handling my model - it tops 10 Gb.  That seems a bit excessive and probably contributes to the drain on computing power.

However, I'd be interested to see if it's just me and my setup, or if it's a characteristic of f360.  Unfortunately I won't have access to my f360 for a couple of weeks - I need to fix my model before it's going to be any value to you.

Regards

Peter

[Phil.E]

@pludikar

All of what you describe is exactly what would slow down the LOD calculation. Many edges.

Strange thing however, I did not have any performance problems recreating your model. I guessed that it was 4x8' and counted the grooves and holes. I could reproduce the hang on zoom and added the test case to the bug report. But I did not have any issues creating the part or any performance problems.

The way I did it was to map out the grooves using single sketch lines. Then I used the Pipe command to populate single representative grooves with 3D shapes, then patterned the representative groove features into the network as you have on your model. This all went smoothly in a couple minutes.

When I hear of any improvements I'll let you know. For now this is something you'll have to work around. Hopefully it doesn't cause too much trouble.

Regards,