#
Geometry Nodes Volume Features Implementation #103248

Open

opened 2022-12-15 20:50:32 +01:00 by Hans Goudey
·
21 comments

No Branch/Tag Specified

blender-v4.0-release

main

temp-sculpt-dyntopo

blender-v3.6-release

universal-scene-description

blender-v3.3-release

asset-browser-frontend-split

brush-assets-project

asset-shelf

anim/armature-drawing-refactor-3

temp-sculpt-dyntopo-hive-alloc

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-projects-basics

blender-v2.93-release

temp-sculpt-attr-api

realtime-clock

sculpt-dev

gpencil-next

bevelv2

microfacet_hair

xr-dev

principled-v2

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

**Labels**

Apply labels

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compatibility

This issue affects/is about backward or forward compatibility

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

EEVEE & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest

Import Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest: Wayland

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

EEVEE & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

No Label

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compatibility

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

EEVEE & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest

Import Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest: Wayland

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

EEVEE & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

**Milestone**

Set milestone

Clear milestone

No items

No Milestone

**Projects**

Set Project

Clear projects

No project

**Assignees**

Assign users

Clear assignees

No Assignees

**10 Participants**

**Notifications**

**Due Date**

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

**Dependencies**

No dependencies set.

Reference: blender/blender#103248

Reference in New Issue

There is no content yet.

Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?

Status:In planning phase## Team

Commissioner:@HooglyBooglyProject leader:`?`

Project members:@erik85## Description

Big picture:Address the large opportunities for procedural volumes while fitting into geometry nodes design, especially using existing openVDB toolsUse cases:Design:Engineer plan:## Work plan

## Milestone 1 - Very basic SDF volume nodes

Expose SDF volumes as a basic data type, provide a few fundamental nodes for future development## Milestone 2 - Basic support for fields as references to grids

Allow referring to grids with the named attribute node, but not any modification`AttributeFieldInput`

) should work for volumes too, referencing grids by name`AttributeFieldInput`

input. Any other field can be rejected for now. It just looks up the grid by name## Milestone 3 - Grids as anonymous attributes

Creation of and references to grids without a name, to allow referencing them with node links`AttributeFieldInput`

for now.## Milestone 4 - Evaluating fields on grids

Support basic volume advection`VolumeGridFieldContext`

that can provide the position field at each voxel (by index for now, so voxels probably have to be flattened)## Milestone 5 - Changing grid values with fields

## Milestone 6 - More advanced volume nodes

More advanced use cases building on the fundamentals above## Relevant links

Changed status from 'Needs Triage' to: 'Confirmed'

to~~Geometry Nodes Volume Features Overview~~Geometry Nodes Volume Features Implementationmaybe a dumb question, but will the openvdb csg oprations be part of this? (csgDifference/csgIntersection etc)

Dang, csg on milestone 6? yikes

I was hoping to see it on miilestone 1 tbh, since it's one of the most useful things of openvdb.

Anyways, waiting for milestone 6 then

The design for the volume boolean node is a bit complex here, it's one sore spot in the design currently.

It's complex because the volume might contain multiple grids, both named and anonymous.

It's not clear how they should be matched together when you want to run a union on two of those volumes, for example.

I'm open to suggestions there, maybe there is some way to simplify it, or maybe it isn't necessary to support more than one grid.

We have a similar problem in the join geometry node, where you can't explicitly decide how to join specific anonymous attributes together.

This is a very cool idea, it will be great to have SDF support :)

Charlie Jolly's patch had some cool node ideas for working with SDFs https://developer.blender.org/D6464

Maybe I will try to replicate some of them later

Nodes & PhysicsprojectGeometry Nodes: Experimental option for Volumes#104552Are there plans to include heightfields like the flat plane volumes for terrain generation?

This task is more about 3D volumes. I'm sure a similar approach might be helpful for heighmaps too (though there is the design question of how different they are from images), but that use case doesn't fit so well here.

How to handle volumes and join node#89957Nodes: SDF Volume nodes milestone 1#105090You might like to keep an eye on the progress of this Blender SDF modeling add-on. It might offer some inspiration for your implementation.

