Phonybone's Blender Blog

Matt Ebb, well-known Blender coder and artist, has pointed out a potential problem with the current design idea for accessing per-particle data, that is, attributes and all subsequently calculated values. If you have some parameter on a node that you want to set depending on some particle property, be it a common property like position or velocity or a custom user attribute, you can read that data with a special node:

Using the age property for simple per-particle force strength

Writing and reading a custom attribute

The problem with this way of reading particle data is that the data node is referring to some implicit particle state, which depends on the final node to which it is linked. For instance, in the following case the particle age attribute is used for two different modifier components, so the data it delivers may be completely unrelated (e.g. from different emitters or disjoint groups) and depends on the respective particle input state of the caller:

MyAttribute used in different contexts

The first step to resolving this situation would be to simply disallow the use of per-particle data in unrelated nodes. The particle data input node and subsequent math would have to be duplicated or put into a group node for instantiation.

One separate node for each user

However, this still does not remove the notion of an “implicit state”: the result of Particle Data nodes depends on the context of their use and it requires following links to the user nodes (Force and Gravity) to find out what particle data they actually refer to.

If we were to straightforwardly add stream inputs to the attribute reader nodes it would make the state relation explicit, but on the other hand introduce a lot of complexity. In the following example the attributes are read from a specific input stream. Pay attention to the second attribute node on the right side: the input stream differs from the target output, the Age property is modified after the input link to the reader node! This means that the values read from particle attributes in this case would need to be stored in memory, so they can be reused in the rightmost Gravity node. A lot more complicated situations could arise when particles are added or removed between reading and writing of attributes or when source and target streams are unrelated.

Explicit particle inputs to attribute nodes

This situation could be avoided by removing “data” nodes altogether and only use stream socket connections for particle data flow (white squares). But this would in turn mean that parameters can only depend on constant, animated or driven values, not on any per-particle attributes! Without a replacement for attribute access it would result in node trees that are not much more useful than the mesh modifier stacks currently in use, where there is no way whatsoever to influence modifiers other than user-defined vertex groups.

Scripted expressions would be an alternative method to access attributes in sockets and buttons without visually separating this access from the node itself. You could then use a driver-like expression, e.g. “age * 0.4 + position[z]” for a node parameter and it would be clear that this refers to the input state of the node.

I would currently prefer the original design of implementing attribute access for particle nodes with implicit states, since it adds the needed flexibility without allowing impossible or strangely behaving situations. But in the good tradition of Open Source software i’m willing to listen to user input and good ideas :-)