# Investigation: Cage Deformation with Grids ## Problem Statement _Samples inside a mesh should follow the deformation of the mesh volume._ ## Conventional Solution [Mesh Deform Modifier](https://docs.blender.org/manual/en/latest/modeling/modifiers/deform/mesh_deform.html) - Slow preprocessing required. - Performance determined by both cage resolution and sample count. ## Proposed Method Idea: Use a grid to make sample deformation fast! 1. Rasterize deformation from mesh vertices into a grid. 2. Compute deformation in each grid cell ("blurring", "extension", see below). 3. Transfer deformation to samples with a simple lookup. If the grid relaxation/blurring can be fast enough this would decouple the sample count from performance, allowing higher sample counts than what would be feasible with mesh deform. This is because the transfer (step 3) is very cheap, compared to Mesh Deform where a full set of weights has to be computed for each sample. The grid resolution determines performance but not visual detail. ## Field Extension OpenVDB provides methods for "extending" fields across a fog or SDF volume based on some boundary conditions ([API methods](https://www.openvdb.org/documentation/doxygen/FastSweeping_8h.html)). This is probably the best method for generating a deformation vector for interior voxels. ![grid-deform](https://hackmd.io/_uploads/rJoaNkLHp.png) ## Math _True_ deformation is an unknown function $D(x)$. We compute an approximate $D_p$ for sample points described by grid interpolation: $$D_p = G_p(x) = \sum_i k_{p,i}(x) G_i$$ where $k_{p,i}(x)$ are the weighting factors for each sample and grid voxel and $G_i$ are the deformation vectors stored in grid voxels. Grid deformation is defined at voxel centers $c_i$ by projection from the surface: $$G_i = S_{closest}(c_i)$$ This introduces an error
Last changed by  
 
lukas-tonne
130

Read more

Node Socket Type System Inferrence

Node socket types are mostly static, but some aspects of it are, or will be, dynamically inferred.Field types in geometry nodes are the main example right now: Whether a socket represents a single value, a field, or can be either of these (undecided) is

11/16/2023
Volume Attributes MVP

Make volumes in geometry nodes more useful and flexible.

10/6/2023
High level controls for node assets

A proposal for making complex node trees customizable using node groups parameters. Node assets that are supposed to be used as building blocks require detail knowledge to tweak their internals. Some parameters can be exposed on the modifier level, but extending a system requires a different approach, as will be demonstrated below. This proposal describes a mechanism to allow users to specify node groups at the highest level of a node asset, which are then used inside the asset without requiring users to touch the asset internals themselves. The modifier stack for node assets and its limitations Simon Thommes recently published the first set of hair hair assets to be shipped with Blender. Simon breaks down the hair workflow into separate modifiers. This relies a lot on the fact that modifiers can be applied as a single self-contained step one after the other.

5/12/2023
Function Socket Notes

Function sockets are single-valued (no fields). This should keep overhead from type checking and dispatching to a minimum. That does not mean function sockets cannot take and return fields, it just means the function itself is the same for all elements of a field. Data flow for functions in geometry nodes flowchart G[Node Tree]:::data F[Default Bindings]:::data G --> E([bind]):::op F --> E E --> D[Closure]:::data D -->|passed through the node tree| B([evaluate]):::op

5/12/2023
Read more from lukas-tonne
Published on HackMD