~~Iliya Katueshenock referenced this issue~~2023-04-23 12:17:09 +02:00
Color attributes from geometry nodes have no effect on volumes#107264Color attributes from geometry nodes have no effect on volumes#107264Geometry Nodes: Add 'Signed Distance' input node#107828We should have a way to share the TreePtr between grids. Grids themselves are basically attributes, but right now we don't seem to have much flexibility for creating multiple attributes sharing the same topology (tree).

With other geometry types we'd capture attributes on a given geometry, which defines the underlying topology. But since Volumes have multiple grids and trees it's not clear how to specify which tree gets used. Maybe nodes that store grid attributes could have a "copy from" attribute input that defines the tree, although that doesn't seem great either. Or should capturing on a Volume create the grid for

allits trees, treating them as joined geometry?Another topic that will become important for fluid sim is

staggered grids. These are an optimization for velocity grids that are frequently used with divergence and gradient operators. The vectors on the grid are interpreted with a different half-cell offset for each component. This avoids interpolation losses when converting between pressure and velocity fields. Matthias Mueller has a nice overview.Staggered grids in OpenVDB have their own class. We should have an option to create a vector grid as a staggered grid class. This does not have an immediate effect on low level code, but it allows algorithms to chose appropriate samplers etc. The sample volume node should also take this into account and use

`StaggeredBoxSampler`

vs`BoxSampler`

and so on based on sampling type.This is such a great feature to see coming on line. From my perspective, it doesn't need much to become a 1.0 feature set. some basic functional primitives (sphere, cylinder, cube, curve), non-uniform scale, falloff and a node to convert the shader shape to triangle soup. The rest is candy for later.

Hi, if my understanding is correct. Would I be able to import quantized data. And then use that data to set the individual voxel values in the grid?

Presently, I create each VDB file and save to disk. If I could just load the data into blender and create the volume within geometry nodes that would save a lot of hard disk space.

Hi, I think with this design the store named attribute node would let you set the value of each voxel by index. Though I'm not certain about that. I'm not sure how fast it would be though.

Isn't that done in parallel? How are index assignments handle in Geometry nodes, say for example, on points?

@TheJeran I think, problem in implicit volume conversion of volume to other one. This requered to project indices from one volume topology on other one to make indexing possible.

Volumes are very different than points-- the values aren't stored in a single array. That's what makes them fast. So calculating indices is avoided when possible.

I'm also interested in loading quantized data (as for example Multi-pages TIFFs files, or sequences of images, or UDIMS, etc...)

Maybe just importing them and specifying 3D coordinates for the bounding box corners could be enough to fill the volume data grid by interpolating the source files ?

And if the resolution of the input images matches the resolution of the voxel grid, then we get a 1:1 display of the data.

Accessing the voxel grid by 3D coordinates instead of indices may be more convenient, and it's always possible to use a simple 1D <-> 3D conversion to find the index for a given 3D position or the opposite. (https://coderwall.com/p/fzni3g/bidirectional-translation-between-1d-and-3d-arrays)

I've started an experimental branch (#110044, heavily WIP!) to make volume attributes work. The grid attributes use a specialized

`VArrayImpl`

to access the grid values. Currently only the simple index-based get/set are fully implemented. For efficient read/write of grid data the optimized bulk-access methods with spans and index masks need to be implemented, amortizing the cost of looping over leaf node buffers.WIP: Volume grid attribute support in geometry nodes#110044WIP: Volume grid attribute support in geometry nodes#110044Would it be possible to sample volumes?

At the moment (for another unrelated task) I am doing particle surfing with simulation nodes. Currently what I do is spawn the 3D array I am surfing on as vertices with a vector attribute. Then I sample the nearest vertex for each particle and update their positions based on that value. Unfortunately there is no interpolation. If I could sample a volume like they do with 3D textures in Unity. That would be super dope.

Geometry nodes attributes do not work in volumes in the shader editor#111309I've been implementing a couple of the tasks outlined in Milestones 3 and 4 over the last few weeks:

Now i can do stuff like this:

As you can see, there are some hoops to jump through to handle cases of undefined topology: Each grid has its own topology (active voxels), in contrast to array-based fields where each array has the same size based on the geometry context and domain. When combining multiple grids the result will usually be a topology union of all inputs.

Some grids are defined as abstract spatial functions, for example the

`position`

