Freeze modifier to allow intermediate stack manual edits - Non-Destructive workflow
This has been a long requested idea, something that users from other softwares like Houdini or Max are used to , and it's a workflow that increases the procedurality and non-destructive way of working with meshes, I'll put the explanation below.
I think this is now possible thanks to the concept of "Active Modifier"
I'll illustrate this workflow with a description of some actions with an object:
1.- You have a simple cube
2.- You add a subdivision surface modifier with 2 subdivisions, now you have a spehere
3.- You apply a modifier that “freezes” in memory the current state of the mesh after those two modifiers and then allows you to enter into Edit Mode for that state.
4.- Right now in edit mode you are not editing a cube anymore, but the sphere that you got as a result.
5.- You pick some faces of that sphere and make an extrude
6.- You go out of edit mode
7.- you apply a bevel modifier, there you see some corners being glitched, something that you cannot solve with the modifier or without applying the modifier
8.- You apply the “freeze” modifier again
9.- When you enter edit mode you are able to edit the beveled geometry, being able to do manual fixing of things like interxecting corners and such things.
So basically it’s a procedural way of interleaving manual work that will a llow a much more precise modification of the object, and since we have now the “Active Modifier” concept, I think this is way more feasible now.
¿What happens when you delete the first “freeze” modifier or the first subdivison surface modifier?
Well, obviously the fully procedural modifiers will act as they are expected to, but the second “freeze” modifier will generate a mess in the mesh, why? because the vertex order changed, and there will be some vertices/edges/faces missing.
Is that a show stopper? Not at all, you should know that this may happen and as a user learn to work with this modifier.
What does this brings to the table?
A workflow that is currently impossible with Blender, a fully procedural workflow with manual fixing done by the artist.
This also affects other things, like having UV’s at different “freeze” levels, like with the first “freeze” modifier you can edit the first UV channel, then go to the second “freeze” level and edit the second UV channel to do some specific UV adaptation for a precise texture or shader.
What happens with the newly created geometry by the second “freeze” modifier in the first uv channel?
Those are new vertices and since they don’t exist they should be collapsed in the 0,0 of the UV space, however, that UV channel could be edited at any time, for example with the second “freeze” modifier, to correctly unwrap those vertices.
In the end you get exactly the same, after evaluating all the stack you have an object with several UV channels and other properties, and the “valid” one outside of Edit Mode is the result of the latest evaluated modifer, as it happens right now.
The only real new thing here is that the “freeze” modifier allows you to make edit in intermediate steps of the modifier stack instead of allowing you to edit just in the basis of the modifier stack like right now.
35 Comments
Yes, please! Been waiting for such a feature for many years. Sure, removing the modifier would break things... but the possibility of manual adjustments between modifiers is VERY useful, with the knowledge that the fully procedural workflow may suffer if changed.
A warning sign could be added saying that deleting the modifier may break modifiers on top.
Sometimes, there is a little vertex that goes the wrong way after using several modifiers... this would be awesome to be able to just move that vertex, instead of having to apply all modifiers just for that one vertex.
Its kinda possible now with the "Edit Mesh" modifer in the Modifier List addon: extensions.blender.org/add-ons/modifier-list-fork/
Aka the edit poly modifier in 3DS. This has been requested many times, but this one is the most detailed I can remember!
One important thing when designing new features for Blender is to try to avoid mentioning any kind of third party software, it should be a clean and agnostic description to avoid any Copyright problem.
It’s not exactly the same since Edit Poly has its own set of tools that are slightly different (from time to time) from the editable poly toolset, but I get your point and yes, one of the most requiested features, just that I think that now is way more plausible and possible :)
mentioning is fine, linking or screenshotting is verboten. devtalk.blender.org/t/copyright-guidelines-for-devtalk/17331
(smartass mode) and on RCS it's not even prohibited, either since this isn't an official developer Plattform. It's a community like Blender Artists where pretty much anything can be named or discussed within reason. It just can't find its way into the developer forum.
I know, but I better prefer to fully avoid references to other softwares, this is because developers understand it better if the description is detailed, and why you may know other software to the bnones the developer don't so that screenshot that could be super explanatory for you may mean nothing for teh developer or even may confuse the developer.
In your example: “Maya’s layer system offers overrides”, you first have to explain what Maya's layer system is, how does it work and why is it better or worse than what it's present in Blender, after that you have to explain what overrides means in Maya, what kind of override or how does it affect to the layer, and what are their benefits or limitations, in the end I think it's more work than just giving a more agnostic explanation without referring to a third party software :)
So it's a better practice IMHO to avoid mentioning other software and to give the best description possible in "blender terms"
Mentioning something available in other software is relevant in many cases so the devs know it even exists, such as the SubD differences between Maya and Blender. Maya has objectively better SubD since it retains the volume of the object while Blender erratically reduces it, for example.
The other issue is software compatibility. Blender doesn't have the luxury to ignore professional pipelines anymore, and over time it's adopted a lot of functionality from leading software to its benefit.
The copyright concerns around screenshots are perfectly valid, but users need to be able to discuss "Competing" software and devs need to acknowledge what they do better. Blender hasn't survived in isolation.
I think the issue with volume differences in SubD were fixed (there is an option in the modifier) in the latest Blender versions, but I may be wrong.
@SpookyDoom
True, but often a developer will refer back to the RCS thread in patch notes or forum posts, it's cleaner to treat this like an official blender site, if nothing else to give it the credibility that would encourage developers to pull ideas from here.
so yeah, no official rule on RCS (yet) but there's a strong desire for parity.
I get your point, and for some things may be useful, in this case I prefer to not do it, there is no need for it.
Also when using other software implementation you may fall into the same problems the other software has, that’s why I prefer to make the full description instead of referring to other softwares :)
I've been wanting this for so long.
Since the focus concerning modifiers lately has been in geometry nodes (and most modifiers--for sure all of the modifiers' functionalities in some way or another--are planned to be eventually ported to geometry nodes with the plan to eventually move entirely to the node editor and not even need the stack-based modifiers), it might be even better to present this as a node.
There's one huge hurdle, though, to overcome for the freeze modifier to work, and I don't know how the developers would overcome it: whenever geometry is added or removed in edit mode before the application of the freeze modifier, how will the modifiers after the freeze modifier keep track of what geometry is what? I have no idea how vertex IDs are managed under the hood. I'm sure there's a way to handle this (especially given that other softwares have found a way), but I'll bet this is a huge part of why we don't have this feature yet.
Another thing to think about is that this modifier will likely come at a huge memory price tag when used with huge complex modifier/node setups, as it will be baking everything that came before it into raw geometry data, totally nullifying any memory shortcuts that were being taken by instancing geometry before its (the freeze modifier/node's) application. Definitely not a show stopper, as it will still offer the non-destructive editing advantage (and we all love those), but just something to consider for users who are depending on the memory conservation by instancing stuff in their modifier/node setup.
They won’t, the rest of the stack is applied blindly, so if you modify the underlying geometry the rest of the stack may produce undesired results, but that’s expected, the user should be aware, I explain this case in the description
What's the difference then between adding this modifier at a certain point vs simply applying (as in making permanent) all the modifiers up to that point?
That you maintain the original geometry and everything is procedural, you can go back and forth whenever you want
Also it's good to note that, in addition of keeping everything as much procedural as possible, it allows more interaction like creating vertex groups or editing UVs at X level, whilst everything is still editable. Meaning you can correct UVs after modifiers without the need to bake the geometry, you always have a way back. Ideally if there was a way to export/import data such as UVs and vertex colors/weights, that would make it even stronger.
Finally, if editing the mesh before the modifier might produce undesired results, it also might be an acceptable result, sometimes exactly what you want.
@juangea but you just said you can't go back and make edits before the freeze modifier...
No no, you CAN go back and make changes, however those changes will affect the modifiers ahead.
If you move something everything will work as expected, if you change the vertices count and you have another "freeze" modifier ahead, the operations applied to that other "freeze" modifier may be applied incorrectly, in the end you changed the vertex count and everything depends on the vertices index.
It like it's recording the operations you do in that modifier and they are applied when you evaluate the whole stack.
You can always go back and fix things, but that modification will affect the evaluation ahead too :)
Ah, so moving stuff around is fine, you just can't add or delete stuff. I would still find that somewhat limiting, and it might actually be possible to implement a way to work somewhat with adding and deleting stuff.
Yes please, i thought about something similar many times! Definitely it will keep my workflow from endless copying of a mesh.
I agree. I know we're not there yet but maybe the naming could be more descriptive like "mesh snapshot" or simply "edit mesh" because "freeze" can be associated with masking or blocking behaviors. Note that "edit mesh" is not a registered syntagma.
Good idea, "Edit Mesh State" or something like that could be better, I'll think about it, other ideas welcome, I'll edit the proposale when I decided it in the end, developers will name it sa they want :)
I only will say that we need this.
It's equally interestingas I'd imagine it being sketchy one to maintain, I'd assume.
The only two ways I can imagine right now how a selection could work would be either by an object proximity with falloff or clipping volume within the geometry or by a manual selection, which would probably be based upon vertex numbers. Meaning that when the geometry changes everything about the edits further down the modifier/node hierarchy woud change as well.
Both options are very interesting, I think. With the Proximity or Volume Clipping one being especially interesting in regards to staying procedural.
Why do you refer to a selection?
I have not said anything about maintaining a selection, I think that's already solved with vertext groups and hopefully with face groups.
But in any case, as I said, if you delete one Freeze modifier from the stack, if you changed the vertex count then the restuls won't be correct, but the user should be conscious of this and understand what's happening :)
Yes, I guess I was thinking of an edit mesh modifier but splitting it into an edit mesh and a freeze could actually be more sensible. While the two would probably be used together frequently it's not a necessity.
The thing is that the Edit Poly / Edit Mesh modifier implies that they have an specific Edit mode INSIDE the modifier, that's not "compatible" with Blender workflow itself, that's why I call it "freeze" modifier, but it's not a freeze per-se, just something that enables you to use Edit Mode at a specific stage of the stack evaluation
Great!! I love it. I love the idea of not having to apply the modifiers until the final result, or not applying them at all.
I think that would appear at the same time of long after keymesh is done. But that's indeed needed
Great idea here!!!
this is a test comment because i think comments are currently broken
this will beat max modifier list !!
See "Geometry Checkpoints" code.blender.org/2021/07/nodes-workshop-june-2021/
Aren't you talking about Modifreeze [ for Blender 2.8 ] - Coding / Released Scripts and Themes - Blender Artists Community blenderartists.org/t/modifreeze-for-blender-2-8/1168471 ?
Nope, that’s a clever hack, but a hack, I’m talking about true modifier that enables Edit mode at any step of the modifier stack :)