This was introduced in 23c93873f4.
This could be moved to deg_flush_base_flags_and_settings but since we
only need this for duplis I think it's fine to be handled separately.
Use indirect access to it via object.
It was already flushing from base to object, now we can avoid such flushing.
Still weird to have selection color filled in by dependency graph, but now
there is no synchronization going on at least.
As with operators, the window-manager has the API for defining,
the editor can implement and register its own manipulators.
This exposes wmManipulator, keeping it opaque isn't
practical if editors and Python are to implement their own.
The problem was that the strokes in the copy-paste buffer could be keeping
dangling pointers to colors that were already freed. Therefore, this commit
makes it so that when copying the strokes, we now make copies of the colors
and put them in a hashtable beside the stroke buffer. This is convenient,
as it saves us having to look up what colours need to be copied over each
time when pasting.
The problem was that newly pasted strokes were still using colours from
the original datablock. As a result, you'd either get an immediate crash,
or if you managed to save the file before it crashed, each stroke would get
reloaded with a dummy colour.
This commit fixes makes it possible to copy/paste strokes between datablocks
again. However, there are still problems when trying to paste across file
boundaries (i.e. copy strokes in one file, paste in another), which the next
commit will address.
faces.
This was requested by script writers. Especially needed if beveling
wire edges with vertex_only.
Should be backward compatible as just adds two new keys to returned
dict in python ('edges' and 'verts').
Was internally a no-op operation, which only caused extra work
to be done during depsgrpah traversal and evaluation, without
making any measurable improvement.
The issue was caused by usage of address of dupli-object (which will vary
from iteration process to iteration process) as something denoting whether
we've got the data synchronized to Cycles or not.
For now solved by using address of original object (the one DupliObject
points to) as a pointer for the map.
Need to do more thoughts about this.
This is supposed to help catch bugs if referrencing stack data out of
the draw loop context.
No change is suppose to happen for users (specially because the changes
here happens mostly on debug).
It includes a change in the logic for render loop, to make sure DST is
not accessed before we enter it - contribution by Campbell Barton.
This commit extends the work from Dalai made around scene iterators to
support iterating into objects from dupli-lists.
Changes can be summarized as:
- Depsgraph iterator will hold pointer to an object which created current
duplilist. It is available via `dupli_parent` field of the iterator.
It is only set when duplilist is not NULL and guaranteed to be NULL
for all other cases.
- Introduced new depsgraph.duplis collection which gives a more extended
information about depsgraph iterator. It is basically a collection on top
of DEGObjectsIteratorData.
It is used to provide access to such data as persistent ID, generated space
and so on.
Things which still needs to be done/finished/clarified:
- Need to introduce some sort of `is_instance` boolean property which will
indicate Python and C++ RNA that we are inside of dupli-list.
- Introduce a way to skip dupli-list for particular objects.
So, for example, if we are culling object due to distance we can skip all
objects it was duplicating.
- Introduce a way to skip particular duplicators.
So we can skip iterating into particle system.
- Introduce some cleaner API for C side of operators to access all data such as
persistent ID and friends.
This way we wouldn't need de-reference iterator and could keep access to such
data really abstract. Who knows how we'll be storing internal state of the
operator in the future.
While there is still stuff to do, current state works and moves us in the proper
direction.
We only show object center if object is selected, active or if viewport
has the "All Object Origins" options.
The viewport display options can migrate to renderlayer options.
However, we can mimic 2.7x as a compromise while the final design is
finalized.
This way we are not afraid of recursion being too deep.
That could have happened when having two collections which
are sharing same list of 1000s of objects.
