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.

Any news ?

I'm not sure why a new UI is necessary since this seems to cover exactly what node groups do ? Is the idea to communicate to the user that they are working in a special sandbox and only certain nodes are allowed ?(as opposed to a regular node group which has no such limitations)
Apart from that you have my blessing. I've also started finding long string of attribute nodes unnecessarily difficult to read.

It may be good to expose individual counts as sockets, so as to drive them from the modifier interface.

In case the attribute doesn't exist yet, replace will create the attribute ? In this case, how about calling it create or create/replace ?

Hope that passes review. That would be quite the qol improvement. Thanks for working on it anyway.

If indeed the fake user is on its way out, then the user count can be overlaid on top of the datablock icon on the left, and the duplicate button can be moved to the dropdown menu, at it is arguably less essential than the unlink button.

Apologies for the noise, but I'll drink to your health tonight @Brecht Van Lommel (brecht). Big, big thanks !!

That is so much better. I don't see why decorators should be hidden though, these properties can be either connected to other nodes or animated/driven in their own right, as far as I know. I think this should be communicated as with all animatable properties.

In T84310#1087292, @Germano Cavalcante (mano-wii) wrote:

Although with a different keymap, this is the same problem as T40059
It is important to keep in mind that in some cases it is preferable that the "click to focus on the blender window should be used only to bring it into focus". (See T79766: Mouse clicks to bring blender into focus aren't being discarded)

As far as I know regular modifiers are not going anywhere so anyone can still use the array modifier in between geometry nodes.

In T83059#1066192, @Hans Goudey (HooglyBoogly) wrote:

In T83059#1066142, @Karlis Stigis (karlisstigis) wrote:

Would this not be solved by point groups? If a point is part of a certain group, it can be deleted, separated, processed down the line. Are attributes saved on every point or this works in some other way?

Yes, it would be possible to limit scattering to a certain group of points. (A point group is just another attribute, a boolean attribute I suppose). I'm not certain about the reasoning for doing it this way instead, but bplitting points into multiple geometries makes it more explicit that there are different groups anyway.

In rBdf31ecf0c3e3b406906dd8bbe99cb75273e9dc4b#287605, @Yevgeny Makarov (jenkm) wrote:

No, you need a different code for middle-click-drag.
Although IMHO with the mouse it is easier to use the scroll wheel.

Sorry for the noise, does this enable middle-click-drag to scroll popovers ?

Will they ? I thought current modifiers would be kept ? Is the plan to convert them all to "node tree presets" ?

In T74967#1043080, @michael campbell (3di) wrote:

I don't understand why the UX of an existing tool would need to be altered in order to be represented by a node, could you give an example of an existing edit mode operator that would need additional parameters adding to it in order for it to be replicated as a node? The only additional information that a node would need over the redo panel would be the selected verts/edges/faces as Adrien mentioned, but this wouldn't need to be represented in the redo panel or the tool options, this would just be obtained from the selection and stored in the node (there's no downside to having additional parameters in the node that aren't in the interactive tools parameters, in fact it's useful to be able to have access to the selection after the fact, this allow to change which verts/edges/faces are affected either by manually changing the selection, or by feeding in a selection node which would have options for automatic selectin based on attributes or face angles etc.

In T74967#1042990, @michael campbell (3di) wrote:

Once each edit mode operator has a node counterpart, then it will be very easy to auto generate the the node tree because it'll just be a case of populating the node with the same parameters as the redo menu and then wiring it's input to the previous nodes output. There'll need to be a transform node with a selection property too in order to capture user transformations (move, rotate, scale)

@Don Hopkins (SimHacker) hadn't seen your answer. Thanks for your interest! I don't think mouse warping can work with devices that communicate an absolute pointer position (tablets)? My idea was more in line with spawning the menu partly offscreen, just as if the interface actually extended beyond the screen's edge. This works on paper because the minimum necessary interaction area for pie menus (or even regular ones) is much smaller than their entire displayed size, and one way to interact with them is to simply flick the pointer in any direction, with no need to actually reach the desired button with the pointer. However, I think pointer warping can be desirable for when the user uses a mouse and when the invoked menus are small enough that they don't cover the entire editor.

I'll add my thoughts because I feel something may be overlooked : besides the fact that this fallof visualization is completely standard in all DCCs I used (because that alone doesn't make it a necessity in Blender), it is useful because :

1. adjusting the "proportional size" before a transform operation is impossible (it should be possible), so there is no way to know beforehand how big of an area will be affected
2. tablet users have no practical way of changing the proportional size during transform (bound to mouse wheel), so they are pretty much relegated to having to tweak the proportional size in the last operator panel
3. finally they can't even do that because Blender struggles too much when changing any value in the last operator panel if the mesh is bigger than about 50k verts (which is very, very low)

That sounds very flexible, best of both worlds ! I assume existing modifiers will be kept around for transition and compatibility ?
Additionally I suppose custom interfaces for "node modifiers" will require a more thorough access to socket type, widget creation (checkboxes...), etc. than we currently have in Cycles node groups ?

It doesn't sound like this has been discussed with Pablo ? Fast navigate is a necessity to keep navigating smoothly around a heavy multires object, it is standard in sculpting programs. Then, @ronan ducluzeau (zeauro) is right about a multires cube not being a good candidate for "starter geometry" - the workflow introduced by Pablo goes like this : 1. blockout forms from a primitive, using voxel remesh 2. retopo and use multires on the new object. For a "starter geometry", it does make more sense to use a subdivided cube.

In T79785#996298, @Pablo Dobarro (pablodp606) wrote:

I'm also not sure about that. What about editing tools for armatures or volumes?

Typical characters are symmetrical, props and other objects can either be or not be, so I would say it makes sense in the context of rigging that symmetry be a per-armature setting as well. However, it would probably have to be split off from pose mode's symmetry options as well, because animators don't want to be posing their character symmetrically (unless exceptional circumstances), otherwise any symmetrical edit required on the character rig file would require the rigger to turn symmetry on, make the needed fixes, and turn it off again before saving. Or maybe this is something riggers could live with ?

Given the number of new tools added recently to sculpt mode, I reckon it'd make sense to only have a single "brush" tool, and have all brushes be accessible from there.

In T66426#970900, @Dan Pool (dpdp) wrote:

I want to point out that the software, whose name I will not mention, that people are expecting this feature to perform similarly to also allows for snapping in a particular local or world axis. So, for instance, if I want to snap to only the z location of the target vertex, I will drag the z gizmo when sliding along an edge and the vertex will project the axis of motion along the edge to the z location of the target - the vertex slides until it reaches the xy plane that the target vertex lies on. The current state of things has the vertex snapping to the point where a ray perpendicular to the edge intersects with the vertex. So far, this has only been useful to me when the edge I'm sliding on is parallel to one of the primary world axes.

The image below depicts the current behavior of the edge slide snap which snaps perpendicular to the edge as shown in red. If I press the z key during this transform while having World Coordinates selected, I would expect the vertex to snap in a location that lies in the xy plane of the target vertex - shown in blue.

In T66426#970463, @Fran Marz (franMarz) wrote:

Please bear with me, but I'll try to be clear to avoid more noise:

Right now, the point of snap is determined by the intersection of the edge where the vertex slide is performed with the plane perpendicular to it and that contains the snap target, i.e., the shortest path. This is not so handy neither predictable in a lot of situations, especially with irregular meshes where you would prefer to snap to the intersection of the edge of slide with one of the three global planes (XY, YZ, XZ) at the target position, i.e., like moving with an axis constraint like when using G + X, Y or Z, but while sliding.

A proposal: shortcut options (X, Y, Z) for especifying during the running of the operator the direction of sliding, so the intersecting plane is the one that is perpendicular to this direction and contains the snapping target, and not the perpendicular to the edge of slide, which could remain the default.

Last I heard, pictures and videos of other software are prohibited here for legal reasons - I think it's safer to remove it and take it to devtalk.blender.org/ or https://rightclickselect.com/p/ where there can be a lengthy design discussion about this particular feature.

In T66426#969072, @Yuri (YuriKruglovRus) wrote:

In T66426#969043, @Paul Kotelevets (1D_Inc) wrote:

As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean.

I know Arrimus, he was popular, but his methods are far from being the most effective)
Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc
That's all )
Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

