Converting Modifiers to Nodes #86839
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
35 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#86839
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Benefits
Geometry nodes offer increase flexibility and improved usability compared with modifiers:
Conclusions
General Questions
Functionality Available
indexexpression / attribute.Functionality Mostly Available
Ready to Implement
There are no open design questions, but there may be code architecture questions to answer before work starts.
For example, modifiers generally retrieve weights from vertex groups, but geometry nodes do not create vertex groups.
Whenever a problem like this comes up, sometimes it's possible to share code,
but it often makes more sense to rewrite or "duplicate" code, with the eventual aim of replacing the modifier anyway.
Needs Design
More design work is required to figure out the best solution for these modifiers,
or stakeholder artists who can provide a better view of the use cases these modifiers address,
or input from other developers.
Requires "Binding"
Nodes will need a way to store data for use later-- currently they cannot.
That should be designed first as a general idea before these nodes are implemented.
Simulation
These are modifiers that should tie into a more generalized simulation system.
Most of the code can be reused in many cases like Mantaflow, but a direct copy from the modifier
to a node would not make sense, and needs design for how node-based simulation should work.
Not to be Replaced
These are modifiers with a design that does not fit into the goals for geometry nodes.
For example, the multi-resolution modifier must be the first, and is more of a specific tool
for sculpt mode than a modifier "function."
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscriber: @HooglyBoogly
Added subscriber: @Erindale
Added subscriber: @zNight
Added subscriber: @MiroHorvath
Added subscriber: @KenzieMac130
Added subscriber: @ostry
Added subscriber: @zanqdo
Added subscriber: @NoBlahBlah
Stakeholder for shrinkwrap here. Some of the many use cases of the modifier involve - Retopology , very quickly making clothing items, using it in conjunction with vertex proximity also enables many interesting applications especially now with geometry nodes thanks to the ability to do arbitrary math with vertex weights. And i imagine as a node you may also be able to use it for example to squeeze out information about other objects. For example once it has shrinkwrapped i can just read out the position or normals attribute etc etc and do god knows how many things with it. The sky is the limit really, once you have a way to pass information between arbitrary things like this, just like how you guys pass around all kinds of data in your function calls. Not exactly standard use case i know but good food for thought none the less.
Edit: Didn't read about the "Attribute transfer node" discard the last point i guess. The rest still stands though.
Added subscriber: @FabianSchempp
Added subscriber: @ckohl_art
Added subscriber: @Keavon
The Array modifier is probably the most common modifier used in Blender. Even though it's a duplicate of functionality that is possible already in the geometry node graph, a standalone Array node should absolutely exist for convenience and clarity of understanding to people transitioning to geometry nodes. It's generally good to avoid redundancy but redundancy is helpful in some circumstances such as here. It definitely should not be out of scope for conversion from a modifier to a node; instead, it's probably low-hanging fruit for easily completing.
Added subscriber: @Calra
The same could be said about the mirror modifier, in fact: its even more specific with clipping feeding back to edit mode. But I would avoid recreating the mirror modifier as a node and instead break it down to it's base parts and address the clipping issue.
When every modifier is ported to nodes the user will already have access to a list of examples by being able to inspect the node contents of the added modifier. It would probably be best to make the most use of atomic nodes as reasonable.
Added subscriber: @victorlouis
Another stakeholder for shrinkwrap here... Ability to stick(snap) objects to terrain is an essential feature for landscapes creation. I'm talking about the scenario when terrain object isn't the instancer, but rather the target object to snap instances to. To achieve this behaviour user just need to set Wrap Method to Project(Z-axis), here are two examples:
I discussed the need for such functionality within GeoNodes before with @HooglyBoogly and @victorlouis and we came to conclusion that such functionality can be covered by a separate Raycast node which would, for each instance, return:
...basically what raycast allows us to do with Python API.
Added subscriber: @mv.artz
Unless there's a really fancy way of doing calculus that i never knew about i am guessing in order to be able to implement Laplacian smooth/deform you are going to need some way of getting (and maybe even setting) data from neighbors, in which case it might be better to expose that functionality directly in geometry nodes. Functionality like this could also be useful for particle nodes example for creating boids based simulations.
Added subscriber: @Jamesmp
Added subscriber: @Grady
I would like to propose discussion about the merits of a dedicated 'Displace' node.
It makes sense to me that I can do 'displacement' by doing some attribute maths like this...
.. that might not make sense to someone who doesn't know, for example, that you can just scale a normal and add it to a position to move the vertex outwards. having a dedicated 'Displace' node to 'abstract' that kind of logic could be a worthwhile UX improvement.
I would like to second that. Again, while it may be 'possible' to recreate some of this functionality with enough nodes and problem solving, I believe that common needs should be quickly available and easily accessible to avoid creating unnecessary extra work for fairly common requirements like wanting a grid of 10x10 copies of something.
As for the previous suggestion about a raycast node, can't support that idea enough, that would be exceptionally useful for a bunch of very clever node logic to automate placement of objects.
Added subscriber: @Aeraglyx
Added subscriber: @PhlixFer
Added subscriber: @SecuoyaEx
The Mask modifier now has the smooth mask option, so delete geometry alone won't do. Mask should be put up back in the list as todo, maybe a different node?
Removed subscriber: @SecuoyaEx
Added subscriber: @Yuro
Added subscriber: @Dangry
Added subscriber: @sozap
Added subscriber: @Michael-Drake
Added subscriber: @BClark
Added subscriber: @mod_moder
Added subscriber: @JacobMerrill-1
I have been able to create a 'smart 2d project shrink wrap' using geonodes
it's very nice for terrain that snaps to roads / foundations for buildings
Added subscriber: @cmzw
Added subscriber: @dabo
Added subscriber: @hzuika
Added subscriber: @winorier
Added subscriber: @emilis
Added subscriber: @vasiln
Coming here from https://developer.blender.org/T99197 . Note that vertex groups are used in Blender for far more than modifiers; one example would be as targets of constraints. Attributes may have improved flexibility over VGs at some point down the line, but for the near future, the rest of Blender isn't built around them, which severely limits what can be done with meshes that can only use attributes. There are plenty of similar issues with GN meshes playing nicely with other features, for example trying to use a GN generated curve for follow path or spline IK. This plan seems like a very, very long path to me.
Vertex group modifiers, such as a data transfer, are also important because vertex groups are currently exportable, while attributes are not. Anyone that wants to render someplace else-- typically, a game engine-- cares about vertex groups. As an example of someplace where I've found both great potential and great frustration with GN, I loved that I could keep various mesh bits as separate objects for different modifiers, then instance to a single object and join as shapes to my last realized instance, which simplified shapekey generation enough that I could put more work into the art, but I hated the fact that I lost all my UV and VGs on those realized instances, and recovery of those was not necessarily convenient.
My comments on how I use modifiers, especially focused on things I'm scared of losing, and sometimes, things I'm scared of keeping:
I could build an armature modifier in GN today (well, it would take me more than a day) but it would be a nightmare, and it would be a per-armature thing. It is hard for me to imagine that an armature modifier could be anything other than a single node receiving a geometry and an object (armature) input. Not without major changes to interface. It would be nice to be able to do modifications on multiple VGs at once, perhaps discarding all that lacked a particular text string, or doing math but only all that also existed on some input object, but it's hard to imagine that would fit into GN as it currently exists.
While shrinkwraps can be done right now, all of the options lead to pretty different looking node groups, and the modifier interface is preferable. I suppose a single "shrinkwrap" node, to contain all those options (all of which are important) would improve usability. I know I have concerns about performance whenever I think about building a one-size-fits-all shrinkwrap node group. SW can already be very expensive.
While I have used skin extensively for quick work, I have gotten much more in the habit of mesh->curve->mesh via GN. I do wish that skin radius could be provided as an attribute, or converted from an attribute, to make it easier to change. That's not to say that a mesh->curve->mesh is the same as a skin, they're very different in some cases. It would be nice to be able to combine the two in GN to take advantage of skin branching with the consistent topology of curves, and any implementation might consider controls/attributes for the skin (like rotation about generating edge) that made welds convenient. Skin modifier tries to be too smart regarding root assignment, leading to unskinned meshes when it follows a mask modifier that separates strings of verts, and I would advise against copying that part of it.
One of the hidden but great uses of corrective smooth is to use at a weird scale, which acts much like a Laplacian Smooth but is a million times faster, and I now consider the scale parameter to be an essential part of the modifier.
My main use case for wireframe is to make 0 area faces that I can shrinkwrap to. Transfer attribute accepting a "nearest edge interpolated" mode would eliminate my most frequent need. For other modifiers targeting this one, it's important that zero-area be an option.
UV Warp seems obvious to me; if we could output UV, it's just math. My main use case is currently as a workaround to turn GN UV attribute into exportable, real UV, by turning the attribute UV into VGs that I can then use to control the UV warp.
In terms of binding, I'm already creating bind data in GN as it stands by saving data in attributes, or by creating proxy meshes with those appropriate attributes and then copying by index. Note that it isn't technically necessary to bind to the same object as you then use to deform, and that there are sometimes good reasons to bind from something different (but of course, with same topo.) Sometimes, you can trick Blender into doing this with current modifier implementations, but mostly it won't let you.
Consider that you don't necessarily have to bind or deform to position. As an example of why you might not, consider recent changes to surface deform to allow it to (kinda) still work after changes of subdivision to the target. We very well may want to deform from a position backed up as an attribute before we did some other thing.
Mesh deform (dynamic bind) and surface deform are my most used modifiers outside of armature and subdivision. Surface deform code could be smarter by doing an implicit, fixed triangulation of both meshes, which improves the likelihood of a successful bind. Mesh deform bind has no "sparse bind" option and is always sparse, which is a problem; one irritation in its use is having to scale stuff up really big in object mode just to get everything to bind and then reset the scale on the deformer. (This is one reason to prefer separate bind and deform objects, because it can often be hard to restore the original bind position of the deformer.) For curves, its important that handles and controls be able to be bound separately: one of the failings of the current modifier system for curves is that handles get bound as if they were vertices, but it would be better to turn them into infinitesimals, bind and deform, and then restore their length after deformation (it is very easy to have curves that you just can't mesh deform right because their handles can't fit in your deformer.) It would also be very handy to be able to treat tilt as a similar (infinitesimal) vector and deform it along with the controls and handles.
A normal edit modifier is already doable with a shader attribute node, and it worked fine. The painful part was not getting to use all the default normal inputs in the shader. Flipping faces in strange ways is usually desirable to prevent interpolation through 0 vector along the face. If trying to handle via custom normals, I would pay careful attention to how a custom normal handled strange, 180 degree interpolations relative to vertex normals, because it's unlikely to be a situation that's been well-tested.
A hook modifier "binds" in two ways. One, it uses assignment to modulate the modifier. This doesn't have to be done in GN, because it's a redundancy with VGs anyways (and, from people I've helped, seems confusing.) Two, it creates an inverse transform and stores it. The ability to create an inverse transform from current values would be a useful general thing if it could be disassociated from the hook, but the proper way to deal with an inverse is as a 4x4 data type and I don't think you have any of those. Other than the bind, it's just any other simple, interpolated deformation, warp or single bone armature or whatever, which makes it seem like it probably shouldn't get its own specific node....
Modifiers that take curves (say, warp modifier falloff) offer presets like "smooth" and "root" , and it would convenient for users to offer these presets on GN's vector curves/RGB curves nodes.
Added subscriber: @pauanyu_blender
I guess I have one more comment on this plan.
It's not impossible to get the best of both worlds-- the convenience, interface, and performance of modifiers, along with the flexibility of geometry nodes-- by creating GN modifiers as built-in node groups rather than as monolithic nodes.
Let's imagine the user wants a shrinkwrap. They add a node, search, get a shrinkwrap node. This has the exact same options as a shrinkwrap modifier. Later, they decide they want to do something unsupported by those inputs. Let's say they want to use an attribute to determine in which axis the shrinkwrap projects. They then tab into that shrinkwrap node and adjust the nodes. Yes, they could maintain a library of geometry nodes to achieve the same thing, but that's not realistic; users aren't going to all maintain some pristine library of GN groups. And there are circumstances where even if they did, it wouldn't help them, like a conceivable Armature node:
Imagine a single Armature node that recreates the Armature modifier. Before anyone tabs into it, it refers to one particular block of code-- but upon tabbing, a script is run that creates the lower-level data as nodes, using the input armature as a parameter for that script. The resulting nodes are not necessarily very easy to edit, but they are as flexible as one could ever wish for. (We could also imagine the deconstructed Armature uses further built-in subgroups, like "matrix multiply," to allow users to find some balance between usability and flexibility between those two extremes.)
I think it's important to remember that the benefit of GN is not really their flexibility. It is their usability. Any mesh that can be made with GN can be made with traditional techniques, because traditional techniques can make (and animate) every polygonal mesh. It's always possible, not always realistic, but that's because of usability. The benefit to GN is when they allow that mesh to be made more easily, more performant, or with a smaller memory footprint. It's "more easily" that counts the most, because computers are cheaper than people.
Added subscriber: @Stephan-Kellermayr
Added subscriber: @GeorgiaPacific
Added subscriber: @Harry-Kunz