- User Since
- Apr 30 2018, 12:11 AM (76 w, 3 d)
Thu, Oct 3
Thanks Germano! I will note that I don't know if it's necessarily a workbench issue (see 3:23pm comment: seems to be the same thing going on with eevee, partially related to color space transform, etc.)
I note that changing Properties -> Render Properties -> Color Management -> View Transform from "Filmic" to either "Standard" or "Raw" results in a CLI-reported "Saving" time dropping from .65 to .42 seconds per frame at 4k. A significant speedup. (Nowhere near fast enough, but still: interesting.)
Thanks Germano -- I hope you have some time to take a closer look at this -- IMO this is a significant regression from 2.79. After looking further, I think it has less to do with the render engine choice and configuration, and mostly to do with between-frame time, specifically the writing of the output files. My example project provided in the original report is already quite simple: a few Suzannes rotating. But here is an even simpler example project:
Wed, Oct 2
Sat, Sep 28
(I note that as a workaround for anyone finding this, one can place a true-black plane in the background of the frame and it renders to true black.)
Thu, Sep 26
Wed, Sep 25
Thanks -- orbit sensitivity was indeed at 0.
Tue, Sep 24
I also found a way to fix this permanently, in case it helps to fix the bug:
Mon, Sep 23
Sep 13 2019
Tested in latest 2.81 as well: still broken
Aug 19 2019
Same behavior on Windows 8.1, for the record.
Aug 15 2019
Jul 9 2019
I came to respond to all the questions, and I find that I am unable to reproduce most of these issues now, either with the version I was on at the time or the current version. I have no explanation. Sorry for the confusion. I'll post again if I can. (Oddly, rendering is also faster now, perhaps 3-5 fps, and unaffected by JACK.)
Jun 26 2019
Thanks -- I do post at RCS -- this seemed like a bug more than a usability thing, hence the report (because there is no indication that there is hidden content in the pane.) Sorry for the noise.
I'm confused -- you can keyframe there, with the right click context menu... but not via the "I" key? Or maybe that's what you meant.
@Jacques Lucke (JacquesLucke) Isn't it already supported for radians vs degrees? In that case the fcurves are using different units, but the graph editor Y axis is just showing a unitless value, right? Or do I misunderstand?
Jun 25 2019
I don't mean to "me too"; just wanted to point out that at least for some users (e.g. me) this issue basically breaks using multiple windows due to all the accidental incorrect mouse issues that come from it. The only way I can use Blender multi-monitor is to have one big window stretched across multiple screens, which requires window manager rules to remember the window position, and since the monitors are different sizes, awkward workarounds to handle that, etc. Thanks for any time you have to look at it.
I see, that makes sense.
Thanks -- one of the main issues to my mind is that the units in the N menu of the graph editor itself use one unit system, and the points use another:
Just tested this in Windows as well, commit c0c1b4542f39 -- same issue.
Yes -- blank profile.
More info: the same thing happens with multiple Blender windows. Go to "Window -> New window" and make a second window; the same issue occurs between the two Blender windows. This makes using multiple windows very frustrating.
Jun 24 2019
Jun 21 2019
Jun 20 2019
Just found the correct crash report (build from the 17th), which I attach for the archive only, in case it's useful:
Ok, I'll post again if I can generate a reproducible case.
Jun 12 2019
Thanks -- yes, just confirmed it with d93a7290e506.
Jun 8 2019
Jun 7 2019
I can not reproduce this in 2.80, so it's probably safe to close (unless 2.79 bugs are still considered valid?)
May 29 2019
Confirmed that it's fixed here as well. Thanks!
May 22 2019
(Also happened in 9efe117535c6.)
May 20 2019
Mar 5 2019
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.
Mar 4 2019
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.)
Feb 23 2019
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.