Indeed... still it would be nice to support snapping along a different axis than the transform axis. (Non-orthogonal snapping)

Vertex sliding is basically a translation with an axis constraint, so I guess it could behave exactly the same (along with planned improvements such "snap to intersecting geometry").

In T75821#915530, @William Reynish (billreynish) wrote:

Alternative design, with different tradeoffs:

This leans even more into the pie/pie piece concept, but is a much bigger change:

Just chiming in to say as useful as it sounds it would be much appreciated if kept optional - I like selecting what I can see without any side effects, so the sync between xray and selection occlusion suits me fine.

Thanks for the merge I wasn't sure the issue affected all modifiers.

To me it seems the gizmo just needs to follow the input transform values. @Julian Eisel (Severin) in your example, showing the gizmo while transforming and continually updating its position to match the selection's center of mass would probably look like it's lagging behind the mouse cursor. In my opinion as an artist, it seems okay to update it according to the input transform values while the operator is running, and then recalculate its position once the transformation is done (just like we do now).

If we don't plan on supporting live creation of nodetree from edit mesh operators, then a potential solution would be to create a "procedural object". This object would not have a predetermined data type (mesh, curve, volume...) but would be able to convert between types internally through conversion nodes and use any operators related to them such as VDB boolean operations, curve lofting or regular mesh operations. It could also have its own edit mode where selection, instead of activating given vertex or edge, would activate the relevant node and display its gizmo(s). Just water to the mill.

