The list of possible nodes in that category is huge, but here are some examples: Nodes that output an operation are the ones actually doing some work. However, maybe it might be better to just not allow this situation and enforce a total order of operations that could theoretically affect each other. Therefore, I'd currently prefer to explicitly randomize the order. The issue with just not allowing this situation at all is that it can be useful sometimes.įor example, when one state object is only passive in two separate operations, it might result in a nicer node tree, when the user does not have to define an order.
The Merge node performs the union of an arbitrary number of incoming state object sets and outputs the new set. The name of the state object will be made unique automatically if necessary. In this case, it is as if the node has been copied. However, when a State Object node is in a node group, it can be instanced. There is a one-to-one mapping between all the state objects used in the simulation and the State Object nodes. The State Object node represents a single state object, that has a unique name among all state objects used by a simulation. There are only three core nodes for now: State Object, Merge and Apply Operation. While the *state* is split up into smaller state objects, the simulate function from the previous section is split up into smaller operations.Īn operation could also be called "solver", but I found that confusing in some contexts. The signature of this function is void operation(set_of_state_objects, environment, time_step). Or, when a state object gets a point cloud attached to it, it can be interpreted as particle system.Īn Operation does not represent data, but a function that can be run later. However, predefined node groups will add specific data to them, that will give them meaning.įor example, when a state object gets a density and velocity grid attached to it, it can be interpreted as fluid domain object. Those can then be processed by nodes more easily.īy default, a state object does not have any meaning attached to it. The idea is to split up the *state* from the previous section into smaller state objects. It has a (possibly nested) key-value storage, whereby the key is always a string. Then, some syntactic sugar is introduced, that will make working with the node system more practical.Īt its core, the node system has only two different socket types: State Objects and Operation.Ī State Object is a container for arbitrary data. This section describes what a node system representing arbitrary simulations can look like.įirst, the core concepts will be explained. How to integrate that node system with the rest of Blender?.How to define the simulate function using nodes?.The rest of the proposal mainly deals with the following questions: * Third Frame */ simulate ( state, new_scene_state, 1 / fps ) * Second Frame */ simulate ( state, new_scene_state, 1 / fps ). */ simulate ( state, initial_scene_state, 0 ).
* First Frame */ state = empty_state () /* Use zero time step to initialize the state. This applies to all simulations I can think of currently. time_step: A non-negative real number that represents the amount of time that should be simulated.įor example, when the simulation is started from frame zero, the calls to simulate in every frame would look like below.
Usually, that will be a partially evaluated Blender scene. environment: Immutable data containing information about the outside world that the simulation runs in.For example, it may contain the positions and rotations of all objects in a rigid body simulation. state: Mutable container that contains the state to be modified.It can be thought of as a function with the following signature void simulate(state, environment, time_step). On an abstract level, a simulation is a function that modifies state. It is supposed to be read by developers and technical artists. Since this is a document about a framework and not about individual features, it will be relatively technical. My hope is that this proposal can offer a concrete starting point for further discussion about how we want simulations to work in Blender in the future. The goal is to have a unified environment to setup all kinds of simulations. This is a proposal for a simulation framework for Blender.
0 kommentar(er)
