- User Since
- Feb 6 2013, 7:05 PM (386 w, 6 d)
Thu, Jul 2
Wed, Jul 1
Mon, Jun 29
Indeed. It would be nice to support snapping to along a different axis than the transform axis though. (Non-orthogonal snapping)
Thu, Jun 18
Thu, Jun 11
Wed, Jun 10
Tue, Jun 9
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").
Jun 6 2020
May 25 2020
May 6 2020
Apr 16 2020
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.
Apr 14 2020
Thanks for the merge I wasn't sure the issue affected all modifiers.
Apr 12 2020
Apr 6 2020
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).
Mar 31 2020
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.
Mar 23 2020
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.
Mar 22 2020
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.
Mar 21 2020
@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).
Mar 20 2020
@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 :
- give the choice of component type, so that following node can act on either, say, new faces or new edges, such as bevel
- split into several groups when relevant, *eg* extrusion tip and sides
Mar 13 2020
Feb 24 2020
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.
Feb 13 2020
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 ?
Jan 16 2020
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.
Jan 14 2020
Dec 10 2019
Dec 3 2019
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 ?
Dec 1 2019
Nov 30 2019
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.
Nov 23 2019
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 ?
Nov 8 2019
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.
Oct 2 2019
@Brecht Van Lommel (brecht) Why not simply write them as xml instead of inside a blend file ?
Sep 30 2019
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.
Sep 25 2019
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.
Sep 20 2019
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 !
Sep 4 2019
Sep 3 2019
@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.
Aug 30 2019
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 ?
Aug 26 2019
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.
Aug 22 2019
Aug 21 2019
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.
Aug 20 2019
Aug 8 2019
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).
Aug 5 2019
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.
Jul 25 2019
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.
Jul 23 2019
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...?
Jul 17 2019
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.
Jul 5 2019
Jun 3 2019
Jun 2 2019
Jun 1 2019
Is this going to be worked on further or is it considered final ? (brushes as tools, global brush palette)
May 23 2019
May 8 2019
May 7 2019
Pressing F2 could pop up a window with two fields (label & name), auto focusing the label field ?
May 6 2019
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.
Apr 24 2019
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).
Apr 14 2019
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 ?
Feb 16 2019
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.
Jan 24 2019
Jan 21 2019
For the record, it's been swinged at before : https://developer.blender.org/T40059
Jan 14 2019
Jan 12 2019
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.
Jan 8 2019
Alright my bad.
Jan 7 2019
Dec 29 2018
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 ?
Dec 8 2018
Mesh edit mode menus are singular (vertex, edge, face), so maybe have those be singular as well (control point, segment) ?
Nov 20 2018
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.
Nov 19 2018
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.
Nov 15 2018
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).
Oct 29 2018
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.
Oct 2 2018
Two remarks from reading this discussion :
Jun 20 2018
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.
May 31 2018
Great ! Is this using merwin's technique ? (suposedly preventing zfighting)
May 21 2018
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) ?
May 20 2018
It seems like this is essentially moving the T region to the right-hand-side ?
Jan 23 2018
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...".
Jan 22 2018
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).
Jan 16 2018
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)