For as long as I can remember, SW would occasionally behave badly when rotating models with the standard middle-click drag operation. The entire model would disappear completely, as though the rotation center was way off in space somewhere.
Currently, I'm using SW2016 SP2, and it happened a few times today on one particular assembly model, so I decided to investigate. The bad behavior appears to be tied in with the function that allows you to rotate a model or assembly around a particular edge or axis. Under normal conditions, if you middle click and release an edge or axis and then move your mouse away from the selected item, the rotate icon changes into the rotate about axis icon. You can then middle drag to rotate the model. If you middle click on an edge or axis and don't release the mouse button, the icon should remain as the rotate icon and things rotate in the normal way. However, sometimes when you middle click and immediately drag (no release of the button), the icon changes to Rotate about axis and that is when things can go haywire. I say 'can' because I see three different behaviors:
- sometimes it rotates as you would expect if you had the normal rotate icon
- sometimes it rotates about some center or axis near the model but not actually part of the model
- sometimes the model view flies off into space
Zooming in or out can change the likelihood of the bad behavior.
The assembly model I'm using has a simple sketch visible in a subassembly which is two levels deep. I can repeatably (but not 100%) make the problem occur when middle clicking in the vicinity of a line in the sketch. I can't replicate the problem if I open the immediate parent of the subassembly with the sketch, or the subassembly itself.
My guess is that there are two parts of the program getting conflicting information about where the mouse is, and what has (or hasn't) been selected. These two incongruent bits of information are then combined into 'Rotate the model around that point at infinity'.
Reposting from another thread since it came up today...just so the answer is here in case anyone else finds this in the future
Here is how middle mouse rotate works:
If the entire model is within view, it rotates about the centroid of the model. This works very well if the model is centered in the screen. It also works well if the model is smaller in the view than "fit" and is off center; try it by doing a zoom to fit and then zooming out/panning so the model is on the screen but in one corner and you will see it rotates about its centroid. Imagine what that rotation would be like if we rotated about the center of the screen (which is what a lot of systems do) instead of the centroid of the model under that condition; the part would be flying around the view. Now, if the entire part is not on the screen (i.e. you're zoomed in), you will get the most predictable results if you push the middle mouse button over the geometry to start the rotation since when you push the middle mouse button, we project a point onto the face and rotate about that face (we draw the point in magenta and highlight the edges of the entity that it is project on). If we didn't do that and used the centroid of the part, or center of the screen, again the model would always fly all over the place/off the screen. That is how it used to work about 10 releases ago or so until we came up with this approach. Lastly, if you are zoomed in and you use the middle mouse button in empty space, then we have an algorithm to try to find the geometry and project a point onto it to rotate about (again, it shows the point in magenta with the edges of the geometry on which we projected in magenta). This is probably the case you are talking about where the model flies off the screen; depending on the position and orientation of the model and how close you are to the model when you push the mouse button, the point we pick may not give good results. So, I think you will find that when zoomed in, if you simply push the middle mouse button on top of geometry instead of in blank space to rotate, you should get predictable results every single time.
Although I have not heard of specific cases where it doesn't work well with visible sketches, that isn't to say there might not be a problem relating to visible sketches so if you do find something repeatable, certainly report it.
Thanks,
Jim