blender
/
blender
134
398
Fork 579
Code Issues 6.3k Pull Requests 754 Projects 19 Wiki Activity

Geometry Nodes: new Bake node #115466

Merged
Jacques Lucke merged 93 commits from JacquesLucke/blender:bake-geometry-nodes into main 2023-12-18 13:01:16 +01:00
Conversation 19 Commits 93 Files Changed 33 +1872 -386
Jacques Lucke commented 2023-11-27 12:11:42 +01:00
Member
Copy Link

This adds a new Bake node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are:

  • Bake some data for use with a render engine.
  • Bake parts of the node tree explicitly for better performance.

For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an Import Bake node that allows reading the blender-specific baked data independent of the Bake node and at different frames.

The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are:

  • The Bake node has a Bake Still and Bake Animation mode.
  • The Bake node doesn't do automatic caching.

image

After this basic implementation is merged, we can focus on making bake functionality available in other places in the UI (like the outliner) to improve the workflow in a production. For now, the focus lies on getting similar UI features for simulation-baking and the bake node.

Implementation details:

  • Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones.
  • The ModifierCache stores an independent map of SimulationNodeCache and BakeNodeCache, but both share a common data structure for the actually baked data.
  • For baking, the Bake node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output.
  • Had to add a new DEG_id_tag_update_for_side_effect_request function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using DEG_id_tag_update technically works as well, but has the problem that it also uses the DEG_UPDATE_SOURCE_USER_EDIT flag which (rightly) invalidates simulation caches which shouldn't happen here.
  • Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though.
  • The bake operator is refactored to bake a list of NodeBakeRequest which makes the code easier to follow compared to the previous nested ObjectBakeData > ModifierBakeData > NodeBakeData data structure.
  • The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
  • The same operators are used to bake and delete single bakes in Bake nodes and Simulation Zones. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes).
  • The Bake node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an Is Attribute flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected.
  • Similar to simulation zones, the behavior of Bake nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new GeoNodesBakeParams in GeoNodesCallData when executing geometry nodes.

Next Steps (mostly because they also involve simulations):

  • Visualize nodes that have not been evaluated in the last evaluation.
  • Fix issue with seemingly loosing baked data after undo.
  • Improve error handling when baked data is not found.
  • Show bake node in link drag search.
  • Higher level tools for managing bakes.
This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. ![image](/attachments/d5b14701-ae49-4bfc-b3df-2537bead903b) After this basic implementation is merged, we can focus on making bake functionality available in other places in the UI (like the outliner) to improve the workflow in a production. For now, the focus lies on getting similar UI features for simulation-baking and the bake node. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes.
image.png
59 KiB
image.png
50 KiB
image.png
❤️ 9 🎉 1 🚀 3
Jacques Lucke added 2 commits 2023-11-27 12:11:54 +01:00
Jacques Lucke added 2 commits 2023-11-27 16:04:51 +01:00
Jacques Lucke added 3 commits 2023-11-29 14:36:34 +01:00
Jacques Lucke added 1 commit 2023-11-29 15:27:31 +01:00
Jacques Lucke added 3 commits 2023-12-01 15:57:58 +01:00
Jacques Lucke added 3 commits 2023-12-01 16:34:28 +01:00
Jacques Lucke added 1 commit 2023-12-01 17:15:29 +01:00
Jacques Lucke added 5 commits 2023-12-02 10:24:09 +01:00
Jacques Lucke added 16 commits 2023-12-04 12:30:34 +01:00
Jacques Lucke added 3 commits 2023-12-04 12:55:33 +01:00
Jacques Lucke added 10 commits 2023-12-05 13:50:00 +01:00
Jacques Lucke added 2 commits 2023-12-05 16:16:30 +01:00
Jacques Lucke added 5 commits 2023-12-07 17:46:52 +01:00
Jacques Lucke added 4 commits 2023-12-07 18:45:19 +01:00
Jacques Lucke added 1 commit 2023-12-07 18:58:38 +01:00
Jacques Lucke added 1 commit 2023-12-07 19:05:44 +01:00
Brady Johnston commented 2023-12-08 02:38:09 +01:00
First-time contributor
Copy Link

I have built with the latest commit and it seems to work pretty well (MacOS, M2 Max).

Some minor things: material is lost on baking (example):

CleanShot 2023-12-08 at 09.31.42@2x

I wasn't able to get the baking to work unless I used a custom path, but then I realised I needed to have the file saved somewhere for the automatic path to work. Maybe a warning / message that the file hasn't been saved yet in the node, as the default is to not use a custom path.

