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.

In T66426#969110, @Matt (Kickflipkid687) wrote:

I may have got too excited for this patch as well. But I will have to experiment with it more.

I still am hoping for a edge constraint feature where you can rotate an edge loop along other edges. Plus what people have mentioned otherwise.
Basically just stealing/replicating what 3DS Max has.

There is currently no way to use a constraint that I know of, to rotate an edge loop in blender along a cylinder type shape. You can Shear, but that doesn't work well often.

You can also do some interesting things like slide an edge loop against another one (in Max), to conform it. Although you sort of can do that in Blender maybe...

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. It would be nice to support snapping to along a different axis than the transform axis though. (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.

What does mat4_to_volume_scale do ? Does it average the individual scale values ? A scale of x on a single axis would become sqrc(x) on all axes on the target object ?

Zoom to mouse position is pretty much unusable with a tablet, as it continually reframes the viewport as @Jean Da Costa (jeacom256) said, but that's not the majority of users I guess. I personally keep it off but I couldn't care less about the default.

In D5546#126967, @noki paike (amonpaike) wrote:

Wouldn't it become unreadable quickly as well ? (over a dense mesh) What's the rationale behind having a preview at all ? Most often (in my experience) the ambiguity is whether I am snapping to a point nearby on the desired object, or to some distant point part of another object that I didn't even notice was overlapping the first object. Communicating the target clearly might be as simple as highlighting the actual target element ?

Some comments above, I talked about snapping points preview near the cursor radius ...
that is to say that if they appear with a gradient effect, you have no overflow. and you quickly know where the snapping point is.

An other applications that adopt this technique, it works great.

In D5546#126815, @noki paike (amonpaike) wrote:

In D5546#126784, @Vitalii Vlasov (Fracture128) wrote:

+1 for snapping points preview.

...becomes practically essential as soon as the geometry starts to increase ...

This looks to be getting in the way too much. Maybe offset that icon from the mouse cursor so that it doesn't overlap the snapped element, or just display it in the header.

One thing to keep in mind is that menu items can be selected with "mouse release" events and "key release" events as well (hold spacebar, release with mouse cursor over an item to select it).

This is the same as T49029 I think. This happens with all kinds of menus as far as I know : lists, popovers, pies. It would be nice to allow them to be drawn partly offscreen.

Concerning that last screenshot, I'd like to suggest making the filter toggle a button of its own, with an arrow for expanding the popover, similar to how overlays and shading popovers work. Simply toggling the filtering is then more straightforward and it doesn't take much more space.

It's a small thing, but what it's worth I find the 'parent directory' item (...) really handy for navigating : no need to move the cursor over the address field, it's right there... I had this thingy on my Fedora's file browser (I think it might have been Dolphin...) not so long ago - any plans to replace it with clickable breadcrumbs, or some other contraption...?

If the user wishes to ‘freeze’ the node tree, they can do so by running a ‘Freeze Nodes’ operator, or by going to Edit Mode, which will automatically prompt the user to freeze the mesh.

That doesn't have to be the case, as any operator called from within Edit Mode could add a corresponding node to the tree instead, keeping the process non-destructive. It's also important to be able to access edit mode to just select components (points, faces) to work on, or to simply transform a selection. Such an operation could be stored in a 'transform' node.

In T65426#693928, @William Reynish (billreynish) wrote:

Following your steps, the mirror effect looks normal.

However, if you add more steps, such as rotating the empty, then indeed there seems to be an issue

In T56744#693209, @William Reynish (billreynish) wrote:

@Hadrien Brissaud (hadrien) Hopefully yes, this is an area that can improve - especially with dynamic brush previews.

Is this going to be worked on further or is it considered final ? (brushes as tools, global brush palette)

Pressing F2 could pop up a window with two fields (label & name), auto focusing the label field ?

I agree that having enum items jump positions depending on which one is currently active does not seem desireable (what Brecht says), but I have no experience using this, am only judging from the captures provided above. An indicator however would be most welcome, either in the form of a checkmark or a dot at the rightmost edge of selected enum item, or a different background color.

Nice addition, thanks ! Can't versioning code take care of updating drivers on scalein/scaleout ? Or maybe it's simply possible through python (not familiar with this area).

Also, even for LMB select, we could keep Ctrl-RMB as an alternative way to scrub anywhere. But it’s too hidden to be the only way, and requires using a modifier key.

This is fantastic, mad props. :) Does it also apply to copy rotate constraint ?

That looks very nice, great proposal. Probably out of the scope of this task, a way to set a custom falloff curve would be welcome at some point too.

For the record, it's been swinged at before : https://developer.blender.org/T40059

In D3869#94718, @Campbell Barton (campbellbarton) wrote:

