This workshop took place at the Blender HQ in Amsterdam. This thread contains just the raw meeting notes we took during the workshop. See the blog post on code.blender.org for a better summary of various topics.
Present
- Bastien Montagne (assets)
- Dalai Felinto (~3 days)
- Demeter Dzadik (Bone Info)
- Falk David (~1 day)
- Jacques Lucke
- Julian Eisel (assets)
- Lukas Tönne (~2 days)
- Pablo Vazquez (UI)
- Sergey Sharybin (assets, shading nodes, code style)
- Simon Thommes (~3 days)
- Sybren Stüvel (Bone Info)
Workshop Planning
| Topic | Complexity | Priority |
|---|---|---|
| Delaunay Triangulation | ★ | ✦ |
| Auto-link Routing | ★ | ✦ |
| Shipped Assets | ★★ | ✦✦✦ |
| Inline Sockets in Groups | ★★ | ✦ |
| Attribute Interpolation | ★ | ✦✦ |
| Progress Report | ★ | ✦ |
| Lists MVP | ★★ | ✦✦✦ |
| ColorRamp / Curve Mapping | ★ | ✦ |
| Gizmos Drivers | ★ | ✦ |
| Modal Node Tools | ★★ | ✦ |
| Catalog Menu Path | ★★ | ✦✦ |
| Node Tool Tools | ★★★ | ✦✦ |
| Modifier UI: Row | ★★ | ✦ |
| Viewer w/o Geometry Socket | ★★ | ✦✦ |
| Active Geometry Set | ★ | ✦ |
| Evaluation Modes | ★★ | ✦✦ |
| Custom (Sticky) Viewer | ★★★ | ✦✦ |
| Surface/UV Fallback | ★★ | ✦✦✦ |
| Modifier Order Constraints | ★★★ | ✦✦✦ |
| Hair Solver | ★ | ✦✦✦ |
| Socket Shapes | ★ | ✦✦✦ |
| Packed Assets | ★ | ✦✦✦ |
| Bone Info | ★★ | ✦ |
| Fit Curve | ★ | ✦ |
| Asset Versioning | ★★★ | ✦✦✦ |
Hair Project Landing Task
Hair Dynamics - Landing Project Task.
Lists
- Initial PR
- Currently has three nodes:
- List: create new lists from field
- Get List Item: Retrieve an item from a list for an index
- Index can be a single value, field, grid, …
- List Length
- Would be good to be able to affect the geometry in some way already before this is merged as experimental.
- Noticed that the Get List Item node can be used for that already when the input is a field. The output can then be passed into the Store Named Attribute node.
- The Get List Item node can also be used for appending, slicing, …
- Element vs Item
- Conclusion: Item
- “Get Item” vs. “Get List Item” vs. “Sample List Index” vs. “List Item”?
- Conclusion: “Get List Item”
- Get List Item:
- Move “List” input before “Index”
- “Index” input default should be consistent with Sample Index field.
- So there shouldn’t be the default Index Field now
- We can discuss to use the Index field default in the future again.
- List Length node does not really care about the input type
- Unfortunate to have the type dropdown, but probably best we can do for now.
- Should have a rainbow socket in the future.
- Also a bit related to the “pin type” prototype, but slightly different.
- Socket shape
- Find old mockup by Simon (three horizontal lines or so)
- Combining lists of different lenghts:
- Repeating shorter lists seems fine to everyone.
- Would be nice to communicate to user but there might not be a better solution than showing in tooltips.
- Combining a list and field should output a list (we didn’t try it)
- These three nodes should be good enough to merge into main as experimental option with function/switch nodes support.
Color Ramp / Curve Mapping
-
Everyone likes it.
-
Showing the inputs in the modifier is still a todo.
- Briefly talked with Bastien about it and it seemed best to just add new more specialized id property types that use a pointer to the existing DNA structures under the hood.
-
The widgets take up a lot of space in node groups currently.
- We thought about ways to reduce the size by making some things optional.
- Best option seems to be to do something like for colors: you see a preview of the ramp / curve and can click on it to open an edit popup.
-
Update: Instead of a pop-up we expand the widget upon clicking on it.
- The collapsed widget stays on top, it can be clicked further to collapse again.
- The complete widget background can either be inside a box or have a darker background (similar to sub-panels).
- When expanded, could show an arrow on the collapsed widget part of the widget.
Extended Socket Interface
- inspired by Godot incspector interface
- somewhat related to curve/ramp input UI
- somewhat similar to material properties representation of the node-tree
- evolution of the existing spreadsheet icon
- idea:
- make it possible to select pre-existing scructs as modifier/socket inputs
- example: float or noise or attribute or attribute + 1
- these structs could be fully customizable as node-trees
- in theory the structs could have their own inputs and this could be indefinitely nested
Row/Inline Panels
From the Node Group properties panel you can directly add the different layout types:
In the TreeView we indicate the layout type similar to how we should “Domain - Data-type” for Attributes:
- Even if something is displayed as row in the modifier, it’s still displayed as panel in group nodes.
- However, when the “panel” is collapsed, it still shows as “row”.
- if something is connected to one of the inputs and the row is collapsed the whole row UI is not shown either way
- In group nodes, the when the panel is expanded, all inputs are separate sockets. When the panel is collapsed, the inputs can still be shown as row.
- Inline sockets can be solved the same way: There can be a group containing the input and output socket.
- the names of the layout, input and output can be synced up, just like for the panel toggle right now
- Different options for handling order constraints:
- Don’t allow the user to build invalid things.
- Can be annoying when invalid intermediate states are necessary to get from one good state to a nother.
- Auto-fix layout option when there is something invalid, optionally with a warning.
- Very non-Blender like.
- Show a warning on the group that its layout is currently invalid.
- Don’t allow the user to build invalid things.
- Check if we can have multi-selection in the group sockets now.
- Panels before sockets can be a useful intermediate step to introducing panels to a tree.
- Should be able to tell group (layout) types apart when they are collapsed in the group sockets tree view.
- Different layout types:
- Panel
- Row
- Column
- “inline sockets” are be a special case of the row layout
- Options for new items:
- Socket: Input, Output, Layout: Panel, Column, Row
- Layouts can be above sockets, but there is an error if the layout is of type panel.
- “Aligned” is an option for both the row or the column layouts.
- The “Separator” can work as a line separator for node groups, and as a blank space for the modifier UI.
Modifiers as Behaviors
- idea:
- leverage declarative system within bundles and closures to define behaviors from exisitng modifiers (e.g. define existing hair nodegroups as hair deformers, hair in - hair out)
- group input of the hair modifier contains an input (list of bundles) that specifies the compatible behavior types and closure signature to evaluate
- the behavior node-groups need to follow that signature and define their type
- that ‘list of bundles’ input can then be shown in the modifier as a dynamic list of behaviors that can be added from a list of availabe compatible node-groups
- for nodes we would then need a new node that can take a node-group and turn it into a closure output that can be used in that list input (maybe, maybe different)
- it’s not yet entirely clear how a group is turned into a closure
- could happen wherever the node-group is used
- the type used for filtering could be specified in the node-group’s usage panel
Socket Defaults
- revisit idea of node-based defaults
- default state with visual indication would help to avoid issues with changing defaults (already a problem)
- changing back to this can be in the right-click panel
- this could be related to the idea of the
Extended Socket Interface- defaults, rather than being defined on the same level as the node-group, could be individual small node-trees stored by each group input socket
Surface Geometry/UV fallbacks
- use context inputs
- potentially use geometry input subtypes that can be changed by the modifier user (realted to Extended Socket Interface)
- switch types in context menu
- default type set by node-group author
Socket Shapes
- collapsed sockets with single value sockets looks questionable
- Structure Type options should be ordered alphabetically
- change
Structure TypetoShape, since here it just describes the property of the Socket. In other places, where talking about the data itself (socket tooltip) the expressionData Structure(or Data Shape, Structure Type ?) should be used
Solver Bundle Structure
Example by Jacques:
/
Cube/
Type: Geometry
Geometry: <...>
Cylinder/
Type: Geometry
Geometry: <...>
Scene Gravity/
Type: Constant Acceleration
Acceleration: <0, 0, -9.81>
Scene Forces/
Wind.001/
Type: Force Field
Force Field: <...>
Vortex/
Type: Force Field
Force Field: <...>
Noise/
Type: Force Field
Force Field: <...>
Filter: /Cube
Some Constraints/
Edge Lengths:
Type: Edge Length Constraint
Stiffness: <...>
Inner Edges:
Type: Vertex Distance Constraints
Vertices: <(0, 2), (4, 10), ...>
Lengths: <0.2, 0.5, ...>
Target: /Cylinder
Pin/
Type: Static Pin Constraint
Vertices: <3>
Positions: <(1, 2, 3)>
Target: /Cube
Link/
Type: Dynamic Pin Constraint
Target 1: /Cube
Target 2: /Cylinder
Vertices 1: <5, ...>
Vertices 2: <8, ...>
Ground/
Type: Infinite Plane Collider
Position: <0, 0, 0>
Normal: <0, 0, 1>
Other Object/
Type: Animated Collider
Geometry: <...>
- The Data output is a (partial) copy of the Control input. The geometries in the Data are simulated.
- Need to restrict bundle item names (can’t use
/in them and maybe some other chars neither).
Code Style Discussion with Sergey
- Comment style:
// - Static named constructors:
from_some_thing(..) - Include paths:
BKE_...>blenkernel/... - Namespaces: Sergey still needs to know what he likes.
- Enum names:
HTTPError>HttpError - Error handling: Add
blender::Resultusing similar API likestd::expected. - DNA defaults: Still need to drag Brecht in the discussion to resolve the free/delete patch.
Active Geometry
- Show active geometry set of spreadsheet in viewport.
- If there are multiple spreadsheets, show them all.
- Should the 3D view have the geometry selection as well?
- Use local view with viewer path in 3d view.
- Can somehow “activate” a geometry in the spreadsheet to view in the 3d view.
- Would be good to be explicit about which 3D view to show the geometry.
- Also see screencast keys addon.
- Would be good to not require the use of the spreadsheet because many don’t use it.
- Idea: Use ctrl+/ in 3D view to enter local view on a “sub object” (partial local view).
- Idea: Object Mode Instance “sub-mode”, where you select individual instances (and then go to local view).
Viewer without Geometry Socket
- Same or separate viewer node?
- Existing viewer node only does something when there is a geometry.
- When there are multiple viewer nodes, ctrl+shift+click could activate the “best” one.
- Viewable data:
- Geometry with field (exists)
- Grids
- Lists
- Show in spreadsheet (remove Geometry and Domain panels)
- Bundle
- Tree view in spreadsheet
- Single Values
- Some data can be viewed directly in the node editor, other data in the spreadsheet and 3D view.
- How to select which viewer node should be used?
- Need to use logged data or inferred data structure data.
- Can the existing viewer node be split into two separate viewers (one for geometry and one for the field)?
- Seems tricky with custom viewers.
- Idea! Have a single viewer node with a rainbow multi-input. It just views whatever data is passed to it.
- Instead of using rainbow socket, one can also use the commonly used extend socket. The sockets automatically change type and disappear as needed.
Custom Viewer
- Node group with single(?) viewer inside.
- Tagged as being a viewer group (usage panel).
- Inputs can be marked as “viewer inputs”.
- Ctrl+shift+click connects to one of these viewer inputs using a heuristic (based on socket order and structure type).
- If there are multiple viewer nodes inside the viewer group, then one needs a way to control which viewer is used.
Evaluation Modes
- General solution for existing Is Viewport node (or often requested Is Edit Mode node).
- Performance-Quality-Tradeoff.
- Somewhat related to Edit Mode toggle in modifier.
- Could configure when “interactive mode” is enabled in the Simplify settings (e.g. when being in edit mode, or when using a modal operator).
- Render/Final, Medium, Interactive
Debug Views
- On modifier level, have debug views defined by the modifier, that can be enabled.
- Would be nice if checkboxes to enable an overlay can be interleaved with other modifier inputs.
- Would be nicer instead, have a unified “Viewport Display” panel for the modifier.
- Ideally, the user can be sure that activating an overlay does not affect the evaluated geometry.
- Ideally, transforming the modifier output would also transform the overlay (similar to gizmos).
- Can be generalized to custom overlays? Similar to crease overlay.
- Probably need to be able to disable modifier overlays in overlay popover.
- Two ways:
- Visualizing attributes (with builtin features)
- Adding geometry as overlay
- Should it replace the actual geometry or just be drawn on top?
- Could have a separate Overlay Geometry node (geometry input, transform output (like gizmo)).
- Third way:
- add closure input to viewer node to define overlay geometry from input geometry
- if input geometry is unused use the final evaluation of the object as input (including additional generation/deformation after modifier)
- OR pass custom viewer logic as a closure that takes a geometry input which will be the evaluated data of the object at the end of the modifier stack
Delaunay Triangulation
- Which domain is the group ID evaluated on:
- Somewhat arbitrary between point, edge and face domain.
- Probably most straight forward to just use point domain.
- Can split mesh beforehand when just using the point domain would ignore faces that use points which are in different groups.
- Splitting behavior is similar to Split to Instances node.
- Attribute propagation?
- Still on Falks todo list.
- If there is a significant performance cost, it could be optional.
- Instead, one could also remove all attributes before the node for better performance.
- Sockets still need descriptions.
- When the input contains multiple geometries (e.g. a mesh and pointcloud), those should be combined first before doing the triangulation.
- Similar to the Convex Hull node.
- Instance handling seems fine.
- Handling when there are no faces still seems confusing sometimes.
- Might add (intersections) and remove (duplicates) points.
- Should randomize indices in the end.
- Still needs regression tests.
- Should be the same as the Fill Curve node under some circumstances.
Point Density Replacement
- Can’t be fully replaced with grids in Geometry Nodes yet.
- Consider: overlapping colored points
Repeat zone etc. in shading
- Generating an intermediate bNodeTree seems ok, needs to be consumable by Python (so a new intermediate data structure might be overkill).
- Some external renderers use our nodes but only use the Python API.
Global Solvers
- See Declarative System for more context.
- One object to own the “solver” modifier/GN.
- Behaviours could also be defined for:
- Default Behaviours (those that are added when the modifier is added).
- Optional Behaviours (added with +).
- Behaviours for to-be-solved objects:
- Those behaviours are for instance for an object to define its mass and retrieve back the evaluated geometry.
- Depedency graph could be made granular to support partial object geometry evaluation
- This is to the “to-be-solved” objects, that have a modifier that inside its node-tree send data to the solver and wait for it to be solved.
- Rigid body may be better handled on the collection or scene level (and integrated with object-level constraints).
Catalog Menu Path
- Problems:
- There might be a top level “Modifier” catalog containing modifiers, but this top level catalog should not be in the Add menu of the modifier.
Modifiers/Physics/X -> Physics/X
- Change the root.
Author/Normals/X -> Utils/X
- Same asset may be in different places in different menus:
SubdivideinGenerate/andMesh/Operations/
- There might be a top level “Modifier” catalog containing modifiers, but this top level catalog should not be in the Add menu of the modifier.
- Options:
- Exclude catalog from menu path.
- Have a “node add menu path entry” per catalog
- There could be a new display mode in the asset browser to show the menu structure to be able to edit the path entry with drag & drop
- Need to differentiate the cases where the menu path of the asset catalog is defined by the asset author or overridden by the end user.
- Would be nice to be able to move the assets directly in the menu where they are shown.
- Would be good for the quick favorites menu too.
- Asset shelf locations could follow a similar approach to add menu
- Should the menu path either be fully defined by asset catalogs or fully defined by a different system.
- There could be an entirely separate hierarchy system for each kind of menu which is stored separately from the existing
cats.txt.
- There could be an entirely separate hierarchy system for each kind of menu which is stored separately from the existing
cats.txtis hard to extend with more properties- every catalog is a single line
- This would be easier if the storage format would e.g. be json, toml or sqlite.
- Current places where assets show:
CatalogsModifierAdd Menu¹Tool²ID TemplateAsset Shelf
- Can decouple menu path entirely from asset catalog path.
- If there is no menu path specified on an asset, it can fall back to the unassigned category.
- How many menu paths do we need to define?
- One path for 3D view menu path (shared among different object modes)
- Can use path templates:
{DATA_MENU}/Transform/...→Object/Transform/...,Mesh/Transform/..., …
- Can use path templates:
- Node Add menu
- Modifier Add menu
- Tool
- One path for 3D view menu path (shared among different object modes)
¹Add Menu: Type (Geometry Nodes, Compositor, VSE).
²Tools: Type (Curves, Grease Pencil, Mesh, Points) x Mode (object, edit, sculpt, draw)
Bone Info
- The node should definitely output the (rest and pose) bone matrix in armature space.
- Optionally the local bone transform
- Output naming:
PoseLocal PoseRest Pose
- It’s important to be able to detect which bones geometry nodes depends on specifically.
- This allows us to build the depsgraph more granulary.
Lengthoutput is redundant, it can be built by combining theRest Lengthand Pose matrix.Eval Constraintsinput is somewhat illegal, constraints should always be taken into account.- It could make sense for the local pose.
Rollis likely redundant too.
Asset Versioning
- Asset packing has the concept of having assets with the same name which are different.
- We can’t detect yet which one is newer yet though.
- Becomes more important was we ship more assets.
- Is the asset version somehow related to the Blender version?
- Minimum Blender version that an asset can be used with:
- Simplest approach is to just use the version that the .blend file has been saved with.
- In some cases it may be good to be able to use assets in older Blender versions.
- Could store an optional minimum-version-override.
- Should it be possible to have multiple versions of the same asset in the same asset library?
- Would be useful.
- Simplest solution:
- Store version number in the asset meta data (instead of on the
IDdirectly).
- Store version number in the asset meta data (instead of on the
- Alternative (seems to be the preferred solution for now):
- Only use the file name to encode version numbers, like
materials_v1.0.0.blend. - The exact syntax for the version number should be somewhat flexible (look at what is done in Python).
- E.g. support
v1instead ofv1.0.0
- E.g. support
- Has potential issue that all data-blocks in the same .blend file have the same version.
- Then a version number on the asset data is not necessary.
- Same approach can’t be used for variants because one would want multiple variants of the same data-block in a single .blend files (e.g. different LoD levels)
- Only use the file name to encode version numbers, like
- Yet another alternative:
- Store current version in .blend file without version prefix but store older versions in a subdirectory that has a version encoded in the name.
- How to detect that two assets are two versions of the same.
- Needs some “abstract path” for e.g. essentials.
- Can use a naming convention like calling corresponding .blend files
my_asset_v1.blendandmy_asset_v2.blend. - Alternative: store an additional identifier on each asset (initialized with random uuid?)
- There can be a new config file in the asset library that know which data blocks / files are the same besides being different versions.
- There could be a changelog in the asset.
- Use semantic versioning (or the spirit of it).
- Assets can depend on other assets.
- What to do to the version number of an asset if a dependency is updated?
- Detect such cases when uploading assets to the extensions platform and/or when using the assets in Blender.
- Unversioned data is assumed to be version 0.0.0.
Closures and Bundles
- do explicit sync with button
- show button in node when difference is automatically detected
- if no in- nor outputs are defined on the evaluate closure node, do automatically sync when connecting a closure for the first time (as an exception)
- same for the other way around (connect new closure with existing evaluate node)
- even create internal links if necessary, basically treat the same as initializing the state after adding the closure via link-drag-search
- same for the combine/separate bundle node
- same for the other way around (connect new closure with existing evaluate node)
- don’t allow certain characters in bundle item names and the bundle type
/&|"^~,- could also do this for closure in-/outputs, but there is no strong reason currently
- show warning when out of sync with more information on what is different
- try adding the sync button to that warning
- implicit conversion between name matches of different data type
- sync button should show up to indicate difference, even if it’s just the type
- there should be an indication of what is different to know if there is data lost by the implicit conversion (maybe just the prev mentioned warning info)
- mention “bundle” in the bundle related warnings
- colors
- to be decided
- closure socket color very close to integer
- closure zone color representative of socket color
Fit Curves
- Add regression tests
- Fix zero/one point crash
- Cyclic curves not supported yet
- Add socket descriptions.
- Should output aligned handles instead of free for non-corners.
- Corner selection is ignored in Refit method.
- Either make it work or hide the socket.
Builtin Menus as Sockets
- off-topic, but would be nice to visualize which menu dependant sockets belong to which menu option (existing issue already)
- multiple menus with matching item options (e.g. domain selection)
- aggregate intersection of available options (e.g. [Points, Edges, Faces], [Points, Corners, Faces] → [Points, Faces])
Output visibility inferencing
-
- Name not final
- Would be nice if outputs containing unavailable anonymous attributes could be hidden automatically
- Somewhat tricky because fields can also reference multiple attributes, or change them using math nodes.
WIth my understanding !