- User Since
- Apr 30 2018, 12:11 AM (46 w, 5 d)
Tue, Mar 5
Thanks Satoshi -- I see that you are correct -- I didn't notice the tiny changes in zoom because it only takes me 2 or 3 screen heights to lock it up, but after releasing the MMB it takes 10 or 20 screen heights the opposite direction to see only a tiny movement. Then if I stop and do further zoom-out movements, it moves quickly. I will stop commenting on this bug and assume that this is all intentional, even if it's hard to imagine why for a beginner like me.
Mon, Mar 4
Interesting development: the most recent version (c7cf8282a6ab) seems to have fixed this when MMB zooming on an object. The viewport still freezes when you MMB and push in to empty space, but it's a nice improvement to not have it freeze when zooming to an object (unlike e.g. 779860d34e26, see last post.)
Sat, Feb 23
This is still happening in 779860d34e26, just FYI. Shouldn't this bug be re-opened? Was anyone able to reproduce with the demo project file? (See the animated gif for the method to trigger it.)
Feb 12 2019
Same thing happening in Windows, for the record. In case it helps, here's an animated gif demonstrating the issue (this is with test.blend):
Feb 11 2019
I can not zoom out -- the test.blend uploaded above has the error. But you need to zoom in to where it stops, and then keep "pushing" against the stop a little bit. If it lets you zoom out, zoom back in to the stop and push a little bit more, etc. Pretty soon it will lock up, and you can neither zoom out nor translate the viewpoint. Only MMB-drag will allow you to rotate. Alt-Home will not break the lockup, only shift-c does.
Thank you -- but are you sure? The link you provided describes the zoom being limited, but once I try to zoom past the limit, I am unable to zoom in or out, or translate the view whatsoever, until I shift-c alt-home. (Again, you have to zoom to the stop, but then push in to it a bit to make it lock up.)
Feb 8 2019
@Campbell Barton (campbellbarton) I just tried 2.80beta 3d16a268ee68 from the website -- not sure if I should expect this to be fixed in that build? If so, there is still something broken: the default cube works as expected when a clipping border is in place, but if the cube is first moved away from origin (e.g. 2m in some direction) it does not work as expected: sometimes points that are clipped are selected, sometimes unclipped points can't be selected, etc, depending on orientation of the clipping pyramid, etc.
Feb 7 2019
Ah, thanks. That is unexpected, but I understand the logic.
Feb 5 2019
May 31 2018
Wanted to follow up -- is this in fact still "incomplete" somehow? Meaning, should I be supplying anything else? Thanks!
Apr 30 2018
Thanks -- with me the gradual slow down in rendering speed happens with both the one-window setup and the original demo project two-window setup, but in the one-window setup the green cursors move as expected in both the "good" and "bad" renders, where with the two-window setup the green cursors do not move in the bad render.