You're valuing perceived consistency above typical workflows and down sides of making users have to re-consider these options when they switch between editing different objects.

2: Select all items in-between when holding shift / select individual items by holding Ctrl.
When holding shift to select multiple items, we can select all the items in between.
Users can then use Ctrl to select individual items without the ones in between.

Alright my bad.

In D4123#93672, @Harley Acheson (harley) wrote:

Perhaps based on the difference between the header width and the totals of all the items’ current widths, so the current amount of empty space on the header.

Could it be handled by the new adaptive layout engine (the one from preferences editor) ?

There could be an auto-hide thingy that shows the button text when it has enough space, and shrinks down to a simple arrow when the viewport is resized ?

Mesh edit mode menus are singular (vertex, edge, face), so maybe have those be singular as well (control point, segment) ?

Very good point. I also use a tablet exclusively (forearm injury prevents me from using a mouse for longer periods of time) and this has been one of my pet peeves. The popovers could also benefit from being scrollable - I am mainly thinking of overlays, as it can quickly get very lengthy, but this is also valid for the new collection visibility popover : I expect with complex scenes it might quickly overflow as well.

I understand that you argue in favor of making more settings available to more brush types - I consider this can only be a good thing ! However I also understood that in your line of thought this brought along the deletion of many brushes from the toolbar/quick-access/whatever because of their similarity to one another. Let me know if I misunderstood. To me, this would be ill-advised because being able to make several very different brush presets from a single brush-type/tool does not justify not making those readily available in the first place.

In T56744#555946, @Julien Kaspar (JulienKaspar) wrote:

I am aware that there are more settings under the hood that make the Tools different but these are very simple and artificial.
You can still make a Clay Strips brush out of a Clay brush. There is not need to make these 2 separate Tools.

Hey, this is obviously going in the right direction, but I would like to add this : having tool presets appear in the viewport toolbar would be fantastic (in a tab, or in a retractable part of the region).

Just want to say this is a fantastic idea !

Just chiming in to suggest making this optional. I really don't want to have to look at this while animating, it looks extremely busy.

Two remarks from reading this discussion :

I hate to nag you guys about this, but seeing as there's work on including pie menus in default 2.8 config -which imho is a good move- it seems the right moment to do so. If there was any chance this could be looked at it would be neat. Let me know if it needs clarification.

In rBbf4ce5755f3699105a1e97793db63f9fc8f7ad9a#184634, @Clément Foucault (fclem) wrote:

In rBbf4ce5755f3699105a1e97793db63f9fc8f7ad9a#184631, @Hadrien Brissaud (hadrien) wrote:

Great ! Is this using merwin's technique ? (suposedly preventing zfighting)

https://youtu.be/MD7MU-UVG2U?t=13m41s

Well I wouldn't call it merwin's technique but yes it's the same idea :)

Great ! Is this using merwin's technique ? (suposedly preventing zfighting)

https://youtu.be/MD7MU-UVG2U?t=13m41s

Ok thanks for the clarification. I am not really convinced this is an improvement over an overlapping toolbar (as with the T region), but let's see it shaping up !

Alright ! Is it meant to stay visible when an editor is maximized ?
How does it know which settings to show if two editors are open side by side ? Or is there only one tool active at a time ?
Is it also meant to host settings for the "simpler" tools like knife, etc (which have only a handful of checkboxes) ?

In T55043#504103, @PawelP (Zuorion) wrote:

In T55043#503960, @Hadrien Brissaud (hadrien) wrote:

It seems like this is essentially moving the T region to the right-hand-side ?

"T" and "N" are (Just press F5 while mouseover panel) and should remain flippable

It seems like this is essentially moving the T region to the right-hand-side ?

Not sure why groups are kept around actually, wouldn't collections completely fill the functionality gap ?
As for the three horizontal lines, don't you think it's really too generic ? As you say, it could evoke stacked layers, or pretty much anything else... additionally it is quite connoted because this design is used more and more on the web and in other programs (Firefox comes to mind), and in those other contexts it usually means "menu" or "more...".

I like the cardboard box one (4 or 5). I also like the first one but the icon for "group" already looks like a group of objects (a sphere and a box) and having a group of three objects as the icon for collections is a bit confusing.
Having all collection-related icons in a different color could also make sense - after all we already have a color code within the outliner : orange (objects), grey (data), blue (modifiers). Why not have them in say, green ? It could also help differentiate at a glance what is a collection and what is an object (color stands out more immediately than shape, I think).

This is really, really great. Do you think it is doable for the graph editor as well ?
https://blender.community/c/rightclickselect/P0bbbc/snap-toggle-in-graph-editor (see mockup)