attribute returns the center of each voxel. These virtual grids don't have a finite topology, so when capturing them alone the result will just be an empty grid. That's the reason i'm first constructing a volume cube and then using the`density`

attribute: it forces the resulting topology to match the cube even though the position field has no topology of its own. A nicer solution to this problem needs to be found, like using a default topology from the volume context. Of course this default topology also needs to be somehow specified first.## Point Data Grids

I'd also like to discuss how point clouds and grids can interact. OpenVDB has a dedicated grid type for point cloud storage, which could help a lot with performance. There are two variants (link):

`PointIndexGrid`

is a simple integer grid, storing offsets into a sorted point cloud. Each slice of the point cloud indicated by the grid contains particles within a cell.`PointDataGrid`

stores the entire point data set, including attributes. This data structure has many advantages, such as ease of use (no need to keep the point cloud around), data compression, and floating point accuracy mitigation (storing positions relative to a cell in fixed-point format).Integrating point data grids into the existing geometry nodes concepts is challenging. It represents a complex data type that would require a new socket type and is quite opaque. There would need to be special nodes for reading and writing attributes, and for converting a point data grid to and from a regular point cloud.

A better design would be to treat an OpenVDB

`PointDataGrid`

as just another form ofstoragefor a point cloud. The`PointCloud`

data structure would optionally (!) store a point data grid, either alongside or instead of plain`CustomData`

arrays. Grid storage could be enabled by users or by certain algorithms (spatial sampling, fluid sim, etc.) and can be disabled at any time.On the UX level there would be no immediate changes, the point cloud continues to be treated as normal geometry. A couple of simple utility nodes to enable/disable grid storage and get the current storage mode could be added if needed.

One use of grid storage would be for simulations:

With an internal grid storage for the point cloud it would be much easier to fit into existing paradigms. The point cloud geometry can be stored as a simulation zone item and efficiently simulate fluid motion over time. Serialization can convert to a conventional point cloud, or could serialize

`PointDataGrid`

directly (TBD).image.pngimage.pngI've been considering another way to integrate

`PointDataGrid`

into geometry nodes concepts. Instead of storing a point cloud in two different ways, we can store the data grid representation in the`Volume`

component and expose particle data through the`POINT`

domain. This avoids difficult questions of cell size, ownership, and data duplication in`PointCloud`

. A key difference between point data grids and regular data grids would be that we only store one point data grid per volume. Joining multiple volumes would merge the point sets and their attributes, following the same behavior as a regular point cloud.In addition to

`Points to Volume`

and`Points to SDF Volume`

there would be a`Points to Data Grid`

node. This will store particle data in the volume component as a`PointDataGrid`

instead of rasterizing straight into a fog or SDF grid. The spreadsheet will show the point data under the point domain.Point data can be

rasterizedinto a grid using different methods (see`rasterize***`

methods here). For fluid simulation purposes we want to generate a velocity grid using trilinear rasterization. This can be the default mode when adapting from the point domain to the voxel domain, which means we can simply connect a named attribute to the fluid solver and it will generate a velocity grid from the point data grid. This might not be transparent enough, perhaps some node along the lines of "evaluate on domain" could be added to make this more explicit.After rasterizing the velocity grid and then solving the pressure field (making incompressible fluid) particle advection is applied to the point data grid. We don't want to convert back and forth into a point cloud all the time, so the point data grid remains the main simulation geometry.

The simulation output can finally be converted back into something renderable. We can just extract the point data as a point cloud again. Or we can generate a mesh from the point data, which may involve rasterizing to a different grid resolution.

image.pngimage.pngimage.pngimage.pngimage.pngThe volume changes look great! I think it would make sense to start splitting the branch into smaller changes and move thing to main.

I wouldn't really consider these "virtual grids" as attributes. Volumes shouldn't have a

`position`

attribute. The position is just a field input, it doesn't have to go through the attribute system. The point of that is to clarify the design of attributes asdata stored on geometry.Regarding the point grid storage, I'd prefer to discuss that elsewhere. For design simplicity, I think point clouds should remain part of the point cloud component. The use cases are related, especially for something like a flip solver, but design-wise it's much simpler, since it's basically just a performance thing.

Compositor: Procedural texturing, Step 1#112732