A core design idea I'd like to emphasise is that "What you see is what you get".

Wouldn't it be nice to show a hint that explains why the option is greyed-out, inside the tooltip? I believe Blender supports this in a few places already, and such messages appear in red.

Any chance this can be considered for 3.1 ? it has been such an annoyance, the sooner I can forget about it the better. Thanks a bunch for fixing this !

This is a wonderful addition ! If I understand correctly right now the node needs neighbouring faces to return an angle. Any reason why this wouldn't be possible between two edges not necessarily attached to faces ? (such as a curve converted to mesh)

I didn't know that. In my experience autokey works fine pretty much everywhere (scene properties, shading and compositing nodes, and so on). Thanks for taking a look. It's only misleading because changing the property values directly does work.

I am not entirely sure this is indeed what's mentioned in the manual. To help clarify things, here is my experience : there is indeed a hard zoom limit in the supplied file, something I have not encountered before -but in addition to that there is also some strange interaction between zoom and dolly that I encountered when trying to work around the issue : once the zoom limit is reached (something that in my experience should happen once the camera lens reaches the point of interest, which is not the case here), we can still dolly further with shift+ctrl+mmb. However this dollying pushes the point of orbit further than we would like to (beyond the point of interest), which is expected from a dolly, from there we're again able to orbit around the point of interest if and only if we use "auto depth" (PreferencesInput.use_mouse_depth_navigate). At that point however, trying to zoom or unzoom again results in the view immediately snapping back to the hard limit. So, all in all it seemed a little fishy to me... especially given it's all happening at the centimeter scale, so not especially close to where you see numerical problems creep in.

In D12814#340399, @Felix Kütt (fkytt) wrote:

In D12814#335537, @Harley Acheson (harley) wrote:

I really like this. In fact I tried doing exactly this quite a few years ago without luck. Back then the part I didn't like, and couldn't figure out how to fix nicely, is seen here too:

With "Region Overlap" enabled, 3DViewport, View Sidebar. There is a see-through gap that separates the tabs from contents:

Sorry for the (somewhat?) off-topic reply, but just wanted to point out that in visual terms the solution to the issue in quoted bit is to simply anchor(re-orient/attach?) said tabs the other way around so they extend out from the side(area border/edge) and make the tabs background also transparent.

I think I agree with Ludvik Koutny here : distinguishing single values from fields doesn't actually matter that much for the end user. What's the difference, after all ? one uses a single value (or a single vector, etc) whereas the other uses a bunch of values that vary over the mesh. Compare it to Cycles nodes : it's the same as using an input variable (such as the "normal" output from the "geometry" node) versus using a constant vector. The particularity of fields is entirely technical, and the socket change already communicates the fact that it's carrying many values instead of just one -which is a distinction that was never even brought up for Cycles nodes.

The part I like is the grouping of "path" and "filename" fields. The current dissociation was always a bit jarring. On the other hand, moving the navigation buttons seems uncalled for, and the "path" field has become very short too -may quickly become a problem with long paths, files on remote disks, or just deeply nested projects (which are most projects, in my experience).

I wonder if it's not worth just clamping the index ? It sounds sort of counter-intuitive that an index of 10 will end up 1 if there are three connected inputs. In practice I'm not sure artists want such cycling behaviour (maybe they do).

In T88951#1181740, @Hans Goudey (HooglyBoogly) wrote:

Should the Python API for vertex groups be moved to object data as well? Other than consistency and clarity, another reason to do it is so the "Vertex Group" panel can display when you have a mesh pinned in the property editor, but no object.

Also, maybe moving the active vertex group index would be a good opportunity to get rid of the "index starts at one" thing for actdef

In D9493#296468, @Juan Pablo Bouza (jpbouza) wrote:

I know I know, but what I mean is that this is a functionality patch, changing the owner and target names might require a different patch and discussion? Cause it's a Blender general thing.

In D9493#296391, @Juan Pablo Bouza (jpbouza) wrote:

I totally I agree, this owner and target naming thing totally sucks, but maybe that's a different discussion on its own.

In D9493#296361, @Sybren A. Stüvel (sybren) wrote:

Just to check whether I understand this patch correctly. Does the "Owner Local Space" do this?

• Given a bone B1, compute the matrix M that takes it from its rest transform to its current transform
• Convert M to world space
• Given bone B2, convert M to its local space
• Apply M after B2's parent matrix.

I don't think "Owner Local Space" is the best term to describe the feature, as I think few people will understand it intuitively from just reading that name. Not sure if that's possible at all, but I want to help in finding something that's better (or after a while concluding that this name is indeed the best one we can come up with, but at least I want to put in the effort). Before I can help, though, I need to have a clear picture of what it's doing exactly ;-)

Alright. Has it been decided whether or not to decouple the node that gets inspected in the spreadsheet from the node that gets "visualized" in the viewport ? I'm asking this because a "node toggle" like what's in 2.93 seems more straightforward than a full-on node "viewer node". Even further, maybe just make the overlay show the active node output? That's what we really want to see when we tweak properties on a node : its output in particular. Every extra step in a process that involves a lot of "node inspecting" is going to be a burden, I'd encourage you to simplify the process to the max.

Is a viewer node functionally different from the toggle on each node? in addition to being represented in the spreadsheet I thought it was supposed to enable an overlay of the node's output over the final derived geometry in the viewport? or did I read that incorrectly?

In D9493#292676, @Alexander Gavrilov (angavrilov) wrote:

Btw, there is a recent comment by @Hadrien Brissaud (hadrien) supporting the usefulness of the equivalent bone setup in the main task.

This can be done with two additional bones per handle and control pair:

A child of the control, oriented the same as the handle in rest pose, without constraints.
A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child.

Just a thought about UI : I think it makes sense to have filter options both inside the popover and in a sidebar, akin to tool/brush options in the 3D view that are both accessible through the header as popovers and in the sidebar (so they're always visible).

I thought I had a bug, so I checked this task and if I understand correctly overrides in material node trees is still incomplete, am I correct ? It works in some files, and not in others (same character though, which is unexpected). Should I report it ? (I am using 2.92)

@Hans Goudey (HooglyBoogly) The radio button idea is consistent with other places in Blender (fcurve modifiers) and it serves that it's an explicit button instead of an "invisible-hitbox" activation like in 2.92. It's further less horizontal space in a place that's running out of it already though (unless the new datablock selector goes in as well?)

Having shortcuts affect not what seems to be selected is indeed confusing. This is not how the rest of Blender works : viewport, sequencer, ... every editor operates on selection. The problem here is that this is no selection, but looks like one. I'm not sure what being active entails for a modifier, but I think the indicator should be proportional to its importance. If we're going to have shortcuts affects the hovered modifier, then there needs to be a hover indicator that's more prominent than the active indicator.

I don't know, doesn't this seem more complicated than the problem it tries to solve ? Don't frames and reroutes already provide all the organizing functionality ? Is scrolling actually an issue ? Maybe a minimap could help in that regard ?

Concerning the "limits" fmodifier : wouldn't it make sense to group value sliders by dimension (first X, then Y) rather than minimum and maximum ? Using this layout, I feel there is a disconnect between the way they're grouped and the way I tend to mentally picture myself setting the limits in question : first set abcissa bounds, then set ordinate bounds. I realize this is quite nitpicky.