I’d like to ask if and/or it was considered to make Checkpoints an ID type instead of this separate new type of thing? I think this ends up implementing a few miscellaneous things that ID types already do well?
I’m not generally opposed to making checkpoints an ID type and maybe it turns out better this way. Would be good to discuss this more. Currently I think that this would be an unnecessary indirection, but I might change my mind. If I want to reference a checkpoint location on disk, it feels like it should be enough to just use the file path instead of having to create an ID data block first. A checkpoint data block would essentially just be a general container for various geometry types and maybe other data. It probably shouldn’t be called “checkpoint” then.
Needing to reference checkpoints by name
In the proposal, checkpoints are not referenced by name. The name is more like a label that helps the user organize things. The internal identifier of a checkpoint would be the owner id together with a node id or modifier name and an additional integer id for group nodes.
The path can be used to specify a location on disk where the baked data should be stored and loaded from.
I’m not arguing this is not good enough for the first version, but won’t this get cumbersome fast? When a nodegroup uses a bunch of checkpoints and then if used one or more times within the same graph either every instance either all the names or paths need to be changed so they don’t conflict? Or was it just already planned to append the nodegroup node name to every file metadat/name it outputs so this becomes a non issue?
I think it is essential to have the flexibility to manually choose a path on a per checkpoint basis. However, I also see that it would be useful to build additional utilities on top of that so that you don’t have to choose every path manually all the time. If you don’t care about storing checkpoints separately, they can also be stored in the .blend file directly.
The checkpoints behave essentially like sockets in the way they bubble up, to the point they could even be implemented as a socket type. I don’t want to suggest actually making them input sockets, but at least conceptually it helps me understand how they fit into things and should behave similarly in some ways.
Yeah, the way it’s bubbling up is similar indeed. In theory, it could probably be implemented with a new socket type that’s user-visible. That would also benefit from checkpoints being an id type. A potential issue arises when the checkpoint socket is linked to more than one
Checkpoint node. That would work as long as the checkpoint is only read from, but it’s more challenging to define the behavior when baking the checkpoint, because then it’s not clear which nested
Checkpoint node should be baked. That could be solved by setting a link-limit of 1 for checkpoint output sockets, but then you couldn’t link it to multiple import nodes.
As I mentioned earlier in this design task, I still think there should be some clear UI distinction between checkpoints that are expected to be automatically cached/baked, and freezing of geometry as a more manual step as part of the modelling process.
I agree that there are different kinds of checkpoints for different use-cases that need to be differentiated somehow:
- Some checkpoints are only baked temporarily to make geometry nodes evaluation faster while working on it. This should become mostly unnecessy eventually with automated caching.
- A slight variation of that are checkpoints that you bake for faster evaluation but also want to store in the .blend file or on disk so that the data does not have to be reevaluated after loading the file.
- Then there are the “classic” animated geometry checkpoints (whether that uses simulation or not is kind of unrelated). Those kinds of checkpoints you likely want to be able to bake/free all at once (or at least in groups).
- Some checkpoints are made to be able to manually modify the data destructively in the middle of a geometry node tree. Freeing those globally seems mostly useless unless the manual edits are only done to fix up e.g. a simulation that was also freed.
My main point is that I agree that there are different kinds of checkpoints but I don’t think that there are only two categories that every checkpoint can be organized into. Hence I mentioned that we might need some kind of tagging system that allows users to group their checkpoints however they want. And then those tags can be used for filtering when baking/freeing. I wouldn’t mind defining some standard tag for the common use case of simulation baking.