Nope, that’s not it. You have most likely mistaken it for the viewport turn feature. That one is really weird, as it doesn’t properly work unless you are starting from an aligned view already. It’s completely unpredictable most of the time. That one should IMHO be removed as it does more harm than good.
If you first hold Alt key, and then flick the middle mouse button, you will trigger the viewport turn thing. If you perform it from a perspective view that’s not aligned, it’s pretty much random which view you end up in. Rarely in the desired one…
Viewport snap works differently. You first press Shift and MMB to orbit, and then, while orbitting, you also hold down the Alt key. That will trigger viewport snap.
Actually, yet another benefit of fixing Auto Perspective for view snap would be that this view turn would become obsolete, and hopefully removed
Well sorry to get you excited for no reason. Yes, I didn’t realize the behavior was different when you “flick” versus just dragging with alt held down.
If you first hold Alt key, and then flick the middle mouse button, you will trigger the viewport turn thing. If you perform it from a perspective view that’s not aligned, it’s pretty much random which view you end up in. Rarely in the desired one…
My doing this doesn’t just “rarely” get the desired one as far as I can tell, and it does seem a bit better than the last time I tried it. The flick seems to reliably go straight into the next orthographic view without fail when I try it no matter what weird perspective I start with. Although a little odd, but expected, that it favors only one particular top and bottom view.
I really don’t want to derail the thread for something that isn’t about your initial complaint.
But if I follow the above instructions I do always get the exact horizontal orthographic view I am expecting no matter how hard I try. With the big exception that flicking up or down will always go to the same top and bottom views, not the ones it really should go to. For that it needs to be aware of the other valid top and bottom views with differing rolls. But I’m guess that isn’t the issue you are talking about.
Hey, really not implying that there is nothing wrong or that you are doing it incorrectly. Just trying to understand these intricacies. I was earlier attempting (and failing) to add new named views (including top and bottom with different rolls), which is why I was in there. Next time I am poking around for that I will look to see where that viewport snap is done versus viewport flick. But probably needs someone more experienced there than me.
The current behaviour does seem strange. Once you realise the difference between holding before or after you click you can reliably get the same view, but it never feels like it’s the right view.
For instance: Create a cube with three materials, so both sides look like this
Align it so the red face is most prominently displayed
Now try to alt-snap to the corresponding view. You’ll pretty much always get the green faces, because that’s how it seems to function to me.
It seems like it will always go to the view in the direction you flick, but… what you’d really want, ideally, is for it to snap to the view that corresponds the most to what’s already on screen first.
For clarity’s sake: if you press alt while already rotating the view, it will snap to the red face, but it won’t go into ortho. All in all, it just feels very inconsistent and counter-intuitive
Yes, unfortunately there are currently 2 different ways of snapping the views assigned to same combination (alt+orbit) but they happen depending on the order. I think it’s very unfortunate and confusing decision.
Chiming in that when using the industry compatible keymap the current implementation of snapping view is very confusing, feels very much like it is picking the “wrong” view when I snap. The standard blender keymap seems to snap view appropriately but still has issue of not using auto-perspective.
Yea, I agree. The snapping does seem to be rather inconsistent and somewhat counter-intuitive.
In the case of a cube, such as @michaelknubben’s example, I would expect the face with the most visible surface area to be the one that snaps. Would be great to get a fix
Actually I came across this thread via Google. I’m glad that others such as @LudvikKoutny had the exact same idea before me but it’s kinda disappointing that this feature didn’t get any attention.
However I found a solution to get the same functionality: just bind a key of your choice to view3d.view_axis, set view to Back and enable Relative.
This is not as convenient as hitting Alt while orbiting but still much better than going through some pie menu several times to find the right axis…
Hello! I’ve written some code and here’s the result: Build with ortho axis snap
In this build with option Auto Perspective enabled view will turn to orthographic on snap (Alt key by default in Rotate View mode). Please have a look and give your feedback. In case everything is ok, I’ll make a pull request.
Known issues:
Snap to axis works not very good in top/bottom views because of view becomes parallel to reference axis value (0,0,1). Do not know how to overcome it
In case view snapping activated, then snap applied but not confirmed and snap key released, the view will remain orthographic, not perspective
Hey, this is amazing. Could you submit this as a patch request? It would be great if this made it into official Blender, as it would pretty much make concept of view switch menus/pies obsolete
Hey, thanks so much for spending time on this! I’ve just tested and it indeed works, but as you said, exiting user ortho still does not restore perspective.
Also, user orthographic views do not display 2D Grid (Grid) but 3D grid (Floor) instead. 2D grid is a good indicator to let user know he’s in a 2D ortho mode. I know this is not completely related to this task, but I think it should be fixed alongside it.
Fix with exiting back to persp out of user ortho was just sent for review.
As for the issue with 2D Grid / 3D Floor. Can you please explain the desired behavior? I cannot see any problem: on snap apply, the view becomes ortho as before, no additional changes were done from my side.
Anyway, it looks like a separate request not related to this improvement.
@Skif The orthogrid has a finer/smaller gridsize.
You have to zoom in a bit in the start scene with a default cube,
the one grid still has subgrids, the other one not.
So Whenever in the Top Left corner Top Orthographic is displayed the grid itself differs from the cases where User Ortho is displayed.
