- User Since
- Jul 22 2008, 10:04 AM (578 w, 2 d)
T66613 might have some useful information
Fri, Aug 9
Jul 9 2019
Okay, I used the cube add operator in the test as it was convenient, figuring it would show the behaviour I was seeing when creating meshes. Turns out the difference is much smaller in the latter case, but still quite a big slowdown in 2.8 compared to 2.7 (and higher memory usage). See the attached script, which uses foreach_set() as the fastest way I know to create geometry from a bpy script. This again creates lots (20,000) of mesh objects in a loop, simulating an import script that does more-or-less the same. The mesh objects are simple quads to focus on the overhead of object creation. Here's some results (note: different blender versions that above, as this is on my home system):
Jun 27 2019
One more mention of the difficulty to access accent-grave/backtick on some keyboards: we're giving a course in Italy and a lot of keyboards (both Mac and Windows) do not have the backtick on a key anywhere. We're having to show how to assign a custom shortcut (not really attractive in an introductory course).
Jun 25 2019
I see a variant of this in d08312463b27651171be1c487633804f6ea98d65 that does not involve the render command:
May 31 2019
I'm curious about this change, as the poly count in the status bar always seemed to be related to the amount of geometry *drawn*. For example, even when making duplicated copies of objects in 2.79 with Alt-D the count would increase. And switching layers (and currently collections) will also change the count, so it is at least somehow related to what is on screen. So what is the point of *not* counting instanced geometry when that seems to mostly create a confusing relationship between the status bar poly count and what is visible on screen? Hopefully a statistic that is so prominently displayed in the UI should be easy to understand?
May 23 2019
Yup, appears that was the issue, render example now working fine.
Strange, the incorrect preview render indeed only happens in my locally built version (from latest git). With an official binary it works fine. The --factory-startup option makes no difference.
May 21 2019
May 17 2019
May 14 2019
Yes, disabling gizmos in camera view makes the selection of the camera work reliably
May 13 2019
May 12 2019
May 10 2019
This also happens in a camera view, where it is even more annoying. Clicking on the image outline will fail to select, even though it gets highlighted when hovering over it with the mouse
May 9 2019
Part of this may be a feature request, but can you explain the logic between what stays selected when switching collections? Because it seems inconsistent/unpredictable and therefore buggy.
Okay, that clears up the use of the active collection in the outliner (should have figured that out myself, doh). So the "Add selection to active collection" is misnamed (as the active object does have to be on the active layer)?
May 8 2019
May 7 2019
May 5 2019
Bisected down to 7cbb8f20a4b479380dac1d2a2f7c7f85ede408be (probably, as I needed to skip 2 commits that didn't build, see log below).
Had an older binary daily of 2.8 lying around, in 6439ed844e7814fdc65e675bc851642382b72b60 it still works
May 4 2019
Mar 6 2019
Okay, adding the Addons tag
Sorry, this issue should have been created under the addons section I guess. Anyway to move it after the fact?
Dec 10 2018
Just chiming in here as the OP: renaming is_dirty_xxx to recalculate_xxx without negating the value would seem to just as confusing to me (e.g. moving a camera would trigger with recalculate_geom set to True). But maybe I'm misunderstanding what exactly the flags are supposed to signal to downstream users of depsgraph updates (e.g. a render engine script). I originally expected the flags to indicate for which objects the local (downstream) copy of the scene needs to be updated to match the current depsgraph. But it seems that that is a secondary usage, as the flags actually specify which parts of the depsgraph itself need updating. Which is surprising, because what if the downstream script does not handle the updated depsgraph part and therefore doesn't take any action on them to update?
Dec 9 2018
well, no shading at all, but that's to be expected since you don't seem to have implemented any drawing in view_draw yet.
This is the conventional terminology in computing. Read "is dirty" as meaning "needs cleanup" or in this case, "needs updated".
Hmm, more weird behaviour:
Dec 5 2018
Dec 3 2018
@LazyDodo (LazyDodo) So just to get some clearity, the known CUDA bug you mentioned only applies to 2.80 (while 2.79 used different CUDA code and isn't affected)? And it's now up to NVIDIA to fix this? How does that go together with Blender's apparent policy of trying to keep the used CUDA version low, so older GPUs can still be used? NVIDIA won't release any fix in CUDA 9.x anymore, I suspect.
Feb 5 2018
(Ahum, submitted too soon :))