Blender Developers Blog: Recent Episodes

View Details

Wing it! Early NPR project by Blender Studio.In July 2024 the NPR (Non-Photorealistic Rendering) project officially started, with a workshop with Dillon Goo Studio and Blender developers.

While the use-cases were clear, the architecture and overall design were not. To help with this, the team started working in a prototype containing many shading features essential to the NPR workflow (such as filter support, custom shading, and AOV access).

Exploring the new Blender NPR Branch by Azra ReyesThis prototype received a lot of attention, with users contributing a lot of nice examples of what is possible with such system. The feedback showed that there is a big interest from the community for a wide range of effects.

However the amount of flexibity made possible with the prototype came with a cost: it locked NPR features within EEVEE, alienating Cycles from part of the NPR pipeline. It also deviated from the EEVEE architecture, which could limit future feature development.

After much consideration, the design was modified to address these core issues. The outcome can be summarized as:

• Move filters and color modification to a multi-stage compositing workflow.
• Keep shading features inside the renderer’s material system.

Multi-stage compositingOne of the core feature needed for NPR is the ability to access and modify the shaded pixels.

Doing it inside a render engine has been notoriously difficult. The current way of doing it inside EEVEE is to use the ShaderToRGB node, which comes with a lot of limitations. In Cycles, limited effects can be achieved using custom OSL nodes.

As a result, in production pipeline, this is often done through very cumbersome and time consuming scene-wide compositing. The major downside is that all asset specific compositing needs to be manually merged and managed inside the scene compositor.

Instead, the parts of the compositing pipeline that are specific to a certain asset should be defined at the asset level. The reasoning is that these compositing nodes define the appearance of this asset and should be shared between scene.

Multi-stage compositing is just that! A part of the compositing pipeline is linked to a specific object or material. This part receives the rendered color as well as its AOVs and render passes as input, and output the modified rendered color.

The object level compositor at the bottom right define the final appearance of the objectIn this example the appearance of the Suzanne object is defined at the object level inside its asset file. When linked into a scene with other elements, it is automatically combined with other assets.

From left to right: Smooth Toon shading with alpha over specular, Pixelate, Half-Tone with OutlineThis new multi-stage compositing will be reusing the compositor nodes, with a different subset of nodes available at the object and material levels. This is an opportunity to streamline the workflow between material nodes editing and compositor nodes.

Grease Pencil Effects can eventually be replaced by this solution.

Final render showing 3 objects with different stylizations seamlessly integrated.There are a lot more to be said about this feature. For more details see the associated development task.

Anti-Aliased outputA major issue with working with the a compositing workflow is Anti-Aliasing (AA). When compositing anti-aliased input, results often include hard to resolve fringes.

Left: Render Pass, Middle: Object Matte, Right: Extracted Object Render PassThe common workaround to this issue is to render at higher resolution without AA and downscale after compositing. This method is very memory intensive and only allows for 4x or 9x AA with usually less than ideal filtering. Another option is to use post-process AA filters but that often results in flickering animations.

Left: Anti-Aliased done before compositor based shading
Right: Anti-Aliasing is done after compositor.The solution to this problem is to run the compositor for each AA step and filter the composited pixels like a renderer would do. This will produce the best image quality with only the added memory usage of the final frame.

Converged inputOne of the main issues with modern renderers is that their output is noisy. This doesn’t play well with NPR workflows as many effects require applying sharp transformations of the rendered image or light buffers.

For instance, this is what happens when applying a constant interpolated color ramp over the ambient occlusion node. The averaging operation is run on a noisy output instead of running on a noisy input before the transformation.

Left: Original AO, Middle: Constant Ramp in material, Right: Ramp applied in compositor (desired)Doing these effects at compositing time gives us the final converged image as input. However, as explained above, the compositor needs to run before the AA filtering.

So the multi-stage compositors needs to be able to run on converged or denoised inputs while being AA free. In other words, it means that the render samples will be distributed between render passes convergence and final compositor AA.

Engine FeaturesWhile improving the compositing workflow is important for stylization flexibility, some features are more suited for the inside of the render engine. This allows builtin interaction with light transport and other renderer features. These features are not exclusive to NPR workflows and fit well inside the engine architecture.

As such, the following features are planned to be directly implemented inside the render engines:

• Ray Queries
• Portal BSDF
• Custom Shading
• Depth Offset

The development will start after the Blender 5.0 release, planned for November 2025.

Meanwhile, to follow the project, subscribe to the development task. For more details about the project, join the announcement thread.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

At the beginning of 2025, several projects were announced as the initial targets for the year. Now that we’re in the middle of the second quarter, let’s take a look at where each project stands.

Complete* Vulkan

In Progress* Hair Dynamics * Project Setup * Shape Keys Improvements * Remote Asset Libraries

Not Started Layered Sculpting * Dynamic Overrides Almost Complete UV Sync * Better Integration Across Node Trees

Design/Prototype* Texture Cache & Mipmaps * NPR * Story Tools

CompleteVulkanThe Vulkan backend is now officially supported in the upcoming Blender 4.5 LTS, offering feature parity and comparable performance to OpenGL.

The next step is to monitor bug reports and eventually make it the default backend (for non-macOS systems).

Users are encouraged to enable it in Preferences and report bugs.

Almost CompleteUV SyncAll issues from the (five-year-old!) UV Sync design task have been addressed. Development is ongoing in the pr-uv-sync-select branch (builds are available here).

The remaining work involves finalizing the port of certain selection operators and resolving minor issues. Follow the project at #136817.

Better Integration Across Node TreesThe Compositor is moving closer to feature parity with Shading and Geometry Nodes, thanks to the addition of new nodes such as Vector Math, Vector Rotate, Vector Mix, Value Mix, Clamp, Float Curve, and Blackbody.

