I’m starting this post to talk about Blender modifiers.
If it’s not at the good place, feel free to move it or to remove it.
So, Modifiers, can a dev tell me if it’s possible to talk about and to try to make proposals to improve current modifiers and also, why not to add new modifiers, but like Bretch said, it’s not a request forum.
Maybe you could tell us how you see all of that with the next everything nodes etc.
I know some people who are afraid of losing the modifier stack for example.
So, to improve modifiers, we could list things modifiers miss (vgroups, revert vgroup), things that are broken, find better ways to make a modifier more user friendly, etc.
no selection groups vert/edge/face available in blender at all. not only for modifiers. except maybe for vertex groups or face groups(this wasn’t intended to be used like that)
there is no way to call a regular operator from a generic modifier. we would not have this discution if that would be possible
modifier middleware api to run python at different states during modifier execution. e.g. change the vertex color before rendering of the active mesh wihle in edit mode for certain objects. This one might be a stretch and I am pretty sure that the current blender architecture is not supporting something like this
Adding a generic modifier with python support is very easy. Most operators in blender can be executed in user defined context(this stuff is documented). So, the only chalengehere is to actually imlement an empty modifier and call the ‘execute’ method you define in python and collect the output object from there. Everything else stays the same, edit mode behavoir, etc. Maybe a small task here is to add custom prams to this modifier, but even that is very easy to do
You are correct that this forum is not intended as a feature request forum. The best place to get started about working out proposals for improvements and even new functionality would be rightclickselect.com. Once you think you have got a solid proposal you can poke devs to see how this can be slotted into the development process. You can poke me here when you do have proposals ready, either with an @-mention in a public post or through a PM here on devtalk. I can help connecting you to the relevant devs when the time is ripe.
The other devs have said several times that they are not opposed to the idea of adding edge groups to Blender. I imagine the same goes for face groups. It’s just a matter of someone prioritizing doing that.
An edge is indicating a direction, can contribute to a path, be converted to a curve or an element of a boundary. As is, they are used for lots of things as UVseams, cloth sewing seams, sharp edges, freestyle edges, etc…
A face map can be different from a vertex group using same vertices because of edges at is boundary.
So, useful info is a property of edges more than faces.
For those reasons, I think that simply rethinking modifiers to make them able to exploit edge groups will improve existing ones, prepare people mind to transition to a node system that would have such abilities and beyond and simplify management of our current system of edge properties.
Blender modifiers stack lacks so many basic things like drag & drop ,copy a modifier from one object to another or multiples, a single modifier affecting multiple objects and so on, lets fix the basic functionalities first before adding new modifiers.
I’d like to request the following for the Subdivision (Surface) modifier:
Please make 1 subdivision the default for both viewport and rendering, in stead of 1 for viewport and 2 for rendering.
Please add a lock button that’s on by default, so you only need to click once to increase both viewport and rendering subdivisions.
If you want different subdivisions for each, you can press the lock button to unlock the values.
I’ll just mirror my remark from RCS that really (2) alone should be sufficient, as with lock (1) doesn’t matter and without lock you want the values to be different anyway
If you keep the current default values, clicking the counter with the lock active would result in rendering always being one iteration higher, while I’d like the rendering value to remain equal to the viewport as long as the lock is active. The lock is meant to keep the relationship of the values intact, not to discard the rendering value.
I agree about the default. To me, both values should be the same by default.
That would be more coherent with intention of 2.8 design to make viewport the more WYSIWYG as possible.
In practice, we can click and drag to modify both values, at same time.
But the idea of a lock option could make sense for shortcuts. Currently, they are only modifying viewport level.
Hello, I already gave feedback on the 2.92 modifier’s “active state” feature in the geometry nodes thread since the feature was created inside its development, but I’ll continue in this thread for more accuracy.
The issue I reported was that setting the active modifier was quite limited by the few places where you could click to make it active: Geometry Nodes
I’m happy that the devs listened to it, as a partial fix was commited (https://developer.blender.org/rBe845467d93fe35e222d14b0bb27472ccb309b321), but unfortunately I think it still doesn’t completely solve the issue, since clicking on checkboxes or modifying values, editing the modifier’s name, opening drop-down menus or clicking on the animate decorators still doesn’t make it active.
I rely a lot on the modifer’s hotkeys, which before 2.92 work on hover, and having still such a limited amount of instances to set the active modifer slows down a lot the process, as I have to know and precisely click on a point to set the active state.
I’m happy the devs partially covered the issue, but until the active state won’t become more resposive and able to be set up in basically every area of the modifier, it will continue to be a slow and painful process to do every time.
No thread on Modifiers (and geometry nodes) should proceed without mentioning an edit poly/ mesh modifier…
I’ll show myself the way to the exit now
Ontopic: The future of nodes and geometry nodes should be a coexistence of the two, where geometry nodes can be turned into modifiers. Modifiers haven’t been used to their fullest potential yet, neither in Blender nor other DCCs. If only you could create a modifier UI alongside a custom node setup, because it’ll be difficult to autopopulate one. A possible solution is along the lines of the HumanUI plugin in GH.
E: Selection pass through (even as vertex groups) makes sense within a modifier stack too, since you won’t have to fiddle around in the object’s properties. Instead the workflow converges within the modifier stack. Though certainly vertex groups could also be propagated back to the object properties. Redundancy would be a strength in that regard.
It would be great if Blender could incorporate the Apply Scale with Modifiers add-on or even better: implement the add-on’s functionality as a native tool.
Apply Scale with Modifiers automatically corrects modifier values when you apply a scale. It adds an entry to the default Control + A shortcut menu, and is extremely useful if you’ve got one or more modifiers on an object with values that depend on world units / values that are relative to the object’s scale factor, such as the Solidify, Bevel and Skin modifier. Currently, when you Apply Scale on such objects, you need to manually correct the modifier values, which is a tedious process.
Additionally or alternatively, a toggle between absolute or relative modifier values could be implemented as an option in the Preferences and/or in each modifier.
I don’t know the addon.
But I would prefer an option in modifier to an operator that has to be recalled at each change.
IMO, there should be a toggle to make effect of modifier Absolute or Relative.
When modifier is absolute, whatever object’s scale is, modifier’s effect is respecting measures in world space. So if object is scaled, geometry is changed, object is looking different in viewport.
When modifier is relative to object’s scale, whatever object’s scale is ; object is looking the same in viewport, just bigger or smaller.
and I am pretty sure that the current blender architecture is not supporting something like this
If you keep the current default values, clicking the counter with the lock active would result in rendering always being one iteration higher, while I’d like the rendering value to remain equal to the viewport as long as the lock is active. The lock is meant to keep the relationship of the values intact, not to discard the rendering value.