- User Since
- Mar 17 2014, 2:08 PM (350 w, 2 d)
Tue, Nov 3
Oct 31 2020
This bug, or unintended behavior, was NOT present in version 2.79. It also worked properly not only in Sculpt but in every other mode such as Vertex Paint and Weight Paint.
Maybe it would be proper to also add to the description that it worked properly in 2.79
Oct 21 2020
it's very useful to have in quick sight the number of users of datablocks
Sep 29 2020
Sep 25 2020
When transforming you quickly see the area being adjusted. I doubt users will often view the weights before making any transformation.
This is exactly the reason why it's not optimal. You have to manually transform to see the area affected. If you are planning the best place to grab a component, you have no idea exactly where are the boundaries to the proportional, look at the example below.
Also, once procedural transforms gets into the mix (in Everything Nodes), it would definitely be required to preview the weighted transform areas of the model, as we would not be directly editing the mesh, but doing so by means of nodes.
Sep 23 2020
"Users will constantly want to preview certain sections of the node tree, and having to manually connect those things up to the output node will be a pain. An easier way to preview the output of any node would be extra useful for geometry nodes, but would also be a benefit for shader or compositing nodes."
Sep 16 2020
Sep 7 2020
Sep 2 2020
A fact of the matter is that some buttons are used much more frequently than others, such as New Material (which should be called Duplicate Material) and Unlink, and therefore IMO should be always visible in order to be accessible with a single click (instead of hidden in a menu which would require an additional click for every Material you want to access)... And one button, the "Fake User", is basically required to be exposed at all times due to blender's unintuitive behavior of data-block users (if even with this exposed new blender users are confused, imagine if its hidden).
Scalability: I don't see why can't we have a dynamic solution. This problem only arises if the window size or Resolution Scaling (in Edit>Preferences>Interface) is smaller than a certain point. Solved by the proposals below of a dynamic change to the interface.
1- If the properties region horizontal pixel length is reduced past a certain threshold (be it due to window size or Resolution Scaling), the most commonly used FakeUser/NewMaterial/Unlink buttons are then replaced by a "Down Arrow" button, which opens the menu suggested in the task:
2-If the properties region is reduced past a certain threshold, replace the common buttons with a "Side Arrow Left" which when clicked expands the three icons to the left... and works as a toggle, so that one click expands, and keeps it open indefinitely, with now a "Side Arrow Right" button that if clicked retracts them back.
3-Transfer the most commonly used buttons to the list above. This would free space for the Material name field below (allowing longer names to be read there) and would also allow Shift+MouseDrag functionality for quickly mass Fake-Usering, Material Duplication or Unlinkage of long lists of materials.
Discoverability : I see absolutely no problem with some buttons appearing or disappearing, depending on which conditions are met. This is a matter of the user understanding the operation, which happens either by experience (learning/trial-error), or by being told on the spot by means of clear tooltips, as mentioned below.
If the user doesn't understand the operation (ex: clicking on "Create Library Override" will change it's button to "Make Local", since this is now the only operation possible) keeping the buttons visible at all times doesn't solve the issue, as he still doesn't understand the functions or why one button became grey/unclickable and the other didnt.
Unclear Status: The problem with Fake User being unintuitive for new users is a global blender issue, which goes beyond this material discussion. Until this is reviewed, it and the rest of the buttons are explained by tooltips, which as far as I can tell, are doing a great job so far (much better than 2.7x)
But they could maybe be improved, because in blender: the tooltips still only explain the button action/function, not what the operation is about.
Jul 18 2020
Jul 16 2020
One suggestion is for this to be expanded to allow not only one python command but multiple operations sequentially. Or maybe this could become it's own task in the form of a "Macro editor".
I'm thinking of this because right now it's a hassle to edit object origins in Edit mode, but the built-in addon 3D Viewport Pie Menus has a pie menu (for both object and edit mode) with the option "Origin to Selected" which basically does three commands sequentially as the image above shows.
And as far as I know it's impossible to add addons functions such as that "Origin to Selected" into the Quick Favorites. Allowing a single command would only permit being able to set a Quick Favorite to open the entire addon pie menu, instead of the specific function inside.
Jul 15 2020
@Germano Cavalcante (mano-wii)
Thanks for taking a look!
I'll consider creating a feature request of number 4 on RightClickSelect, but it's not much annoying, one only has to remember that when connecting reroutes the line always has to be pulled towards the node flow direction, never in reverse, in order not to break the flow, so it's very simple to keep this in mind (even though may require more mouse movements).
Maybe it's better to keep this in it's current state as it's simpler than having different behaviors depending on multiple factors.
A solution for number 1 and 2 would be to keep Reroute node color/type even after duplicating it or cutting a connection between two colored Reroute nodes. This color/type would only be overridden after a connection of another color/type is made to that node.
D1283 = Possibly related Issue
Jul 14 2020
Jul 8 2020
Thanks for checking the issue as well Richard!
If it happens to be the case that this is due to a technical limitation, I'd appreciate if you would advise me if creating a feature/improvement request on the proper venues would be helpful, or worthless, in case this is a part of Blender code that is not and would not be so easily changed. Thanks!
Jul 4 2020
Thanks! I have worded the issue in a way that became too confuse. So confuse in fact that I myself made several mistakes in my last reply to you. I have now edited the mistakes, I'm sorry.
But the first post, the error description, steps and the GIF, were correct in describing the problem, so I don't have to change them.
Thanks for looking into the issue.
Are you saying that is it working as intended that moving a canvas through a brush acts differently than moving a brush through a canvas, with playback active?
Or is it NOT an intended behavior?
Jul 3 2020
Jun 22 2020
Jun 5 2020
May 22 2020
I think some people are flocking here to give feedback regarding features instead of UX because the main task T68980 Everything Nodes was closed as a duplicate of T73324 Particles Nodes, even though Particles are only a fraction of the Everything Nodes project (?).
May 21 2020
May 18 2020
May 13 2020
In my tests, using the 3D cursor Move Panel X/Y/Z sliders sends the cursor to infinity and beyond. Behaves as when you have a circular dependency in hierarchy.
This happens in all 2.82 stable, 2.83 beta and 2.90 alpha. Windows.
I can't even control the cursor like the original gif in this report shows, maybe because I'm on Windows?
Should I open a new bug report?
May 5 2020
Not sure if its permitted to comment here (if so, feel free to delete this). In the video, once Pablo "Deleted Lower" subdivisions, and all the numbers dropped to "0", I noticed how the lack of "number of subdivisions" information is prone to create confusion. Nowhere in the Multires panel it says how many subdivisions there are in total (or if there are higher levels than where the user is currently in). This could lead to situations where the user start sculpting at level 0 (maybe after Deleting lower levels or not) and doesn't know/notice that he is also interfering with higher levels of the sculpt (that he doesn't remember or doesn't know of).
This could be prevented by showing how many subdivs are there in total, for example with a "0/n" instead of only the number of the current level that the user is in. Another option is to display a warning red message in the panel ex: "There are sculpted levels above the current one" to indicate to the user that his sculpting will interfere with higher levels.
Here are the two examples:
May 4 2020
Apr 30 2020
Apr 14 2020
In case someone's interested, here's a middle ground between Dark and Light themes would be a good option for people like me that think that one is too dark and the other too bright to work confortably.
I made one which gets pretty close to the average luminance of those two themes. (If you averaged Blender’s Dark and Light Themes it would be 87 gamma or 34% between B&W. Mine has 38% which is so far the closest to a true Medium grey theme.)
Apr 8 2020
Has this project died? Has nobody reviewed it in a year and a half?
It was so useful, I could think of a dozen uses...
Dec 4 2019
Nov 28 2019
Jul 11 2019
On your video you are not on Bone Constraint tab, which is the proper tab for IK constraint. I'm pretty sure it is there.
Apr 15 2019
is there an easy other way to establish the delay effect for children, driven by one object?
Dec 4 2018
Nov 23 2018
Amazing!! Thanks for the answer, and for all the work on the animation front for Blender!
Great commit! I know this is not the place for suggestions, but this makes me think how good would it be to have a "B-Bone Child constraint" that takes the B-bone curvature into consideration when applying transforms to a child bone of it. (Or to have blender consider the B-bone form changes into proper parenting relations and constraints, instead of a separate constraint)
Right now if you create a child of a B-bone, add segments and ease-in and ease-out to the b-bone, then move/rotate the bone before or after the B-bone, the curvature of the b-bone will change, but it's child bone will remain static as if ignoring the form changes happening to the B-bone.
Nov 22 2018
Nov 21 2018
Hello. If I can make a suggestion... on top of the proposed ideas, which I think are great, would be to use the Alt+Edit current behavior, but inverted.
On 2.79, if you select multiple objects and press Alt before you change something (not everything is supported), this change propagates to everything selected.
Now, on the proposal of automatically changing everything and showing it through an outline/color is great, but it would also be handy to be able to to the opposite: without deselecting everything, changing only the last (current active) selection. And my proposal is to use the current Alt+click behavior. If the user simply hovers over a field or checkbox, it is outlined and everything selected can be changed. But if the user pressed Alt beforehand, the outline would disappear and then only the (current active) last selection is changed (without the need of deselecting everything).
Jun 3 2018
Hi Dalai... can I ask a question?
Are there any plans to use a similar approach to Armature Layers, to turn them to a Collections system instead of limited layers like they are today?
Jun 2 2018
Edit: Wrong interpretation of information on my part.
May 18 2018
May 10 2018
Nov 11 2015