- User Since
- Jul 26 2018, 5:02 AM (60 w, 4 d)
Wed, Sep 18
Please clarify what you mean by "committing the operation" and "undo without committing the operation".
committing the operation- when the operator is no longer running modal and has returned. in other words- while the operator panel with all of the operator properties is still visible.
This appears to be fixed in 2.81
Tue, Sep 17
Here's a video of it happening in face mode with the latest from git.
Scratch that- not happening in edge mode, but I was able to repro it in face mode. Since I went through the trouble of building Blender I went ahead and made a debug build to get a callstack, this is the output:
Good news, does not appear to be happening on the build I just made- so it may have been fixed by something else. I'll hammer on it for a bit longer and see if I can get it to break
Well, I'll post an update whenever either the 2.81 download finishes (it's been going for about 2 hours now, previous attempts have timed out) or the build I just started finishes.
I'm not sure if it's the same bug, but after a week of trying to solve a similar crash I came up with a repeatable crash. Note that my bug is not for the modifier, but the bevel operator: https://developer.blender.org/T69966
Tue, Sep 3
Yep, sorry for the delay- been busy. Here's a blend file, not much to it though, repro is as described in the original report and verified with a factory default 2.80
Thu, Aug 29
Wed, Aug 28
Thinking about it a bit more, I think we could solve some of issues you mentioned with a tagging solution if we left the support edges visible but displayed them in a slightly different way to indicate their nature. (See the mockup I've attached). In this example, you can see that the 'support edges' are tagged and displayed differently than normal edges. This would allow them to remain selectable like normal edges, and would inform the user about the underlying geometry that could have an impact on tools like bevel and inset. I imagine users could even select and manipulate them (re-connect them to different verts if the automatically generated solution is not optimal or interferes with a tool). I think this could also help new users understand the difference between an edge they can dissolve and an edge they cannot. It would be intuitive visual feedback to say "dotted edges are different than normal edges for these reasons, and cannot be dissolved". Currently there's a UX issue where a user could create an ngon like the one in my example and attempt to dissolve one of the supporting edges and have it fail without understanding why.
Howard, just for clarification, are the pros and cons you listed in relation to *actual* holes in faces (ie, multiple loops per face) or does that also apply to the tagging solution?
This is something I've suggested in the past and agree that it's a good compromise solution. I have some mockups I would need to dig up but the idea was that if you flag ngon support edges and simply hide them, tool/addon authors can account for them and make their own decisions on what happens. For example, loop selection on the hole becomes trivial, where it takes two attempts currently due to the support edge breaking the loop (and no discernable difference between the user-made edge and the one added internally to support the ngons).
Aug 23 2019
Figured it out- the missing keymap items were added to a version of they 3D View Generic keymap that has space_type='EMPTY' rather than 'VIEW_3D'
Aug 22 2019
Aug 13 2019
Ok, so I have some more information. This bug is being caused by bgl.glEnable( bgl.GL_POLYGON_SMOOTH )! I noticed that the issue was only happening when a particular studio script was triggered (which I'm not able to share here unfortunately), but if I comment that one line out the artifacts go away.
Aug 12 2019
Confirmed, this is due to color calibration software- feel free to archive this bug!
Aug 7 2019
After more investigation, I believe this is being caused by my studio's monitor color calibration- I've tested it on two other machines and have not been able to repro it. When I'm at my workstation again tomorrow I will try disabling the Spyder auto-calibration and verify that this is the case.
Aug 3 2019
It happens on the default cube, there's nothing particularly special about the blend file but I'll attach it anyway. I imagine this is more to do with hardware?
Aug 2 2019
Aug 1 2019
Jul 11 2019
Aha! now that is a detail that I was not aware of. I had incorrectly assumed that ui_scale was simply the value that appears in preferences->interface, I never actually queried the value. It does correctly report a ui_scale that takes dpi into consideration, and now that I have a multiplier I can create consistent results on any display. Thanks for the guidance!
It's not a feature request, so far as I know, unless I'm missing something. The issue is that there is no way to ensure the end result is 100% identical on different displays that have different dpi. it doesn't matter what I set the dpi to in blf.size, it will look incorrect regardless. For example, if I set the dpi in blf.size to bpy.context.preferences.system.dpi, I get the following result in my 4k monitor (with a dpi of 108, according to system.dpi):
Jul 10 2019
Jul 9 2019
sorry, got distracted! It's happening in Linux as well. Two videos from Ubuntu 18.10 attached. First video shows same repro in multiple UV editors in the UV workspace, second video shows that it's not happening in any other workspace! so bizarre, hopefully since it's so weird nobody else will run into it 🙂
Jul 8 2019
This is actually still happening with sticky selection disabled! See attached video.
Jul 5 2019
Yeah it should be happening with any object in that scene in that particular workspace. It could be a windows-specific thing, I'll try it on Linux when i get home from work and see if it repros there.
Yes, this is still happening with the latest build- but it's only happening in one particular layout, which is very odd. If I create a new UV editor elsewhere it doesn't happen, so this appears to be some sort of edge case. blend file attached if you'd like to see it in action.
This is happening with the latest version from the buildbot with factory settings loaded. Here is a video with simplified repro:
so then there is no way in Blender to do the common task of selecting alternating uv edge loops in a UV island without also selecting UV edges from a completely separate island. that's pretty awful, but you are right, it's not a bug- just awful by design. hopefully that will be improved someday.
Additionally, this behavior is not exhibited while sync selection is enabled:
Note that this also happens with incorrectly 'selected' edges in edge mode. This is virtually impossible to show in a video due to compression, so here's a screenshot.
Jul 4 2019
Jul 3 2019
For anyone else who might need this functionality, a workaround that I use is the following:
Jun 21 2019
Ah, okay- the fix probably hasn't made its way over to the nightly builds yet. I'll check it again tomorrow.
This is still happening in the latest 2.80 build available on buildbot: version: 2.80 (sub 74), branch: master, commit date: 2019-06-19 18:29, hash: rBd30f72dfd8ac
Jun 19 2019
Jun 16 2019
Jun 15 2019
Jun 5 2019
I should clarify that image.view_zoom *does* work correctly, the bug is that view2d.zoom should either work in the UV editor- or not work at all. Right now the operator is allowed to execute, and correctly displays the tooltip- but does not function.
May 30 2019
May 6 2019
Apr 9 2019
Feb 19 2019
Dec 31 2018
No worries, thanks for taking another look!
Dec 30 2018
Dec 29 2018
Dec 28 2018
It's ten lines of code.. is there really nobody who can review this? It's been sitting in limbo for two and a half years. This would be very useful for addon developers....
Dec 26 2018
yeah this behavior is just bizarre. are any other modal tools affected by this, or is it just Inset?