- User Since
- Apr 30 2018, 12:11 AM (125 w, 19 h)
May 16 2020
Will do, thanks. Do you know if there a task/bug/wiki/roadmap somewhere to follow re; the text editor undo being grouped with other steps? I only find this; https://developer.blender.org/T24543 (closed, from 10 years ago).
No, I'm unable to reproduce the crash, I'm afraid.
May 15 2020
Apr 17 2020
Thinking about this for more than 5 seconds; this is probably Z-fighting, right?
Apr 16 2020
Mar 21 2020
Just want to emphasize that this isn't just Eevee that has the issue, it's Eevee and Workbench. Thanks!
Mar 13 2020
Thank you -- using "closest" seems to eliminate the issue, so that method seems to be implemented in Workbench. Not sure if "closest" will be usable in general, but it's a potential workaround.
Thanks Germano -- is that correct? Even if Workbench only supports Repeat, it shouldn't be repeating these pixels at the edge of the plane?
Mar 11 2020
Thanks Jeroen -- without the setting in the shading popover, where is the proper place to tell the viewport (in rendered mode) to show the background the same way it does in an F12 render?
Mar 10 2020
Feb 6 2020
Appears to have been fixed along with T73467. Thanks!
Yeah, downloaded the latest (cad09e5227df) and no more crash! Thanks!
Jan 29 2020
I can't reproduce it on my other Linux system either (old/slow Lubuntu netbook) but it happens every time on my Kubuntu desktop... anything else I can do to help explore this?
Jan 28 2020
Jan 21 2020
Thanks Jeroen -- in the mean time, it is accurate to say that Cycles is "correct" and EeeVee/Workbench are not correct, as regards this issue right?
Jan 15 2020
@Jeroen Bakker (jbakker) : Thanks -- We're talking about the project in the bug report above? Are these changes in 2.83 already? Here is what I'm seeing:
Dec 26 2019
I tried that demo file but the packed images don't seem to come through... In the image editor I see only "5.png" and the image doesn't actually appear in the image editor when it's selected (although the icon/thumbnail seems to be correct?). Similarly the outliner shows only "5.png"... let me know if I'm doing something wrong...
Dec 24 2019
Nevermind, I managed to get a reliable crash with this .blend.
I will try -- if I can not, is there a private address I can send a file to?
Dec 22 2019
Could we please un-resolve this bug? It seems that it is still an issue? Thank you!
Nov 26 2019
Confirmed on linux with 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: rB26bd5ebd42e3
Oct 29 2019
Thank you, Jeroen!
Oct 28 2019
@Alberto Velázquez (dcvertice) -- thanks for the reminder of that -- that is faster than regular rendering (roughly .14s/frame for the demo project in this comment), but still significantly slower than the viewport (.017s/frame)
Oct 24 2019
Oct 3 2019
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:
Oct 2 2019
Sep 28 2019
(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.)
Sep 26 2019
Sep 25 2019
Thanks -- orbit sensitivity was indeed at 0.
Sep 24 2019
I also found a way to fix this permanently, in case it helps to fix the bug:
Sep 23 2019
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!