GeoNodes - Workshop May 2024 (Simon Notes) ====================== ## UI/UX - Evaluation Context Visualisation !!! - Rename sockets in node UI (GROUP/SIM/REPEAT/CAPTURE/BAKE) - Tools for node tree structure - Single Use Nodegroup - Multiline Comments - auto layout operator ? ## Gizmos - Flow visualisation ## Bake Management ### Overall Requirements - bake to .blend - don't bake unnecessary dependencies (simple isolated sims that are only used for other bakes) - identify as such in UI - high-level overview of bakes with info on state - override state of bake settings -> propagate path - Simulation Range - indication in timeline - playback including pre-roll (like preview range ?) - bake evaluation only including actual dependencies - bake/clear buttons on simulation node - cache invalidation to cause immediate re-evaluation, not only on 1st frame (?) ### Paths - Project/scene/object/modifier/node level path hierarchy - project variables (callbacks? - receive shot and sequence number) - handle object duplication (editable path when baked) ## Socket Type Inferencing - e.g. volume socket - dynamic data type ## Lists ## For-Each Loop Types ## Assets - embedded assets - menu integration (-> brush assets) ## Project Project - adopt the orphan ---- ## Papercuts ### Menu Socket Modularity From Rocket Chat: Simon: Hey, quick question about the menu switch: How does one use the same menu for switching multiple sets of values with different types? I'm trying to remember the design discussions we had. The approach with encapsulating the node in a group doesn't work for this, since the type switch would need to be exposed, which it can't be. Was the idea to rely on this + the dynamic type socket? Simon: Another thing: Is there any way that we could to the trick of using the same menu multiple times with a node-group under the hood in the future? The node-group thing is really not very intuitive and it's not immediately obvious why just connecting the same menu to another node doesn't just work, by syncing the item inputs. Jacques: you remember correctly. The final design relies on dynamic types. The workaround is correct. Simon: Would there be a way of treating menu switch nodes as something special and kind of doing the node-group thing under the hood? Right now it's really just not very intuitive. Jacques: We could wrap it in a node group by default, but that also comes with some disadvantages of course. I guess you describe some kind of design that requires a "menu data-block" that can be referenced by multiple menu switch nodes, but that design was decided against in favor of using the node group mechanism. Lukas: the "menu switch wrapped by node group" trick is abusing ID data blocks as a unique storage/identifier hack. i'd rather not entrench this further by doing it automatically and hide it from the user. We are probably going to need ID data blocks for this in some way for the foreseeable future, but maybe menus could be shared at least within the same node tree. I.e. a node tree stores multiple menu definitions with a name. Menu nodes can share items with other menu nodes in the same tree. Jacques: The problem with sharing things like this within the same node tree is that it makes ctrl+g to create node groups unreliable, because it would break these links. Jacques: Generally, the enum data-block design would work too. The main tricky thing is to justify a new data-block as I mentioned a few years ago already. Brecht also said that using node-groups for this is fine. I think we should finish the current design for now, which means we have to improve node groups in general and support dynamic socket types. If that's still not enough in the future, it seems quite possible to switch to using enum data-blocks.