- User Since
- Dec 5 2017, 10:51 PM (135 w, 17 h)
Interesting, and this is indeed an issue back in the 2.7x series too.
This was probably fixed just after that build there -- looks like the build you tried was dated July 3rd. It was fixed later that day as part of rB4a48939f0
Tue, Jun 30
I'll need to merge in a recent change to the .blend before this can go in. Additionally, I want to see how the recent testing GSOC project plays out as it drastically changing the formatting of the .py along the way. Will put this change on hold until later in the summer I guess.
In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2
Mon, Jun 29
Can you report the version of your nVidia driver? Several news outlets mention that the first driver to support this feature is 451.48
Fri, Jun 26
I didn't want this piece of feedback above to be lost: As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.
Wed, Jun 24
This is controlled by the theme: User Preferences -> Themes -> 3D Viewport -> Edge Length Text
Thu, Jun 18
Unfortunately I can now repro more reliably (without having to use Undo; but still involving tbb / threading) with latest master. Here's the full crash report:
Tue, Jun 16
Might be because your Wireframe Overlay value is set to 0.5 - try setting this to 1.0 (it's 1 by default since quite some time so maybe your preferences are old and/or you've changed the value?)
Optimal display is now the default: https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Modeling (applies to both Multi-resolution and Subdivision Surface modifiers)
Sun, Jun 14
I can confirm this crash here as well using a slightly newer build even. However, it sometimes doesn't happen during the first shift-d, alt-d, repeat cycle. It usually happens on the second attempt for me.
Tue, Jun 9
Alright, tested with your new files in both Image Viewer and Shading tabs with thumbnails enabled and when set in an Image texture and looks good (again)
Do not depend on higher layers having ensured file is of a sufficient size already
Mon, Jun 8
Interesting, yes, it's actually the Pixel Size setting as I'm on hidpi here too. So seems like this and T75289 really are the same, I wouldn't have guessed that :)
Jun 8 2020
Jun 7 2020
Jun 6 2020
Jun 5 2020
This is really great! Appreciate you taking all the feedback from the other thread into account here.
Jun 4 2020
Does this still occur if using the official builds?
Jun 3 2020
Naming things with words like "complex" also doesn't mean much. What happens when there's an even more complex case in the future etc. In fact I debated just removing this case since it's not very complex at all :) I think bug number means a lot more and it allows people now and in the future to more easily track down the details of the test if required.
Jun 2 2020
The manual already has a very visible orange warning box explaining the situation. Since that has existed for some time, and users still inadvertently run into issues quite frequently, I think it's time for a more direct UI indicator now.
Jun 1 2020
Probably would be addressed by D262
May 23 2020
May 18 2020
You can already do that. Just add a keymap entry to the 3D View (Global) section
Not quite, at least for 3D View (Global). Adding a custom keymap entry there doesn't work in Object mode (weirdly enough). It's why e.g. the Subdivision Set operator is duplicated for Object mode explicitly even -- 6 extra keymap entries that are nothing but clutter.
May 17 2020
Yes, the OIDN denoiser is very memory hungry indeed. However, there's at least 1 thing blender itself can do to potentially mitigate this (if this is truly an out of memory situation): Use the OIDN API setting which limits memory.
The issue is due to the very wide clip start/end settings that are in use for the file. It is currently set to 0.0001 m to 10000 m. This range is much too wide and the Knife tool, in particular, is very susceptible to precision problems based on the clipping distance.
May 16 2020
I think the primary reason why folks would want to retain an "advanced" list of entries that span multiple contexts at once is because there's no hierarchy to the keymap. In many instances I want to add/change a keymap entry at a "top level" and have it apply to everything below that unless overridden later.
I can confirm the crash here. Note that this does NOT happen if using the old, legacy, undo system.
May 9 2020
The problem where the old .blend didn't open has been resolved (was because it was set to openvdb/modular format). However, the issue with the lines and completely different looking simulation still seem present :-/
May 7 2020
Yes, the existing modifiers.py unit tests are failing on collapse (as well as operators.py) according to the buildbot. Please run the test suite to see if it's still ok.
May 6 2020
Remember this is only for 2.9x, not for 2.83.x. As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.
May 4 2020
Probably related to rBd0ff3434cff
May 1 2020
Apr 27 2020
Thank you for continuing to improve the new stats display!
Apr 25 2020
Here's what my personal addon does. I added in the "Tris" entry as an example even though I don't display it personally. I also don't use "Edges" while in Object mode. Both of those cuts down on text drawn on the viewport for me.
I guess I interpreted consistency with the outliner a different way, where the lesser used options are more to the right, like when you enable the Holdout and Indirect Only filters.
Did you intend to reorder the modifier options as [cage|edit|viewport|render] instead of the order that they are today of [render|viewport|edit|cage] ?
Apr 24 2020
Apr 22 2020
Apr 20 2020
I can still reproduce as of rB9618bd9202a
Apr 17 2020
Apr 16 2020
I think the question is about if there's a breaking change for the following API: bpy.types.Scene.statistics(...)
Does that api still exist? If so, what is the returned format now?
Apr 15 2020
Are .blends from 2.82 supposed to be usable in 2.83? I can't get the attached .blend to work in recent builds (after bake). Wanted to see if things improved here.
Apr 14 2020
This should be fixed in what will become 2.83. See previous bug T74834
Apr 11 2020
Most likely the same as T74928. Multires internally acts like more than one modifier in a stacked fashion (1 and 3 above). But having a single modifier (2) seems to match what the other bug is saying.
Not op but it's trivially reproducible, applying the modifier isn't even required. Here's 2 files.
Apr 10 2020
Apr 9 2020
EDIT 2020-04-18: Actually, even saving a new startup file doesn't seem to fix this as I originally thought.
Apr 6 2020
It was just fixed so you'll have to wait to download the new nightly build available in the next 4 hours or so.
There does seem to be an issue with master.
Apr 2 2020
The buildbot version does not have Jacques's fix. You either need to build yourself or wait ~7 more hours from now for a new daily build. Please always include your build hash when commenting about a particular build as I'm only guessing you're using the buildbot right now.
Mar 31 2020
A known issue is fine I guess albeit a bit unfortunate.
Mar 30 2020
Mar 29 2020
I'd also prefer a column based format and I use that in my own personal addon. But that aside:
- Having the object name (Cube in your example) embedded towards the left of that stat line will cause unnecessary text shift when you're selecting different objects, some of which have vastly different name lengths. It's visual noise that would inevitably cause your eye to jump to see what's going on. Should probably place the object name elsewhere
- I would like to continue to use my own addon UI to display the stats instead of this but would hate to have the information duplicated up there. I also don't want to suggest an option to turn it off but...
- I'm guessing the ultimate reason to move stats out from that window area is to make more room for tool options there (T56599) Heck, Bevel today shifts the stats well out of view already :) But I'm really not sure how that design issue is going to land (if at all). I would personally prefer if both a tools' options and keymap are in the viewport and not just in the status area. If that happens then this section of the viewport is now pretty text heavy. Even if just the option values are in the viewport, this area of the viewport may still be too crowded?
I second the feedback to keep the title small. This has ramifications for the '*' symbol as well. For instance, here I can tell which instance has loaded a modified file and which hasn't:
Duplicate of T74834. Maybe mention your proposed fix over there too
Mar 26 2020
There's explicit code in the addon to handle modifiers and it worked in prior versions, as well as 2.79 (so I'll invoke the magical "regression" word to keep the bug alive :))
Mar 25 2020
Mar 24 2020
I'm running hidpi here too. 4k 3840x2160 resolution, Windows UI scale 2.0x, Blender UI scale 1.0.
Mar 23 2020
Being able to see how the gradient changes during the transform, as you move and expand the proportional editing influence circle, is definitely the most useful part here and I'd love to see it.
Mar 22 2020
Mar 21 2020
Hehe, I asked those same questions slightly above :)
Mar 20 2020
A few additional thoughts:
- Just to clarify the "constant" input item, that's really just saying that a single value will be used for a given execution of a node correct? It would still be possible to, say, have a Distance-to-Camera node or a Current-Frame node drive the Bevel segment count or the SubD levels count? In that sense the number could vary frame to frame (not constant), but just that a _single_ number is applied to the entire mesh at the point of execution.
- To speed up the transition, giving python addons a better, more intuitive, way to create node graphs, even linear ones like what exists with the stack today, is probably going to be required :-/
- Can "Apply" be expanded a bit. It's not clear how you would destructively apply a modifier (removing it from the graph; not just cache and gray out) exactly.
Mar 18 2020
Testing with a newly downloaded 2.83 buildbot shows the same issue as Jan 22nd above. i.e. While I cannot repro my original cpu/gpu always spinning issue any longer, I can still repro unnecessary viewport redraws during mouse-moves, w/GPU at 100%, while in Lookdev/Rendered modes if the BlenderKit UI is visible.
Mar 17 2020
Mar 16 2020
Mar 3 2020
I downloaded a nightly build last night after seeing this report but it works fine without extra settings for me. I run win10 @ 4k, Windows UI scale at 200%, and Blender UI scale at 1.0 which seems to match what you run. I've never had a problem with it though. Strange.
Mar 2 2020
Feb 28 2020
Feb 27 2020
This is the same as T66320
Feb 25 2020
Seems the recent update went slightly wrong
Feb 16 2020
This was fixed in rBAbb093696 on Feb 4th but that change was only committed to master (2.83) and not to the 2.82 branch.
Feb 15 2020
Feb 8 2020
Relative Offset is exactly that: relative to the dimension of the object. Your object here has a 0 height z dimension so it cannot offset relative to that. You probably want either the Constant Offset field to be set or use an Object offset. The other bug was invalid for the correct reason as well.
Jan 29 2020
Jan 24 2020
That it increments by 2 is by design and expected. This is due to the cryptomatte specification itself; each layer that cryptomatte creates internally will keep track of up to 2 different objects/pixel. The increment by 2 is just conveying that concept albeit in a non obvious way.
Jan 22 2020
The latest BlenderKit version has changed somewhat in terms of UI but the bad GPU behavior remains at least though slightly different.
Jan 21 2020
Add test for the Complex solidify mode