← All ideas
  • Published 20 Jan 2026

Allow baking for all nodes in Geometry Nodes

The Bake node in Geometry Nodes has been a great addition for users like myself who loves to use Geometry Nodes to create systems that uses a lot of points/geometry/voxels etc.. Everything high resolution. Being able to just place a bake node when you need your node tree to run smoothly while working on the post-bake process is a true blessing, but it does have a flaw : It is a node and nothing else.

  • The issue with that is it can get tricky when the setups are really heavy, and you'd need to bake it every here and then. If you create a geometry node toolkit intended to manipulate or generate heavy geometry/point clouds/other, it can often necessitate a Bake node between each custom node groups, just in case you need to bake at one precise moment.
  • What if every node were a "bake node" ? - By that I mean, what if we could freeze the data that holds any node at any time, including regular nodes and node groups, just like the Bake node does, but it is already supported by the node itself, so any node tree could be baked at any moment, with ease and without polluting the node tree visually with many bake nodes.
  • This already exists in other softwares such as Houdini, but I understand that such a feature could necessitate a certain amount of thought into the design / the way the user will bake from any node, and furthermore know if a node is baked or not.

I like the idea of calling a node "Frozen" if it's baked, like in Houdini, because it is compelling and conveys well the idea of a node that froze the data/cannot update the operation as long as it's not updated or unfrozen/unbaked.

I do not believe I have the best design idea, but to not come here empty handed, here's a rough idea. I'm open to discussion on the design, and how it could be added to fit and match blender's global ui and logic

image (10).jpg

You could have a new dropdown panel in the sidebar, under the "Node" tab, named "Bake" or "Freeze" or something similar, it has the same features as the properties of the bake node. By the way, I'm thinking the Bake properties could be added as a subsection of the Properties panel. Instead of adding items to bake like with the Bake node, every output of the current node is baked.

image (11).jpg

If the node is baked/frozen, there is a clear indication to the user that it is. It could be the same as the "Baked Frame" that is shown on the already existing Bake node.

The flaws of this design is it requires the user to go in the sidebar to bake or unbake the nodes, which can be seen as an extra step and an unintuitive way of doing it, but it can be a possible option until a better design is found. Capture d'écran 2026-01-21 004410.png

100%

Development Status: Open

Upvote 5 Downvote 0
maxime1
20 Jan 2026

2 Comments

lobo_alcalino

That needs to happen not only for nodes but for modifiers as well. It would go around cycle dependendies of a mesh influencing another with modifiers, it's just about picking the mesh in different 'times'. I believe something like that is being developed, but not for individual nodes. As for this idea, I have mixed feelings because if you unfreeze the node and something got terribly different from the frozen version and u don't know what you changed, that would be really bad.

maxime1 Author

yes, changing everything and unfreezing the node could lead to something terribly different from the previous frozen version. Just like with the current Bake node. And this how Houdini works as well, you can freeze any node, and unfreezing could lead to surprising changes. This is the byproduct of freezing, but if you know what you're doing, it should be all good.

This is why design is important, and it should be very clear visually that if a node is frozen or not, in order to avoid incomprehensions and human mistakes. But I don't see why it would be really bad to include a Bake option in every nodes, while you can already place a Bake node in-between every nodes and do the same thing, but it's just visually polluting the node tree.

However yes, having this both for nodes/nodegroups and modifiers would make sense. Let me know if there are other aspects of my idea that would conflict