This was storing the original object matrix, which builds on the
assumption that obmat is modified during dupli construction, which is a
bad hack.
Now the obmats are still modified, but this only happens outside of the
dupli system itself and the original ("omat") is stored as local
variables in the same place where the obmat manipulation takes place.
This is easier to follow and avoids hidden hacks as much as possible.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D254
Evaluating the animation is causing the object to get tagged as changed, but in
this case it's not a permanent change so no one should be notified. Also found
a case where the persistent ID for duplis wasn't unique, fixed that as well.
This is a first step toward improving our dupli system. It implements a more
generic way of treating the various methods of dupli generation by adding a few
structs:
* DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists.
* DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c)
Beside making the code more easily understandable this implementation should
also help to avoid weird side effects from custom matrix hacks by defining
clearly what a generator does. The DupliContext is deliberately made const, so a
generator can not simply add hidden matrix or flag modifications that are hard
to track down.
The result container for the generated duplis is stored in the context instead
of being passed explicitly. This means the generators are oblivious to the
storage of duplis, all they need to do is call the make_dupli function. This
will allow us to implement more efficient ways of storing DupliObject instances,
such as MemPools or batches. These can be implemented alongside the current
ListBase so we can improve dupli bottlenecks without having to replace each and
every dupli use case at once.
Differential Revision: https://developer.blender.org/D189
