More or less Jacques' proposal Partial Embedded library (for essentials only?), Smart append operators that deduplicate across project blend files that link to each other. Don't deduplicate across blend files, improve duplicate detection for single blend, hide node groups more. Simon wants to think more about option 4. Jacques wants to reevaluate the proposal with the restriction that data from asset libraries is always embedded (never just linked) except when the asset library is part of a project. We were also talking about curve rendering in cycles. Especially how it different rendering approaches my be useful for curves with different radii. Sometimes it's better to just tesselate the curves to a mesh (if the radius is large).

https://hackmd.io/@lukas-tonne/H1HjaGalp https://hackmd.io/@II9-Bkl4TJifCqGL2jgbUw/SJ3puQ2x6 https://hackmd.io/DHI9TXW6Rxu-AGWy7qXv_g The key difference: Grids can be grouped together with meaning even when they have no topological similarity Key point Geometry shouldn't be the only way to have data-flow in BlenderThis design transcends geometry nodes in that way Similar data typesGrids Images Lists

November 24, 2022 Present: Andy Goralczyk Dalai Felinto Daniel Bystedt Jacques Lucke Lukas Tonne

https://devtalk.blender.org/t/2022-10-31-geometry-nodes-post-bcon22-workshop/26491 Things Simulation Loops/Repeat Asset containers Node tools Node operators Procedural hair

Name Changes Naming: Working Document Documentation Sprint Documentation: Working Document Changes necessary Node Done

A list of patches and topics that I (Hans) would like to consider prioritizing for geometry nodes in the 3.0 release. Larger Topics [ ] Fields Conversion [x] Basic math nodes, field inputs [ ] Convert nodes like attribute transfer / proximity [ ] Geometry joining, etc.

Adding a procedural curve editing pipeline in 3.0 has been a large focus for the geometry nodes team and community for the past few months. One of the last larger changes for 3.0, supporting the geometry nodes modifier on curve objects, was committed this week. So I thought it would be a good idea to give an update on the project. Where are we, and what does the future hold? Just like curve objects, geometry nodes support three types of curves: Bezier With control points and handles, editable as separate attributes Poly A simple series of connected points NURBS A more advanced spline type with different controls exposed The New Nodes

Edited transcript of a conversation between Jacques and Hans We want to build functions and we want to evaluate functions that we have built before. We can have various systems to build functions and various systems to evaluate functions. It now happens to be the case that sometimes one system is capable of building and evaluating functions. However, these should still be considered to be separate tasks. When evaluating a function we typically have to look at the function and the context to determine the best way to evaluate it. The system used for evaluation might be the same system that built the function, but it might be a separate system on the CPU, or it might run the function on the GPU. Theoretically, it could even make sense that an individual node, in order to evaluate a geometry field, creates a new geometry-nodes-evaluator during its execution. Then we would have nested geometry-nodes-evaluators. The geometry nodes evaluator and multi-function procedure evaluator are both essentially just moving generic data around and call functions with that data. The evaluator is responsible for the overall geometry nodes evaluation, building up the callbacks that can then be used by individual nodes. We also want to be able to evaluate fields separate from the evaluator (e.g. for the viewer maybe). When the geometry nodes evaluator executes the function nodes, it should just create a new field that also references the input fields. It does not actually evaluate the fields, that is done by the node that uses the field. In the prototype the evaluator also does not evaluate the fields (unless it is constant, which is not important right now). Basically, you build up some kind of tree data structure when the nodes are evaluated. Then, when the field is evaluated, this tree is converted into a multi-function procedure, and then you evaluate this procedure. The multi-function field just references a bunch of other fields.

Potential module targets before next project. Project Next Projects Attribute tools/mode painting edit [*] Sculpt Vertex Paint Own mode OR new tools Node tools / gizmos

Sampling uniform lengths from a curve should produce a curve You can still do other things you would do with a curve: create a mesh, curve deform, sample attributes, anything added in the future. These are common use cases. There is no need for changing the data type, so the operation is less complicated without the change. Similarly, creating a new spline with a set number of points is a natural operation, easy to understand. Sampling uniform lengths should produce a poly spline The number of evaluated points in the output doesn't depend on the resolution, which makes the output simpler. Sampling uniform lengths is not really meant for the situation where you just need a few more control points to work with anyway. In that case there is no need to resample, simply adding more (with subdivision) will work.

Domain Combinations Source Domain Result Domain Topology Raycast Nearest Nearest Interpolated Matching Attribute (normals)

Moved to devtalk. Dalai asked Erindale to try to build a procedural wall inspired in the work by Marc Chevry. The goal was to identify any showstoppers and potential improvements for geometry nodes: Sample file: https://we.tl/t-6qu93y785m Not 100% on what the curve tools Hans is working on covers but for this it would have been great to get the curve into the tree early and calculate its length to use for the wall length and then obviously at the end to conform the straight wall back to the curve similar to the curve modifier. For me the ideal process would have been to make it flat and then extrude individual faces by a random amount. I think this would have made the booleans more robust as well. I used my straight brick wall node and just removed random points from the top row and randomised the Y scale for bricks. That worked okay but it slowed everything up with the next lot of operations because it was having to make the bricks all real to get the uneven row heights. I was initially using a boolean straight after making the instances to trim the ends of the wall straight (because of the half brick offset between rows) but I worked out later that having any sort of operations after a boolean is practically unworkable. The performance just not production-ready with booleans at the moment. Luckily I was able to stick it at the end with the arch boolean without any issues in this case.