- User Since
- Mar 8 2017, 9:24 PM (298 w, 4 d)
Fri, Nov 25
Are the secondary windows expected to remember their size? From this task description, it is not clear to me. But I always found it quite frustrating that user preference window would always reset its size when re-opened, even during the very same Blender session. User preferences are very bloated with lots of settings, so it's almost unusable at the default size, and therefore requires resizing every single time it's opened. This is an example of how it opens at 2560x1440 resolution:
It uses like 1/8th of the screen. And it never remembers the size and position user has changed it to.
Tue, Nov 15
what happened to this patch? It could have made it into 3.3 and it has not made it even into 3.4. I am struggling with this heavily on daily basis. The fact node socket hiding doesn't work when adding new nodes makes usage of multiple group inputs (to keep the node trees clean and readable) very painful.
Fri, Nov 11
Sorry, but this doesn't seem to be expected behavior from the user point of view. There's absolutely no excuse for not sorting alphabetically when user explicitly decides to sort alphabetically. Whether the file is open or not should have absolutely no impact on the sorting. Users should not have to know this deeply obscure piece of information to be aware that the alphabetical sorting does not behave predictably.
Tue, Nov 8
Mon, Nov 7
Oct 23 2022
Oct 19 2022
@Hologram (Hologram) I am not for or against that argument. I just pointed out I believe someone will eventually make it, and it will be more likely made if the scope of this patch duo is extended from just edit mode into object mode as well. I don't have a preference in this, as I am just really happy things are moving. But I am worried that extending the scope will once again grind the progress to a halt, because people opposing these changes will use the "there are still unanswered questions" argument.
The important difference to faces is that objects may often have their origin points far outside the average location of the vertices they contain, where as face dots are always centered to average location of the face vertices. Object origins are often displaced for purposes of asset placement onto surfaces, or rigging of parented hierarchies. This would either make it often difficult to find the origin belonging to the object, or it would mean some new "object dots" need to be invented, which would always show up in the center of the object's bounding box, instead of where the origin is. This also means that these would have to be drawn for all the objects when Xray mode is manually activated in Object Mode, not only for the selected objects, as you probably want to see them prior to starting to make the selection, so you can start your selection at the right spot.
I wanted to point this inconsistency as well, but the other way around. Instead enforcing the only select what you see paradigm, I wanted to stress that it's not as important as the core developer team makes it to be, because people tolerate breaking it in the object mode.
Oct 18 2022
Tweak was replaced by Click-Drag. It's essentially the same operation, just deduplicated (so there are not two modes doing the same thing).
This is great. I have to admit that this is the smartest design of the feature I've seen so far. The idea to take existing Direction modifier into account to implement user-defined selection behavior together with directional selection at once is brilliant.
Any news on this? I have even nearly decade old production scenes which don't exceed any reasonable complexity, yet the node editor is unusable in them. For example:
A scene with mere 10M triangles and 600 objects should not be so slow that one can't use the node editor, even if the viewport is closed. This is not a limitation of current hardware or software architectures.
Oct 13 2022
Oct 12 2022
The thing is that if the underlying problem of selection being inseparably tied to viewport drawing is ever to be solved, it will affect this feature too. So I don't think it makes sense to start with this, if this relies on something that is an unsolved problem to begin with.
This does not seem to make much sense from the UX standpoint. The popover called "Viewport Shading" which groups the options, which define how the viewport displays its contents, now contains a checkbox which alters how selection tools work. Blender already has a problem where something, that is supposed to be a viewport shading setting, changes how the selection tool behaves, and this just exacerbates the problem, instead of solving it.
Oct 10 2022
Currently, materials can not be edited with the material editor unless they are assigned to an object which is selected. Would this change address that as well? Or would it have the same behavior as before, with the exception that you would not only need to have an object selected, but also have material assignment modifier present on that object?
Oct 7 2022
Sep 6 2022
Sep 3 2022
Deleting the small areas doesn't sound like acceptable solution, and neither does disallowing the join, because that would be jarring to the user. In fact, when someone sees such a small area, common instinct may be that it was created in an error, so they will probably want to close it by joining. So it would be very odd when the users would have to be aware of this corner case to know that joining not working is not a bug in this very specific scenario.
Sep 2 2022
Sep 1 2022
Aug 31 2022
Aug 27 2022
3.3 is almost released and this is still ignored. This is not a general performance insufficiency. This is a bug which causes whole scene to re-evaluate when nodes are selected and moved around. A change, which should not even need to read, let alone re-evaluate mesh geometry in the viewport does so.
Aug 12 2022
I don't think changing Window focus on hover is a good idea. The amount of unexpected issues this can cause will compound over time. It's also inconsistent with pretty much most other multi-window software out there. Issue with modifier keys not working on first interaction should be solved specifically, not with a monstrous solution that has many side effects.
Aug 11 2022
@Campbell Barton (campbellbarton) I am confused this task was closed. This was reported on Windows OS. Isn't Wayland a Linux specific environment? Does this really solve the bug on Windows?
Aug 2 2022
Jul 16 2022
To keep the UI cleaner, it'd make sense to have dropdown of common resolutions and then one of the options being "Custom", so that when anything else than "Custom" is selected, the resolution size UI element(s) are hidden or frozen.
In similar manner, when the square aspect ratio checkbox is checked, the Width and Height value fields should be replaced with a single "Size" field.
Jul 8 2022
Jul 7 2022
While I am grateful for the idea of replacing those 6 ridiculous individual data wrangling operators with one, I still don't think this addresses the core issue - that when you purge, you don't know what you are purging. Blender ridiculously expects us to keep mental library of all the things we've fake-usered over time when working on our scene in the back of our heads, and then mentally, in our head, do inverse of that to predict what "Purging X unused datablocks" means when the dialog doesn't tell as almost anything useful, datablock types aside.
Jul 5 2022
Solution 2. sounds the best. Solution 1 is also acceptable. Solution 3 sounds like a hell. There's already more than enough error prone data management wrangling Blender blatantly offloads onto user's mind. It would be really bad to add even more to it.
Jun 30 2022
Jun 29 2022
Jun 17 2022
It doesn't appear that https://developer.blender.org/rB8810d0cecdd5c192d0562c62490695d22ca684d5 fixed anything. Applying a cube projection of a size of 2 onto a 2x2x2 cube with 1.0 scale will still result in cubic mapping of size 1:
The fix either did not make it into the main branch or it's a placebo.
Jun 7 2022
Jun 6 2022
Jun 3 2022
May 27 2022
May 26 2022
May 24 2022
May 13 2022
May 12 2022
May 11 2022
May 10 2022
@Jeroen Bakker (jbakker) I could, if you want me to, but this issue is reproducible in exactly the same build as the resize lag issue. When I test the blender builds prior to the change, the lag when adding new nodes is not there either.
May 9 2022
May 5 2022
This issue is even worse, as it causes very short but very uncomfortable lag when adding new nodes inside a node editor. Just in general, the node editor now suffers from frustrating short lags.
May 3 2022
This doesn't make sense. So we get very severely reduced performance across the entire Blender UI just because someone's obscure old laptop GPU had a driver issue? O_o
May 1 2022
Apr 21 2022
I vote for the first option - creating the node at the same width as others, and just truncating the end of the name. "Attr" ends up being a really good abbreviation.
Apr 13 2022
Apr 12 2022
Apr 11 2022
Apr 9 2022
Apr 1 2022
Mar 26 2022
Mar 22 2022
Mar 7 2022
Mar 1 2022
Feb 18 2022
Since 3.1 release is getting dangerously close, will this be fixed in time? This severely limits usability of GN. As soon as Image Texture node is used, the overall Blender performance degrades to unusable levels nearly immediately. :(
Feb 14 2022
Feb 11 2022
Feb 9 2022
I'd suggest perhaps adding also Sharpen Even Less, Sharpen Slightly More and Sharpen More filters.
Maybe more fitting title would be "image texture datablock" instead of a node? Since this seems to also affect non-GN modifiers which use image texture, such as displace.