Check the overview thread for more information about the meeting.
Present
Sean Kim
Hans Goudey
Daniel Bystedt
Julien Kaspar
Thomas Dinges
Announcements
N/A
Feedback Requested
Are there commonly used workflows for Texture Nodes specifically for the various paint modes that we should be aware of? What would need to be added to the PR linked below to fill these usecases?
Since the Last Meeting
Sean - Same as the last few weeks, high priority reports, minor management of the issue queue, and testing goals.
General agreement that changing this to diameter seems sane.
Conclusion: Will make design and add tracking task.
Make UnifiedPaintSettings per mode instead of shared.
Julien thinks this would in general be a good idea.
Grease Pencil Draw Mode is most affected by this.
There’s some other work that would need to be done to really make these settings more useful (i.e. per-brush opt-in / opt-out) but that’s out of scope for this particular task.
Conclusion: Will make todo and add to main tracking task.
Texture Node removal
Probably too soon from 5.0, good to check with the community if this is actually still used.
Doesn’t take a lot of maintenance from a developer POV
Related to the replacement mentioned above, we want to figure out what the migration path is from a user-side.
Conclusion: General plan is to remove dependencies on it in the code side, but full removal soon is unlikely.
Proposal for Enhancing Texture Nodes in Blender
To address the limitations of the current shader node system, we suggest implementing the following improvements inspired by tools like Material Maker and Substance Designer, while referencing features from InstaMAT:
Advanced Procedural Texture Nodes
Introduce nodes for blur, edge detection, high-pass, and sharpen effects to enable higher-level procedural texture creation.
Expand mathematical and convolution operations for greater flexibility in procedural workflows.
Packaged Texture Node Group Assets
Allow users to save complex node setups as reusable “material ball” node group assets (e.g., zippers, fabric patterns).
Ensure these assets support real-time parameter adjustments (e.g., scaling, roughness, color variations) even after packaging.
Integration with Painting Tools
Enable packaged node groups to be used directly in texture painting brushes, affecting multiple channels simultaneously (color, normal, roughness, metalness).
Support future “Paint Layer Nodes” (as hinted by Blender’s roadmap) by allowing node-based materials to drive procedural painting layers.
Game Engine Compatibility
Add a one-click export function to bake node-based materials into standard texture maps (albedo, normal, roughness, metalness, etc.).
Optimize outputs for seamless integration with engines like Unity, Unreal, or Godot.
Real-Time Material Editing
Reference InstaMAT’s workflow, where packaged materials retain editable parameters for non-destructive iteration during asset creation.
*Due to my limited English proficiency, I used AI to help translate and express my ideas.
I found an issue with the translation of my second suggestion: My proposal is that texture nodes can be packaged into material node groups in the final output, and can be used through shader nodes - similar to how material presets exported from Substance Designer are utilized in Substance Painter.
Due to my limited knowledge in computer graphics, I learned through BlenderArtists forum discussions that effects like blur, sharpen, high-pass filtering, and edge detection are challenging to implement with current shader nodes. There are currently no reference projects meeting these requirements for Blender developers to follow. This significantly hinders the advancement of procedural textures in Blender and limits the potential of future official material painting layer nodes. Considering Blender’s texture node system exists as an independent module currently at a crossroads between further development or deprecation, it would be ideal to redesign it with the necessary capabilities to implement these essential functions.
The Compositor can do most of the things you are looking for, but the output would need to be baked. Otherwise, texture painting while executing complex node trees with expensive textures (such as noise) on every stroke step would be prohibitive.
Yes, the other work described is still be needed - the main motivation for tackling the radius / size change for 5.0 is that it’s pretty invasive and difficult to fit into a normal release without causing versioning incompatibilities.