The concept of 'Field Objects' #112956

New Issue

Simon Thommes · 2023-09-27T15:39:20+02:00

Simon Thommes commented

2023-09-27 15:39:20 +02:00

General Idea

I'd like to consider the idea of objects that don't contain any actual geometry data at all, original nor evaluated. But instead, using geometry nodes and their concept of fields and combine it with the concept of an object with transformations and properties to compose fields modularly in the 3D viewport.

Motivation

My main motivation with this idea is a generic replacement for the force field objects that is compatible with geometry nodes to compose force fields without needing to interact with the simulation data/the node-tree of the simulation directly.

I just want to point out that, while I have loosely talked about this with some people (so far @HooglyBoogly and @Sergey ) and they seemed to generally like the idea. I have not in detail considered all implications or all necessary design questions. Far from it, this task is more so meant to document the initial idea and give room to discussion

The abstract concept of a field object that is evaluated separately on the data of the context brings the benefit that aspects of communicating information that is currently reserved to the evaluation of a single node-tree, made up by node-groups and their inputs, could be leveraging the composability of a setup made up of individual parts that can be duplicated, transformed and edited on an object level. The concept of gizmos can only bring this concept to a limited extent since a lot of aspects, (like the number and type of forces in the example) need to be predefined by the system anyways, unless we come up with something else.
The concept of passing structs of nodegroups from the outside has been proposed, but it comes with its own design challenges, makes the node system more complex and does not solve all the issues.

Loose Proposal

The way I imagine this could work is to introduce the ability for a modifier to pass out not only evauated geometry but any field instead, as is the case for a nodegroup within a node-tree context. This field can depend on several things: textures, geometry, attributes of the context (e.g. position), as well as inputs on the modifier level of this node-tree (per object).

To use this field you could add the object explicitly in the node-tree, similar to how you pass the evaluated geometry of one object to a modifier node-tree. Key difference here would be that instead of receiving evaluated geometry, this input node would pass in the field from that object to be evaluated in the context of wherever that wrapper node-tree is being used.

Extrapolating this idea, one can think of extending it to compose fields on a collection level by implicitly combining multiple field objects. Whether this works additively or in some other way would nee to be specified somehow.

Example

A simple example would be a radial vector field defining the attraction force to an objects origin. The force field object would only pass out the field information of calculating this force. The location, strength and shape of that attraction can be defined in an isolated way on that field object itself.
The node-tree the force field is used does not need to know anything about how this field is defined, it can simply be passed in as a force object/collection and is then evaluated for every point in the simulation where the force needs to be calculated depending on the position and potentially other properties of the simulation data, like the point's mass for example in this case.

Challenges

I can't speak for implementation challenges, which I am sure there would be plenty of.
I'm sure there are several challenges with this on a design level that I am not aware of right now, but there are a couple that I can imagine:

where is the composition of multiple fields defined?
where do we define handling the transformation of the output under object transformation/ local and global space?
how many fields can be propagated in a modifier stack in parallel/how does this affect regular geometry objects. Can they output just a field? Can they output both?
how do we handle dynamic count and type of sockets that depend on the evaluation context?

## General Idea I'd like to consider the idea of objects that don't contain any actual geometry data at all, original nor evaluated. But instead, using geometry nodes and their concept of fields and combine it with the concept of an object with transformations and properties to compose fields modularly in the 3D viewport. ## Motivation My main motivation with this idea is a generic replacement for the force field objects that is compatible with geometry nodes to compose force fields without needing to interact with the simulation data/the node-tree of the simulation directly. I just want to point out that, while I have loosely talked about this with some people (so far @HooglyBoogly and @Sergey ) and they seemed to generally like the idea. I have not in detail considered all implications or all necessary design questions. Far from it, this task is more so meant to document the initial idea and give room to discussion The abstract concept of a field object that is evaluated separately on the data of the context brings the benefit that aspects of communicating information that is currently reserved to the evaluation of a single node-tree, made up by node-groups and their inputs, could be leveraging the composability of a setup made up of individual parts that can be duplicated, transformed and edited on an object level. The concept of gizmos can only bring this concept to a limited extent since a lot of aspects, (like the number and type of forces in the example) need to be predefined by the system anyways, unless we come up with something else. The concept of passing structs of nodegroups from the outside has been proposed, but it comes with its own design challenges, makes the node system more complex and does not solve all the issues. ## Loose Proposal The way I imagine this could work is to introduce the ability for a modifier to pass out not only evauated geometry but any field instead, as is the case for a nodegroup within a node-tree context. This field can depend on several things: textures, geometry, attributes of the context (e.g. position), as well as inputs on the modifier level of this node-tree (per object). To use this field you could add the object explicitly in the node-tree, similar to how you pass the evaluated geometry of one object to a modifier node-tree. Key difference here would be that instead of receiving evaluated geometry, this input node would pass in the field from that object to be evaluated in the context of wherever that wrapper node-tree is being used. Extrapolating this idea, one can think of extending it to compose fields on a collection level by implicitly combining multiple field objects. Whether this works additively or in some other way would nee to be specified somehow. ### Example A simple example would be a radial vector field defining the attraction force to an objects origin. The force field object would only pass out the field information of calculating this force. The location, strength and shape of that attraction can be defined in an isolated way on that field object itself. The node-tree the force field is used does not need to know anything about how this field is defined, it can simply be passed in as a `force object/collection` and is then evaluated for every point in the simulation where the force needs to be calculated depending on the position and potentially other properties of the simulation data, like the point's mass for example in this case. ## Challenges I can't speak for implementation challenges, which I am sure there would be plenty of. I'm sure there are several challenges with this on a design level that I am not aware of right now, but there are a couple that I can imagine: - where is the composition of multiple fields defined? - where do we define handling the transformation of the output under object transformation/ local and global space? - how many fields can be propagated in a modifier stack in parallel/how does this affect regular geometry objects. Can they output just a field? Can they output both? - how do we handle dynamic count and type of sockets that depend on the evaluation context?