I have built with the latest commit and it seems to work pretty well (MacOS, M2 Max). Some minor things: material is lost on baking (example): ![CleanShot 2023-12-08 at 09.31.42@2x](/attachments/d1ddbe63-379e-4085-8cee-f3527fa0dfa0) I wasn't able to get the baking to work unless I used a custom path, but then I realised I needed to have the file saved somewhere for the automatic path to work. Maybe a warning / message that the file hasn't been saved yet in the node, as the default is to not use a custom path.
CleanShot 2023-12-08 at 09.33.32.mp4
1.5 MiB
CleanShot 2023-12-08 at 09.31.42@2x.png
105 KiB
Arye Ramaty commented 2023-12-08 12:05:20 +01:00
Contributor
Copy Link

I also conducted some tests, but first, as a disclaimer, my intended use case is not the typical intended use of 'baking.' The problem I aimed to solve is: how can I transfer instances (or any multi-component geometry) created through GN to a client without giving them the whole GN setup? Using the bake node, it's now possible.

As I mentioned, I don't believe the purpose of baking is to be used as a general 'geometry set' import-export format, nor as a substitute for applying modifiers to multi-component geometry; this would be better done as part of the old 'geometry object' proposal.

With that context in mind, here are some points I have found:

  1. A load button - It is possible to assign two different nodes (in different files) to the same path and 'link them,' but it does not always work (I couldn't find the exact reason, but I think that when the bake node is already connected to the viewer before assigning the path, it never works).
  2. I think the file path property should be on the node itself, the same way the compositor output node has it. I think it is the right place to 'load file' and to 'set path'.
  3. I think (not sure) that presenting all the baked data within the same blend as an ID data block can help in some aspects; this is also an already known concept throughout Blender (like the image node dropdown, materials, etc.).
  4. The file path property does not duplicate with the node.
  5. I made it crash a couple of times (4-5), mostly while trying to view the baked data.
  6. Somehow (not sure how) I created a hybrid from two bakes (the 0 frame was from a different file).
  7. I won't be available until tomorrow evening; I'll probably have more feedback/ideas by then"
I also conducted some tests, but first, as a disclaimer, my intended use case is not the typical intended use of 'baking.' The problem I aimed to solve is: how can I transfer instances (or any multi-component geometry) created through GN to a client without giving them the whole GN setup? Using the bake node, it's now possible. As I mentioned, I don't believe the purpose of baking is to be used as a general 'geometry set' import-export format, nor as a substitute for applying modifiers to multi-component geometry; this would be better done as part of the old 'geometry object' proposal. With that context in mind, here are some points I have found: 1. A load button - It is possible to assign two different nodes (in different files) to the same path and 'link them,' but it does not always work (I couldn't find the exact reason, but I think that when the bake node is already connected to the viewer before assigning the path, it never works). 2. I think the file path property should be on the node itself, the same way the compositor output node has it. I think it is the right place to 'load file' and to 'set path'. 3. I think (not sure) that presenting all the baked data within the same blend as an ID data block can help in some aspects; this is also an already known concept throughout Blender (like the image node dropdown, materials, etc.). 4. The file path property does not duplicate with the node. 5. I made it crash a couple of times (4-5), mostly while trying to view the baked data. 6. Somehow (not sure how) I created a hybrid from two bakes (the 0 frame was from a different file). 7. I won't be available until tomorrow evening; I'll probably have more feedback/ideas by then"
Arye Ramaty commented 2023-12-08 12:16:40 +01:00
Contributor
Copy Link

Crash:

Bug:

Crash: <video src="/attachments/4f2bf258-e810-4dbc-a61b-b58169d036e9" title="Crash.webm" controls></video> Bug: <video src="/attachments/f932f68a-129c-4452-919d-2fa323c8b81b" title=" Using the same path is not always working.webm" controls></video>
Crash.webm
679 KiB
Using the same path is not alway working.webm
1.7 MiB
Jacques Lucke added 4 commits 2023-12-11 10:32:10 +01:00
Jacques Lucke commented 2023-12-11 10:39:51 +01:00
Author
Member
Copy Link

Thanks for testing!

Some minor things: material is lost on baking (example)

That's still a known issue unfortunately. The underlying issue is the same as for simulation baking. It will be fixed by #109703.

I wasn't able to get the baking to work unless I used a custom path, but then I realised I needed to have the file saved somewhere for the automatic path to work. Maybe a warning / message that the file hasn't been saved yet in the node, as the default is to not use a custom path.

I disabled the bake button now when the file is not saved yet.

I also conducted some tests, but first, as a disclaimer, my intended use case is not the typical intended use of 'baking.' The problem I aimed to solve is: how can I transfer instances (or any multi-component geometry) created through GN to a client without giving them the whole GN setup? Using the bake node, it's now possible.

It is a typical use case, but not one we are trying to solve right now with this patch. In general, each Bake node should have a separate bake path. We do plan to have a separate Import Bake node that will allow you to do what you want, and more. This goes more in the direction of general import and export in geometry nodes which we'll get to a little later. I think some of your comments invalidated by this for now.

The file path property does not duplicate with the node.

Could be solved as part of the copy node operator but doesn't have high priority right now since we don't really want people to use the same file path in two bake nodes.

Crash

Next time please try to provide more exact steps to reproduce the issue (and a .blend file). I committed a fix now that I believe also fixes your issue, but hard to be sure.

Thanks for testing! > Some minor things: material is lost on baking (example) That's still a known issue unfortunately. The underlying issue is the same as for simulation baking. It will be fixed by #109703. > I wasn't able to get the baking to work unless I used a custom path, but then I realised I needed to have the file saved somewhere for the automatic path to work. Maybe a warning / message that the file hasn't been saved yet in the node, as the default is to not use a custom path. I disabled the bake button now when the file is not saved yet. > I also conducted some tests, but first, as a disclaimer, my intended use case is not the typical intended use of 'baking.' The problem I aimed to solve is: how can I transfer instances (or any multi-component geometry) created through GN to a client without giving them the whole GN setup? Using the bake node, it's now possible. It is a typical use case, but not one we are trying to solve right now with this patch. In general, each `Bake` node should have a separate bake path. We do plan to have a separate `Import Bake` node that will allow you to do what you want, and more. This goes more in the direction of general import and export in geometry nodes which we'll get to a little later. I think some of your comments invalidated by this for now. > The file path property does not duplicate with the node. Could be solved as part of the copy node operator but doesn't have high priority right now since we don't really want people to use the same file path in two bake nodes. > Crash Next time please try to provide more exact steps to reproduce the issue (and a .blend file). I committed a fix now that I believe also fixes your issue, but hard to be sure.
Jacques Lucke added 1 commit 2023-12-11 10:42:42 +01:00
Jacques Lucke added 3 commits 2023-12-11 11:44:51 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
2663aeef51 cleanup
Jacques Lucke changed title from WIP: Geometry Nodes: new Bake node to Geometry Nodes: new Bake node 2023-12-11 12:15:44 +01:00
Jacques Lucke commented 2023-12-11 12:22:18 +01:00
Author
Member
Copy Link

@Sergey For the bake operator to work well I had to add a new DEG_id_tag_update_for_side_effect_request function. It's similar to DEG_graph_id_tag_update but uses DEG_UPDATE_SOURCE_SIDE_EFFECT_REQUEST instead of DEG_UPDATE_SOURCE_USER_EDIT as update_source. This is necessary, because I want to trigger a reevaluation of an object even though none of its dependencies have changed. The reevaluation is required because the to-be-baked geometry is generated during the modifier evaluation.

Using DEG_graph_id_tag_update technically works, but also (rightly) causes e.g. simulation caches to invalidate because of DEG_UPDATE_SOURCE_USER_EDIT. Those shouldn't be invalidated because I'm not actually changing any dependencies.

Does this sound ok to you?

@Sergey For the bake operator to work well I had to add a new `DEG_id_tag_update_for_side_effect_request` function. It's similar to `DEG_graph_id_tag_update` but uses `DEG_UPDATE_SOURCE_SIDE_EFFECT_REQUEST` instead of `DEG_UPDATE_SOURCE_USER_EDIT` as `update_source`. This is necessary, because I want to trigger a reevaluation of an object even though none of its dependencies have changed. The reevaluation is required because the to-be-baked geometry is generated during the modifier evaluation. Using `DEG_graph_id_tag_update` technically works, but also (rightly) causes e.g. simulation caches to invalidate because of `DEG_UPDATE_SOURCE_USER_EDIT`. Those shouldn't be invalidated because I'm not actually changing any dependencies. Does this sound ok to you?
Jacques Lucke commented 2023-12-11 12:28:11 +01:00
Author
Member
Copy Link

@blender-bot build

@blender-bot build
Jacques Lucke requested review from Lukas Tönne 2023-12-11 12:28:35 +01:00
Jacques Lucke requested review from Simon Thommes 2023-12-11 12:28:36 +01:00
Jacques Lucke requested review from Hans Goudey 2023-12-11 12:28:37 +01:00
Jacques Lucke added 1 commit 2023-12-11 13:05:26 +01:00
Hans Goudey approved these changes 2023-12-11 16:09:10 +01:00
Hans Goudey left a comment
Member
Copy Link

This looks fairly straightforward actually. I left some inline comments, but nothing that needs another review iteration I don't think.

This looks fairly straightforward actually. I left some inline comments, but nothing that needs another review iteration I don't think.
scripts/startup/bl_ui/space_node.py Outdated
@ -1148,0 +1199,4 @@
layout.use_property_split = True
layout.use_property_decorate = False
layout.prop(active_item, "socket_type")
if active_item.socket_type in {'VECTOR', 'INT', 'BOOLEAN', 'FLOAT', 'RGBA'}:
Hans Goudey commented 2023-12-11 14:58:40 +01:00
Member
Copy Link

This is missing rotation sockets

This is missing rotation sockets
JacquesLucke marked this conversation as resolved
source/blender/editors/object/object_bake_simulation.cc
@ -298,0 +306,4 @@
NodesModifierData &nmd = *request.nmd;
bake::ModifierCache &modifier_cache = *nmd.runtime->cache;
const bake::NodeBakeCache *bake_cache = nullptr;
switch (request.node_type) {
Hans Goudey commented 2023-12-11 15:45:04 +01:00
Member
Copy Link

How about splitting this to a function called get_node_bake_cache or something?

How about splitting this to a function called `get_node_bake_cache` or something?
JacquesLucke marked this conversation as resolved
source/blender/editors/object/object_bake_simulation.cc Outdated
@ -820,0 +892,4 @@
if (BKE_main_blendfile_path(bmain)[0] == '\0') {
/* Saving the .blend file is not technically necessary in all cases but only when the bake path
* depends on the .blend file path (which is the case by default). */
CTX_wm_operator_poll_msg_set(C, TIP_("Save file before baking"));
Hans Goudey commented 2023-12-11 15:48:42 +01:00
Member
Copy Link

I think it's a bit more consistent/friendly if this is phrased more like File must be saved before baking.
Also TIP_ is unnecessary here, these are extracted by a regex and translated inside

I think it's a bit more consistent/friendly if this is phrased more like `File must be saved before baking`. Also `TIP_` is unnecessary here, these are extracted by a regex and translated inside
JacquesLucke marked this conversation as resolved
source/blender/nodes/NOD_static_types.h Outdated
@ -292,6 +292,7 @@ DefNode(FunctionNode, FN_NODE_VALUE_TO_STRING, 0, "VALUE_TO_STRING", ValueToStri
DefNode(GeometryNode, GEO_NODE_ACCUMULATE_FIELD, 0, "ACCUMULATE_FIELD", AccumulateField, "Accumulate Field", "Add the values of an evaluated field together and output the running total for each element")
DefNode(GeometryNode, GEO_NODE_ATTRIBUTE_DOMAIN_SIZE, 0, "ATTRIBUTE_DOMAIN_SIZE", AttributeDomainSize, "Domain Size", "Retrieve the number of elements in a geometry for each attribute domain")
DefNode(GeometryNode, GEO_NODE_ATTRIBUTE_STATISTIC, 0, "ATTRIBUTE_STATISTIC",AttributeStatistic, "Attribute Statistic", "Calculate statistics about a data set from a field evaluated on a geometry")
DefNode(GeometryNode, GEO_NODE_BAKE, rna_def_geo_bake, "BAKE", Bake, "Bake", "Cache the incoming data so that it can be used without computing it every time")
Hans Goudey commented 2023-12-11 15:27:28 +01:00
Member
Copy Link

computing it every time -> without recomputation maybe?

`computing it every time` -> `without recomputation` maybe?
JacquesLucke marked this conversation as resolved
source/blender/nodes/geometry/nodes/node_geo_bake.cc Outdated
@ -0,0 +413,4 @@
return false;
}
r_ctx.bake = nullptr;
for (const NodesModifierBake &iter_bake : Span{r_ctx.nmd->bakes, r_ctx.nmd->bakes_num}) {
Hans Goudey commented 2023-12-11 16:03:06 +01:00
Member
Copy Link

I usually prefer the () constructors, they're a bit more well defined and safe in general

I usually prefer the `()` constructors, they're a bit more well defined and safe in general
JacquesLucke marked this conversation as resolved
source/blender/nodes/geometry/nodes/node_geo_bake.cc Outdated
@ -0,0 +454,4 @@
}
else {
SNPRINTF(
str, N_("Baked %d - %d"), int(ctx.baked_range->first()), int(ctx.baked_range->last()));
Hans Goudey commented 2023-12-11 16:07:12 +01:00
Member
Copy Link

N_ doesn't really make sense here. If it's translated later, that will include the numbers which will make the lookup fail.

How about including <fmt/format.h> and using return fmt::format(TIP_("Baked {} - {}"), ctx.baked_range->first(), ctx.baked_range->last());

`N_` doesn't really make sense here. If it's translated later, that will include the numbers which will make the lookup fail. How about including `<fmt/format.h>` and using `return fmt::format(TIP_("Baked {} - {}"), ctx.baked_range->first(), ctx.baked_range->last());`
Jacques Lucke commented 2023-12-11 16:14:05 +01:00
Author
Member
Copy Link

Just replacing it with TIP_ seems fine as well. Don't really want to start using <fmt/format.h> here now, I haven't looked into it much yet.

Just replacing it with `TIP_` seems fine as well. Don't really want to start using `<fmt/format.h>` here now, I haven't looked into it much yet.
Hans Goudey commented 2023-12-11 16:16:17 +01:00
Member
Copy Link

It's used in other similar places. It's a required dependency, and it's just a much nicer way to do that sort of formatting that's faster and doesn't require the temporary buffer.

It's used in other similar places. It's a required dependency, and it's just a much nicer way to do that sort of formatting that's faster and doesn't require the temporary buffer.
JacquesLucke marked this conversation as resolved
source/blender/nodes/geometry/nodes/node_geo_bake.cc Outdated
@ -0,0 +569,4 @@
}
}
static void node_rna(StructRNA *srna)
Hans Goudey commented 2023-12-11 16:03:28 +01:00
Member
Copy Link

Might as well just remove this?

Might as well just remove this?
JacquesLucke marked this conversation as resolved
Jacques Lucke added 8 commits 2023-12-12 10:20:12 +01:00
Simon Thommes requested changes 2023-12-12 18:52:25 +01:00
Simon Thommes left a comment
Member
Copy Link

Functionality wise this works great in my tests! My feedback is mainly about UI/UX.

So other than the things mentioned below and the loss of materials I think this is mainly just leaving open the need for better interaction with the bake settings/baking itself in an overview like the outliner, that we talked about.

Regarding your question of the frame range:
I think that it is reasonable to fall back to the same range as the simulation baking. While the main reason for detaching that range with simulations is preroll, which is not necessarily something that is needed for baking animated data, it is reasonable to assume that some of the simulation might rely on data that uses a bake node. So I think it makes sense to use the same by default and rely on the custom range , if people need to change this.

UI

  • It would also be nice for the trashcan icon to be greyed out, when there is nothing to delete. It should definitely also be greyed out when the file is not saved.
  • It would be reasonable imo to grey out the bake mode enum in the baked state to avoid the awkward situation for example when it is set to still but outputting an animated bake. So to change this after baking would require you to trash the bake.
  • When baked in still mode the overlay info on top should also show the frame it was baked in, just like it shows the range for an animation 'Baked Frame N'. (same for the properties panel) This is valuable information.
  • Looking at the node, I would suggest renaming 'Animated' to 'Animation'. Thinking about this more I would even consider moving to 'Frame Range - Still Frame' instead of 'Animation - Still' since it's more semantically neutral. But I'm not sure, what do you think?
  • Not sure if we talked about this specifically, but imo the choice between Animation and Still is so crucial to the functionality of the node that it should be exposed as an expanded enum in the node UI.
  • The button should then also just be called 'Bake' imo. It makes sense to me to diconnect the action from the type and makes things a bit more clear and structured.
  • The baked state is really not striking enough at the moment imo. I'm hoping that drawing the nodes that aren't evaluated differently will help enough with this but right now the overlay on top of the node is definitely not striking enough for something so quite important.

Bugs/Issues

  • Looks like the baking operator is missing an undo step (?) Doing Bake Animation and then another operator, undoing after will undo both actions.
  • There should be some sort of validation that the cache files exist. Currently, baking and deleting the files will not show any feedback in the UI that would indicate the missing files, other than the evaluation just missing data.
  • After deleting the bake in the properties panel the overlay on top of the node does not update until the cursor moves into the node editor region.
  • The bake node does not show up in the link drag search.

UX

  • I'm not sure how doable that is, but it would be great if inserting/removing a bake node in an unbaked state that just passes through the data wouldn't trigger a node-tree re-evaluation. (I just realized that it's not guaranteed that an inserted passthrough not do anything, since anonymous attributes might not be available. Still leaving this here though since it would be amazing if, in the future, inserting a bake node could automatically collect all necessary anonymous attributes to be captured for baking.)
  • Just want to point out that it's good that anonymous attributes that are not piped through the bake node stop working in the unbaked state just like they will when baked. Ideally there would also be feedback in the node-tree UI showing this issue, but that is something we could do in general for missing anonymous attribute links.
  • Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context. Since this leaves digging deep through all the node-trees as the only way to do this without python, I wouldn't feel comfortable leaving this gap in functionality in for a release.
    Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists.
  • Generally I think it would be useful to indicate how a bake node is intended to be used, by defining the bake_mode in the node itself, rather than the instance of it. At the same time this needs to be changeable in the instance, so I'm not sure how we can soolve this at the moment. Maybe this is a topic we can just pick up again at a later time.
Functionality wise this works great in my tests! My feedback is mainly about UI/UX. So other than the things mentioned below and the loss of materials I think this is mainly just leaving open the need for better interaction with the bake settings/baking itself in an overview like the outliner, that we talked about. Regarding your question of the frame range: I think that it is reasonable to fall back to the same range as the simulation baking. While the main reason for detaching that range with simulations is preroll, which is not necessarily something that is needed for baking animated data, it is reasonable to assume that some of the simulation might rely on data that uses a bake node. So I think it makes sense to use the same by default and rely on the custom range , if people need to change this. UI - It would also be nice for the trashcan icon to be greyed out, when there is nothing to delete. It should definitely also be greyed out when the file is not saved. - It would be reasonable imo to grey out the bake mode enum in the baked state to avoid the awkward situation for example when it is set to still but outputting an animated bake. So to change this after baking would require you to trash the bake. - When baked in still mode the overlay info on top should also show the frame it was baked in, just like it shows the range for an animation 'Baked Frame N'. (same for the properties panel) This is valuable information. - Looking at the node, I would suggest renaming 'Animated' to 'Animation'. Thinking about this more I would even consider moving to 'Frame Range - Still Frame' instead of 'Animation - Still' since it's more semantically neutral. But I'm not sure, what do you think? - Not sure if we talked about this specifically, but imo the choice between Animation and Still is so crucial to the functionality of the node that it should be exposed as an expanded enum in the node UI. - The button should then also just be called 'Bake' imo. It makes sense to me to diconnect the action from the type and makes things a bit more clear and structured. - The baked state is really not striking enough at the moment imo. I'm hoping that drawing the nodes that aren't evaluated differently will help enough with this but right now the overlay on top of the node is definitely not striking enough for something so quite important. Bugs/Issues - Looks like the baking operator is missing an undo step (?) Doing Bake Animation and then another operator, undoing after will undo both actions. - There should be some sort of validation that the cache files exist. Currently, baking and deleting the files will not show any feedback in the UI that would indicate the missing files, other than the evaluation just missing data. - After deleting the bake in the properties panel the overlay on top of the node does not update until the cursor moves into the node editor region. - The bake node does not show up in the link drag search. UX - I'm not sure how doable that is, but it would be great if inserting/removing a bake node in an unbaked state that just passes through the data wouldn't trigger a node-tree re-evaluation. (I just realized that it's not guaranteed that an inserted passthrough not do anything, since anonymous attributes might not be available. Still leaving this here though since it would be amazing if, in the future, inserting a bake node could automatically collect all necessary anonymous attributes to be captured for baking.) - Just want to point out that it's good that anonymous attributes that are not piped through the bake node stop working in the unbaked state just like they will when baked. Ideally there would also be feedback in the node-tree UI showing this issue, but that is something we could do in general for missing anonymous attribute links. - Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context. Since this leaves digging deep through all the node-trees as the only way to do this without python, I wouldn't feel comfortable leaving this gap in functionality in for a release. Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists. - Generally I think it would be useful to indicate how a bake node is intended to be used, by defining the bake_mode in the node itself, rather than the instance of it. At the same time this needs to be changeable in the instance, so I'm not sure how we can soolve this at the moment. Maybe this is a topic we can just pick up again at a later time.
Jacques Lucke added 8 commits 2023-12-13 12:56:39 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
5b344dccc0 missing redraw after freeing bake
Jacques Lucke commented 2023-12-13 13:04:59 +01:00
Author
Member
Copy Link

I fixed some of the issues you mentioned. Others I added as next steps to the patch description.

I'm not sure how doable that is, but it would be great if inserting/removing a bake node in an unbaked state that just passes through the data wouldn't trigger a node-tree re-evaluation. (I just realized that it's not guaranteed that an inserted passthrough not do anything, since anonymous attributes might not be available. Still leaving this here though since it would be amazing if, in the future, inserting a bake node could automatically collect all necessary anonymous attributes to be captured for baking.)

Could work in theory, but it's fairly difficult to implement I think.

Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context.

What do you mean by "the context" here exactly?
I think it's definitely something we need, but I'd like to keep separate if possible to be able to make progress..

Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists.

I'm really not a fan of adding a button for baking all bake nodes without any kind of tagging. We could do it as a last resort if we don't manage to finish something more useful for the release. Implementation wise it's easy.

I fixed some of the issues you mentioned. Others I added as next steps to the patch description. > I'm not sure how doable that is, but it would be great if inserting/removing a bake node in an unbaked state that just passes through the data wouldn't trigger a node-tree re-evaluation. (I just realized that it's not guaranteed that an inserted passthrough not do anything, since anonymous attributes might not be available. Still leaving this here though since it would be amazing if, in the future, inserting a bake node could automatically collect all necessary anonymous attributes to be captured for baking.) Could work in theory, but it's fairly difficult to implement I think. > Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context. What do you mean by "the context" here exactly? I think it's definitely something we need, but I'd like to keep separate if possible to be able to make progress.. > Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists. I'm really not a fan of adding a button for baking all bake nodes without any kind of tagging. We could do it as a last resort if we don't manage to finish something more useful for the release. Implementation wise it's easy.
Simon Thommes commented 2023-12-13 14:18:46 +01:00
Member
Copy Link

Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context.

What do you mean by "the context" here exactly?
I think it's definitely something we need, but I'd like to keep separate if possible to be able to make progress.

Here, by context, I mean all bakes of all modifiers of all selected objects. This ties in to your last point as well.

Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists.

I'm really not a fan of adding a button for baking all bake nodes without any kind of tagging. We could do it as a last resort if we don't manage to finish something more useful for the release. Implementation wise it's easy.

We definitely need some sort of handling for baking several bakes without needing to hunt them down individually. I'm fine with handling that in a separate task, but if the final solution is not ready for 4.1, I'd strongly suggest to go for a simpler approach that at least gives some of that functionality.
In my personal opinion, the need for baking in the bake node and the simulation zone is really not too different. So handling them the same, even before the nice overview is available, would make sense to me.

> > Until there is an overview of all bakes somewhere with the functionality to batch bake, the current implementation leaves a huge lack in the functionality to bake the all bake nodes in the context. > > What do you mean by "the context" here exactly? > I think it's definitely something we need, but I'd like to keep separate if possible to be able to make progress. Here, by context, I mean all bakes of all modifiers of all selected objects. This ties in to your last point as well. > > Since there might very well be a dependency between different bake and simulation nodes, I personally don't think it would be too unreasonable to provide a button that bakes both at the same time in the physics panel. At least until the better solution exists. > > I'm really not a fan of adding a button for baking all bake nodes without any kind of tagging. We could do it as a last resort if we don't manage to finish something more useful for the release. Implementation wise it's easy. We definitely need some sort of handling for baking several bakes without needing to hunt them down individually. I'm fine with handling that in a separate task, but if the final solution is not ready for 4.1, I'd strongly suggest to go for a simpler approach that at least gives some of that functionality. In my personal opinion, the need for baking in the bake node and the simulation zone is really not too different. So handling them the same, even before the nice overview is available, would make sense to me.
Jacques Lucke commented 2023-12-15 10:25:08 +01:00
Author
Member
Copy Link

@blender-bot build

@blender-bot build
Simon Thommes commented 2023-12-15 12:27:19 +01:00
Member
Copy Link

Okay, with greying out the mode when it's baked I also meant that you shouldn't be able to change it. I should have been more specific about that. You can still change it atm. Now I'm noticing that this is also the same with the other settings in the properties panel. Shouldn't these be locked for the UI while they are greyed out? I don't see a use-case for changing these after baking.

I see you added a warning in node and modifier when Blender fails to load the bake data, that's great! I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right?

Once I change the active object the bake data seems to be lost but the warning does not show up. Would be good if this could be more consistent with the data that is actually there on disk if possible.

Other than that this looks good to me as the initial state tbh.
What is your plan regarding exposing the bake functionality in other places? Again, imo this is a topic that definitely needs to be addressed in some way for the release, even if the proper solution will not be ready in time.

Okay, with greying out the mode when it's baked I also meant that you shouldn't be able to change it. I should have been more specific about that. You can still change it atm. Now I'm noticing that this is also the same with the other settings in the properties panel. Shouldn't these be locked for the UI while they are greyed out? I don't see a use-case for changing these after baking. I see you added a warning in node and modifier when Blender fails to load the bake data, that's great! I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right? Once I change the active object the bake data seems to be lost but the warning does not show up. Would be good if this could be more consistent with the data that is actually there on disk if possible. Other than that this looks good to me as the initial state tbh. What is your plan regarding exposing the bake functionality in other places? Again, imo this is a topic that definitely needs to be addressed in some way for the release, even if the proper solution will not be ready in time.
Jacques Lucke added 2 commits 2023-12-15 19:59:03 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
4bd4dd40c8 disable properties when baked
Jacques Lucke commented 2023-12-15 20:03:42 +01:00
Author
Member
Copy Link

Shouldn't these be locked for the UI while they are greyed out?

Done.

I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right?

Yeah, Blender keeps the bake in memory, same with simulations. I think there was a related bug were it would try to reload on every evaluation. Maybe the change in behavior you found is caused by that. It's fairly clear to me that we don't want to access the disk on every evaluation as that can be slow (even just checking if a file is still there).

Once I change the active object the bake data seems to be lost but the warning does not show up.

Not entirely sure what changing the active object has to do with that. I think I don't understand what you mean.

What is your plan regarding exposing the bake functionality in other places? Again, imo this is a topic that definitely needs to be addressed in some way for the release, even if the proper solution will not be ready in time.

I want to start working on that next week.

> Shouldn't these be locked for the UI while they are greyed out? Done. > I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right? Yeah, Blender keeps the bake in memory, same with simulations. I think there was a related bug were it would try to reload on every evaluation. Maybe the change in behavior you found is caused by that. It's fairly clear to me that we don't want to access the disk on every evaluation as that can be slow (even just checking if a file is still there). > Once I change the active object the bake data seems to be lost but the warning does not show up. Not entirely sure what changing the active object has to do with that. I think I don't understand what you mean. > What is your plan regarding exposing the bake functionality in other places? Again, imo this is a topic that definitely needs to be addressed in some way for the release, even if the proper solution will not be ready in time. I want to start working on that next week.
Jacques Lucke commented 2023-12-15 20:03:54 +01:00
Author
Member
Copy Link

@blender-bot build

@blender-bot build
Simon Thommes commented 2023-12-18 10:31:25 +01:00
Member
Copy Link

I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right?

Yeah, Blender keeps the bake in memory, same with simulations. I think there was a related bug were it would try to reload on every evaluation. Maybe the change in behavior you found is caused by that. It's fairly clear to me that we don't want to access the disk on every evaluation as that can be slow (even just checking if a file is still there).

Once I change the active object the bake data seems to be lost but the warning does not show up.

Not entirely sure what changing the active object has to do with that. I think I don't understand what you mean.

I was mainly surprised that the behavior changed. And yes, of course we should keep the data in memory and not reload it from disk all the time. I wasn't sure how expensive checking the existance would be, but it's fine with me to only do that when the files actually need to be read.

I figured out that the issue of changing the active object was my fault, I was using the viewer node. Just confirmed that this is working as expected.

> > I'm a bit confused that this is not the case after I bake and directly delete the bake data from disk. Does Blender keep all of it in memory from the baking process? This changed since your last update, right? > > Yeah, Blender keeps the bake in memory, same with simulations. I think there was a related bug were it would try to reload on every evaluation. Maybe the change in behavior you found is caused by that. It's fairly clear to me that we don't want to access the disk on every evaluation as that can be slow (even just checking if a file is still there). > > > Once I change the active object the bake data seems to be lost but the warning does not show up. > > Not entirely sure what changing the active object has to do with that. I think I don't understand what you mean. I was mainly surprised that the behavior changed. And yes, of course we should keep the data in memory and not reload it from disk all the time. I wasn't sure how expensive checking the existance would be, but it's fine with me to only do that when the files actually need to be read. I figured out that the issue of changing the active object was my fault, I was using the viewer node. Just confirmed that this is working as expected.
Simon Thommes approved these changes 2023-12-18 10:43:18 +01:00
Simon Thommes left a comment
Member
Copy Link

Okay, just gave it another quick check, for me this is good to go!

Okay, just gave it another quick check, for me this is good to go!
Jacques Lucke added 4 commits 2023-12-18 12:22:31 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
b2714e004b Merge branch 'main' into bake-geometry-nodes
Jacques Lucke commented 2023-12-18 12:24:45 +01:00
Author
Member
Copy Link

@blender-bot build

@blender-bot build
Jacques Lucke merged commit 00eaddbd51 into main 2023-12-18 13:01:16 +01:00
Jacques Lucke deleted branch bake-geometry-nodes 2023-12-18 13:01:18 +01:00
Jacob Merrill commented 2023-12-23 18:02:35 +01:00
First-time contributor
Copy Link

Was wondering, for quick playback - does this data live in a array on the gpu or is the geo still fed each frame to the gpu?

Was wondering, for quick playback - does this data live in a array on the gpu or is the geo still fed each frame to the gpu?
Cube-1 commented 2024-02-18 21:14:22 +01:00
First-time contributor
Copy Link

Is it possible to add frame offset option for baked animation? like in mesh cache sequence modifier

Is it possible to add frame offset option for baked animation? like in mesh cache sequence modifier
Jacques Lucke commented 2024-02-19 16:13:57 +01:00
Author
Member
Copy Link

This is not planned currently. Instead we want to have a separate Import Bake node where you can load any frame you want.

This is not planned currently. Instead we want to have a separate Import Bake node where you can load any frame you want.
👍 2
Roman Yu commented 2024-03-18 12:48:44 +01:00
First-time contributor
Copy Link

cache node crash Blender every time with GN hairs

cache node crash Blender every time with GN hairs
Simon Thommes commented 2024-03-18 13:37:44 +01:00
Member
Copy Link

@ramonkarlos please create a proper bug report with instructions on how to replicate the issue, so it can be investigated and fixed.

@ramonkarlos please create a proper bug report with instructions on how to replicate the issue, so it can be investigated and fixed.
Sign in to join this conversation.
Reviewers
No reviewers
Lukas Tönne
Hans Goudey
Simon Thommes
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#115466
No description provided.
Delete Branch "JacquesLucke/blender:bake-geometry-nodes"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?