I apologize for the long silence here, my excuse is that i’ve been working on internal stuff lately, which is not well suited for producing eye-popping videos ;) Part of this work is better parallelization support and integration of the OpenCL API. My original goal for this blog post was to make a more detailed description of how this all works internally, but it turned out to be a rather long article, which should better be part of the design document and needs a little more work. Like most coders i’m not too fond of writing documentation (a necessary evil, i know), so please be patient. :) If you have any specific questions regarding OpenCL or CPU multithreading, feel free to ask in the comments or IRC or mailing list. Let me talk about some fun stuff and new features instead now.
New quaternion and matrix socket types
These usually describe rotations and transformations. There are currently no math nodes to modify these data types, but they can be selected and copied from data nodes. Note that euler angles and axis-angle representations are also converted to quaternions! This might be a bit of a problem when using euler angles, since the order of rotations matters for these. It’s best to directly use real quaternion rotation data where available.
ForGroup node and the ‘self’ data context
As described in the previous post, there are different data contexts associated to each socket in the node tree. An powerful feature is the use of the “self” context. This is a special keyword that can be used in path inputs to refer to the context a data node is evaluated in. At the moment the places in which node trees exist are limited (in my branch they are still part of a ‘NodeTree’ modifier for particle sets), so the ‘self’ context on the base level isn’t all that interesting. But now there is a special loop node called “ForGroup”, which makes use of this feature:
This simple tree moves all objects in group “Group” by a small amount along the x-axis by adding to the location vectors. Note that the GetData and SetData nodes have no explicit input path set: they work in the object in the ‘self’ context. The ‘ForGroup’ node executes the subtree on the left side for each object in the group and sets the ‘self’ context accordingly. The path inputs of the data nodes could also use a relative path like “self.data.vertices” to access the vertices of the self-context object.
Plans and ideas
- Make shortcuts to common data nodes: current GetData/SetData nodes are a little cumbersome to use and many of the properties should not be accessed (partly this is due to missing flags in the RNA property settings). Making restricted data nodes for the most common data types (objects, meshes, etc.) will make this easier.
- Memory management is an important issue in node trees (this has been noted with compositor trees for some time). The idea is to activate nodes “from left to right”, so that the tree does not allocate all node buffer memory at one time. Instead the nodes should be activated successively, so that buffer memory allocation stays below a threshold to avoid problems and free memory as soon as possible.
- Another possible feature for saving memory could be the “concatenation” of certain nodes: Many node kernels (esp. math nodes) only work on one single work item at a time. When several of these nodes are chained together (as is often the case in complex math expressions), the internal buffers between them might be avoided completely.
- Many people have been asking for specific node tree uses. While there are many good ideas among these, you will have to accept that my time and capabilities are limited. Here are some of the things that will unfortunately not be part of my work (which doesn’t mean somebody else couldn’t implement them some day using the features i added):
- Node tree drivers (as an alternative to python expressions)
- Video compositing
- Mesh modifier replacement
- Rigging systems
- What i will concentrate on instead is the implementation of particle simulation features using nodes. Next step for creating more interesting particle effects will be a mesh sampling node for generating points on a mesh surface/volume. This will allow the implementation of common particle emitters.