👍 2 🚀 2

Simon Thommes added the

Type

Design

label 2023-09-27 15:39:20 +02:00

Simon Thommes added this to the Nodes & Physics project 2023-09-27 15:39:22 +02:00

Lukas Tönne commented

2023-09-27 16:34:54 +02:00

I like the idea.

where is the composition of multiple fields defined?

This would generally happen on the "target" side of things, for example:

Force fields are evaluated and simply added up by the simulation (fancy words: superposition principle)
SDF functions can be combined in different ways. The generator that combines the objects has to decide which operation to apply, possibly based on a declared "type" of the object. (examples)

So the individual objects can have hints for the evaluator but ultimately the target nodes decide how to use a field.

The "function sockets" core idea (#107842) is quite similar, but maybe a bit too complex in its implementation. It might be easier to expose individual fields as described here, since the target immediately knows what type of field to expect.

where do we define handling the transformation of the output under object transformation/ local and global space?

I don't think this should be part of the field itself. A field can have different semantics and rules for transformation (just for vectors: position, direction, normal, or none at all). The target has to decide what a vector "means" in that context and how to transform inputs. The object info could be provided alongside the field to make that possible.

how do we handle dynamic count and type of sockets that depend on the evaluation context?

Do you have a concrete example for this in mind? I'm not sure i fully understand.

The simplest way to support a dynamic number of input fields would be to utilize existing object and collection structures:

A node tree can output a named field similar to a "Store Attribute" node (except it's a reference to a node sub-graph and not a materialized attribute).
The evaluating nodes do a "foreach" loop over a collection. For each object the field is looked up by name, evaluated, and combined with other fields.
Object would not be able to output more than one field of the same name, so it would be important to know if there is a critical use case for it.

I like the idea. > where is the composition of multiple fields defined? This would generally happen on the "target" side of things, for example: - Force fields are evaluated and simply added up by the simulation (fancy words: [superposition principle](https://en.wikipedia.org/wiki/Superposition_principle)) - SDF functions can be combined in different ways. The generator that combines the objects has to decide which operation to apply, possibly based on a declared "type" of the object. ([examples](https://www.ronja-tutorials.com/post/035-2d-sdf-combination/)) So the individual objects can have _hints_ for the evaluator but ultimately the target nodes decide how to use a field. The "function sockets" core idea (#107842) is quite similar, but maybe a bit too complex in its implementation. It might be easier to expose individual fields as described here, since the target immediately knows what type of field to expect. > where do we define handling the transformation of the output under object transformation/ local and global space? I don't think this should be part of the field itself. A field can have different semantics and rules for transformation (just for vectors: position, direction, normal, or none at all). The target has to decide what a vector "means" in that context and how to transform inputs. The object info could be provided alongside the field to make that possible. > how do we handle dynamic count and type of sockets that depend on the evaluation context? Do you have a concrete example for this in mind? I'm not sure i fully understand. The simplest way to support a dynamic number of input fields would be to utilize existing object and collection structures: - A node tree can output a named field similar to a "Store Attribute" node (except it's a reference to a node sub-graph and not a materialized attribute). - The evaluating nodes do a "foreach" loop over a collection. For each object the field is looked up by name, evaluated, and combined with other fields. Object would not be able to output more than one field of the same name, so it would be important to know if there is a critical use case for it.

Simon Thommes commented

2023-09-27 17:45:41 +02:00

Thanks @LukasTonne glad you like the idea! Everything your saying makes sense to me 👍

how do we handle dynamic count and type of sockets that depend on the evaluation context?

Do you have a concrete example for this in mind? I'm not sure i fully understand.

What I meant is that if we allow to pass the data block with the field from outside the node-tree, the socket type inside the nodetree of what the field returns depends on the evaluation context and what is passed from outside. But I suppose the simplest solution would be to define the type in the input node itself and do an implicit conversion if necessary. The definition of how the fields are combined would be done in that node anyways, as you say. That makes sense to me.

Supporting passing multiple fields at the same time would be another separate question.

Thanks @LukasTonne glad you like the idea! Everything your saying makes sense to me 👍 >> how do we handle dynamic count and type of sockets that depend on the evaluation context? > Do you have a concrete example for this in mind? I'm not sure i fully understand. What I meant is that if we allow to pass the data block with the field from outside the node-tree, the socket type inside the nodetree of what the field returns depends on the evaluation context and what is passed from outside. But I suppose the simplest solution would be to define the type in the input node itself and do an implicit conversion if necessary. The definition of how the fields are combined would be done in that node anyways, as you say. That makes sense to me. Supporting passing multiple fields at the same time would be another separate question.

Jacques Lucke commented

2023-09-27 17:55:48 +02:00

I still need to organize my thoughts on the topic before I can have a proper opinion. Some initial thoughts:

Generally, the idea of having objects represent forces or falloffs is something we talked about in the past I think, generalizing it to more kinds of fields sounds interesting.
I wonder if this this is mainly for position dependent fields or whether there are benefits to having objects encapsulate other fields as well?
I see parallels to texture nodes. A texture data block that uses nodes also essentially encapsulate a position dependent field (either in 2D or 3D).
We are slowly moving moving towards blurring the line between different object types, I wonder how "field objects" would fit into that.
I can see how it might be enticing to just pass a collection of force objects into a particle simulation solver node group. I also don't really have anything against it, as long as there are ways to pass forces into it in another way as well. I don't like the reliance of objects for such things.
I don't see that as an alternative to passing "closures/node groups" around, because those can capture many more kinds of behavior that fields can't (e.g. particle behavior like duplicate-on-collision). The ideas are compatible though and I could see objects representing more complex behavior that is not necessarily just a field as well (maybe similar to how rigid body constraints are separate objects).

I still need to organize my thoughts on the topic before I can have a proper opinion. Some initial thoughts: * Generally, the idea of having objects represent forces or falloffs is something we talked about in the past I think, generalizing it to more kinds of fields sounds interesting. * I wonder if this this is mainly for position dependent fields or whether there are benefits to having objects encapsulate other fields as well? * I see parallels to texture nodes. A texture data block that uses nodes also essentially encapsulate a position dependent field (either in 2D or 3D). * We are slowly moving moving towards blurring the line between different object types, I wonder how "field objects" would fit into that. * I can see how it might be enticing to just pass a collection of force objects into a particle simulation solver node group. I also don't really have anything against it, as long as there are ways to pass forces into it in another way as well. I don't like the reliance of objects for such things. * I don't see that as an alternative to passing "closures/node groups" around, because those can capture many more kinds of behavior that fields can't (e.g. particle behavior like duplicate-on-collision). The ideas are compatible though and I could see objects representing more complex behavior that is not necessarily just a field as well (maybe similar to how rigid body constraints are separate objects).

👍 2

Simon Thommes commented

2023-09-27 18:15:50 +02:00

Thanks, @JacquesLucke you're raising good points!

Just to be clear: I'm not necessarily meaning to propose a new separate object type. As we are moving away from object types in general, I think any object could just instead of passing out evaluated geometry data, pass a field of any type that is evaluated per context where it is used.

I just used the term 'Field Object' for lack of a better one, and it seemed most intuitive to me.

Thanks, @JacquesLucke you're raising good points! Just to be clear: I'm not necessarily meaning to propose a new separate object type. As we are moving away from object types in general, I think any object could just instead of passing out evaluated geometry data, pass a field of any type that is evaluated per context where it is used. I just used the term 'Field Object' for lack of a better one, and it seemed most intuitive to me.

Iliya Katushenock commented

2023-09-27 18:54:41 +02:00

I use Fields Space \ Set of Anonymous Attributes with Prefix\

I use `Fields Space` \ `Set of Anonymous Attributes with Prefix`\

image.png

502 KiB

image.png

559 KiB

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The concept of 'Field Objects' #112956

General Idea

Motivation

Loose Proposal

Example

Challenges