In D4786#172545, @Clément Foucault (fclem) wrote:

Not 100% convinced about this being very helpful after starting transforming. But by judging about the hype this patch has received I can see this is a much requested feature. But I don't know if the hype is about some expected feature not present in the patch (preview before transform) or about the implemented feature.

Blender's Vertex Groups perhaps should be renamed to Weight Groups, since they don't really store selections, don't allow for edge or face data - instead they allow you to specify a weight value per vertex.

As long as we're talking about simulation with meshes, and not flips or other kind of data, I think it would make sense to present geometry nodes and higher level simulation nodes in the same place : rigid bodies, soft bodies, cloth all manipulate geometry, the main difference being the latter have to be aware of their previous state to compute current state, hence requiring a simulation step from frame 1 - but the way I see it they're a different tool to manipulate the same data.
To add to that, I believe there are advantages to having a mesh freely going back and forth between generative modeling and simulation and back : adding procedural cracking or wrinkling onto a simulated cloth or skin, or instantiate static flowers on top of a plant asset rocking in the wind, for instance. The use cases seem pretty much infinite.

@Brecht Van Lommel (brecht) other programs separate object manipulation (working with transforms, matrices, object instancing...) from geometry manipulation, I'd say that's good UX. I expect within the latter everything would happen in object space, with utilities to convert to other spaces optionally (matrix nodes already present in Jacques' functions branch).

@William Reynish (billreynish) I think the bracket-socket works very nicely for constants.

For grouping of newly created geometry, it's important to do two things :

1. give the choice of component type, so that following node can act on either, say, new faces or new edges, such as bevel
2. split into several groups when relevant, *eg* extrusion tip and sides

The only reasonable way I can seem is to only show properties that are available on all selected items. Take the example in the task, where a Point and Sun light are both selected. Point lights have a Radius property, but Sun lights have an Angle property. If we react to the selection instead of the active item, we could either show both or none of those properties. Showing one of them doesn't work - it only makes sense when you use the *active* option. Showing none of them is much clearer, because they you know that everything you see can be multi-edited, and otherwise our layouts might also break if we try to merge layouts to show all properties.

If there's a single multiply node that can handle floats and vectors, how does it interface ? We should keep the value field when nothing's connected to the socket, but how should it behave then ? as a vector, or a single value field ?

I requested this some time ago on twitter, and I am very happy that you worked on it Pablo. I think this is a great improvement. However, previous behaviour is desirable in some cases, and should be kept of course.

In T73047#846737, @Alberto Velázquez (dcvertice) wrote:

I would certainly like to raise... is it really necessary that the multires be a modifier? Given that having more than one modifier of this type is a nonsense and that it is always forced to be the first modifier... wouldn't it be more logical that it simply be a property of the mesh like the vertex groups? Maybe I'm wrong, but I don't see any sense in it being a modifier. Also future sculpt layers could be placed in same mesh tab, like vertex groups or shapes, where have more sense than inside a modifier.

The technicalities may fly over my head, the importance of being able to deeply modify a linked character while it's being animated in another file (add/remove/rename objects) is not lost on me - not being able to do this would be quite the limitation. However I don't understand why there has to be something else on the UI side ? Shouldn't this all be mostly transparent ? How are these override groups relevant to the user ?

In T67088#821829, @Ivan (Rasterman) wrote:

In general, I would suggest looking into Hou mechanics and how it deals with different contexts (rendering, compositing, particles, modeling, etc.) and their communication. The Geo Spreadsheet is where the party's at.

Maybe this should be a global property ? I'm not sure how much added value there is in having it per-brush. In any case, great qol addition.

Haven't tested, but from the changelog looks like a much welcome improvement, especially in the absence of a gizmo - any plans to have one or does it become superfluous with these changes ?

Just saw that commit and I think it's great having more flexibility in regular parenting. This last possibility you mention (inheritance of individual scale values) sounds good as an alternative to setting up copyscale constraints on a long bone chain, and average sounds like it might just be better as default, imho, but I'm hesitant on that tbh - like you say, any rigger should know that decomposition, even that fancy polar one attempted on sheared bones won't really work in any predictable/desirable way, which is why (afaik) non-uniform scaling on a (simply parented) chain is usually either prohibited by the rigger or not attempted by the animator, so... All in all this sounds like a good, thought-through change to me.

@Brecht Van Lommel (brecht) Why not simply write them as xml instead of inside a blend file ?

Good point. I know of a way certain programs address that : they allow for splitting the list in two : one at the top, another at the bottom. Moving an item a long way is then just a matter of scrolling to the right place in the first 'pane' so to say, and then dragging the item from the second pane into the first one.

I have to say that falloff preview looks rather distracting... not sure if that's necessary. One look to the top (or right) is enough to remind the user which falloff they've selected, if that's the intended use (?). Apart from that I like the changes. The strength direction being reversed will take some getting used to, but makes more sense. Those little tweaks really obviously come from a sculptor !

I'm not fond of animations especially for the 'UI list' case - I think drawing a dotted line where the item is going to be inserted is more efficient and straightforward (as most painting programs do it in their 'layers' list) - seeing items shift around disorientates me when I'm trying to precisely move a specific item to a location I'm targeting - when suddenly that visual target slides around, I'm not sure where to drop the thing anymore. Maybe that's just my brain ? Quite a few interfaces do this (off the top of my head Discord does this with its channel list, & last I checked Android UI framework kind of enforces it too) and I find it quite disturbing. They do make more sense in a grid view (2D) though, because the order of items is not necessarily as obvious as in a list (1D).
Other than that, obviously in full agreement of the proposal.

Worth noting that currently bones can neither be sorted alphabetically, nor by hand. Would be super cool to have them benefit from all these enhancements, too !

@William Reynish (billreynish) Oh so it's actually an additional mode ? I thought that would replace Lookdev. Ok, so I understand better now : Lookdev becomes a way to preview your assets using the scene engine -supposedly the one that'll be used for the final renders- and Material Preview is gonna be what Lookdev was until now. Am I correct ?

For what it's worth, here is my use case : I have a scene set to render with Cycles, of which I render out previews using lookdev mode, with 'scene lights' and 'scene world' enabled, because that's what I need in a preview (not just previewing assets, but entire animated shots with lighting and backdrop). Why not simply use Eevee as the scene renderer then ? Good question ! Simply because I do full renders once in a while to check on the final look and lighting. Ideally, - and I have read all of the above and understood at least 40% of it- I could still do that after this change.