Blender Git Commits

Use a std::vector for storing Dupli instances in bvm for efficiency.

Return duplis from a bvm node evaluation, just like DerivedMesh.

Fix for default values of array types.

Now an array can be passed directly to the add_input functions to
construct an ArrayValue.

New opaque type 'DUPLIS' for storing a dupli list.

This works just like the MESH type, but wraps a ListBase instead of
a DerivedMesh. Using this type the duplis can be generated internally
and returned as a result.

All such data types should be handled in a generalized way eventually.

Correct types for array 'pass' nodes.

Reordered data types a bit, so mesh and other complex types are at the end.

Array types for node sockets.

These are an extension of the type description to support contiguous
arrays of base values. They effectively form a second set of types,
mirroring the 'single' base types. Socket connections will have to
strictly match between these types as well, i.e. any dereferencing and
array access will have to be explicit.

PASS nodes for array types.

Sqrt math node mode, patch by lichtwerk.

Removed unused function declaration.

New dupli mode for use of BVM node trees to generate duplis.

Not yet functional, as it doesn't have opcodes yet.

Object pointer should not be needed for constructing modifier node functions.

Merge branch 'master' into object_nodes

Use the bvm function cache for modifier nodes, to avoid recompiling all the time.

Separation of dependencies of node trees and their users for compiling vs. evaluation.

So far any change in a node tree would cause both a recompile of bvm functions
as well as a re-evaluation of any users of that function. This is quite inefficient
and should be separated to allow caching of the bvm functions independent from
their users.

To this end the nodes now have 2 callbacks: one for getting compile deps, the other
for getting eval deps.
* Compile dependencies are typically other node trees (node groups). In the future
this could also be Text datablocks, similar to how OSL script nodes work.
* Eval dependencies are all the blend_data blocks that a function might access.
For modifier nodes these could typically be meshes, curves; for shaders could
be images, textures; and so forth.

Separating these dependencies means the bvm functions will have to be recompiled
only when the actual bNodes change (add/remove, linking, socket values).
Conversely when some modifier input data changes (editing, cfra) the modifier
function will be re-evaluated.

Use C callbacks for implementation of DepsNodeHandle.

This makes it possible to create generic dependency functions to
handle dependencies in various ways, using the same reporting callback.
Currently used for depsgraph building in 2 passes (nodes & relations).

Removed default case for the opcode switch, all opcodes should be handled explicitly.

Merge branch 'master' into object_nodes

Explicit depsgraph tagging for object nodetree is not necessary any more.

Extension of depsgraph API to handle the relations between node trees.

This allows node groups and similar nodes with a node tree ID pointer
to register in the depsgraph.

In addition to defining relations, the builder must also make sure
that the node tree depsnodes are created first, because, unlike objects,
node trees depsnodes have no direct scene connection and are not generated
in advance. Since the build process has two distinct steps for creating
nodes and relations, the same API is used for both to simplify the code.