The next step is to expose most of the existing node options as socket inputs (#137223). This will enable Compositor node assets to be bundled with Blender.

Compositor assets mockup.After that, the focus will remain on simplifying onboarding for new users by making node trees reusable (#135223).

In ProgressProject SetupThe first milestone (Blender variables) was recently merged. The next step is to handle Path Templates errors in a more robust way.

Project Setup mockup.After that, work will begin on the Project Definition phase. Follow updates at #133001.

Shape Keys ImprovementsWhat was originally framed as a performance problem has shifted focus toward the usability and management of shape keys.

As part of this, new operators for duplicating and updating shape keys have already been merged, with their mirrored counterparts to follow.

Additionally, work on multi-select and editing of shape keys is gaining momentum. Follow the project at #136838.

Remote Asset LibrariesThe project has broadened in scope to address usability improvements, including:

• Preview generation for all selected assets.
• A more compact view with a horizontal list and two-line names.
• Snap support when dragging Collection assets.

Remote Asset Library mockup.Meanwhile, the code for handling downloads has been submitted for review but encountered a setback.

Development is taking place in the remote-asset-library-monolithic branch. Follow the project at #134495.

Hair DynamicsThe Hair Dynamics project consists of multiple deliverables:

• Bundles and Closures — merged as experimental
• Embedded Linked Data (#133801) — still under review
• Declarative Systems — published as a design proposal
• Hair Solver — see below

For the hair physics solver, the plan is to use the upcoming Blender Studio project—currently unnamed but focused on a facial rig—as a use case, at least to develop it as an experimental feature.

This will also involve addressing existing issues with animated hair and integrating animation and simulation for the same character—initially using separate hair objects.

Design/PrototypeTexture Cache & MipmapsInitially unplanned due to limited resources, this project was eventually added to the agenda. A rudimentary prototype is already available in the cycles-tx branch. In the Attic and Bistro benchmark scenes, memory usage is already significantly reduced.

These scenes were chosen because they include texture cache (.tx) files. Follow the project at #68917.

NPRThe NPR (Non-photorealistic rendering) prototype received extensive feedback, helping to map out all planned and unsupported use cases for the project.

More details, including the final design and development plans, will be shared soon.

In brief:

• Some features will be implemented as EEVEE nodes.
• Others will be enabled via per-material/object compositing nodes.

EEVEE features will be prioritized first, while the per-material/object compositing nodes require further design.

Story ToolsSo far, the focus has been on prototyping and finalizing the design to pull VSE strips out of the scene and create a dedicated sequence data-block.

Story Tools Mockup.The next step is to finalize the design by either:

• Exploring once more the idea of keeping the sequence as part of the scene; or
• Settling on a per-camera and file settings design.

After that, a technical breakdown will follow, then development. Follow the project at #131329.

Not StartedLayered SculptingLayered sculpting hasn’t started yet. The original plan was to first address multi-resolution undo and rebuild issues, followed by fixing propagation spikes.

However, in recent months the focus shifted to tackling sculpting performance issues present since the 4.3 release, mainly:

• Performance problems with smaller brush strokes.
• Local brush management.

The performance patches are currently under review and expected in time for the upcoming 4.5 LTS release. Once completed, work on undo and multi-resolution will resume.

Dynamic OverridesThe team is currently focused on the 5.0 breaking change targets and other tasks, so they have not yet been able to start the initial changes aimed at simplifying the overrides process.

And more…Beyond these projects, daily activity continues across various development modules. For a more frequent, day-to-day view of progress, check out the Weekly Updates and Module Meetings.

All this progress is made possible thanks to donations and ongoing community involvement and contributions.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

Larger node setups have a tendency to become hard to understand. One of the main tools at our disposal to organize them are frames. A frame allows grouping nodes together visually and giving them a label.

Unfortunately, using frames extensively has been rather annoying for various reasons including hard-to-reach shortcuts (ctrl + J, alt + P, F2), bad readability of nested frames, and various smaller bugs.

In an effort to encourage and help users to build more understandable node groups, we designed and implemented various workflow improvements for dealing with frames. These will be available in Blender 4.5 LTS.

The F KeyThe most important functionality related to frames has been moved to the F key, which is easy to reach and remember. It has two main functions:

1. Create a new Frame around the selected nodes, or a new empty frame. This will also open the rename popup where users can start typing right away to set a label. This makes creating labeled frames as easy as it can be, which is good as those help much more with readability than unlabeled frames.
2. Detach and attach selected nodes while transforming them. This makes moving nodes between frames a breeze, unlike before where frames felt like they got in the way.

The old functionality has been moved to J.

Visualization ImprovementsFrame Highlighting: It used to be difficult which frame nodes will be attached to while moving them. This has been solved by highlighting the border of the frame under the cursor.

Better Labels: Frame labels now sit a bit higher so they’re easier to read. The frame size also adjusts better by considering the full area/bounding box of the nodes inside.

Alternating Frame Colors: Frames are quite dark in the default theme, which made nested frames very hard to see (they were essentially black on black). Now, nested frames use alternating shading depending on the nesting depth. The frame color from the theme is used, just slightly darker/lighter. This keeps all frames visible regardless of the nesting level.

Frame visualization improvements.

“Frame First” WorkflowWith all of these improvements, working with frames has become much more enjoyable than before. Our hope is that this lowers the barrier to using frames so much that they become more frequently and not just as an afterthought when cleaning it up later on.

In fact, I’d even be curious to see how well a “frame first” workflow would work for people. The thought came up when thinking about how when writing code, one usually first writes a function or variable name before writing any of the actual logic. Maybe something similar could work for node systems too, where a labeled frame is created before the first node is added inside. However, it’s not clear yet how well that works in practice right now or if more features would be needed to make that feasible. Let me know!

Try It!Download the latest Blender 4.5 LTS Alpha build and test out the new workflow!

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

Currently, one of our primary goals for Geometry Nodes is to get to a point where we can build high level and easy to use node group assets for physics simulations. Our general approach was described briefly last year. The goal of this document is to go into a bit more detail.

For the examples below I’ll use a particle simulation because it’s the easiest, but the same applies to many other simulation types like hair, cloth and fluids.

Two Different ViewsThere are two different ways to look at a particle simulation:

• Declarative view: Describe the intended behavior of the particles by combining various existing behaviors like emitters, forces, colliders, surface attachment and more.
• Imperative view: Describe the computation steps to simulate the particles. Such steps are for example “integrate forces”, “update positions”, “find collision points”, etc.

Both are totally valid views at a particle simulation, but depending on what you’re trying to achieve exactly, one view is more practical than the other. Most particle simulations can be described using a combination of various behaviors in which case the declarative view is more practical, but when you’re building a particle system from scratch or have custom needs, the imperative approach works better because it has more flexibility at the cost of dealing with low-level details.

Current StateGeometry Nodes is already quite decent at building particle systems using the imperative approach. Obviously, there are various missing built-in features to really be able to tackle any kind of simulation, but the overall structure is there.

Building particle systems using the declarative approach by combining a set of behaviors is much harder, because it requires creating node groups that describe a certain behavior which are passed to a “solver” which performs the actual computations in the right order.

GoalWe are working towards various core features (bundles, closures, lists) that together will allow building declarative systems. The image below shows how individual behaviors could be encapsulated by node groups. All behaviors have the same type which allows easily combining them to form higher level behaviors. Also note that the order in which they are passed to the particle solver is largely irrelevant.

This approach to building particle solvers allows someone to focus on building the actual solver that exposes a specific interface while anyone else can just build and combine behaviors for that solver without worrying too much about how it works internally.

Since all behavior node groups have a very similar structure (various inputs, one behavior output), we can also build a higher level UI for managing them. For example, if the Particle Solver node group is used as modifier, the UI could look like in the following mockup. Note that each panel corresponds to one behavior and that an arbitrary number of behaviors can be added. The individual behaviors would be node group assets coming from an asset library.

Of course one always has more flexibility in the node editor, but this kind of UI should be capable of solving the most common needs without requiring the node editor at all.

Lastly, this approach of using declarative systems also simplifies creating add-ons that have a custom high level UI for some node tree. That’s because it’s way easier to write code that merges a few behaviors together automatically, than it is to edit potentially deeply nested node groups.

Beyond SimulationsAs mentioned, this behavior-based approach works well for all kinds of physics simulations. However, using declarative systems also makes sense in other cases where the user thinks more about the what and not the how.

One example for such a system is Line Art. A potential Line Art node is supposed to generate curves based on various features (e.g. silhouette, non-occluded edges and intersections). Here again, the user does not really care about how the curves are computed exactly, but only what kind of curves are expected. One could build node groups describing the different kind of curves, pass these to the Line Art node which then outputs all the requested curves.

Something similar could be done for landscape generation, where behaviors encapsulate terrain features or asset scattering rules.

There is always a bit of a trade-off when choosing between the imperative and declarative approach, but for high level tools used by potentially millions of people, the declarative approach is often better because it significantly reduces the cognitive load at the cost of a little less flexibility.

How do Bundles and Closures fit in?Bundles and closures are currently an experimental feature. They have many interesting uses on their own, but the primary reason for why we are working on them is to allow building these declarative systems.

You can check out the pull request for more details, but in short a Bundle allows passing multiple values along using a single link and a Closure allows passing around functions that can be evaluated anywhere.

Each individual behavior will generally be encapsulated as a bundle. The exact structure of that bundle is determined by the solver that uses the behavior. For example, a very basic mesh particle emitter could look like in the image below. Note that the Type in the bundle will be used by the solver to figure out what kind of behavior this is. The solver will call the Emit callback to actually create the new particles. The inputs and outputs of the callback are also determined by the particle solver.

Closures are a fundamental feature to make this whole system work, while at the same time being a fairly niche feature that most people will not have to know about. Most people will just use systems that heavily rely on closures under the hood to be able to provide a good high level user interface.

Feedback can be posted in the corresponding forum thread.

View Details

During the 2024–2025 winter (northern hemisphere), Blender developers focused on quality and stability. This blog post offers an overview of the work accomplished.

Bugfixes

Between December 1 and January 31, 2025, more than 500 reported issues were fixed.

High severity bugs since January 1st 2025Here is a per-module breakdown of the fixed reports:

• Animation & Rigging: 24
• Asset System: 6
• Core: 10
• Grease Pencil: 82
• Modeling: 33
• Nodes & Physics: 71
• Pipeline & IO: 9
• Python API: 3
• Render & Cycles: 37
• Sculpt, Paint & Texture: 31
• User Interface: 82
• VFX & Video: 40
• Viewport & EEVEE: 76

Additionally, many old reports have been double-checked and either fixed or closed (for example, if the issue could not be reproduced in a recent Blender version). Issues that were not reported by users were also addressed.

Module Work OverviewIn addition to fixing bugs, developers also spent time tackling technical debt, updating documentation, and stabilizing certain areas of the code. Let’s take a look at the reports from each module.

Animation & Rigging* Multiple bugs have been closed (either fixed or re-investigated and closed). * Pose Library: + Added support for slotted actions, including multi-object poses. + Added support for pushing to the pose library. * New tools for slotted actions have been implemented. * Switching assigned actions is now smoother. * Library Overrides for slotted actions have improved. * Code documentation is much better, APIs have been polished, and the new animation system is generally easier to work with for future development.

CompositorThe CPU compositor rewrite has been completed, aiming to improve maintainability by unifying the CPU and GPU compositors. In the process:
• Tens of thousands of lines of code were removed.
• Performance of many operations was improved.
• The behavior of CPU and GPU devices was unified.

The main benefit of this rewrite is that future development of the compositor will be faster and easier.

Grease PencilThe focus was on stabilization following the significant Grease Pencil v3 changes introduced in Blender 4.3. A total of 91 bug fixes were committed, 86 of which were high-severity bugs, many addressing regressions.

ModelingThe focus was on fixing crashes and older unresolved bugs. 17 issues were addressed, including several long-standing bugs and 8 crashes. In total, 74 issues were closed.

Nodes & PhysicsThe team kicked off the quality project by developing a tool to categorize all module issues and split them into batches. This tool made the project feel far less daunting, as they were only tackling 20 issues per day instead of 700.

The focus was on addressing reports for “active” projects (rather than end-of-life features like the particle system or inactive areas such as the cloth modifier). In total, they closed about 150 issues and resolved several long-standing, frustrating problems.

They also made time for some important refactors, including:

• Reducing the number of changes required to add a new node.
• Starting a replacement for the CustomData system.
• Implementing various smaller improvements.

Render & CyclesThe team improved test coverage, fixed around 40 bugs, and cleaned up the code to better align with modern C++ standards.

Sculpt, Texture & PaintThe team focused on bug fixes, as well as improving testing and documentation.

• Issues
  • Closed 25 high severity reports.
  • Followed up on issues tagged with Need Information from Developers
  • Closed 57 additional issues (Design, To Do, and Bugs).
  • Created a tracking issue for Sculpt/Paint undo problems.
• Testing & Documentation
  • Added a BVH building unit test.
  • Work is ongoing for a sculpt stroke + render test.
  • Added a technical documentation overview for mesh painting.

USD (Universal Scene Description)The team focused on a variety of tasks, including adding additional test coverage, completing partially implemented features, and upgrading the user manual.

They also investigated, fixed, and prototyped performance improvements for USD import, which were also useful in determining some other areas of Blender that should be improved.

User InterfaceThey focused on reducing the number of UI issues to a more manageable state. Out of more than 1000 open issues, 275 were closed.

• Closed 209 bug reports (most of them as resolved). 13 of them were high severity reports.
• Closed 66 other issues (Design, To Do, etc).
• Followed up on issues tagged with Need Information from Developers.

Viewport & EEVEEThe team migrated overlay, selection, and image engine to the new drawing manager API. This migration fixes known and long-standing issues with overlays, and it paves the way for future optimizations, including removal of a global lock/freeze.

The team also focused on improving test cases, fixing high-severity issues, and better platform support.

Video Sequence EditorThe team focused on bug reports, code cleanups, and refactors:

• The Sequence -> Strip rename in the codebase (and to some extent the Python API) to make the code less confusing.
• All movie read/write-related C++ code is now in imbuf/movie, with clearer naming and improved structure.
• The code for VSE effects and modifiers was cleaned up and modernized to align more with C++ standards, resulting in a slight performance boost.
• Retiming code received fixes, cleanups, and improved developer documentation.
• Several UI interactions were polished for better usability.

Future Quality ProjectsAfter a year of exciting new features like EEVEE-Next and Grease Pencil v3, the Blender Winter of Quality was the perfect opportunity to tackle loose ends and enhance stability.

While quality is always a core focus of new development and part of the daily work of module teams, having a dedicated period to focus solely on it was great. As a result, future quality projects are being considered, and feedback is currently being gathered to learn about the experience for developers and identify areas for improvement in the future.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

Just before Blender Conference 2024, the Animation & Rigging module held a day-long workshop to discuss layered actions should work in Blender. In this post, we’ll share the outcomes of that workshop.

For more context on this topic, please visit Animation 2025: Progress & Planning.

Joining in the workshop were Brad Clark, Christoph Lendenfeld, Dorothee Ditrich, Falk David, Lukas Tönne, Marion Stalke, Nate Rupsis, Nathan Vegdahl, Nika Kutsniashvili, Pierrick Picaut, Raymond Luc, Rik Schutte, and Sybren Stüvel.

Workshop FocusA single day isn’t long enough to come up with a full design, so we tried to focus on topics that we could make real progress on within a day, and which would help orient the project. With that in mind, we structured the workshop into two parts:

Part 1: decide which use cases and supporting workflows we should target in the initial minimal version of layered actions, and also what features we need to support in service of that. The focus here was on determining a minimal set of features that we can feasibly develop in a reasonable time frame, while still being a useful initial version.

Part 2: discuss some of the trickier UI/UX questions raised by the features we decided on, and how they should work in practice.

So, without further delay, here is what we discussed at the workshop.

Use Cases and WorkflowsWe identified four broad categories of use cases/workflows for animation layers:

1. Creating new animations from scratch via layers. For example, animating a base layer of a character walking and then an additional layer for finer details in the motion, like shivering.
2. Adjusting existing animations. For example, adjusting mocap data non-destructively, or fixing an intersecting hand in someone else’s (or your own!) messy animation.
3. Organizing animation data. For example, putting a character’s facial animation on one layer and their body animation on another, or storing backups of previous animation stages (blocking, splining, etc.) in disabled layers for reference.
4. Incorporating non-keyframe data. This might be things like simulation layers, layers that bring in motion from cache files, layers that define animation-level constraints, etc.

Of these categories, we decided to leave #4 out of the initial version of layered actions. There are a lot of unknowns and potentially hard problems to solve with many of the use cases in that category, and just generally it’s not the primary reason people want animation layers.

We decided that the remaining three categories are all reasonable to accomodate in an initial “minimal viable product” (MVP) as long as we stick to the basics rather than trying to get fancy.

Initial Feature SetFrom the above use cases, we narrowed down what we thought a reasonable minimal feature set would be. Additional features can always be added later, so the focus of this was on the minimum features needed for it to be useful. We of course want additional features down the line.

Here is a list of what we thought we couldn’t be without:

• Layers can be named.
• Layers can be given a color.
• Layers can be selected, and there is an active layer.
• Layers can be reordered.
• Layers can be added, deleted, and duplicated.
• Layers can be locked.
• Layers can be muted/disabled.
• Layers can be solo’ed (multiple layers can be solo’ed simultaneously).
• Each Layer has a blend mode. For initial release, these will be “replace” (similar to alpha-over in compositing software) and “combine” (conceptually an “add” mode, except data-type aware so that rotations rotate, scales scale, etc.).
• Layers have animatable influence / weight.
• Layers can be baked down together with the layers below them, as a way of merging layers togther. For the initial version this will just be a dumb per-frame bake.
• Layers are contained within, and owned by, an Action. Each Action has its own set of layers.

These features may seem quite basic. That’s because they are quite basic, and that’s the point. It’s a small, basic set of features that are manageable to tackle in an initial Minimal Viable Product (MVP). Additional features (like layer groups, smart baking, time warping, etc.) can wait for after the MVP is completed and in people’s hands.

We don’t want people to have to wait for all of the fancy features to be done before they can use the system at all. And when we get feedback, we want a ‘simple’ system we can easily adjust.

Where/How Do You Manage Layers?There will be a separate editor for managing layers, and for selecting the active layer within an Action. Maybe this will even start out as a panel in the Action editor for the simplest of implementations.

At first, the other animation editors are only going to show data from the active layer.

This is just a start to get something simple in the hands of animators as soon as possible. With a more tangible layered workflow in Blender, it will be easier to design the necessary improvements to the UI/UX.

Where Do Keys Go?When working with multiple layers, it is not immediately obvious where keys should go when you press the I button to key something. Below is the flow diagram we came up with.

Let’s talk through the above flow diagram:

• If there are no layers yet, create one and use that to store the keys.
• If there is only one layer, use that to store the keys.
• With multiple layers, there is a choice depending on whether the “Available” (name to be improved) checkbox is checked.
  • Unchecked: keys should always go to the active layer. Blender ensures that there is always a layer active (if there are no layers → see above).
  • Checked: keys should go to the layer that already animates whatever you’re keying now. See below.
• How many layers are already animating this property?
  • none → use the active layer (*)
  • one layer → use that
  • more than one layer: is one of those the active layer? If so, use it, otherwise use the topmost, unlocked layer.

(*): The flow diagram also goes into a choice for auto-keying vs. explicit keying. We hope that with this text the rest of the diagram is also clear.

That “Available” checkbox will likely be a user preference, as it is expected that it’ll be a personal choice and reflect more how you animate than what file you’re working in.

How Does Blending Work?Blending the animation from different layers together is a fundamental aspect of layered animation, but is also surprisingly tricky to get right. It also impacts how certain other features should work.

So “how does blending work?” was an important question to answer. Below are our answers to that, as well as to the further questions that it raises.

What blend modes are there, and how do they work?The initial Minimal Viable Product (MVP) will have just two blend modes: “replace” and “combine”. Other blend modes may be added in the future if there are real use cases for them, but for the MVP we will just have these two:

• Replace is like alpha over, overriding the animated values of the layers below. Changing the layer’s influence between 0-100% blends between the values of the layers below and the values of the current layer.
• Combine is conceptually like add, accumulating on top of the animated values of the layers below. For most properties this is a literal mathematical add, but for some properties (such as scale and quaternion rotation) that either isn’t really what you want or isn’t even sensical. In those latter cases the most appropriate accumulation operation is used instead (e.g. multiply for scale and quaternion multiplication for quaternion rotations). Changing the layer’s influence between 0-100% blends between the values of the layers below and the accumulated result of those values with the current layer.

For both blend modes, layers only affect properties that they animate: if a property is not animated on a layer then its value is simply passed through untouched.

What happens when there is no value on the layers below?For “replace” layers with less-than-100% influence and “combine” layers with any influence, there has to be something below for the layer to blend with. But what if the layer is the bottom layer? Or what if it animates a property that isn’t animated on any of the layers below it? What does it blend with?

We considered two alternatives:

• Not blending: if there is nothing to blend with, don’t blend at all and just replace at 100% regardless of the layer’s actual blend mode and influence.
• Blend to default: use the property’s default value as the “value below” to blend with. This means blending to zero for location, one for scale, etc. Effectively, this means bones blend to their rest pose, and objects blend to their delta transform (which is often also zero, so then they blend to the origin, parent, etc.).

Neither solution is perfect, each having less-than-ideal behavior in at least some situations.

Not blending means that the effective influence of a layer can be 100% even when actually set to 0% or an extremely small percentage. Moreover, that effective influence can be different for different animated properties depending on what is and isn’t animated on the layers below, which could be confusing. It could also frustrate certain workflows, such as temporarily muting other layers to tweak the current layer’s animation in isolation: if the current layer’s influence is small, then muting the layers below it would effectively jump its influence to 100%, exaggerating its actual effect on the animation.

On the other hand, blend to default also has issues. The default values for properties often aren’t useful/meaningful, so blending with them is likely to be pretty useless in many cases. For example, unparented objects would typically blend to the world origin.

In the end we settled on blend to default. Its behavior is more predictable and less disruptive, and the user can work around useless default values if needed by keying useful values on a base layer.

What happens when you mute a layer?Muting a layer will affect blending as if you removed the layer entirely. Note that for animated properties that are not on any layers below, this is specifically different from setting the layer’s influence to zero; that would blend to default, while muting the layer stops animating the property altogether.

Terminology note: we may want to call this “disable” rather than “mute”. To be decided.

Inserting and editing keys on middle layersWhen you have multiple layers, you will often want to insert keys on one of the middle layers. When this happens, the value of that key must be determined.

We decided that the inserted value should be whatever value makes the final mix of all layers together produce the current pose. In practice this is almost always what is wanted: any other behavior would mean that inserting a key with the current pose may actually change the pose itself, which would be quite surprising! Accomplishing this means that the keyframing code needs to account for and reverse the effects of the other layers when determining the value to key. This is a bit like crazy space in mesh edit mode, which allows you to directly adjust the deformed positions of vertices.

However, just like crazy space, this isn’t always the behavior you want. Occasionally you want to specify the exact value to key, regardless of the effects of other layers. For the initial MVP you will be able to more-or-less accomplish this by soloing the layer before posing and keying, but in the future we want to explore approaches to accomplish this more directly.

There are also operations other than key insertion that may be useful to do with this “crazy space” behavior. For example, perhaps you want to add a layer and use it to smooth out the final mixed animation. If the smooth operator in the graph editor only sees the f-curves of a single layer in isolation, this won’t work. Instead, it will need to (optionally) perform the smoothing on the final mixed values and then back-propagate those smoothed values, accounting for the effects of the other layers. For the MVP we likely won’t be implementing this; there are some subtle and non-obvious details that may be challenging to get right. But it is something we want to support in the future.

Finally, there are of course cases where the “crazy space” keying behavior is impossible. For example, if there is a “replace” layer with 100% influence above the layer you’re keying on: no matter what value you insert a key with, it cannot affect the final mixed pose. We discussed a few alternatives for what should happen in such cases, but ultimately decided that for the MVP we should keep it simple: Blender will simply reject keying and issue an error. After this system is built, we can experiment with other approaches and see what actually works best in practice.

Wrapping UpWe’re extremely happy with how the workshop went, and we believe this is a solid direction for layered actions. Nevertheless, this is not the end of the design process. There is still a lot that needs to be figured out. Moreover, we could only accommodate a limited number of people at the workshop, and we want feedback and ideas from wider community as well. The best way to get involved is to join our weekly module meeting, and we look forward to seeing you there!

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

In December 2024, a workshop was held at the Blender HQ in Amsterdam to discuss the use of overrides in production environments.

The workshop was attended by Andy Goralczyk and Simon Thommes from Blender Studio, while Bastien Montagne, Sergey Sharybin, and Dalai Felinto attended on behalf of the development team.

Left to right: Simon, Sergey, Bastien, Andy, Dalai (photo) at the Blender HQ in Amsterdam.The main topics discussed were the pain points of the existing (library) overrides system, its limitations, and potential improvements for future productions.

Overrides in productionsThe existing Library Overrides system is very powerful. However, with great power comes great ~~responsibility~~ complexity.

The system was designed to replace the old proxy system and support multiple instances of the same character within a scene. Its most extensive use case was the Sprite Fright project, which involved animating numerous Sprite characters, all overridden from the same blendfile.

Sprite Fright – CC-BY Blender Studio.Although the initial plan appeared solid, the system’s design introduced the need for active maintenance. Files would frequently go out of sync, requiring Blender to resync linked libraries—taking minutes each time a file containing modified linked rig was opened.

This led to name collisions in production files and the need for a custom script to reopen and resave all interlinked files daily, to keep relationships in sync.

Meanwhile, Blender Studio developed an add-on to handle shot-based non-character overrides (e.g., light tweaks). This simpler approach was very functional and could handle a wide range of use cases more efficiently compared to Library Overrides.

After completing enough projects using this pipeline (Sprite Fright, Charge, Wing It!, Gold, and smaller productions), it is time to improve Blender’s approach to overrides.

Leave the complexity out for 99% casesThe main feedback was that, in most scenarios where overrides are needed, a simple solution should suffice. To put it differently:

I want to link a character and animate it [but]

in 99% of cases we don’t need the complexity of overrides.

For the rare instances where artists require full control over a hierarchy, the existing Library Overrides system will still be available. In that sense, Library Overrides are here to stay. However, both rigged character animations and individual properties (e.g., Light power) should be overridable in a more streamlined way.

(Dynamic) OverridesThe proposed solution introduces a new type of override (codename: Dynamic Overrides), which can operate on linked or local data. When working with linked data, a Library Override can still be created when necessary, but now it can be done without overriding the entire hierarchy.

Key-points:

• Flexible Storage: Dynamic Overrides can be stored in various places, such as scenes or collections, giving users full control over their location.
• Linkable: Depending on where they are stored, Dynamic Overrides can also be linked.
• Granular Control:
  • Overrides can apply to specific properties rather than entire hierarchies.
  • The system allows for individual adjustments (i.e., a single property).
• ID Pointers Support: Can replace/override ID pointers.
• Remappable: They can be swapped when broken paths are found.
• Enhanced Usability:
  • Dynamic Overrides take over most of the current Library Overrides interface, providing a streamlined experience.
  • Library Overrides will still be necessary for specific features like modifiers and viewport interactions for now.
• Co-Existence with Library Overrides:
  • Linked rigged characters will first get a Library Override for the rig, without any hierarchy.
  • Followed by a Dynamic Override to remap usages of the linked armature to the local library overridden rig.
  • This re-creates the “proxy” system experience with a more robust implementation.
• Library Overrides Hierarchy still available:
  • Library Overrides hierarchies remain available for the rare (1%) complex use cases.
  • Dynamic Overrides can be converted into Library Overrides when a full hierarchy is required.

Overrides data-blockA new data-block type, Override, would be introduced. Initially, this will be used by the Scene ID, making the overrides globally applicable within a single scene.

In the future, this data-block could be applied more specifically to collections and other contexts. This would allow different versions of the same material or object to coexist, each with distinct properties based on their context’s overrides.

Overrides ID Data-block data structure design.There are three types of override rules which are being considered:

1. ID Remap: Designed for animation of linked rigged characters.
2. RNAPath: Focused on overriding individual properties.
3. Filter: A mechanism to apply RNAPath changes to multiple data-blocks simultaneously, rather than just one.

User InterfaceBelow are mockups showcasing possible integrations for overrides in the user interface.

Creating overridesAn override can be added via the context menu or by using the “O” shortcut.

Context Menu: Add Override and Remove Override options.Where to view Overrides? Properties Editor: Overrides can be identified by their override-specific color. * Overrides Panel*: A dedicated panel listing all overrides will be available.

Initially, this list will only appear at the scene level. In the future, it will be accessible in other locations where overrides can be stored (e.g., Collections).

Advanced SetupFor more complex setups, the overrides data-block can be linked from a different file. This allows for creating a hierarchical set of override rules that can be stacked and reused across multiple contexts.

Short term alternativesBefore this project can fully begin, a few steps will be taken to speed up background blend-files processing:

• Command-line option to skip dependency graph building in background mode.
• Command-line option to skip Library Override re-sync on blend-file opening.
• Expose some blend-file libraries dependency information in the Python API.

These improvements will help with the Blender Studio pipeline, which relies on daily project-wide resyncs to minimize override conflicts. A script is used to open all files that link any edited files and save them, ensuring that override resyncs do not accumulate over time.

Milestones* Override ID Data-block * Animation support for overriden properties. * Filter for overrides (wildcard RNA properties). * Non-global overrides (context-based overrides).

Good-to-have targets:

• Viewport interaction (gizmos).
• Modifiers, constraints, … (requires design, could be targeted for 5.0).

Closing thoughtsThe concept of dynamic overrides is not new, but it has now been refined to a point where the team feels it is ready for development.

This maturation period was also crucial for Library Overrides to be battle-tested and for the use cases of dynamic overrides to become more clearly defined. This will enable both types of overrides to be used in combination, leveraging the strengths of each to achieve the best of both worlds.

Next stepsOverrides will be one of the main targets for 2025. The exact timeline will depend on the Blender Studio project lineup and the availability of the development team.

Once an initial prototype is ready for testing, a thread will be created on the Developer Forum for studios and individual artists to share their feedback.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

Over the past several months sculpt mode underwent a large rewrite. Since the project has wrapped up, this post gives an overview of what changed.

Unlike most other development projects, this had no effect on the interface. Before and after the project, Blender looked exactly the same. Typically this should raise some eyebrows, because it often means developers are prioritizing work based on its effect on the code rather than its utility to users. In this case, problems with the code have made feature development significantly harder over the years, and refactoring came with plenty of potential performance improvements.

Overall, for those who want to skip all the technical details, entering sculpt mode in Blender 4.3 is over 5x faster, brushes themselves are about 8x faster, and memory usage is reduced by about 30%. For actual visible changes to sculpting in 4.3, see brush assets. For a full list of the refactor work, see the task.

Entering Sculpt ModeEntering sculpt mode was known to be quite slow. Based on profiles, it also looked much slower than it should be, since it was completely single threaded.

A profile of Blender as it enters sculpt mode on a large mesh in 4.2, where each row is a CPU core.It turns out Blender was bottlenecked by two things: building the BVH tree that accelerates spatial searches and raycasting and uploading the mesh data to the GPU for drawing.

Improving the BVH build time was a months-long iterative process of finding bottlenecks with a profiler, addressing them, and cleaning the code to make further refactoring possible. Adding trivial multi-threading to the calculation of bounds and other temporary data was the most significant improvement, at almost 5x. Beyond that, reducing memory usage improved performance by another 30%, simplifying the spatial partitioning of face indices using the C++ standard library another 30%. And finally, changing the BVH from storing triangles to storing faces (for a quad mesh there are half as many faces as triangles!) improved performance by another 2.3x.

Entering sculpt mode is about 5 times faster compared to 4.2 (a change from 11 to 1.9 seconds with a 16 million face mesh with a Ryzen 7950x).Lessons for Developers* Any array the size of a mesh is far from free. We should think hard about whether all the data in the array is really necessary. * Any algorithm should clearly separate serial and parallel parts. Any loop that can be done in parallel should be inside a parallel_for. * We shouldn’t be reimplementing common algorithms like partitioning; that makes code so scary and weird that no one touches it for years. DrawingThere is a fundamental cost of uploading geometry data to the GPU and we will always be bottlenecked to some extent by the large amount of data we need to render. However, as a tweaked version of code from 15 years ago, sculpt mode drawing had enough overhead and complexity that significant improvements were possible.

The GPU data for the whole mesh is split into chunks, with one chunk per BVH node. One main problem with the old data upload was its outer loop over nodes. That forced all the book-keeping to be duplicated for every node. Often just focusing on simplifying the code gave performance improvements indirectly.

1. Removing two levels of function call indirection for multires data upload roughly doubled the performance, and removing function calls for every mesh edge gave another 30% improvement.
2. The main change to the drawing code was a rewrite to avoid all duplicate work per BVH node, add multi-threading, and change the way we tag changed data. This improved memory usage by roughly 15% (we now calculate viewport wireframe data if the overlay is actually turned on), and entering sculpt mode became at least 10% faster.
3. GPU memory usage was reduced by almost 2x using indexed drawing to avoid duplicating vertex data for every single triangle. Now vertex data is only duplicated per face corner.
4. Previously, sculpting on a BVH node would cause every single attribute to be reuploaded to the GPU. Now we only reupload attributes that actually changed. For example, changing face sets only reuploads face sets. Tracking this state only costs a single bit per node.

BVH Tree DesignPreviously, the sculpt BVH tree, often referred to as the “PBVH” (Paint Bounding Volume Hierarchy) was a catch-all storage for any data needed anywhere in sculpt mode. To reduce the code’s spaghetti factor and clarify the design, we wanted to focus the BVH on its goal of accelerating spatial lookups and raycasting. To do that we removed references to mesh visibility, topology, positions, colors, masks, the viewport clipping planes, back pointers to the geometry, etc. from the BVH tree. All of this data was stored redundantly in the BVH tree, so whenever it changed, the BVH tree needed to change too. Nowadays the design is more focused and it’s much easier to understand the purpose of the BVH.

Another fundamental change to the BVH was replacing each node’s references to triangles with references to faces. In a typical quad mesh there are twice as many triangles as faces, so this allowed us to halve a good portion of the BVH tree’s memory overhead.

Brush EvaluationTo evaluate a brush, regions (BVH nodes) of the mesh are first tested roughly for inclusion within its radius. For every vertex in each of these regions, we calculate a position translation and the brush’s strength. The vertex strength includes more granular filtering based on the brush radius, mask values, automasking, and other brush settings.

Meshes are split into multiple BVH nodes which are used to filter unaffected geometry.Prior to this project, all these calculations were performed vertex by vertex. For each vertex, we retrieved the necessary information, calculated the deformation and the relative strength and then finally applied the brush’s change. Because mesh data is stored in large contiguous arrays, it is inefficient from a memory perspective to process all attributes for a particular vertex at once, as this likely results in many cache misses and evictions.

While the previous code was somewhat concise, handling all three sculpt mesh types (“regular meshes”, dynamic topology, multires) at once, this “generic processing” had some significant negative side effects:

1. The old brush code was hard reason about because of C macros and the combination of multiple data structures in one loop.
2. The structure had little opportunity for improved performance because of runtime switching between data structures and the lowest-common-denominator effect of handling different formats.
3. A “do everything for each vertex” structure has memory access patterns that don’t align with the way data is actually stored.

Brush code now just processes a single action for all the vertices in a node at the same time, splitting the code into very simple hot loops which can use SIMD, use much more predictable memory access patterns, and have significantly less branching per-vertex.

For further reference, here is a change that refactored the clay thumb brush. Though the new code has more lines, it’s more independent, flexible, and easier to change.

Proxy SystemPreviously, brush deformations were accumulating into a temporary “proxy” storage on each BVH node. This accumulation occurred for each symmetry iteration until the end of a given brush step, at which point the data was written into the evaluated mesh positions, shape key data, and the base mesh itself.

We completely removed the proxy system as part of refactoring each brush. Instead, brushes now immediately write their deformation during each each symmetry step calculation. This avoids storing temporary data and improves cache access patterns by writing to memory that is already cached. Removing the proxy storage also reduced the size of BVH nodes by around 40%, which aligns with our ongoing goal of improving performance by splitting the mesh into more nodes.

Thread ContentionProfiling revealed a significant bottleneck during brush evaluation: just storing the mesh’s initial state for the undo system was taking 60% of the time. When something so simple is taking so much time, there is clearly a problem.

The issue turned out to be that most threads involved in brush evaluation were waiting for a lock while a single thread did a linear search through the undo data, trying to find the values for its BVH node.

for (std::unique_ptr<undo::Node> &unode : step_data->nodes) { if (unode->bvh_node == bvh_node && unode->data_type == type) { return unode.get(); }} Simply changing the vector to a Map hash table gave us back that time and significantly improved the responsiveness of brushes.

return step_data->undo_nodes_by_pbvh_node.lookup({node, type}); Though there was plenty of refactoring required to make this possible, the nice part is how often very little time with a profiler is necessary to identify significant improvements.

Undo Data Memory UsageUndo steps also became slightly more memory efficient in 4.3. The overhead of each BVH node’s undo storage for a brush stroke reduced 10x from about 4KB to about 400 bytes.

In the future we would like to look into compressing stored undo step data. This could require significantly less memory.

For another example of thread contention, we look to the counting of undo step memory usage. Undo data is created from multiple threads, and each thread incremented the same memory usage counter variable. Simply counting memory usage later on with a proper reduction gave a 4% brush evaluation performance improvement.

Writing to the same memory from multiple threads at the same time is slow!

In yet another thread contention problem, writing “true” to a single boolean from multiple threads turned out to be a significant issue for the calculation of the average mesh normal under the cursor. The boolean was logically redundant, so just removing it improved brush evaluation performance by 2x.

Multi-Resolution ModifierMost of these performance improvements were targeted at base mesh sculpting where there was more low-hanging fruit. However, multires changes followed the same design and there were a few more specific optimizations for it too. Most significantly, moving to a struct-of-arrays format for positions, normals, and masks gave a 32% improvement to brush performance, and simplified code.

The sculpt-mode multires data structure was optimized the same way meshes were optimized over the past years (see last year’s conference talk)Some multires workflows have remaining bottlenecks though, like subdivision evaluation or bad performance at very high subdivision levels.

The End!Thanks for reading! It was a pleasure to be able to iterate on the internals of sculpt mode. Hopefully the changes can be a solid foundation for many future improvements.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

After the Blender Conference, the Geometry Nodes team came together once again to discuss many design topics. This time our focus main focus was to improve support for physics, especially hair dynamics in Geometry Nodes. A few other topics were discussed as well though. You can also read the raw notes we took during the meetings.

The following people participated in the workshop (from left to right): Lukas Tönne, Hans Goudey, Simon Thommes (afternoons) and Jacques Lucke. Additionally, Dalai Felinto helped kickoff the workshop and Falk David joined in every now and then.

Previously in Geometry NodesOur last workshop was 5 months ago. This section provides a quick update on the topics we discussed there. Omitted topics don’t have any news.

• Gizmos: They are part of the Blender 4.3 release. Next step here is to add gizmos to some built-in nodes like the Transform Geometry or Grid nodes.
• Baking: Bakes can be packed now. Next step is to provide higher level tooling to work with multiple bakes in a scene.
• Rename Sockets in Nodes: Ctrl+click to rename sockets works in a few nodes now (e.g. Bake, Simulation, Capture Attribute). There are some technical difficulties with making it work with double click and for right-aligned labels.
• Tools for Node Tree UX: Built-in nodes support socket separators now (used in the For-Each Zone). Support will be added to node groups at some point. The viewer node automatically changes its position now.
• Asset Embedding: A prototype was built to test the behavior. We agreed on how we solve the technical difficulties with it, but some UI aspects are still somewhat unclear (e.g. how this is presented to the user as a new “import method” besides linking and appending).
• Menu Socket: We improved the error handling when there are invalid links, giving more information to the user about what is wrong. This applies to menu sockets, but also other invalid links like invalid type conversions.
• Socket Shapes: We found a design where everyone is okay with the trade-offs it makes. A prototype was built. The work on it is still ongoing.
• Grease Pencil: Geometry Nodes can work with Grease Pencil data starting with Blender 4.3.
• For-Each Zones: There is a new For-Each Element zone in 4.3. Work on other kinds of For-Each zones is ongoing.

Approaching PhysicsAs usual, there are many different perspectives that we have to take into account for when designing how we want to approach physics in Geometry Nodes:

• Using high level node group assets to setup e.g. a hair simulation.
• Building and/or customizing solvers for specialized effects.
• The modifier-only workflow.
• Higher level add-ons which abstract away the node and modifier interface.

We started out by clarifying that there is a fairly fundamental difference in how to think when chaining multiple geometry operations vs. setting up a physics simulation. The difference is that when creating a simulation, one thinks about the desired behavior (forces, emitters, colliders, …) first, and not so much about the order in which the geometry is actually processed. In fact, the majority of users should only have to care about the behavior without worrying about specific geometry operations.

We therefore want to provide better ways to separate describing the desired behavior from actually implementing the behavior. We call this the declarative approach. It gives users high level control over a potentially very complex evaluation system that makes all the desired behaviors work. The declarative approach can also be very useful for things beyond physics like building a brush engine or scattering system.

To achieve this separation, we will introduce two new socket types: bundles and closures, which are explained in more detail below (exact names are not set in stone yet).

BundlesA bundle is a container that allows packing multiple values into a a single socket. Values of different types can be put into a single bundle. A work-in-progress patch is available already.

Bundles are quite useful to reduce the number of necessary links. For now, we are mostly interested in how they can be used to create a uniform interface for various kinds of simulation behaviors. Each behavior will be a bundle that contains the necessary information for the solver to understand what to do with it.

ClosuresClosures sockets allow passing around arbitrary functions including entire node groups. For example, this allows passing a node group as an input into another group which will then evaluate it. This is an entirely new paradigm in Blender’s node systems, and without being already familiar with the concept of passing functions around as data, it’s not trivial to understand. However, it’s incredibly powerful and allows building much more flexible and user-friendly high level node groups.

In programming, the term “closure” refers to functions which may be passed around as data and can capture variables from where they are created. We have not found a good alternative name yet.

To create closures, we use a new closure zone. It’s a bit like creating a small local node group that can then be passed around. Just using existing node groups does not work, because we need the ability to pass data from the outside into the closure (like in all other zone types). Also, it’s good to have the ability to build the entire node tree in a single group to see everything at once.

Position Based DynamicsThe declarative approach with bundles and closures is generally useful for all kinds of physics simulations. While we want to enable users to build their own solvers, we also want to integrate hair simulation specifically into Geometry Nodes directly.

The hair simulation is designed around a Position-Based Dynamics (PBD/XPBD) solver. This solver has been applied to soft-body simulation, cloth, hair, granular materials and more.

The PBD method is often used for real-time game physics and is relatively easy to implement. It has advantages in terms of speed and accuracy over the linearized velocity-based cloth solver currently used for hair dynamics. There are lots of learning resources and scientific papers on the topic for people to learn more. When first looking into this, we found this overview and this video tutorial series particularly useful.

We will try and implement as much of this as possible using generic geometry nodes. Some parts like collision detection and constraint grouping may require new built-in nodes for performance reasons. This will be decided when we get there.

ListsFor this project we’ll likely need lists in different places, for example to manage a list of behaviors passed into the solver and to process contact points after collision detection. Lists have been a talking point in previous workshops and we don’t have much new information that has not been said before. We went over the set of nodes we’d need, but there were no real surprises there.

Lists are also particularly important for hair, because we need to map generated hair to potentially multiple guide hair strands. Currently, there is no good way to store that mapping which makes any workflow that uses guides, especially for simulation, quite unreliable.

The main blocker to get lists into Geometry Nodes is still the socket shapes discussion.

Socket ShapesThe last blog post contains an explanation of the topic. Last time, we didn’t come to a conclusion for how to deal with socket shapes when we get more types like fields, lists, grids and images. The tricky thing is that we can’t show all information we’d like to with just socket shapes, so we have to decide what we don’t want to show anymore.

Some design work has been done on the topic in the last couple of months and a simple prototype has been built too. We’re now at a point where we are all at least okay with the solution’s tradeoffs so that we can hopefully progress on the topic. Once that is resolved, volume grids and lists are much easier to get into a releasable state.

For Each Geometry ZoneBlender 4.3 comes with the For Each Element zone. While that’s very useful already, there are other kinds of for-each zones that can be useful. One of those is a “For Each Geometry” zone, that we used to call “For Each Unique Instance” in previous workshops.

Its purpose is to iterate over each “real” geometry in a geometry set that may contain an instance hierarchy. Many built-in nodes do this internally already. For example, the Subdivision Surface node applies its effect to all meshes in the input, including those in instances. For various reasons, not all built-in nodes can or should do this. A new For Each Geometry zone would allow adding the same functionality to all built-in nodes and custom node groups which is impossible currently.

This is quite different from the “Instances” mode in the For Each Element zone. If the geometry to be processed contains many instances of the same mesh, the existing zone would run for each mesh separately, while this new zone would only run once, because there is only a single mesh.

There is already some previous design work available in #123021.

Modal Node ToolsWe reconfirmed the overall design for modal node tools from a year ago. Since then, we also noticed that there are two kinds of modal operators in Blender currently:

1. Operators based on the initial state (like bevel). These have redo panels.
2. History dependent operators using the previous state at every modal step (like brushes). These don’t have redo panels.

Both kinds of operators could be created with nodes. However, when we talked about modal node tools so far, we were mainly concerned with the second type. Many use cases of the first kind can probably be solved with gizmos or a gizmo like system. That’s because the interactive part of these operators is mostly just used to control some input values for a non-modal operator.

We also noticed that there are problems caused by fact that all node tools are just a single operator in the end (geometry.execute_node_group), but none of these seem impossible to solve. For example, we want modal node tools to come with their own keymap, but users should be able to override this keymap like any other keymap in Blender. Typically, there is a mapping from modal operator to keymap, but that does not work well here yet for the mentioned reason. Alternatively, it may be a nice solution to attach keymaps to specific assets in the user preferences instead of just to operators.

It can also be possible to register a separate operator for each node tool, but that comes with its own problems. For example, that would introduce yet another way to reference specific asset data-blocks by their operator name and can easily cause operator name conflicts too.

Field Context ZoneWe started discussing a new “Field Context Zone”. The overall design is very incomplete and we don’t have concrete answers to many questions surrounding it yet. The general idea is to give access to the field evaluation context more explicitly.

For example, for a field that’s evaluated on a geometry, the new zone would have the context geometry as input, and would output a field that depends on that geometry. This opens up new opportunities for building fields that would be much more annoying to build before.

The zone would also reduce redundancy in the design of nodes. We have pairs of nodes like Sample Index and Evaluate at Index which are the same except that one has geometry as an input and the other does not. A goal of the zone is that the Evaluate at Index node could be built out of the Sample Index node.

Extra Modifier Evaluation OutputsA limitation of geometry nodes is that it can only output a geometry that is then passed to the next modifier. Sometimes it would be very useful to output other data like another geometry or single values. Those values could become part of the “evaluated state” of an object so that it can be referenced by other objects using nodes or drivers.

This would allow outputting a bunch of vectors from Geometry Nodes which are then used to drive an armature. Additionally, we could allow outputting a bundle of values that is then passed into the next modifier. This way it becomes possible to build more rich modifier stacks without the limitation of having to encode all information in the geometry passed between modifiers.

We could even allow outputting fields and closures from objects (probably with some limitations due to the lifetime of some data). This would allow building all kinds of effector objects that encode some behavior that can be understood by other Geometry Nodes setups. This can also be thought of as a generalization of the existing force field object type.

Internal Data SocketsIn some cases, we want to add functionality that requires passing around data of that we don’t want to expose fully. A good example would be KD trees and BVH trees which allow speeding up algorithms that require finding nearest points or doing ray casts. These data-structures have well defined APIs that we could expose, but exposing their implementation details could make future optimization much more difficult, because optimizations could require breaking files.

It does not seem benefitial to add a new socket type for each kind of internal data. So far we think that it is good enough to only add a single type (with a single color) that is used to pass around all kinds of internal data.

Another use-case that came up in the past is a “Bake Reference” socket that passes data from a Bake to an Import Bake node (once we have that). The tricky thing with an Import Bake node is that it has to be able to read bakes from disk as well as packed bakes. So just giving it a file path input does not work. Reading from files should still be possible of course, but we also need a solution for packed bakes.

Group Input DefaultsEvery input of a node group has a default value. For some types, the default is currently hardcoded (e.g. an empty geometry). Others can be choosen manually in the sidebar where some socket types support more complex inputs. For example, vector sockets can be the position field by default. However, the set of possible defaults is currently hardcoded. The goal of this topic is to generalize the system for defaults to remove limitations.

The overall idea is to have a new “Group Defaults” node that has an input socket for every input of the node group. The default of any input is specified by just connecting the value to the node like in the mockup below.

We could also make it possible for some default values to depend other input values, but it’s not clear yet how much complexity this adds, so that may only be done later.

A tricky aspect is that adding a default to a socket that did not have one yet may override its value in all group nodes that use this group. That’s kind of the inverse of a problem we have already: changing group input defaults are not propagated to group nodes at all. The problem is that we don’t really know if a value has already been modified or not, which becomes even trickier when the node group is linked from another file.

Context InputsThe goal of this topic is to solve the following problems:

• We want to remove the need for control node groups as a way to get global input values (example). While useful in some setups, this approach does not work all that well when building reusable node systems.
• We have no good way to pass the hair system’s surface geometry to the relevant hair nodes in a good way.
• We have no way to override existing contextual input nodes like Mouse Position, Active Camera and Scene Time.
• We need a more flexible replacement for the “Is Viewport” node, which is used to control a performance vs. quality trade-off. Just making this decision based on whether we’re rendering or not is not good enough. Sometimes the “fast” mode of a node group should be used when in edit mode, and otherwise the high quality mode.

What all these issues have in common is that we want to pass information into nested node groups without having to set up all the intermediate links which would cause a lot of annoying boilerplate. Nevertheless, we want to be able to override all these inputs at any intermediate level.

The proposed solution is to generalize the concept of “Context Inputs”. There are many existing context input nodes (like “Scene Time” and “Mouse Position”) already. We also want to add a “Context Input” node for custom inputs. Whenever a context node is used in a (nested) node group, that will automatically create an input for the node group. Group nodes at a higher level can then decide to either pass in a specific value for that input or to not connect it. If it’s not connected, the context input will be propagated further up.

If the context value has not been provided by any node, it’s propagated up to the Geometry Nodes modifier where again users can choose to specify it. If not, we could support reading the value from a custom property of the object or scene.

There is a work-in-progress pull request for this feature.

Modifier InputsWe want to add more features to group inputs in the modifier:

• For context inputs, we need the ability to decide whether a specific input should be provided or not.
• For geometry inputs we want to choose whether an object or collection input should be used and if the original or relative space is used (like in the Object Info node).

Putting all these choices in the modifier and having them always visible is problematic from a UI perspective. Even now, the button to switch between single value and attribute input adds clutter that is not needed in many cases.

We explored options for how this could work like putting the options in the right click menu, in the manage panel or having “edit” button in the modifier that allows temporarily showing all additional settings. For now, the approach with the right click menu seems best even if it is a little less discoverable at first.

Bundles for Dynamic Socket CountsWhen we explored bundles further, we noticed that they may also provide a good solution for another long standing limitation which we discussed back in 2022: dynamic socket counts. Since then, quite some effort went into improved support for dynamic socket counts and nowadays we have them in multiple built-in nodes like all the zones, “Capture Attribute” and “Bake”. What’s missing is support for building node groups that have a dynamic number of inputs and outputs.

We could allow tagging a bundle input of a node group as an extensible socket. Then from the outside, one could pass multiple values which will become a bundle inside the group. When outputting that bundle from the group, all the values are separated again.

Inside of the group, the nodes would have to process all elements in the bundle. Built-in nodes could do that automatically. For example, when the Capture Attribute node has a bundle input, it could recursively capture each contained field and replace it with the captured anonymous attribute field. Something similar can be done in other nodes that already have a dynamic number of sockets.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

Since the start of 2023 when the Brush Asset project went into full force, the goal was also to overhaul the brush thumbnails. A lot of thought went into the new design to make it future proof and fit into the current UI.

This ended up as an active community effort to find a coherent and clear visual language. A big thanks to everyone who gave feedback and helped shape the thumbnails that will now be part of Blender 4.3!

Style Guides & Example FilesTo make the process fully transparent and easy, a detailed style guide can be found in the developer documentation. Even though no elaborate setups are needed to create authentic looking thumbnails, it also links to the repository where the thumbnails were created.

A short snippet of the style guide pageAn Open & Future Proof StyleFor about 15 years since Blender 2.5 the previous brush thumbnails have been added and were built upon. Unfortunately each new addition and iteration created more inconsistencies.

A collage of previous brush thumbnails from Blender 2.5 – 4.2A primary goal was to create a recognizable and consistent design language for all ‘Blender brushes’. For all modes and object types. The thumbnails had to seamlessly fit into the themes of the UI and reuse similar accent colors.
With the addition of Brush Assets it’s easier to create huge brush libraries than ever. This exposed a big issue.

Previously it was quite difficult to expand the set of brush thumbnails and icons. The files were not accessible to recreate the original thumbnails or create new ones and the process was opaque. Because of this many brushes that were added over the years were lacking a thumbnail or were reused existing ones. Even the process of creating new toolbar icons had a limit to how much variation is possible.

That’s why the the creation of Blender 4.3’s new thumbnails had to be easy to reproduce and that they seamlessly fit in with all other brushes. The built-in set of ‘Essentials’ brushes was expanded quite a bit with useful presets, all with new recognizable thumbnails. Users and asset authors should find it just as easy to expand it further.

Various early concepts and ideasWe also explored the idea of automatically generated brush previews during the development of Blender 2.8. But covering all possible 2D and 3D brush types and stroke effects is too complex for a procedural system.
Instead the creation should be in the hands of the user and as straight forward as possible.

Node asset thumbnails for the new hair curves were also created at the same time and the look was directly affected by this. Ideally all official Essentials assets should fit into a similarly coherent look.

Iteration Towards Ease of CreationOver the past two years the style of the thumbnails kept being shifted and refined. Many aspects were simplified or dropped in favor for making the creation and visuals simpler.

In the original design the thumbnails were supposed to make use of a set of unique icons in the corner to communicate an otherwise obscure meaning or behavior or the brush types. This idea slowly evolved into the flat colored arrows and lines on most of the thumbnails, which are much easier to create and be creative with.
Colors also stayed a very secondary element for identifying brushes to keep the thumbnails color-blind friendly.

All thumbnails were also supposed to utilize colors, but to keep them clear and focused eventually any regular draw brushes were left without unnecessary colors or strokes.

An example of iteration over the Draw and Snake Hook brushes from start to final result.There was also testing of different shaders and lighting effects but the final look always came back to the idea that anybody should be able to create a perfect brush thumbnail on the fly. Some thumbnails are a bit more specific and involved but the key look of Blender thumbnails should be accessible. Simple use of Matcap/flat shading is all you need.

To put a direct comparison to the old thumbnails above, here is the collage of the final thumbnail selection that was used as a base reference to create all remaining thumbnails. Many more new brushes and existing brushes with missing thumbnails were added since then.

A focused selection of key brushes from every mode and object typeTry it Out!More features can be added for future releases to make the creation of custom thumbnails much faster. For example by making screenshots directly within Blender to assign asset thumbnails. And by adding the exact same Matcap as part of the default selection.

We look forward to how the community will be able to expand the brush selection far more than ever before and share distinct looking brushes. Download the Blender 4.3 Beta now to test it out.

For feedback and contributing to the Essentials brushes, visit the Call for Content: Default Brushes.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

This summer, Blender had the privilege of welcoming six talented contributors as part of the Google Summer of Code program. They worked on exciting projects, enhancing Blender’s nodes, unwrapping, user interface, rendering and video editing features.

This blog post highlights their work and presents an excerpt of the results. You can find further details in the contributors final reports, linked on each section.

UV Stitching ImprovementsFinal report by Anish Bharadwaj. The project focused on enhancing UV mapping workflows by introducing a user-friendly weld-seams utility for efficient UV island merging, drawing inspiration from community suggestions.

The Seam Weld feature allows users to select two non-cyclic edge loops on two
separate UV islands and merge those islands together along that seam. This deliverable took the most time to implement of the three that I worked on due to various misunderstandings I had about how the UV system works in Blender. One major challenge was grasping the concept of loops and understanding that the UV islands are not actually connected to one another but are instead multiple loops sharing locations in 2D space.

Anish Bharadwaj

Sample Sound NodeFinal report by Lleu Yang. This project aimed to provide the ability to retrieve sounds from files in Geomety Nodes, generate amplitude/frequency response information based on several customizable parameters, and be written in native C++ with caching/proxy operations to speed up execution.

The video below used Sample Sound node and simulation zone together, forming a 3-D waterfall plot. The project file is attached in the description of my working pull request. The audio is made by myself and licensed under CC0.

Lleu Yang

Geometry Nodes: File Import NodesFinal report by Devashish Lal. This project aimed to reduce disk usage by externalizing data and also enabling data visualization workflows in Blender. Devashish introduced OBJ, STL, PLY, and CSV import nodes, currently behind an experimental feature flag in the alpha version.

Blender doesn’t have the capability to import CSV files so the first thing was to implement the importer and we didn’t wanna use existing CSV libraries cuz it’s is just simple string handling right ? well the importer is still pretty simple but there were a lot of edge cases although the most time I spent was in designing the importer figuring out which individual functions should be created and utility classes.

[…]

I spent a week looking at the existing OBJ and PLY importers to get inspired into writing the CSV importer and ended up with an implementation that I am quite proud of.

Devashish Lal

Sprucing Up the SequencerFinal report by John Swenson. This project aimed to improve snapping support in the sequencer by adding the option to snap strips to markers, add a link property to all audio/video strips for a given video file and add the ability to select active channels.

After meeting with [my mentor] Aras at the beginning of the summer, we decided that my first order of business should be to get snapping working in the VSE Preview – in theory it’s simple, wouldn’t require as much back-and-forth to determine what the UI should look like or how it should work, etc.

John Swenson

Improvements to the Blender macOS User Interface ExperienceFinal report by Jonas Holzman. The project aimed at adding native macOS menubar support and inline titlebar decoration to Blender.

Over this summer, I got to work on improving the Blender macOS User Interface Experience. While the initial goal of the project was to add native macOS menubar support and inline titlebar decoration to Blender, the end goal ended up shifting towards more general macOS and general UI research, while still working on client-side window decorations, as outlined in this kickoff meeting note by my mentor Julian.

As such, this project ended up focusing on a new cross-platform API for client-side window decorations, combined with a practical colored titlebar macOS decoration implementation. I also worked on general macOS user experience and interface improvements, as well as backend refactors, while also experimenting with additional general UI enhancements.

Jonas Holzman

Improve Distributed Rendering & Task ExecutionFinal report by David Zhang. The main objective of this project was to enhance the distributed rendering and task execution capabilities within Flamenco through several key improvements.

I have implemented the ability for users to pause jobs in Flamenco, introducing a new paused state with relevant status transition logic. The frontend has been updated to allow users to pause a job, and comprehensive unit tests have been added to ensure the new functionality works correctly with existing systems. This feature has been fully implemented, reviewed, and the pull request has been merged into the main codebase.

David Zhang

That’s it! Make sure to check the contributors full reports for further details.

I want to thank all mentors, contributors and of course Google for accepting us into the GSoC program again. It’s been a pleasure to participate in the 25th anniversary edition this year and we plan to apply next year again.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

A Video Sequence Editor workshop was held in Blender HQ on August 2024. Various topics related to VSE were discussed — some already in development, some planned to work on soon, and some others that we want to happen, but it is not sure when or who would do them. Participants were Dalai Felinto, Falk David and Sergey Sharybin from Blender, and myself as an outsider. I am Aras Pranckevičius, and I have been contributing features and improvements to VSE in Blender 4.1 and 4.2.

Previous VSE workshop was held two years ago, and while overall design and wishes for VSE features remains the same, it is clear that with the current amount of VSE contributors the “these tasks will take months to complete” bit was too optimistic (more contributors would be very welcome!). Part of this workshop was about discussing tasks that we have a clear idea that someone would actually do them “soon”. However for other parts it is still unclear what their timelines are.

Larger PictureIn trying to answer the question “why VSE exists?” or “should Blender have VSE at all?”, it helps to keep overall goal in mind. Which is: VSE is a tool to do story telling. Ideally, you’d be able to do layout work, storyboarding, grease pencil annotations directly from your sequencer space. Timeline, preview and powerful tools, without need to have a secondary Blender instance.

“Just assembling a video out of several video clips”, while possible to do with Blender, is not the primary goal. VSE interaction with grease pencil and scene strips, as well as everything being inside the same application, is something that can set Blender apart from other video editing applications.

That is the overall idea, but it needs a lot of work to make it into a polished reality.

One of the large issues is that Blender can display one scene across the whole application (the “current scene”), but VSE data lives in a scene! Which means you can not edit the VSE timeline, and edit some scene (used by a scene strip) at the same time. “Developing Grease Pencil at the SPA Studios” BCON22 talk is one example of how people approach solving this. Falk presented several possible solutions, see forum thread for details. One of the large ideas was to move VSE outside of the scene, into a “Movie” object or something similar. We discussed pros and cons of these approaches, as well as tried to make a quick prototype. No decision was made on final design, but this is something that the team will come back to.

PerformanceSomething that almost any area of any product would appreciate, is more performance. VSE is not an exception. In Blender Studio, largest issues are preview performance, and time taken to render daily “playblasts” (not a full movie, but a section of it for status updates of meetings). Improving performance might be a lot of technical optimization work, but it is “easy” in a sense that most of it does not require design decisions or workflow changes. If things are “just faster”, everyone benefits.

See forum thread for details. Primary things that were discussed were:

• ffmpeg related bits: reducing stalls when starting playback of new movie clip, GPU acceleration etc.,
• CPU SIMD optimizations,
• GPU usage within VSE,
• Proxies, caching and in general faster playback within Preview area,
• Scene strip optimizations.

Overall, primary goal is to make preview (playback, scrubbing) smoother, secondary goal is to make rendering faster.

SummaryVarious other features and improvements were discussed: nodes, text improvements, strongly typed channels, and so on. See forum thread for details.

Many of features outlined in previous workshop (dedicated color grading editor, media bins and interactive file preview) were not explicitly talked about. We still want to have them! But realistically, with amount of people actively working on VSE even getting everything above is “uncertain when”. VSE did get improvements in 4.1 and 4.2, and we hope to keep up similar pace. This is a call for more contributors :) If you want to help, reach out in #sequencer chat channel.

View Details

During July a workshop was held at the Blender HQ about online asset libraries. The design discussions are the first step to scope the project, which is planned to follow the Brush Assets project.

• Online asset libraries
• Extensions and asset libraries
• Variants, representation and versions
• Organizing assets
• Deliverables
• Next steps

Online asset librariesTo enhance its out-of-the-box experience, Blender will come pre-configured with a remote asset library called Online Essentials, containing a selection of CC-0 assets. These assets include crucial resources like base meshes, materials and brushes, readily available to all users.

To integrate the asset system with the internet, a new type of Asset Library will be supported: Remote Asset Library. This will work similarly to the existing (Local) Asset Library system but with a few differences:

• The library content can be downloaded on-demand and cached locally for reusability.
• Each blend-Filemust be self-contained (no linking between files is supported).

Additionally, specialized asset libraries, such as content from Blender’s open movies, may be accessible on the extensions platform.

Extensions and asset librariesHow do asset libraries fit within Blender’s extension framework? Both extensions and asset libraries are pivotal in expanding Blender’s functionality, and conceptually asset libraries can be seen as a type of extension.

However, for simplicity’s sake, they will continue to be configured independently. Adding a remote asset library will be done on the Asset Library tab (to be added), while the Get Extensions tab will be reserved for Add-ons and Themes.

They will still share the same internet access policy and will also be available from the Blender Extensions Platform. The main difference there is that assets are more strictly curated while the other extensions are a purely community-organized project. This can be still a community project though.

Variants, representation and versionsAn important topic for assets is variants, representation and versions. As a recap, these are example of them:

• Variants:
  • New, old, damaged.
  • Dry, wet.
  • Red, blue.
• Representation:
  • LOD 0, LOD 1, …
  • 1K, 2K, 4K, 8K.
• Versions are the state of variants and representation. (v1.0.0, v1.0.1, etc).

For a simple example imagine an asset with different color variants, and different geometry resolution for different levels of detail:

Note that not all representations are required on all the variants.A more realistic example is a production character like Sintel:

Asset: Sintel.
Metadata: Name, Author, License, Tags, Catalog, …
Data-blocks: Damaged Lod 0, Damaged Lod 1, New Lod 0, New Lod 1.

Sintel LOD-0 representationSintel LOD-1 representation

The existing asset system is limited to one variant/representation/version per asset. For the online project, it will be important to revisit this, particularly with regard to representations – users shouldn’t have to download a 8K HDRI when a simple 2K JPG panorama is sufficient.

This has profound implication for asset integration in Blender, even affecting its definition.

What is an asset?Assets were originally defined as: “An asset is a data-block with meaning.”

It’s been 4 years since then, and it’s time to revisit this definition with variants in mind: “An asset is a data-block with meaning, combined with its variants and representations.”

In this context, “meaning” refers to metadata (such as name, author, etc.), which is common to all the different variants and representation available for use.

To support this, Blender needs a way to connect different data-blocks under the same ID metadata.

Organizing AssetsFeatures such as tagging, advanced search, smart catalogs, and the ability to mark favorites are essential tools that can help artists navigate and use their assets more efficiently:

• It should be simple to change the catalog, create or remove tags, for any asset, whether the asset ships with Blender, comes from a remote asset library, or belongs to the current blend-File.
• Advanced search should be supported, with a syntax that allows for AND, OR, specifying tags, and using wildcards.
• Search results should be saveable as smart catalogs for quick access in the Asset Shelf and Asset Browser.
• Any asset can be marked as a favorite and will accessible in a new Favorites catalog, which will always be displayed in the Asset Shelf.

While not directly related to online assets, effectively organization is a pressing need that will only become more critical with the addition of online asset libraries.

This is a good place for the community to help, as each of these topics has its own set of “good-to-have” tasks, which may have to be postponed in order to prioritize the online features.

DeliverablesTo keep track of progress and encourage community involvement, the proposed deliverables are outlined on the issue tracker. They are also listed here; please note that this list may change.

Improving asset management and experience:

• Asset de-duplication (append & reuse) #115660
• Metadata customization, including catalogs
• Favorites #125432
• Tag system improvements #125430
• Advanced search syntax #125434
• Asset publishing (local) #125437
• Finish asset system refactor #122439

Online asset libraries:

• Remote Asset Library (simple) #125597
• Remote Asset Library (advanced) #125600
• External thumbnails #125598
• Online essentials asset library content creation
• Authorized access (for commercial/private remote asset libraries)

Targets that still need a better definition:

• Asset representations
• Asset variations
• Python hooks
• Online publishing
• Non-data-block assets

Next StepsAs we move forward, the focus will be on refining the design, breaking down the technical requirements, and planning.

As mentioned, I hope we can also count on the community for the more approchable targets, such as the asset experience deliverables. If you want to help, be sure to reach out in the #asset-project chat channel.

Support the Future of BlenderDonate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender

View Details

After over 2 years of development, the EEVEE Next project has produced a major evolution of the Blender viewport system, set to be a key feature of the upcoming 4.2 LTS release.

Project goalsThe EEVEE Next project was aimed at modernizing viewport rendering, address technical debt and overcome existing design limitation. The main target of the project was to improve performance and visual quality of viewport rendering, leading to a better user experience while building, animating and rendering 3D scenes.

What changedThe viewport system is now more predictable and supports a wider range of lighting and shading corner cases. A new shadow system was introduced, providing more stable and higher quality shadows, while remaining memory efficient. Other noteworthy features are a new global illumination system, unlimited lights in a scene, improved volumes rendering, motion blur and depth of field.

More detailed technical documentation is available in the Release Notes, while the functionality is described in the User Manual.

Here are some overviews from the community.

Compatibility issuesSignificant efforts have be made to avoid breaking compatibility with previous versions, but given the magnitude of the change, and the number of workarounds used by artists in production, some issue are expected.

A migration guide is available to mitigate these issues. If you are encountering undocumented behavior, please do share your findings and help to improve the guide!

Next stepsThis is the foundation of a new interactive lighting pipeline. In the next releases we can expect improved performance, both for rendering and shader compilation, and hardware-accelerated raytracing.

Congratulations to Clément, Miguel and Jeroen on this milestone. Special thanks to the community of contributors for working on stabilizing and integrating on several platforms.

Thumbnail image by Hamza N. Meo.

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender

View Details

Late in 2022 the initial design for the Brush Assets1 was laid out.

Earlier this year it was chosen to be one of the development targets for 2024. Much has changed since its original design, including a fundamental aspect that improves usability.

It is now integrated into Blender, as part of the Blender 4.3 release scheduled for November 2024.

New Brush WorkflowIn previous versions, brushes were saved in the current blend-file like any other data-block. It is very common to reuse, share and update brushes, so the traditional link/append workflow proved cumbersome.

Brushes are now assets, benefiting from the same ease of use and sharing capabilities as other asset types.

Combined with new ways to access brushes in asset libraries and a quick way to update them, this should improve the workflow considerably.

Essentials LibraryThe Essentials asset library was extended to bundle a number of brush assets with Blender:

So far all the included brushes have been converted into assets. Over time this library can grow to accommodate new brush variations.

Brush ToolThe new brush asset workflow is implemented wherever brushes are used, including sculpting and painting for meshes, Grease Pencil, and (hair) curve objects, as well as vertex, weight and texture paint (in the 3D Viewport and Image Editor).

A single, unified Brush tool replaces all the previous brush-based tools. Activating a brush automatically activates the Brush tool.

The unified Brush tool de-clutters the toolbar and makes the difference between tools and brushes clear.For user created brushes, there is a guide on how to convert them as part of the 4.3 release notes.

Using Brush AssetsAsset ShelfThe new asset shelf introduced in Blender 4.0 has been extended to make use of the brush assets. It was also added to the Image Editor for texture painting.

Switch to a mode such as sculpting to find the brushes available for that mode.

Brush Selector PopupBrushes can also be selected from the brush drop-down on the header, tool panel, or by shortcut (shift + space)

Edit Brushes from AnywhereBrushes can be created and updated from any Blender session, without having to manually edit the files in your asset libraries. This might be all you ever need for your personal brush management.

It is still possible to take full control by manually editing asset library files, for example to carefully curate an asset library to prepare it for sharing with others.

For those following the early iterations of this project, this means there is no more need for drafts. The brushes can now be created on the spot whenever needed.

Creating a New Brush AssetTo create a new brush asset, all you need to do is pick a brush to use as a base, and select Duplicate Asset in the tool options. You can choose one of the asset libraries configured in the Preferences (by default the User Library), and Blender will save the new asset in there.

After tweaking the settings, you can save the changes with Update Asset, and use Edit Metadata or Preview Image to change other data for the brush. Only brush assets created using the Duplicate Asset method support being edited this way. Others are managed as normal local brush data-blocks.

As mentioned before, Blender ships with a set of Essential brushes, covering all possible brush types to use as starting points for brushes.

Generated Asset Blend-FilesBrushes created using the Duplicate Asset operator will be saved as special .asset.blend files generated by Blender.

What is so special about these files? They are created and managed by Blender’s asset system, and contain a single data-block (plus any dependencies packed). It is not possible to overwrite these files from within Blender, although you can still open it and save it as a new file, which will then be just a regular blend-file. This is to prevent data loss as assets get changed, since the asset system may regenerate the file which would overwrite any manual changes.

A warning will be displayed when opening such files, and saving the file will prompt you to save as a new file instead.

Feedback NeededDownload the latest Blender 4.3 daily build to try Brush Assets for yourself. If you have any feedback, please drop a message in the DevTalk thread.

Links* Blender 4.3 Release Notes * Daily builds of Blender 4.3 (alpha) * User Manual * Brush Assets Workflow [old outdated design]

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender1. Brush and Asset Drafts ↩︎

View Details

We are just a few weeks away from the release of Blender 4.2 LTS. A major upgrade with loads of new features and improvements that require testing.

It is impossible for developers to cover all use cases that need to be tested, this is where the power of the community comes in. Let’s put it to the test!

What to TestWhile Blender 4.2 LTS brings updates in pretty much every corner, some of the main ones are:

• EEVEE – Known as project “EEVEE Next”, a new render engine replaces the old one and needs as much testing as possible. Open your old files and check that they render properly. Read the migration process for details.
• Cycles – Ray Portals, Thin Film Interference, updates to shaders, denoising, sampling, and more. Open your old scenes and check if they still render the same.
• GPU-accelerated Compositor – A new performance setting allows you to use the GPU to compute the compositing. Find it under the Performance panel in Render properties. In most cases it should render faster and look fairly similar (although not 100% the same).
• Python API – Try out the new methods, commands, and see if the documentation about breaking changes regarding statically typed IDProperties, EEVEE, and others is clear.

Plus plenty of new features such as the introduction of Extensions, per-collection export, sculpt polyline tools, re-visited Shade Auto Smooth workflow, and so much more.

Hardware RequirementsHardware requirements have changed as well, on Windows and Linux a CPU with SSE4.2 is now required. This is supported since AMD Bulldozer (2011) and Intel Nehalem (2008).

Make sure to check the full list of compatibility changes (for Blender 4.2 LTS and future releases).

How to TestTesting can be pretty straight forward:

1. Download the latest Blender 4.2 LTS Beta
2. Open your old scenes (backup first just in case)
3. Check that everything looks and works fine
4. Found a bug? Report it. Within Blender go to Help → Report a Bug.
   Read more about writing good bug reports.

You can also try out the usual demo files.

For feedback on the features and changes, check the individual threads under Feature & Design Feedback on the forums.

Thank you for helping to make Blender rock solid!

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender

View Details

In May 2024, various Geometry Nodes contributors came together in Amsterdam to discuss many design topics. This post gives a general overview of the topics that were discussed. You can also read all the notes we took during the meetings.

GizmosThe overall design for gizmos had already been agreed upon during the last workshop. However, there were still a few open questions regarding visualizing the backward flow of gizmos and controlling visibility. Furthermore, we discussed an additional Transform Gizmo node which would target the common combination of location, rotation, and scale inputs.

For the backward flow we want to explore double links which kind of shows that the gizmo controls its input value. A few alternatives have been proposed like showing a gizmo icon on the links however the double links seemed better in the end. We still need to try how this will look in practice. If the link visualization works, we can reduce the amount information we currently show in sockets in the gizmo patch because it’s redundant. The gizmo icon should only remain visible where the actual value is that is controlled.

Gizmo visibility can be controlled in a new gizmo panel on group nodes and the Geometry Nodes modifier. We started preferring this option compared to showing the gizmo visibility directly at each input value. This also works better if a gizmo controls more than one input. An optional gizmo panel could be added to node groups which could allow defining groups of gizmos whose visibility can be controlled together.

BakingBaking in Geometry Nodes was also discussed in the last workshop. Since then, we got the Bake node and Simon was able to gather some initial experience of using it in production. That made it all the more clear that higher level tooling is necessary to manage multiple bakes. The centerpiece of that tooling will be a new display mode in the outliner that lists all the bakes, allows filtering, and makes it easy to perform batch actions.

Being able to tag bakes is necessary for organizing them. One can either add tags on the bake node directly, or on the “bake instance” which is stored on the modifier (the same bake node can be used in different contexts). When to use each kinds of tag depends on the use-case and how a production environment is set-up.

For ease of use and sharing of files, we do want to add the ability to store the baked data in the .blend file directly. This functionality should ideally be integrated with the more general packing and unpacking features Blender already has.

Path VariablesOne thing that often comes up when talking about baking is the ability to control file paths at a higher level. For example, one may want to specify a bake directory at the scene or even project level. Individual bakes should be able to specify their path relative to these paths. To support this, we would like to introduce so called path variables like ${SCENE_BAKE_DIR}. Those can be be used as part of filepaths elsewhere and are replaced by the corresponding value when the path is used.

The internal and Python API for path variables requires some more thought. The tricky aspect is that often these variables are not global but depend on context. An additional complexity for bake paths is that we also want to remember the path that we actually baked to last time separately from the path that contains the path variables.

Rename Sockets in NodesIt’s inconvenient to have to go to the side bar to change the name of various sockets, especially when the name is created in the node editor itself rather than the sidebar, by connecting a link to an extension socket. The solution is support for renaming sockets directly in nodes. In theory, we could also support removing and moving sockets, but we ignored that part for now.

Renaming should not happen with a single click on the label because that would make it annoying to move nodes. Ideally, we would support double-click and ctrl+click but unfortunately double-click is hard to do in the current state of UI code. Furthermore, it would be great to have some indicator in the UI that shows when a label is renameable. A box on hover, similar to the one in list views can work. This could potentially also be used on the breadcrumbs in the node-editor.

Tools for Node Tree UXFor this topic we went over various ideas to improve the UX when working with larger node trees. Among others ideas, we talked about multi-line comments, custom zone colors, link portals, frames, improved search, drag-and-drop for attributes, separators in node groups, viewer node position, and huge add menus. See the meeting notes for more information.

We also went a bit deeper into discussing a new interactive “slide” operator which is supposed to become a more controlable and predictable alternative to the auto offset feature that automatically moves nodes apart to make space. Development on this has started, but we are still working out the exact desired behavior.

It’s planned that Blender 4.2 comes with the new extension system, which increases the separation of features that are core of Blender and part of third party add-ons that were only shipped with Blender. The most important add-on for us is Node Wrangler. We went over some of its features because it’s now more urgent to move some of them into core.

Asset EmbeddingAsset embedding started being a bigger topic last year when we noticed that our existing import methods of linking and appending don’t work so well for assets, especially also for assets we want to ship with Blender. We already had a meeting a month prior where we discussed an asset linking proposal. As a follow up to that, a new proposal was written which we discussed this time.

There was much more agreement on the proposed approach now. However, there was still some disagreement on what libraries in Blender are or should be. We concluded that we will avoid changing the definition of a library (which is just a file reference) at the cost of some additional complexity in order to avoid name collisions when different data-blocks with the same name come from the same source file at different points in time. Also the case when the same data-block comes from different source files has to be considered.

The next step for this topic is to better define how these issues should be addressed and to then prototype the solution.

Menu SocketMenu sockets and the Menu Switch node were introduced after the last workshop in Blender 4.1. It was known already that this first implementation is limited in the sense that one needs a workaround to switch multiple different types with the same menu. That limitation has not been resolved yet.

There is another issue that feels like a limitation which is that the Menu Switch can’t be copied without making the menus incompatible. This misses that the way to reuse the same Menu Switch on different values is to make it a node group. The limitation that one can’t simply copy the menu switch node and have menu items automatically match by name is very important for us to be able to use these menu sockets for built-in nodes in the future. It also allows for renaming and reordering of menu items without the fear of breaking node trees that depend on it.

The main immediate problem is that it’s not obvious enough that one can use node groups to reuse a menu socket. One way to address is this show this information to the user when attempting to reuse a menu the invalid way. We’ll likely further generalize this by always showing extra information when a link is invalid which would help in other places too.

Being able to dynamically change socket visibility based on which menu item is selected is not yet supported. However, we checked over the design from the last workshop again, and came to the same conclusions.

Field ContextWhen working with non-trivial node-trees, it’s sometimes hard to tell which context a specific field is evaluated on. We discussed different ways this can be addressed. A simple first measure is to show the domains a field is evaluated on in a tooltip.

More importantly however, we want to be able to highlight where a field flows and which geometries it’s evaluated on. For that we want to extend the ability to select sockets and to visualize extra information based on the socket selection. This can also become a more general feature that can be controlled in the overlay popover. For example, at one point one might want to see where a field is evaluated and at another time all the nodes that are affected by a specific socket.

Even on simpler node-trees this can be a useful learning and teaching tool.

ListsLists as a general feature for Geometry Nodes have been planned for quite a while already but they were never discussed as part of a workshop. The general idea is to support standalone lists and to perform various operations on them. In this context, standalone means that they are not tied to any geometry. That also means that they can easily go out of sync with a geometry when some topology-changing operation is applied.

Besides lists that are just data, we also want to support list fields. Nowadays, a field computes a single value per geometry element. With list fields it would be possible to work with multiple values per element. This can also simplify working with topology nodes a fair amount.

Initially, we’ll likely only have flat lists instead of also supporting nested lists. Those would complicate the type system and one needs to be much more careful with how to expose them to users to avoid many performance pitfalls. We could still add them later on if required.

Socket ShapesCurrently, we use three different socket shapes to represent different kinds of values in Geometry Nodes. A circle means that something is a single value, diamonds mean fields, and diamonds with dots reference a single value but can become a field.

This works reasonably well so far, but things become more difficult with the introduction of volume grids and lists. As the volume proposal shows, we intended to use different socket shapes for volume grids, and later also for lists. However, this turned out to be more challenging than expected. It would be easy if every socket only had one specific kind of value. In reality, many nodes accept different kinds of values requiring an additional more general socket shape like the proposed asterisk. However, depending on the node or node group, the set of allowed types can be fairly arbitrary subsets of all types which the asterisk shape can’t communicate at all.

More complexity arises within node groups where on the inside we don’t really know what will be passed in. Currently, we always fall back to assuming a field is passed in but this assumption might not work anymore when we have more types. Yet more complexity comes from supporting list fields and potentially nested lists which by the current logic would require different socket shapes too. The final piece of complexity comes from the desire to show what value a socket currently has and also what it could be (like the diamond with a dot).

We spent quite some time trying to figure out rules for what these socket shapes should mean exactly and how they propagate through nodes. Unfortunately, we didn’t solve this yet even when we relaxed some of our goals.

The most promising direction currently seems to be to simplify what we intend to show with socket shapes a lot and to rely on other means to communicate the necessary details of what types a socket has and could have. For example, we could keep the current set of socket shapes but say that the circle can represent any kind of data including grids and lists whereby the diamond shape can mean fields and also list fields. The downside is that now it’s often less clear which sockets are allowed to be linked just by the socket shape alone. For example, a float grid and single float value would have the same socket shape, but it’s not valid to connect a grid to a single value. Additional information in tooltips, better error reporting for invalid links, graying out sockets that one can’t connect to when dragging a link and other overlays might solve this well enough. The upside is that this makes the type system much easier to extend without sacrificing the socket shapes we have already.

Local Node-GroupsThe primary purpose of node groups is to share a node-tree in multiple places. However, this focus on share-ability makes use cases where sharing is not the main goal more cumbersome. For example, when using node groups just to organize a larger tree without worrying about reusability, it is unexpected that the node group becomes available in the add menu, can be linked to, and generally clutters data-block lists where it can also lead to name collisions.

The idea with “local” node groups is to have node groups that can be used within a specific context but don’t leak out of it. The most constrained approach would be to support single-use node groups that are completely embedded in their parent data block. Copying the group node would then also copy all the nodes within. We could support reusing embedded node groups multiple times within the same parent group. The next step up would be to allow using groups in multiple other groups without adding them to the Add menu. That can already be done by prefixing data-block names with a dot which hides them in various places.

So far, all of the mentioned solutions only apply to node groups. However, it turns out that the same problem also exists for many other data-block types. For example, a character might consist of multiple sub-objects which should really stay local to this character. Or a node group might use some separate curve object as profile shape and the object is not expected to be used separately from the node group. Ideally, these data-blocks that live in different contexts also shouldn’t be able to have name collisions. This more general solution has not been explored further by us yet, but will likely become a topic again.

Grease PencilOne of the big new advances with Grease Pencil 3 is the ability to use Geometry Nodes. The most challenging aspect is how to integrate the idea of grease pencil layers with how plain curves work in Geometry Nodes. Most of these things have been discussed at the previous workshop already.

This time we focussed more on how to turn grease pencil into separate curves and how to put them back together, ideally without losing too much information. This will allow using the full power of Geometry Nodes to modify grease pencil data but also to generate it from scratch. The fairly straight forward solution is to have nodes that turn grease pencil layers into curve instances and back.

Custom ViewerThe primary goal of custom viewers is to allow building node groups which act like the Viewer node but can do additional processing. For example, one could build a vector field viewer that evaluates the field at various positions and draws arrows. Density grids could be displayed as boxes containing the individual voxels and tiles.

The main difficulty is that now there are different kinds of viewers which makes it less obvious which one ctrl+shift+click should connect to. A simple and probably good enough solution is to connect to the viewer which was active the most recently.

We went over different ways to mark node groups as viewers. For example, a simple heuristic could be that node groups which don’t have output sockets are treated as viewers. That would work fine for now in Geometry Nodes, but breaks down if we get export nodes which also wouldn’t have outputs. Of the proposed solutions, just a simple option on the node group that the user can control manually seemed best. This flag could also be set automatically when creating a new group from just a viewer node.

Besides custom viewers we also briefly talked about the ability to show multiple viewer columns in the spreadsheet and about other kinds of built-in viewers that we’ll likely need eventually. Especially once we have lists, it would be good to have a viewer node that can show the lists content directly in the node editor without having to use the spreadsheet. Another topic was the ability to have multiple active viewers but we did not get far with that yet.

For-Each ZonesFor a couple of releases, we have repeat zones which allow running nodes in series an arbitrary number of times. What’s missing is the ability to iterate over many elements in parallel. For example, one might want to generate 10 different trees or modify each unique instance in an instance hierarchy individually.

There are different kinds of for-each zones. The most common one is the For-Each Geometry Element zone (name still pending). It has a domain dropdown and allows iterating over e.g. all points of a geometry individually and producing some value for each which are then joined together. We noticed that there are two different kinds of outputs in this zone. One is the original geometry with newly added attributes which are initialized by the zone. The other are new geometries which are generated from each geometry element and then joined together.

The initial implementation would iterate over the geometry elements one by one, based on a selection. This could be extended later to support iterating over groups defined by a group ID. For now, one would need the Split to Instances node to iterate over groups. A problem with supporting groups directly is that they break one of the core mechanics of for-each zones which is that they can turn fields from the outside into single values on the inside which allows them to be used in many nodes which don’t support fields. This problem could be aleviated by turning fields into lists instead of single values on the inside.

Other kinds of for-each zones could iterate over a set of indices, list elements, grid voxels and unique instances of an instance hierarchy.

View Details

Today the extensions platform becomes generally available in the development version of Blender, and is on track to be officially available in the upcoming Blender 4.2 LTS, to be released in July.

When opening Blender’s preferences, the “Add-ons” section has been replaced by “Extensions”. After explicit authorization to connect to the extensions.blender.org server, a listing of add-ons and themes will be available. It is now possible to install, enable and update them directly from this interface.

Add-ons and themes that shipped with Blender have been moved to the online platform and their source code is now hosted at projects.blender.org. Authors of those add-ons and themes are encouraged to claim ownership by reaching on the DevTalk forum.

Blender Extensions Extensions are add-ons, themes, and potentially anything else that can extend Blender’s native functionality (e.g. key maps, assets). An extension is an archive (.zip) containing the files and a manifest with metadata such as license, copyright, permissions, useful links, etc. An extension can be manually installed in Blender through the preferences interface, using drag-and-drop or via extension repositories (see below).

Creating a new extension, or converting an existing add-on or theme is simple and well documented at docs.blender.org.

Extensions introduce the concept of permissions for add-ons, with the goal of making users more aware of the behavior of an add-on which might require file system or internet access. This is not a security-oriented feature, rather a way for developers to be more transparent about their intentions.

RepositoriesRepositories are how extensions are made available in Blender. By default, Blender offers a local repository (to manage and install extensions without any online connectivity, similar to previous Blender versions) and an online repository (extensions.blender.org). Staying true to the principle that Blender won’t connect to the Internet by default, this repository must be manually enabled the first time in order to be used.

Extensions manager in the Blender user preferencesMore repositories can be added via the Repositories popover. Developers interested in setting up their own repository (for example to offer commercial add-ons) can check the extensions platform source code, as well as the specs for the listing API are available in the developer docs. Optionally they can host a single JSON file listing all the packages of the repository.

Interface to manage extension repositories within BlenderThe Extensions PlatformThe reference implementation for extension repositories is the official extensions.blender.org website. Besides hosting the add-ons and themes available in Blender’s previous releases, its goal is to host free community-maintained extensions.

This is a community platform, which relies on a public review and approval process. Reviewers are welcome to check out the Approval Queue, join the extension-moderators chat and test and validate extensions.

CreditsA bit of history: after the initial announcement and proof of concept from 2022, design and development has been prioritized since the beginning of 2024. While the initial goal was to provide an online platform hosting Blender add-ons, themes and key maps, the scope of the project was expanded to integrate the platform in Blender itself, providing a better user experience.

Thanks to the key contributors to this project, in order of appearance:

• Anna Sirota
• Pablo Vazquez
• Dalai Felinto
• Campbell Barton
• Oleg Komarov
• Márton Lente
• Nika Kutsniashvili
• Victor Chedeville

Special thanks to the whole Blender developers community and early contributors for helping to reach this major milestone.

View Details

The Animation & Rigging module presented the progress and future plans for Animation 2025, at Blender HQ. This blog post describes that presentation.

Related posts:

• The Future of Character Animation
• Animation Workshop: June 2023

by Sybren Stüvel & Nathan Vegdahl

1. The DreamWhere do we want to go with Blender? These desires stem directly from the workshops linked above.

Multiple animated and strongly interacting characters, with a prop. Cosmos Laundromat (2015), Blender Studio.We want to be able to keep animation of related characters / objects together, in one “Animation” data-block. This should include those constraints that are specific to the shot. That will make tightly coupled animation, like Frank, Victor, and the rope above, easier to manage.

Screenshot of Blender, showing the Rig Nodes prototype.We want to have rigging nodes. Given the desire to keep shot-dependent constraints with the animation data for that shot, it’s likely that these will be somehow implemented with a new rigging nodes system.

Mockup of what a bone picker could look like, showing Ellie from Sprite Fright (2021).We want to have a system for bone pickers, so that animators can work faster and with a less cluttered 3D viewport.

And there are lots more ideas. Example-based drivers, multiple rest poses per rig, custom bone axes, editable motion paths, ghosting (also editable, of course), animation retargeting tools, dense animation workflow, tools for wrangling motion capture data, the list goes on.

So these are all ideas that we would love to do for Animation 2025. All by 2025?!? (To be clear: no, that’s not possible with only 2.2 FTE in paid developers). Well, let’s stop dreaming, step back, and look at…

1. The ConcreteSo far the Animation 2025 project has already brought many improvements to Blender.

— Already in BlenderThe features listed below are all already in Blender or will be released in Blender 4.1:

12x faster graph editor in Blender 4.0 (in this case, compared to Blender 3.6, YMMV).

→

Blender 4.0 replaced the limited armature layers system with the more powerful bone collections, with nesting and more visibility options coming to Blender 4.1.

Many of the Animaide tools were brought to Blender natively. And there is more:

• Camera-relative motion paths
• Keying workflow improvements
• Weight paint mode selection tools
• “View in Graph Editor” on any property
• Copy Global Transform
• Configurable bone relationship lines
• “Parent” transform space
• New F-Curve smoothing operators
• NLA is now fairly usable
• Multi-editing of F-Curve modifiers
• Bendy Bones better bendyness

— What we’re working on right nowCurrently the Animation & Rigging module is working on a new layered animation system: Project Baklava. Why this name? Everybody knows that Baklava consists of two ingredients: layers, and deliciousness. And with ‘deliciousness’ we actually mean ‘Multi-ID animation’.

These two, Layers and Multi-ID animation, form the two pillars for a new animation system. More technical details of this system are described in Animation Workshop: June 2023.

The system itself will just be “Blender’s animation system” in the future. Baklava is the project name.

Mock-up of what the new layered animation system could look like, by Nathan Vegdahl.The above mock-up shows what this new animation system could look like. Two characters, the monster and Bob, are animated from the same Animation data-block. This means that trying out alternative takes for the same animation no longer requires swapping out multiple Actions; instead it can just be done by (un)muting different layers in the animation.

Nathan made a lot of UI/UX designs, including venturing into some further-future topics like animation-level constraints and swappable rigs. To see these designs in more detail, visit Initial UX design for the new Animation data model on Blender Projects.

Working Animation data-block, animating two separate objects at once. Very much a developer-only GUI at this point.In the mean time, Sybren has been working on implementing the data model. It consists of the Animation data-block, which is intended to replace the Action. At this moment the DNA and RNA code are present, and evaluation and simple mixing of layers works too. And, as you can see above, it can animate multiple objects simultaneously.

— Next Step for Project BaklavaThe goal is to get this into animators’ hands as soon as possible. For this, a few things are still necessary:

• Make it possible to key things. The above animation was made via Python, which is suboptimal.
• Show the animation in the dopesheet & graph editor. This is relatively simple (famous last words), as the new Animation data-model still uses the same F-Curves. Any tool that can work with those could work with the new Animation as well.
• Just ~~deliciousness~~ Multi-ID, no layers yet. To keep the feedback loop as small as possible, we decided to focus on the biggest unknown first. And since we already have a decent idea about how layers should work, Multi-ID animation is prioritised.

— Further StepsOnce the Multi-ID animation is in, the efforts will shift towards more tooling, and layered animation.

• Migration tools: for merging multiple Actions into a single Animation. Or to bake down an Animation data-block into an Action per animated object.
• A new editor for layered animation. At first this will likely be a side-panel for the dopesheet. In the longer term, it should be an editor by itself that ideally can replace the entire dopesheet.
• Tools for merging & splitting: animators should be able to “play” with layers. It should be easy to split up layers by object, merge them down, split selected F-Curves off into a separate layer, etc.

• Tools for baking: it should be possible to tweak an animation by adding one or more layers on top, then bake that layer down while keeping the same animation.

• The Management“Make Blender ready for the next decade!” was Ton Roosendaal’s missive for the Animation 2025 project. Exploring this was a lot of fun, and brought us many great ideas (see 1. The Dream above). To keep things manageable, this is our proposal:

• Keep the umbrella goal of futurifying Blender’s animation & rigging systems.

• Rename what we’re doing now to “Project Baklava“. This reduces the work to a significantly smaller, and hence easier to manage, project with concrete steps & deliverables.
• Prioritise other “umbrella projects” as we go.

— The PlanningAs we wrote above, one project at a time. Now it’s Baklava. We aim for inclusion in the main branch as an experimental feature in Q2 2024. The first ‘working state’ will be single-layer, multi-ID animation. After that we might add layers, but maybe we’ll switch to bone pickers or rigging nodes. The point is: we don’t have to wait until Animation 2025 is “done” to refocus and work on what is most needed at the time.

Stay in the LoopKeep an eye on the Animation & Rigging module meeting notes. These are the best source of information of current development and decision making. Or maybe even join a meeting?

View Details

In this proposal, Julian Eisel highlights how a more accessible and powerful documentation platform can help the push towards a development culture more centered around documentation and design.

The focus is on issues with higher level technical documentation (architecture, modules, overall intent, etc.), not lower level API documentation.

This post is based on a presentation given by Julian Eisel at the Blender headquarters during November 2023.

Download SlidesThe Current PlatformTo start off easy, let’s analyze the current wiki-based documentation system.

The Editing ExperienceThe MediaWiki text editor feels outdated, and uses a specific syntax (not Markdown), but most of all provides a very cumbersome workflow for uploading images. These aspects affect the motivation of developers when using it.

A more modern alternative called HackMD is used much more often instead. That is a Markdown editor with live-preview and collaborative editing, where multiple people can work on a document at the same time.

Live editing in HackMD: Edit Markdown on the left, see the rendered result on the right – updated as you type.Some developers used this for technical documentation too and it works well. Eventually, the content needs to be moved to the wiki, which means having to convert the Markdown syntax to the wiki syntax. Sometimes this meant that content wouldn’t end up getting ported.

Navigation and StructureCurrently, the navigation on the wiki provides a limited amount of entry points (for the most used pages) and requires manual edits to add new entries, both for the sidebar and for breadcrumbs. This means that often it is not easy to understand the context of a document, and it is also not easy to find the document on the platform starting from the landing page.

Wiki page navigation: Unrelated, hard-coded top level navigation on the left, current page navigation on the right. There’s no good navigation in-between.More effort can be put in categorizing content as well, making entry-level docs easier to find.

Disconnected From the CodeThe wiki is a separate website that you typically don’t have open unless you consciously decide to use it. Other organizations found that such platforms tend to see less activity from developers; they require a context switch. The closer documentation is to the code, where developers do their actual work, the more likely they are to work on it as well.

Imagine if descriptions for tooltips would live on a separate webpage. They would probably get outdated quite quickly. Currently they live in the source code, and developers maintain them actively (even if there’s a lot of room for improvement still).

Invite-only PlatformTo prevent spam and abuse, the wiki has been an invite-only platform for several years now. This makes extremely hard for community members to get involved and contribute.

Unrelated to the PlatformThere is a shortage of technical documentation. While there are a few well documented areas, and more general information like build instructions are covered well, a lot of Blender’s designs are not documented, and much of the existing documentation is not up-to-date or simply not that useful.

The practical difficulty of contributing improvements, and the lack of good examples has led many developers to not open up the wiki and contribute to it.

Documentation CultureLet’s take a step back, and look for more intrinsic motivations. In fact, this article isn’t just about a change in platform. It is looking for something bigger: Can we build a new developer documentation culture?

That is a big question, isn’t it? Well, here’s some good news: others have done it. Check out “How Google, Twitter and Spotify built a culture of documentation”.

This change was driven by technical writers. Originally technical writers that felt like they failed in addressing the problem they were supposed to solve. They would just jump from project to project, leaving behind brand new documentation that would become outdated in no time. Nowadays, their technical documentation gets used and updated all the time – by engineers! Can it be true?

How did they do it?Various resources from Twitter, Google and Spotify tell their story. They closely followed the same approach, even if specifics differ. Briefly, here are some key findings:

• Culture of docs: Regular documentation sprints. Educate developers on technical writing. Lead by example.
• Standardize and centralize: Provide answers about writing documentation before they arise. Clear examples and templates. Share the same platform for all documentation.
• Feedback loops: Make it easy to give feedback (e.g. mark text in documentation > right click > “Report a Bug”).
• Keep it simple: Don’t overcomplicate; avoid/remove any points of friction so the actual content is the focus.

The technical writers are still there, but their role changed to helping and empowering developers. For example, they maintain the documentation infrastructure and make relevant strategic decisions. They make sure documentation just works for the developers/engineers.

This brings us to what appears to be the most important change: Fiercely optimize for the engineer.

Twitter, Google and Spotify have committed to a documentation infrastructure that is based on the idea of Docs as Code.

Docs as CodeThe idea is simple: Treat documentation like code. Employ a workflow that developers are comfortable with; make them feel at home. This includes features like version control, collaboration and automation.

More specifically, Docs as Code typically features the following:

• Simple markup language (Markdown, ReStructured text, etc.)
• Version controlled repository, close to the code
• Pull requests, versioning, branching
• Forge integration (Gitea, Github, etc.)
• Continuous delivery, automated checks

We actually have some experience with such platforms. The Blender Manual, Blender Studio pipeline documentation and Flamenco documentation follow a similar approach. Let’s try to bring this to the developer documentation. This is where it can really shine.

New Platform ProposalThings should be simple, so they key elements of the new platform are simple as well:

• Material for MkDocs
• Continuous delivery via buildbot
• Edit with preview in Gitea
• Git LFS (Large File Storage) repository
• Possibly pulled with make update
• URL: developer.blender.org/docs

Material for MkDocs is a Material based theme and framework around the MkDocs static site generator. Essentially it turns Markdown files into HTML pages that look great and offer a great browsing experience. It has been chosen over alternatives (such as Sphinx, VitePress and Hugo) since it seems like the best fitting platform. The main features are:

• Easy to set up and use. Developers will have it up and running in an instant.
• Markdown is readable in source, widely used (for example on most developer platforms) and well supported. Many IDEs have builtin Markdown editing and previewing support. Copy & paste from HackMD possible.
• Modern looking, rich in features (client side search, dark mode, … see below) and a big amount of common markdown extensions and plugins.
• Live reloading.
• Python based.
• Good search.

Overall it’s a great documentation experience for both writing and browsing.

ImpressionsThere is an experimental setup of the new documentation platform available under developer.blender.org/docs.

This is how a documentation page looks like:

Note the top-level navigation at the top, the navigation for the current category on the left, and the current page navigation on the right.

A simple toggle in the header switches between light and dark mode:

Material for MkDocs supports Mermaid to define diagrams as text in Markdown, and render them on the fly using the theme colors:

Who would’ve thought that creating such diagrams can actually be fun (for developers)!

Lastly, Material for MkDocs comes with a great working search feature:

• Dark
• Light

EditingThere are two main workflows for editing pages with the new platform. Online and offline editing.

To edit pages online, simply click the editing icon at the top of a page:

This brings you to Gitea, where you can immediately edit the page’s Markdown.

Although a side-by-side view would be a lot nicer, a simple click on the Preview tab gives a preview of the rendered result:

This is Gitea’s Markdown preview, so there might be smaller differences to the output of Material for MkDocs. But it works extremely well. Plus, as you can see, Gitea supports the Mermaid diagrams too!

The second way to edit is offline. Many editors support Markdown editing and previewing. Here is a setup in Visual Studio Code:

MkDocs supports live reloading. Every time you save the file, the preview on the right gets updated. This is using the live preview extension for Visual Studio Code, but the builtin Markdown preview works well too.

When done, you can simply commit and push the edits (or create a pull request). Either via the Gitea UI when editing online, or manually, using the Git interface of your choice. Buildbot will update the documentation output on developer.blender.org/docs within few minutes.

Since this is Markdown, there is another convenient way to edit the docs: HackMD. Work with live preview and in collaboration with others, then simply copy the result from there to the documentation!

Goodbye Wiki?The new platform would replace the current wiki. All the documentation, as well as the release notes can move to the new platform. Personal pages like the weekly reports of developers can be moved to personal repositories on Gitea, also using simple Markdown.

Although converters from Wiki syntax to Markdown are available, the transition will require manual work. Mostly to fix issues from the conversion, fix links, add missing images, etc. A few people volunteered to help already, more help would be welcome.

Status & Next StepsMost preparation work is done:

• Research, testing and experiments
• Buy-in from developers and stakeholders
• Buildbot continuous delivery setup (push changes, Buildbot generates and publishes output to developer.blender.org/docs)
• Hosting on developer.blender.org/docs
• blender-developer-docs Git LFS repository with Material for MkDocs setup & customizations

Follow the latest status on the dedicated task: #116055: New Developer Documentation Platform

This means we are ready to prepare the actual transition, whereby the wiki will be archived. Once this is done we can decide if we want to include the developer documentation as part of the source code or its additional resources (updated together with the source code via make update). This would move the documentation closer to the code, and ensure there’s easy and continuously updated access. Further, we can investigate ways to include internal API documentation (generated from C/C++ API comments using Doxygen) as part of the platform.

Building a developer documentation culture is challenging but possible, like other organizations show. Maybe all it takes is a few clever changes, and a bit of pushing to reach some tipping point; and then it snowballs!

The truth is, developers know that they should be writing technical documentation. They just don’t feel empowered enough to do so, there are too many hurdles and too few incentives. It is time to do some changes:

• A new documentation platform that is optimized for the engineer (docs as code) and removes friction from the workflow.
• Make it easy to write documentation by providing clear examples, templates, tools and education.
• Rethink how we write documentation. Make it actually useful for new and experienced developers alike.
• Foster a culture of documentation. Push until using and writing technical documentation becomes part of every day life for a developer — like it happened with unit testing.
• Open up to the community. A new culture can be a lot more exciting for technical writers or the general community to get involved.

Or, how the technical writers who revolutionized technical documentation at Google put it:

First tooling, then culture.* […] Focus on the Engineer.***

The Knowledge: Towards a Culture of Engineering Documentation – Riana MacNamara, Google

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender

View Details

The Grease Pencil 3 project is well on its way, but there are still many tasks left to do. This is a call to the Blender community to help out and get Grease Pencil 3 out of experimental mode!

What is needed?Development and testing. The main priority is to get feature parity with the current Grease Pencil.

In Edit Mode, we are still missing most of the operators. There is a list of tasks targeted towards newcomers to help port these operators.

How to help?The Overview Task has a brief description on how to get started as a developer as well as a list of tasks to work on.

If you are not a developer, you are still welcome to test Grease Pencil 3.

1. Grab the latest alpha build of Blender 4.1
2. Enable it from the preferences under Experimental (once Developers Extra is enabled in “Interface”).

Please note that the 2D Animation template doesn’t work with Grease Pencil 3, and any tests should be done on new files, since older Grease Pencil objects will not get converted to the new system yet.

If you find a crash or a bug, you can share it in the Grease Pencil 3 Feedback thread on Dev Talk.

Links* #114158: GPv3: Community Tasks: Overview * Grease Pencil Workboard * Overview Task of all the Edit Mode features: #112858: GPv3: Edit Mode

Grease Pencil Work BoardThank you!If you are interested in contributing, drop by the #grease-pencil-module room in Blender Chat and get connected!

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender

View Details

One week after this year’s Blender Conference, the geometry nodes team came together in Amsterdam to discuss many design topics that affect the future of geometry nodes. This post gives a general overview of the topics that were discussed. You can also read all the notes we took during the meetings.

VolumesOne of the main priorities for this workshop was to come to a conclusion for how we want to better integrate volumes into geometry nodes. Working with volumetric data opens up many new opportunities, and while there are already a few volume nodes available, they only offer limited functionality.

We already discussed this topic many times over the past few years, but more recently the topic became more important because we want to use volumes for physics simulations. The main design difficulty comes from the fact that individual volume grids in a volume object are a lot like attributes, but they are also quite different in that they are not attached to the geometry like attributes on a mesh. So a lot of the discussion in the workshop went into the trade-off between extending what a field is so that it can be used for volume grids, compared to introducing a different workflow that is more tailored to volumetric data.

In the end, we decided to introduce a workflow more specific to volume grids. In the future, the same workflow can work with other data types like lists and images. The proposal is described in more detail on devtalk. For reference, this is a proposal that attempts to fit grids into fields.

GizmosThe goal with gizmos is modifying geometry nodes inputs directly in the viewport. We want node groups to be able to specify gizmos for their inputs in a simple but powerful way.

The large design challenge is the inter-dependence between the transform of a gizmo and the value it controls. Changing the gizmo’s position affects the controlled value, while changing the value affects the gizmo position. Furthermore, we want to support so-called “crazyspace” with gizmos– if the gizmo controls a geometry which is transformed later in the node tree, we want the gizmo to be transformed in the same way so that it stays attached to the geometry in the viewport.

Design work for this started in another workshop earlier this year. It then progressed in a follow up proposal, and the latest version is available in a work-in-progress patch.

During the workshop, we went over the general design implemented in the prototype and tried to use it for some simple projects. it worked well, and we concluded that the general design in the prototype is the right way forward and discussed more UI details.

BakingBaking is currently only supported in simulation zones. The original plan was to introduce a new “Bake” node in Blender 4.0, but that didn’t make it, mainly because the design needed more work. Instead we added support for baking individual simulations to 4.0, which is preliminary work for adding the new “Bake” node which can also be baked individually.

The general design of the Bake node has been clear for a while. In the workshop, we mainly discussed the possibility of a scene-wide overview over everything that can be baked. That would be important in a production environment where there may be many bakes that depend on each other.

A baking overview and batch editing should be integrated into the outliner editor, and we have a good idea for what data we want to see there and what operations are needed. However, we couldn’t conclusively decide whether it should be a new view mode in the outliner or whether it can be integrated into an existing mode. While the “View Layer” mode has many elements that would also be needed by the baking overview, we also need some new things that don’t necessarily fit into the existing mode. This decision needs some help from the UI team because it depends on the longer term plan for the outliner and maybe on the “editor tabs” proposal (for example, see an initial attempt, but that needs much more discussion).

Subframe BakingFor baking and simulation, it should be possible to calculate and store results multiple times per scene-frame. In earlier discussions we already concluded that we want the ability to control the number of subframes on a per-simulation basis. We also generally want subframes of separate simulations to align. For example, one simulation with 10 steps per frame combined with another with 9 is problematic because objects used by both simulations (e.g. a collider object) have to be evaluated 19 times. When both would use 10 steps, only 10 evaluations are necessary. We want to guide the user to use aligned subframes by having a dropdown that contains 1, 2, 4, 8, ..., Custom instead of just having a subframes integer property.

Additional problems arise when a simulation depends on another simulation with fewer subframes. In this case it can be necessary to evaluate some frames even more than once. While technically possible, it’s unfortunate that this could make performance worse. Unintuitively, the fix would be to increase the number of subframes for the first simulation.

We couldn’t think of a way to avoid the duplicate evaluation without breaking the principle that playback or baking should behave identically when everything is evaluated at once and when all simulations are baked one after another from start to end. We ended up discussing how we could tell the user when frames are evaluated more often than intended.

Menu Switch NodeThe general design for this has been worked on previously already in a proposal and later in a workshop last year. Now, there is already a working implementation in a WIP patch.

In this workshop, we confirmed the design and discussed details like the socket shape and how the node interacts with attributes. The conclusion was that menu sockets are enough like other data types that they can just use the existing circle shape for single values and the diamond shape for fields. The color still has to be defined though. We won’t support attributes of this type for the time being, since the design outside of geometry nodes has many implications, especially for I/O. If users need this, they just have to map menu values to integers manually.

The original design for the menu switch node assumed that we would have have dynamic socket types before the node existed, which would allow switching different types with the same menu. We found that the node is already useful enough without dynamic types though, so we removed that dependency. Once we have proper dynamic socket types, the Menu Switch node can be extended.

Dynamic Socket VisibilitySome built-in nodes dynamically hide and show sockets based on node properties. Node groups should be able to do the same, so they can behave more like built-in nodes. Furthermore, the usage status of sockets should also depend on the value of other input sockets and not only on node properties that are not exposed as sockets.

Our discussion started out by going over the different options in this document on the topic. We concluded that the automatic approach to detecting socket usage is the way to go. This way users can’t construct “incorrect” usages that say an input has no effect even when it does. The approach should just work based on existing Switch nodes.

We also found that by default, it would be better to just gray out unused inputs instead of hiding them. Though there are still cases where hiding is the better behavior, for example in cases where built-in nodes do this already.

Asset Menu PathCurrently, the catalog path of an asset determines where it is shown in menus across Blender, like the add node editor’s add menu. This behavior was useful originally because it avoided the need to set up separate hierarchies for the whole asset library just to integrate with menus. However, catalog path just does not work well as menu path in many cases.

We discussed different approaches, and though we didn’t decide on a long-term solution yet, we did find that a single “Menu Level” checkbox per catalog would solve most common cases. For example, the checkbox could be turned off for a Nodes catalog that contains an asset like MyAssetLib/Nodes/Radial Array. Then the Radial Array node group would show directly in the MyAssetLib menu instead of a nested Nodes menu.

Replacement-Based Procedural ModellingThe goal of this topic is to make procedural modelling in geometry nodes significantly more powerful by roughly following the idea in the original proposal. The core idea with replacement-based procedural modelling is different from traditional modeling where users perform many small edits on a potentally large mesh. Instead, users would work on smaller changes locally that are then inserted into the large geometry.

A replacement-based approach makes it easier to work on mesh edits on a small scale first, before applying the edit to a large mesh. It would make building blocks easier to reuse for common operations and can also have significantly better performance, because many edits on a large mesh can be batched together and calculated in parallel.

The proposed Replace Faces node can also be used to build nodes for other common operations like inserting edge loops. It also brings many use cases that currently use the Tissue addon into geometry nodes.

We went over a few examples for how this can work and how the deformation works more specifically. Overall, the feedback was positive.

Modal Node ToolsBlender 4.0 introduces Node Tools to Blender, which are a way to build custom operators for e.g. mesh edit mode with geometry nodes. In later versions, we intend to extend this concept to support modal operators– operators that are interactive and take additional user input after their first invocation. In this workshop we discussed how represent these kinds of operators with geometry nodes.

The main problems to be solved are how the node group remembers data from the initial invocation and the previous events, how user-generated-events (e.g. key presses) are passed to geometry nodes, and how the operator finishes.

After considering using a new kind of “zone” for modal operators, we concluded that we can just use the existing simulation zones to remember data from previous modal updates. The Delta Time in the simulation zone would just be the actual real-world time delta. For some kinds of modal operators, it would be useful to runs continuously without additional user input, which can be achieved with a simple “Is Interactive” checkbox on the node group. If it’s turned off, geometry nodes only executes when there are new input events.

Control information is passed into node groups through normal (boolean) group inputs. The node group can then map some of its inputs to specific keymap events. The node group defines some default keymap, which could be overwritten by the user with a custom keymap.

The modal operator can always be cancelled with the escape key, so this key can not be used by the operator. For normal termination, we rely on a “Finished” boolean group output. Once the node groups returns true for that output, it finishes.

Grease Pencil IntegrationOne of the main open topics for the grease pencil integration into geometry nodes was the handling of grease pencil layers in nodes that convert to different geometry types. This is a tricky question because other geometry types do not have the idea of layers.

There are two main approaches for dealing with layers. We could join the geometries generated from each layer together, or can keep them separate by outputting them as instances.

It’s nice to keep layers separate since they were separate before, but turning them into instances is unclear because the word “instances” suggests that the goal is just memory usage reduction. That isn’t the case when every instance references a different geometry. This problem also exists with the new Split to Instances which outputs instances that are all different.

We considered changing the name “instances” but couldn’t really come up with a better fitting alternative. In the end we concluded that just keeping the existing name is fine, but that we can improve the tooling to make the data more obvious.

For example, the spreadsheet and socket inspection should show more details for how many unique geometries are contained in the instances. Naming geometries and their instance references would also be helpful. With those changes, the instance created from each layer could have the same name, making it much more obvious what the data is.

We also talked about a new “Grease Pencil to Curves” node, how curve sampling nodes should work, and different things “Apply Modifier” could do for grease pencil.

Dynamic SocketsFor existing nodes, but also especially for the volume integration, we need new socket designs that capture the ideas of “dynamic socket category” (single value, field, or grid) and “dynamic socket type” (float, int, etc.).

For the dynamic socket category we confirmed that using a wildcard/asterisk socket shape works quite well, since it is semantically meaningful and does not look as busy as originally feared.

For dynamic socket types, the situation is a bit more difficult. Some kind of “rainbow socket” could work, where instead of a single color, a socket could contain a color wheel. We don’t know yet if that looks too busy or not. The more difficult question is the link color.

Interactivity OptionIn the past, something like an “Is Edit Mode” was requested that is similar in spirit to the “Is Viewport” node. The intended use-case is to skip some heavy work while in edit mode so that the experience is more interactive. However, the proposal is quite specific to edit mode, and the same thing could make sense for many kinds of edits, even just transforming objects in object mode. Instead, it could be better to change the Is Viewport node into a more general “Interactivity Level” node.

Furthermore, input nodes like “Is Viewport” or “Is Edit Mode” have the problem that they can’t be controlled by node groups. For example, it isn’t intuitive to use a specific node group in “render” mode even if the scene isn’t currently being rendered. This problem also applies to input nodes for node tools. A potential solution is that automatically adding inputs to a group node for these special nodes. All of these inputs could be in a subpanel. This would make it easy to use the functionality, but it can also allow overrides from the outside.

Realtime ModeThe real-time mode has been in the design phase for quite a while already. One goal is to put Blender into an “interactive mode” where simulations just run in real-time and the user can interact with the scene naturally.

To achieve that, the scene time will likely have to be decoupled from a “real-time clock” that just keeps running independently of the scene time.

One difficulty with the design is finding the right set of use-cases that need the interactive mode but can not be handled by the simpler and less intrusive design for node-based modal operators.

Asset DeduplicationThe “Append and Reuse” functionality for assets works fine within a single file, but it becomes problematic when working in a production setting that also uses linking. The issue is that many .blend files have appended copies of the same data-blocks which currently can’t be automatically deduplicated when they are linked into a separate file. This leads to a large number of duplicate data blocks.

A solution to that is not local to geometry nodes but affects core functionality in Blender related to linking and appending. Fixing this might require automatically detecting if two data blocks are the same and/or version numbers on all data blocks. Both approaches are fairly involved and require their own project.

While there is a proposal for a solution, it is not generally agreed on and requires more discussion.

Next StepsIn this workshop we managed to make quite a few design decisions, so the main next step is to implement them. For example, the volume, gizmo, and grease pencil integration don’t have immediate blocking design questions anymore. Other topics like the real-time mode and asset deduplication still require more discussion.

View Details

Last week a big milestone was reached: the Vulkan backend has been enabled as an experimental option. It is available in alpha builds on Linux and Windows. This option is highly experimental and enabled to collect insight on platform support. Don’t expect a fully working Blender just yet!

Why Vulkan?Blender has been using OpenGL for a long time to draw the UI on the screen. OpenGL is a standard that was developed in 1990’s to define GPU APIs. Back then, a high end GPU had around 128MB of texture memory and geometry only existed in the main RAM of the host system.

OpenGL has tried to keep up to date with new features of GPUs and needs of developers. The API was extended to upload geometry to the GPU memory, use vertex and fragment shaders. Still, core parts of the API that were designed in the 90’s are still visible in the specification.

The specification mostly exists as a set of documents with extensions a GPU vendor could implement. The implementation details often differ per GPU vendor, with AMD trying to follow the specification as close as possible, and NVIDIA being more relaxed about it, allowing to applications handle misusing of the specification. Some extensions are vendor-specific and sometimes redundant.

Internally, GPU drivers also act differently. Optimizing an application for one vendor would not automatically improve the performance for other vendors. Drivers contain bugs as they became complex for the GPU vendor to develop. Many workarounds have been added inside Blender code base to work around driver bugs.

OpenGL decided fix these short comings by starting a project called Next Generation OpenGL Initiative. The result of this initiative lead to the development of Vulkan. Vulkan is much more than a set of API specification. It is an ecosystem with tools and driver validation processes and a place where vendors can work together in ensuring that the changes to the API are vendor-neutral.

Since the introduction of Vulkan, the OpenGL development slowed down quickly and all efforts went into Vulkan development, as vendors and application developers saw more value in that ecosystem. Currently OpenGL isn’t actively developed.

A consequence of this is that new GPU features, like hardware raytracing, mesh shaders and HDRI aren’t supported by OpenGL.

Our conclusion was that we have to migrate away from OpenGL. For Apple devices, Blender 3.5 already introduced the Metal backend. This will become the only supported backend for Apple devices in Blender 4.0. For Windows and Linux we will target Vulkan.

After finishing the migration to Vulkan, new development projects can be started utilizing the newly available GPU features. Here are some examples of projects that could be added to a future release of Blender.

• Improve the viewport performance with huge amount of geometry and complex scenes.
• Improving the quality of EEVEE by replacing screen space effects with hardware ray tracing implementations.
• Adding support for HDRI displays.
• Utilizing the compute power of GPUs in areas like texture painting.

We need your help!The Vulkan backend is still heavily in development and will be for the upcoming time. Our next goal is to ensure that we can support as many devices as possible and that most common development configuration are supported. Blender will be able to run on any platform the supports Vulkan 1.2 with a small set of extensions and required device capabilities.

For more information about the Vulkan backend and how you can help, please check the status thread on devtalk.

View Details

Localization is an important aspect of the Blender project. Translating Blender’s interface and user manual breaks down language barriers and makes tools and knowledge accessible to a wide group of people who are not comfortable with the English language.

Translations overview for the Blender UIThanks to the hard work of Bastien, with the support of Brecht, Sergey and Arnd, it’s now possible to contribute translations online via translate.blender.org. The platform is powered by the free and open source Weblate localization system.

If you are interested in getting involved, reach out via the #translations chat channel.

Grazie!

View Details

Node tools are now available in the upcoming Blender 4.0! Here is some background info about the design and what to expect in the future.

Randomize (custom) Node-ToolsWhat are Node Tools?Node tools are an accessible way to expand Blender and customize tools without requiring Python. They can be accessed just like any other tool, from a custom shortcut or a menu.

This is not the first nor the second time we’ve written about Node Tools on this blog. Read back for more context and to check the related development.

Create, Use and ShareTo create a new Node Tool you go to the Geometry Nodes editor, and switch the context to Tool.

Most of the Geometry Nodes which were available for node modifiers can be used, plus some new tools-specific nodes.

For example, this is how to quickly create a tool to randomly delete selected faces:

Node tools are immediatelly accessible in a menu in the 3D Viewport, where you can run or even assign a shortcut to quickly test them.

Tools can be marked as asset for sharing. The Asset Library catalogs are used to determine on which menus to show the tool.

If the catalog name matches an existing menu, the tool will be added to the end of it.

Adding the Delete Random inside the catalog Mesh → DeleteIn the example above, the Mesh → Delete catalogs match the menus in the 3D Viewport.

Tools-specific NodesAt the moment there are a handful of nodes which are exclusive to Node Tools:

• Selection / Set Selection
• Face Set / Set Face Set
• 3D Cursor

See It in ActionDeveloper Hans Goudey gives a live demo on how to use Node Tools.

Known LimitationsPlanned to be addressed for Blender 4.0:

• Support Object Info node
• Support searching attributes in adjust last operation panel

Limitations not planned in the short term:

• Support read/write to the active attribute
• Allow seed-based randomization
• Implement modal operations

Join the BetaTo get Node Tools in shape for Blender 4.0, please download a daily build of Blender 4.0 Beta, and share your feedback on DevTalk.

Spread the word! Use the hashtag #NodeTools and #GeometryNodes on social media to share your explorations.

Support the Future of BlenderDonate and support Blender Foundation to work on core Blender development.

Donate to Blender

View Details

Some ideas for making design workshops more effective.

View Details

Speeding up animators (and others working with animation data) by reducing manual data management.

View Details

The next Blender Open Movie – Project Gold – is now officially announced. This project has a very strong artistic vision and is aiming at an extremely stylized look.

Project Gold concept art by Blender Studio.The style is so integral to the story that the artists and developers are exploring new workflows. The idea is to make VFX tools (e.g., simulations) part of the early stages of production such as layout.

The goal is to create purely artistic driven tools.

Andy Goralczyk, Art Director at Blender Studio

The Geometry Nodes team explored this idea during the open movie Sprite Fright. The conclusion was that a more high-level interface is needed in order to make node assets more accesible for artists. For example, if an artist creates a mushroom generator, this asset should also include tools to paint the mushrooms density, size, type, and so on.

Node tools workshop at Blender HQ. May 15-17, 2023.Currently, the only way to access these settings is via the Geometry Nodes modifier. This proved to be a good initial approach, but it’s quickly showing its shortcomes. To address that, a workshop was organized at the Blender HQ in Amsterdam during May with the presence of:

• Blender Studio: Andy Goralczyk, Simon Thommes
• Blender Institute: Dalai Felinto, Jacques Lucke, Lukas Tönne

The agenda covered production use cases, tools, gizmos, and checkpoints.

Use Case: Fracture AssetsThe first use case is an asset that can be used to fracture a mesh over time. This asset has a node-tree with a few inputs (texture map, point cloud and curves) that can be edited by different tools. These tools are to be bundled together with the Geometry Nodes tree.

When the user drags the Fracture node-tree from the Asset Browser into an object:

• The object gets a modifier with the fracture Geometry Nodes tree.
• Three new tools are visible when the object is active.

The tools to edit this asset would be:

Realtime InteractionThis would allow for digital-puppetry or VJ-ing usecases. The ultimate workflow would be for Blender to act as a live-performance “instrument” for artists to play with. For that Blender needs to record user input in realtime.

These features can also fit in more traditional pipelines by layout and animation artists. It breaks down to:

• Record geometry (Grease Pencil or curves) over time (*).
• Auto-Keying as the go-to tool for this (nice to have: playback speed control).
• Auto-Keying UI properties.
• Extend support of input devices (VR controllers, MIDI controllers, …).

() – Although Grease Pencil already supports this in combination with the Build modifier, it is not hooked with auto-keying or scene playback.*

ToolsTools are the quintessential interface for interacting with a node-based asset. They permit the asset author to present high level concepts such as “scatter flowers” via a simple brush, hiding the complexity of correlating texture maps and attributes with the inner workings of the asset.

They are to be implemented as part of the modifier inputs; similar to how an input can have a subtype and a range, it can also have a default tool to tweak it.

Only built-in tools are accessible by the modifier inputs. Thus if an input type (vectors) requires a flow map subtype, we first need to have a built-in tool in Blender that supports this. In the future custom asset-specific tools would be supported once we have node-based tools.

The mapping between modifier input and tools can be done automatically in some cases (e.g., a texture map attribute will use the texture paint tool by default).

Context Setup ToolThe modifier input items get a new option to define a tool to be used to edit them. This is exposed as an edit button next to the property which sets the right context to edit this input:

• Active tool (and brush).
• Active object (when the attribute is in a different object). (*)
• Active mode.
• Active attribute.

Mockup: See the tools icon on the right of the modifier inputs.As mentioned, the idea is to focus on having built-in tools in Blender that support editing attributes (e.g., flow map) and then allowing those tools to be hooked up with different modifier inputs. This gets us 80% there, and helps technical artists who are comfortable with the existing tools in Blender. It also brings the artist in the right context in case they need to access another tool for the same attribute.

In some cases we also want to provide an easy to discover tool that is available when the asset is active. That tool would require its own icon and be available in the Toolbar.

() – To get this working as elegantly as possible we would need to have multi-data objects implemented, so there would be no need to change the active object.*

Example: Landscape AssetA landscape asset that adds either water, trees, grass, or flowers to a terrain.

The modifier would have these properties exposed:

• Tree-type
• Water turbulance
• Wind strength

Additionally, a single texture map (or ID attribute) controls which asset type to instance. This map isn’t exposed as a modifier property, but instead as four separate tools:

• Built-in Tool: Attribute Paint (current Draw in Vertex Paint mode)
• Names: Paint Tree / Water / Grass / Flower
• IDs: 1 / 2 / 3 / 4

GizmosGizmos also work as an interface to a Geometry Nodes tree. We explored a few design options until we landed on a new node type which would allow for the most flexibility: Gizmo nodes.

In essence, a gizmo node is a node that brings a potential new data-entry in the node-tree, while also passing the data through during evaluation.

In this Vase Asset example you can see that both the rotation and the arrow slider gizmos depend on the “Height” input.

The node gizmos should work similarly to the camera and light gizmos. They are always available when the object is active, but their visibility can be controlled in the Viewport Gizmos menu.

CheckpointsFinally we talked about the latest proposal for checkpoints. This was discussed a bit during the workshop in October 2022 and revisited when Simulation Nodes became part of the baking pipeline (in the upcoming Blender 3.6 LTS).

A checkpoint is a point in the node-tree that may use baked data instead of live data to help with:

1. Editing part of the node-tree in the viewport
2. Sending simulations to a render farm
3. Performance
4. Re-timing

OverviewIt would be ideal for the above scenarios to use the same solution under the hood and concept. Effectively a single node-tree may have all four scenarios combined:

In this example (of the fracture use-case) the tools inputs are generating curves internally. Those curves are then used for a “Sparkles” simulation (to generate particles) and to fracture the original mesh.

After using the fracture tools to create the initial fracture system, the checkpoints come into play:

1. After the curves to tweak them. That means the tools will no longer create new fracture islands/cracks/impacts.
2. To bake the sparkles simulation (so this can be sent to a renderfarm).
3. To bake the final fractured geometry (for performance reasons).
4. To re-time the baked result after all simulations are done.

In some cases the different steps of a simulation may be used by different objects. For example, one object can be used to generate ocean waves from curves, while another generates foam and water spray.

ConceptsTo better understand a checkpoint we need to understand the concepts of input and passthrough node types.

Input Node
A node that brings new data into the node-tree. E.g., Object Info, Collection Info, and in the future an Importer node or an Editable Mesh node.

Example of potential new Input nodes.Passthrough Node
A node where the data just bypasses the node. E.g., any muted node, the Reroute, and in the future the Gizmo nodes (see above).

Checkpoints Node

A checkpoint is a combination of both node types. It can work either as an input or passthrough depending on whether or not the node is baked. In a way it works like a “quantum” node.

Example of checkpoint nodes: Simulation Zone and Freeze node.The baking options and controllers for both the simulation zone and the freeze node should be accessed in the same way. We will need operators to define whether to bake selected “checkpoints”, and bake objects in the scene-level.

The baked data is stored at the modifier level similar to how Simulation nodes work.

Next StepsThe ideas discussed in this workshop as well as those discussed last year are the foundation of the Geometry Nodes roadmap for Blender 4.0:

• Custom normals
• Legacy instancing replacement
• Node Operators
• UI / UX
• Serial Loop
• Realtime Mode
• Modifier Context Setup Tool
• Standalone Node Tool
• Checkpoints

The specific priorities and targets will shift around, in particular to leverage working closely with the Blender Studio open movie team and their timeline.

To get involved on these projects you are welcome to join the bi-weekly Nodes & Physics meetings and discussions on the forums.

Support the Future of BlenderJoin the Development Fund and support Blender Foundation to work on core Blender development.

Join the Development Fund

View Details

In 2008, Joshua Leung implemented annotations in Blender directly in the 3D Viewport, he called this feature: Grease Pencil.

Grease Pencil as annotation tool in its first iteration. Credit: Virgilio VasconcelosThe first version of Grease Pencil was designed to be a simple annotation tool with basic color settings and animation capabilities. But the community that formed around Grease Pencil had bigger plans and started to use it for things he did not anticipate.

Fast forward to 2019, when Grease Pencil became its own object type and a dedicated workspace for 2D animation as part of the Blender 2.8 project. This version was a major overhaul and had many new features, better performance, and new render engine. The main developers working on it were Antonio Vázquez and Clément Foucault, together with the artists Daniel Martínez Lara and Matias Mendiola.

2D Animation Workspace in Blender 2.80Today, Grease Pencil has grown even more. It is used by small and big studios around the world. Movies like “Unicorn Wars” have been fully animated with it.

And while many aspects of the tool have immensely improved over time, the core data-structures of Grease Pencil have remained the same for about 15 years. We are now facing the limitations of its initial design – introducing: Grease Pencil 3.0.

What is Grease Pencil 3.0?“Grease Pencil 3.0” is a full rewrite of the current implementation, aiming to lay a solid foundation for the next 10+ years.

The goals of the project are as follows:

• Improve performance and memory usage with large amounts of data (e.g. frames, strokes, points).
• Improve the architecture and API for future development.
• Open the door for new features and tools.

The new implementation is based on the same back-end as the new hair curves, designed with multi-threading in mind, allowing for the support of Geometry Nodes, capable of handling much more data, and written in a modern C++ style.

The Timeline* February 2023: Development began in a separate branch. * May 2023: An experimental option will be available in early Blender 4.0 alpha builds for community testing. * June – October 2023: With the help of other contributors, the team hopes to get the bulk of the refactor done. * November 2023: Blender 4.0 released with Grease Pencil 3.0 fully replacing the old system.

The Team Grease Pencil core team: + Daniel Martínez Lara, Antonio Vázquez, Matias Mendiola. + Falk David, hired by the Blender Foundation to work full-time on the project. + Amélie Fondevilla*, developer at Les Fées Spéciales, will join development efforts for ~2 months during summer 2023. * Module contributors. * You! Or anyone who wants to help out (see “Contributing” below).

What to Expect in Blender 4.0The main focus will be to have feature parity with the old system, rather than adding new features. It is mostly a big refactor. That being said, the team is planning a few new things to look out for.

Layer GroupsThe ability to group layers is part of the redesign of the new data-structure.

Layer Groups allow the user to easily group multiple layers, collapse them in the tree, control visibility, editability, onion skinning, and more. Layer Groups can also be color coded.

Mock-up of the layer groups UIReworked TimelineThe new data-structure allows for features like frames having a start and an end as well as instancing a drawing (even on different layers). Instanced drawings share the drawings data (e.g. changing one will change the other).

Mock-up of the reworked timelineGrease Pencil layers now render the keyframes as boxes to indicate the amount of time the drawing is held for. Instanced keyframes are shown in a darker shade.

Python API changesWith this implementation, the team expects the Python API for Grease Pencil to break in Blender 4.0. That being said, we will try to make sure the same functionality is there, so that any script can be adapted to work with Grease Pencil 3.0. There will be documentation on this in the coming months.

After Blender 4.0Once the first milestone is in place and validated by the community, the focus can shift to improving and expanding the Grease Pencil feature set.

At the end of 2022, the Grease Pencil module conducted a survey to figure out what the community (hobbyists and professionals alike) wanted the most. The results showed us that our plans are well aligned with what people expect to have in Grease Pencil.

Here is an (incomplete) list of things on our radar:

• Booleans for fills (boolean eraser, fill brush)
• More (and better) textured brushes
• Geometry Nodes integration
• Grease Pencil assets
• UI improvements

ContributingThe team is happy to help anyone who would want to contribute to the project. If you have any questions, head on over to the main communication channel on blender.chat (#grease-pencil-module). There are also bi-weekly module meetings that anyone who wants to contribute can join. You can find the meeting notes and when the next meeting is happening here.

There is a list of tasks that can be worked on by anyone. They can be found on the Grease Pencil 3.0 workboard in the “Community Tasks” column. These are specifically tasks that have a low barrier of entry. If you like to work on any of these, reach out in the chat.

Thank you!

View Details

Today we would like to announce the first steps in saying goodbye to Subversion, also known as SVN. The Blender project first used CVS as its version control system, then migrated to SVN, and later to Git.

However while the Blender source code uses Git, other repositories like the user manual and libraries continued using SVN. This was due to poor support for binary files such as images and executables in Git. With the addition of Git Large File Support (Git LFS) and the recent move to Gitea, we can now use Git for all repositories.

Using Git rather than SVN gives developers and technical writers the following features:

• Ability to work and make commits offline
• Better branching and merging support
• Better 3rd party GUI clients
• Basic online editing in Gitea
• Less software to install

The first repositories that were migrated away from SVN are the Blender manual and its translations. The Blender libraries, test files and user interface translations will follow later.

Blender Manual MigrationContributors to the project should delete their exiting local repository and read the updated contribution guides to learn how to contribute using the new Git repository. Developers and technical writers with existing commit access will need to make sure to set up SSH Keys to be able to push changes to the repository.

With the move to Git, the repository is browsable on projects.blender.org, and contribution and review is done through pull requests. This workflow should be familiar to those contributing to the Blender source code or using other platforms such as GitHub.

There is also basic support for online editing of the user manual in Gitea. It’s possible to make a fork of the manual, create edits in a branch and submit them as a pull request. Those with commit access can also make small edits directly in the main repository.

However there are some limitations to this. For example, updating a fork to the latest revision or resolving conflicts requires a local checkout of the repository. We plan to improve the online editing experience in Gitea, but there is no concrete timeline for it yet.

If you encounter problems, feel free to ask questions in the topic on devtalk or in #docs on blender.chat.

View Details

At the beginning of the year we published the “Projects to Look Forward to in 2023“. It is time for an update on the planning, and to share the prioritized projects as of now – second quarter of 2023.

Planning session at the Blender headquarters in February, 2023.This concerns mainly the work to be done by the developers working at the Blender headquarters or on a development grant.

In bold are the targets currently in active development or recently implemented.

Cycles Light Linking * Custom Normals * Grease Pencil Integration Extensions Platform Blender Implementation * Web Implementation Character Animation Design and Planning Viewport Compositor Support more Nodes * Painterly Filters * Render Passes * Unify Compositors EEVEE Next SSS * Volumes * Irradiance Baking * Feature Complete Sculpting Dynamic Topology Refactor * Multiresolution Improvements Brush Assets Asset Shelf * Asset Traits * Draft * Brush Systems Grease Pencil 3.0 Merge into Main * Port Modifiers * Feature Parity Physics & Simulation Simulation Nodes * Node Operators * Realtime Mode * Node Tools R&D Vulkan Compute Pipeline and Resources * Graphic Pipeline * Feature Complete * Optimizations UV Improvements UV Packing* * Other Targets In the spirit of transparency in Blender development, below you can find the weekly planning for these projects.

Keep in mind that this schedule is ever evolving, and the target deadlines are bound to be shifted.

Initial monthly targets of the ongoing development projects.The bf-admins column in the spreadsheet corresponds to the person responsible for reviewing and follow-up on that project.

UpdatesThe Brush Assets project is delayed and encountering unforeseen technical difficulties. Thus it will be broken down in two main deliverables:

• Asset Shelf – for Pose Library.
• Draft System – for Brushes.

Cycles and Compositor projects are being developed to be tested and used in the next Blender Studio open movie (to be announced). Procedural Texturing may be part of the open movie development goals after those projects are completed.

Dynamic Overrides may also get in the picture once “Brush Assets” is finished.

Get InvolvedIf you’re interested in joining the development of those projects, visit the #blender-coders channel or attend the related module meetings to learn how to get involved.

Support the Future of BlenderJoin the Development Fund and support Blender Foundation to work on core Blender development.

Join the Development Fund

View Details

Blender gets five slots for Google Summer of Code 2023! Let’s take a look at the projects that contributors will work on this summer.

Flamenco ImprovementsAround a year ago, Flamenco—Blender Studio’s render management software—was released. Flamenco is being used in production and adopted by individuals as well as studios, but there are still many key functionalities that could greatly improve it. The goal of this project is to build upon the foundation of Flamenco to bring it to its full potential, including designing a web interface for the manager configuration, better control over jobs and workers, and improving stability.

Contributor: Eveline Anderson
Mentor: Sybren Stüvel

VSE Waveform Drawing PerformanceBlender supports video editing through its video sequence editor. While the editor allows users to load videos and audio files, computing the audio waveforms for the audio tracks can take a long time when working with large files (multiple gigabytes). This makes for a degraded user experience. This project will reduce the time taken to see the waveforms by: processing multiple audio sequences in parallel in the background and only computing the waveforms of sequences that are visible in the user interface. Once these initial speed ups are achieved, the project will explore improvement opportunities further down the audio processing stack.

Contributor: Lucas Tadeu Teixeira
Mentor: Richard Antalik

UV Editor ImprovementsThe goal of this project is to implement user-suggested improvements to the UV editor tools in order to help users create UV maps more easily. The main focus of the project is incorporating more mesh edit tools such as edge slide into the 2D UV editor, adding optional visible outlines to UV islands, as well as including the number of vertices removed by the merge by distance operator. Additionally, other small features that improve the user experience may be worked on if time allows.

Contributor: Melissa Goon
Mentor: Campbell Barton

Shader Editor Node PreviewThe node previews in the shader editor had been removed when EEVEE replaced the internal render engine. This project’s aim is to bring it back. Indeed, the demand of a preview area under selected nodes to preview the effects is high. This project will involve code to put back this feature in the blender sources, taking into account the specifics of the Cycles engine (particularly with AOV).

Contributor: Colin Marmond
Mentor: Brecht Van Lommel

Outliner Tree RefactoringThis project aims to port the remaining tree elements to the new object-oriented design of the outliner codebase. The project will involve creating new subclasses, modifying existing code, thoroughly testing changes, and documenting the modifications made. The deliverables for this project include a detailed report and updated code of new AbstractTreeElement sub-classes representing the remaining tree elements. The project will contribute to the ongoing development efforts of the outliner by providing a necessary refactoring that will make future development work easier and more efficient, and the outliner module’s documentation will be improved.

Contributor: Almaz Shinbay
Mentor: Julian Eisel

A warm welcome to all contributors and good luck!

If you like to follow the projects progress in the coming weeks, their proposals and weekly reports will be added to the Wiki.

View Details

During the development of Blender 2.8, the release cycle was formalized into a 4-releases per year schedule, with one of the releases offering long-term support (Blender LTS).

While having many releases in a year allows for quick iteration and progressive improvements, based on the experience from developers and users following this schedule over the past years, we propose to reduce the number of releases to 3 per year (one of them being LTS).

Each release comes with overhead such as documentation (manual, API), release notes (web and video), coordinating the actual builds and tests, overlapping development phases (Bcon3/Bcon1). Having one fewer release — and potential corrective releases — each year will reduce this overhead, while new features and improvements won’t have to wait too long to make it into a release.

New Release ScheduleThe proposed schedule extends the Bcon1 (new features/big changes) and Bcon2 (improve and stabilize) phases, and better aligns with annual events (e.g. SIGGRAPH, Blender Conference) and holiday periods.

Blender Release Schedule 2023-2024In order to get into the new release schedule, 2023 will be used as a transition period:

• Blender 3.5 continues unchanged, release expected at the end of March.
• Blender 3.6 follows the old schedule, becomes LTS. To be released in July, with support until July 2025.
• Blender 3.7 is skipped.
• Blender 4.0 follows the new schedule, and adds two extra weeks of Bcon1 to allow for bigger changes, expected to be released in late November.

The goal is to have a new LTS release every year, with support for two years (just as it is now). What changes is that it will be released around the same time each year.

We hope this new schedule will give developers more time to code, users more time to test, and ease the maintenance of tools by studio TDs and add-on developers.

View Details

Today Blender development is moving to a new platform, hosted on projects.blender.org. The move has been announced and documented in several articles and documents, so here we will focus on the expected results of the move.

projects.blender.org is the new platform for bug reporting, task management and code review.

• Bug reports and design tasks have been migrated to projects.blender.org. This includes task status, priority, labels and subscribers.
• User accounts have been migrated to Blender ID. If you had a Blender ID account, the username is now set to the one from the profile there. If you did not, a new Blender ID account was created. Please contact Blender ID support in case of any problems, or reach out through the dedicated chat channel.
• Code reviews and pastes have not been migrated but archived. Pending code reviews need to be resubmitted as pull requests.
• Workboards and project descriptions will be manually recreated by the modules.

New URLsThe Git repositories have changed location. If you have an existing Blender checkout, point to the new location as follows:

git remote set-url origin https://projects.blender.org/blender/blender.git

git fetch origin main

git submodule sync The development branch is now named main instead of master. To get the latest changes, switch as follows:

git checkout main

make update For developers:

• For push access to repositories, set the remote url to SSH and re-upload your SSH key.
• Follow the pull request instructions to create a fork.
• Find additional information for developers and module members on devtalk.

The developer.blender.org website is now archived.

• Code reviews and pastes will remain permanently available as static web pages at the same location as before.
• Tasks links are redirected to projects.blender.org. A static archive of tasks is also available on archive.blender.org/developer.
• The developer.blender.org website will remain available as read-only for a few weeks to help in migration, in particular for workboards.

Given the scope of the migration, some data might not have been correctly migrated. If you see an issue, please report it in the comments below.

Congratulations to the migration task force: Arnd, Brecht, Danny, Sergey, and Sybren, with support from Dalai, Thomas, Pablo, and Philipp.

Special thanks to the Gitea project and all the blender.org developers community!

View Details

Last week we shared the ambitious goal to switch to the new development infrastructure during this week. Well, not so fast! A lot of work has been done, including making sure all data can be migrated as safely and accurately as possible, and that the new infrastructure offers the same (or better) functionality as the current infrastructure. But we are not there, yet.

After setting up a production-ready version of the infrastructure, there have been concerns about performance and responsiveness. In particular, with the current configuration, it could take a few seconds for the server to respond to a user request, especially while dealing with dozens of concurrent requests or performing intensive operations such as creating a pull request. This would lead to a bad user experience.

For this reason the team has spent a few days to investigate and solve these issues before going into production. We will be good to go live next week, after some final server configuration and public docs are ready.

Charts comparing the performance of projects.blender.org.In the meantime, we are excited to share a preview of the new development portal. Introducing: projects.blender.org. Feel free to browse this (read-only) version of the site, and share any feedback in the comments below.

Preview of the projects.blender.org portalIn preparation for the switch, make sure you check the Gitea Diaries: Part 3 blogpost. An update will be published once the transition is complete.

View Details

This is the last chapter of the Gitea Diaries series, as we are approaching the end of our journey! As a reminder, the goal of this project is to migrate all ongoing activities and data hosted on developer.blender.org (Phabricator) to a new portal, powered by Gitea.

At the end of 2022, Arnd provided an update on the state of the Phabricator to Gitea migration project. While a lot of documentation and progress happened, much was left to be done. So we decided to assemble a task force to execute the project as quickly and efficiently as possible and wrap it up during the month of January.

Here are some key decisions that were confirmed in order to proceed with the migration.

Accounts and Blender IDBlender ID will be the only user authentication system used for the new portal.

All users will be migrated across portals. Since developer.blender.org did not require a Blender ID account in order to log in, some users might not have one. In this case, a Blender ID will be created for them during the migration. Gitea usernames will be defined by the Blender ID account nickname. For newly created accounts, we will try to match your username on developer.blender.org as closely as possible. For already-existing accounts, the Blender ID nickname will be left as-is. A support channel to handle account migration issues will be available when the new portal goes live.

Task management and archivalAll issues and related information will be migrated as accurately as possible. This includes discussions and attached files.

Differential revisions will not be migrated. Any module or contributor who wishes to have their patches reviewed should submit them again through the new Pull Request system. All existing review threads on developer.blender.org will be baked into static HTML files and made available through archive.blender.org. This way it will be possible to look up Differential revisions after Phabricator is decommissioned.

Content organizationProject data will be re-organized to fit the Organization → Repository → Tasks/Projects/Labels data hierarchy available in Gitea. This will be quite intuitive to many people, since Gitea provides a user experience very similar to GitHub and GitLab. However, the meaning of some terms will change. For example, while on developer.blender.org “projects” were used for many different functions, projects in Gitea are only used for organizing issues within the context of a repository.

Preparing for the migrationIf you are a Blender contributor, and committed code, reported issues, or participated in discussions on developer.blender.org, you can help with the migration of your account. Please ensure that:

• you have a Blender ID account, with your email address verified,
• your Blender ID email matches your primary email on your developer.blender.org account, and
• your Blender ID nickname matches your developer.blender.org username. In some cases, a one-to-one match will not be possible. If you have any questions about this, please contact blenderid at blender.org.

TimelineA dream team composed by Arnd, Brecht, Danny, Sergey, and Sybren, with support from Thomas, Pablo, and Philipp, in collaboration with members of the Gitea project, is working hard to make this happen – next week! More details and docs will be available in a follow-up blogpost and on wiki.blender.org. Stay tuned.

View Details

Friday, January 27, will be the first all-hands-on-deck technical documentation day. Developers, technical writers and other contributors are invited to spend a day on improving technical documentation. It’s not just about writing some pages; it’s about learning how to write good technical documentation, making the process more enjoyable, and whatever else that contributes to a great technical documentation writing culture.

The plan is to make this a regular event, repeated once or even twice a month for a while.

Why?Technical documentation is important for the long term sustainability of projects like Blender. Knowledge about designs needs to be shared better, so more people can make good decisions. It offloads reliance on core developers, helps avoid conflicts, misunderstandings and a good amount of bugs. And it should lower the barrier to entry for Blender development.

The technical documentation for Blender is lacking quite clearly – many parts of the design are missing documentation entirely even. It just hasn’t found its way into our daily processes. Decent technical writing is difficult, takes a lot of time & energy and may not feel immediately rewarding. It doesn’t have to be that way. But something tangible is needed to initiate change.

JoinIf you are a developer, technical writer, technical artist or some other stakeholder who wants to participate, here’s the basic info:

• Do whatever you think contributes to improving technical documentation.
• However, communicate what you want to work on. Others may plan to work on the same thing.
• Recommended: Read Google’s courses on technical writing. They will make you write better docs.
• You’ll find plenty of things to document and improve here: https://wiki.blender.org/wiki/Source.
• Platforms:
  • Technical documentation goes to the Wiki (at least for now).
  • New Technical Documentation category on Devtalk, for feedback, discussions and meeting notes.
  • New Technical Documentation tag/project on developer.blender.org, to collect specific tasks to work on. Keep an eye on this if you’re not sure what to work on. Or add own tasks.
  • Other developers found live-editing platforms like HackMD useful for writing. Move the documents to the Wiki once ready!
• Guidelines, templates and examples would be useful. Help is welcome, see T102958.
• There will be a video meeting for general discussion. See below.

Recommended: Pair DocumentingSome Blender developers experimented with documenting in pairs, and found it very useful. Basic idea: One person with knowledge about the area in question prepares a draft. Another person with little knowledge about it joins for a review, pointing out which parts are unclear or can be improved. Together they can turn the draft into a polished and well understandable piece.

A platform for collaborative editing is recommended, such as HackMD. Do not keep the documentation there, move it to the Wiki!

Let’s MeetThere will be a video meeting that day to discuss technical documentation topics. Here we can discuss things like, how technical documentation is handled in other organizations (e.g. using docs as code). But also things like tooling, auto-generated API reference documentation (Doxygen), higher-level structuring, etc.

The meeting will be limited to one hour. Meeting time and link will be shared on bf-committers and in the #blender-coders chat.

View Details

The upcoming Blender 3.5 release now provides a Metal GPU backend on macOS builds!

Next to Metal-accelerated computing in Cycles, it is now possible to enjoy improved EEVEE viewport (and UI) performance as well. This functionality has been in the works for a while, and it can be enabled through the user preferences.

Currently, the default backend is still OpenGL, but the goal is to switch to Metal after a period of testing and feedback.

Currently, the Metal backend needs to be enable through the User Preferences.Around one year ago, after joining the Blender Development Fund and seeding hardware to Blender developers, Apple empowered a few of its developers to directly contribute to Blender. The contributions started with Metal for Cycles and then continued with Metal as a GPU backed, for EEVEE, and the UI system. The goal of these contributions is to provide the best Blender experience on Apple hardware, as Blender is moving on from OpenGL.

BenchmarkHere are the results of some benchmarks, performed on a MacBook Pro laptop with an M1 Max chip.

The render benchmark was run in two different scenarios. Pre-cache means that no shader was compiled and cached. This happens when rendering a frame for the first time. Cached means that the frame was rendered at least once before.And these are some results on Mac Studio with M1 Ultra chip.

Ongoing workBesides bug fixing, a few patches to improve support of AMD and Intel graphics devices are expected to be merged. Next to that, the main target is to introduce Viewport compositing support, which is currently not available on macOS. The progress can be followed on developer.blender.org.

Note for add-on developersWhile the ‘bgl’ Python API has been deprecated in favor of the ‘gpu’ API, it still “works” in current releases of Blender. The upcoming GPU backend changes (both Metal and Vulkan) do not support the legacy ‘bgl’ API.

If you are developing add-ons with custom drawing code, make sure you are using the gpu API.

Testing and FeedbackThe new backend is ready for testing! If you are using Blender on a Mac, download the daily alpha build from builder.blender.org and give it a try. In order to enable the Metal backend, open the preferences and select it from the options available. Please report any issues on developer.blender.org.

Congratulations to Michael Parkin-White, Vil Harvy, Marco Giordano and Jason Fielder at Apple for this contribution, and special thanks to Clément and Jeroen for reviewing and coordinating this large project.

View Details

The previous article on Brushes & Drafting went into the basics of how brush assets will work and where they’ll be stored. Now we’ll delve into how brushes will be accessed, tweaked and authored.

Asset ShelfThis will be the new region to immediately access any available asset. The slim horizontal space at the button is ideal for visualizing enough brushes and catalogs for any given task.

A mockup of the asset shelf next to other UI elements in Sculpt Mode
And just like any other region:

• Its size will be dictated by the user and the amount of content within
• Its visibility can be toggled if not needed

The size of the assets can be dynamic to only take up necessary spaceAs the name implies, this region would potentially be used for any assets in any editor. Poses, Nodes, Objects, Materials, Textures and more can eventually be used from here.

This will also respect valuable space in the toolbar and sidebar for tools, properties and add-ons. Meanwhile, the Asset Browser will remain the editor to organize and browse any & all assets.

Tools vs BrushesA key improvement is to make the relationship between tools and brushes in the UI clear and more accessible. This is accomplished by directly displaying and assigning shortcuts to brushes, instead of doing this via tools in the toolbar.

For context, until now the user technically doesn’t pick brushes. Instead they pick “Tools”, either in the Toolbar or via shortcuts. “Brushes” are instead saved presets of the tool settings. This way you can have multiple variations of a single tool.

Brushes are presets of a ToolUnfortunately this makes it very hard to access brushes. Also, categorizing and sorting them in this predefined way quickly becomes counter intuitive when creating & using a lot of them.

Each Tool can have any number of Brushes. Which brush is where is hard to tell. Many Tools will only have a single brush.Brushes will be put into the forefront again. All tools in a mode that contain brushes will be merged and the type of brush will instead become a brush setting, just like any other.

Brushes will then be accessed directly in a “global palette” via the Asset Shelf or via shortcuts.

Only What You NeedProper scalability of the Asset Shelf will make it intuitive to access any brush among potentially hundreds of them. This can be achieved with 3 ways:

1. Compact Display
2. Custom Catalogs
3. Explicit & Implicit Filtering

Compact DisplayThe goal is to comfortably show up to 30 brushes on screen at a time and intuitively navigate to see more. This way most screen space is still available and the brush thumbnails will remain readable.

Sculpt Mode for mesh objects alone will have up to 80 brush assets shipped with Blender. This will ensure that all commonly necessary brushes are available by default. On top of that it’s easy to see how the amount will skyrocket with user created assets and shared assets. But even with this huge library of brushes, it’s not needed to see all at once.

Quickly searching for a specific brush via typing is also important functionality and will be available from the Asset Shelf directly.

Custom CatalogsSorting & categorizing brushes will be done with Asset Catalogs. By cataloging brushes the user can define which set of brushes to display at a time.

Any type of brush asset can be sorted into a custom made catalogTo make this even more customization there will be “Dynamic Catalogs” as well. These catalogs essentially act as “smart filters”, so brushes can appear in multiple catalogs at once. For example any brush that is tagged as “Favorite” will appear in the dynamic catalog called “Favorites”, no matter what other catalog they belong to.

Brushes can be tagged to show up in any dynamic catalogTo make sure all brushes are still at your fingertips, the Asset Shelf needs to be able to comfortably show up to 12 catalogs at a time.

Explicit & Implicit FilteringYou should only ever see what you need. This will be accomplished by:

• Automatically hiding brushes that cannot be used in the current mode or settings
• Automatically hiding catalogs that do not contain any visible brushes
• Allowing users to manually hide specific catalogs from the workspace

Editing your BrushesA Brush Asset has a certain life cycle. It is created from an existing brush asset, is used, tweaked and drafted along the way, and eventually saved as a new Asset that can be shared with others.

Each of these steps need to be at your finger tips, without getting in the way of others. Drafting will be the key to editing your assets for both daily use and asset authoring.

The three stages of a brush asset life cycle.Using brushes must be straightforward with a clean user interface. In the long-term the tool settings will only show “cherry-picked” brush settings, to expose only what is actually needed.

Drafting, as in extensively editing a brush, is expected to happen regularly and deliberately. The full expanse of brush settings will be quickly available in the sidebar and any changes can be saved to the asset as a draft.

Authoring can be compared to publishing. It’s when you package your asset for further reuse and sharing. This is done in the asset browser, in the asset library .blend to finalize Assets for others to enjoy.

Next StepsThe first target is to apply this design on the Pose Library, to properly test its usability and user interface. The Asset Shelf design will evolve further from there. Brush Assets will come after, starting with the Curve Sculpt Mode brushes.

View Details

Simulation, loops and geometry objects: What is next for Geometry Nodes?

View Details

In the days before Blender Conference 2022, the Animation & Rigging module organised a workshop: The Future of Character Animation […]

View Details

Design of a new system to use, tweak, and share brush assets anywhere in Blender, from sculpting to texture painting.

View Details

This document describes the vision for a new way to create and share content with Blender through Blender Apps.

View Details

A proposal for a public platform to host and manage Blender extensions.

View Details

Introducing native support for the popular display server protocol on Linux.

View Details

In 2023 and 2024 Blender will be fully compatible with the VFX Reference Platform specs.

View Details

Blender 3.3 LTS brings support for the latest Intel® Arc™ A-series discrete graphics and Intel® Data Center GPU Flex Series.

View Details

A second update on our Gitea migration. It's short in text, but contains a set of 10 videos recorded on the 10th of August.

View Details

First installment of a series about moving Blender’s development from Phabricator to Gitea.

View Details

A new curves system, suitable for hair, is going to be part of the upcoming Blender 3.3 LTS.

View Details

Introducing a new, GPU accelerated, real-time compositor for Blender.

View Details

Blender 2.83 was released on 3 June 2020 and received 20 updates and 293 bug fixes since.

View Details

Report on the Video Sequence Editor workshop help in May 2022

View Details

During this workshop, Sergey Sharybin and Sebastian König went over the backlog and roadmap for the VFX module.

View Details

Blender gets four slots for Google Summer of Code 2022.

View Details

The creative journey for a new Icon.

View Details

Design of new procedural and layered textures, for community feedback.

View Details

Overview of the upcoming improvements in the Sculpt/Paint module.

View Details

As part of the 2022 strategic targets, a workshop to help refine Overrides was held during January at the Blender HQ.

View Details

Blender will no longer stick to the VFX Reference Platform.

View Details

In 2022 the Blender Institute team will focus on four strategic projects.

View Details

Results from the collaboration with Facebook Reality Labs on Cycles.

View Details

Since the announcement of Cycles X, developers have been working to complete and stabilize the code, as well add new features and improve performance.

View Details

Blender 3.0 takes support for AMD GPUs to the next level with improved AMD GPU rendering support in Cycles.

View Details

Ton Roosendaal shares on what's next after Blender 3.0 and beyond.

View Details

The 2021 Google Summer of Code projects have just wrapped up, concluding ten weeks of Blender development over eight projects helmed by students and supervised by members of the Blender development team. This is the fourth post in a four-part series exploring what the students have achieved during this year’s development stint.

Episode Four: Let’s Get Physical The summer is firmly in the rearview mirror now, meaning the 2021 GSoC overview series is coming to an end. While the third post in the series looked at the Curve and Knife tool projects, this fourth and final post will go through the two GSoC projects dealing with the realm of physics and simulations, closing out this tetralogy with an (adaptively simulated and accurately visualized) bang. More specifically, we will be looking at the “Adaptive Cloth Simulator” project by Ish Bosamiya and the “Display simulation data for rigid bodies and cloth” project by Soumya Pochiraju.

Adaptive Cloth Simulator You Can Keep Your Hat On First up is the “Adaptive Cloth Simulator” project by Ish Bosamiya, with mentors Sebastian Parborg and Sebastián Barschkis. This was not Ish’s first GSoC rodeo, with the student participating in the 2019 edition, laying the groundwork for this year’s project by also working on adaptive cloth simulation. However, the initial plan of simply refactoring the 2019 code and pushing through with the project was dropped when Ish realized how far the general Blender code-base had evolved since then. This led Ish to completely rewrite the project from the ground up, laying up the groundwork for a potential merge with master.

As a result, Ish came up with a new mesh structure and implemented changes to the cloth modifier to become a non-deform modifier storing the previous frame, all efforts to implement new static and dynamic remeshing algorithms.

Static Remeshing A new static remeshing implementation by Ish. Learn More.

• Remesh during cloth simulation
• Remesh with specific values

Dynamic Remeshing and Sewing Ish continued working beyond the initial ten weeks allocated to the GSoC on Dynamic remeshing and Sewing features based on user feedback. Learn More.

• Sewing Feature
• Dynamic Remeshing Based on Curvature

Mesh Analyzer Tool Ish built a standalone Mesh Analyzer tool to aid with the development work over the GSoC period. Learn More.

Ish’s Mesh Analyzer Tool in action debugging static remeshing

Display Simulation Data for Rigid Bodies and Cloth Show Me the Magic Soumya Pochiraju ‘s project aiming at providing visual debugging tools that would be a great addition for physics work in Blender was also mentored by the two Sebastians. Over the summer, Soumya managed to implement displays for all the data mentioned in the initial proposal save for cloth springs, on account of time. This leaves the project with an impressive roster of new visualizations, which we will go through below.

Velocity, Acceleration, and Forces Velocity, acceleration and forces acting on active rigid bodies are displayed in the form of color-coded vectors. Normal, effector and gravitational forces are in pink, frictional forces are in yellow and the resultant is in cyan. Learn more.

Normal, frictional, and net forces on a cube, displayed via Soumya’s implementation. Collisions The frame of the collision shapes lights up if an object collided with something within the past timestep. Learn more.

Colliding Boxes Constraints In collaboration with Sebastian Parborg, three ways were devised to visualize constraints: Slider, Hinge, and Piston. Learn more.

• Slider
• Hinge
• Piston

And more: * Rigid Body States * Non Primitive Collision Shapes

Keep in mind that all GSoC projects are developed in separate branches, meaning that all these features have not necessarily been merged with master. The ultimate landing (or not) of these patches lies in their overall quality and in the GSoC students’ motivation to pursue development and maintenance of their work beyond the GSoC weeks.

This is it for this year’s overview series. It’s been a pleasure covering what has proved to be an exceptional GSoC year, with a majority of the projects hitting their proposed goals and landing in master.

Find out more on these two projects on the links below:

• Displaying Simulation Data by Soumya Pochiraju – Final report
• Continued Development on Adaptive Cloth Simulator for Blender by Ish Bosamiya- Final Report