The goal is: have id->recalc flags set to components which got changed.
To make it possible for render engines to check on a more granular basis
what changed in the object. For example, is it a transform which changed
or is it just some ID property changed which has nothing to do with rendering.
The tricky part is: we don't want duplicated logic in tagging and flushing.
In order to avoid this duplication, we store ID recalc flag in the component
node type information. That type information could easily be accessed by both
tagging and flushing routines.
Remaining part of the changes are related on changing the way how tagging
works. The new idea here is to have utility function which maps update tag to
a component. This way we can easily set ID recalc flags right away. Without
any duplication of ID recalc flags set in multiple flag handler functions.
With all this being said, there should be no user measurable difference for
now, it's a gigantic basement for some upcoming work and fixes.
The issue actually goes a bit deeper, converting curve to mesh will
change texture space just because font and bezier curves are using CV
to calculate texture space.
So now when those objects are converted to mesh, we disable auto
texture space and copy evaluated space over.
Original fix was assuming that particle init operation is updated on every
frame, which is wrong behavior and that was fixed in previous commit to the
original bugfix.
- Highlight's were too intense/distracting
use more subtle alpha (consistent with the rest of our UI).
- Don't fill center cube (only draw edges).
- Draw widget while interacting since this is helpful in some cases.
Thanks to @jbakker for suggestions.
Also change axis hotspots so the nearest is always selected
for quicker axis picking (relies on dragging any axis to orbit).
Makes the 3D view navigation widget easier to use: dragging anywhere
in the rotation region now rotates without having to avoid the XYZ axis
hotspots which only activate on a single click.
Logic for drag detection is complicated by manipulators reliance
on keeping the modal operator running.
Currently this is wrapped in an ifdef,
we may want to implement it differently later.
A comparison should have not just have been against an epsilon,
but relative to the edge length involved.
Thanks to mano-wii for patch on which this is based.
The idea is to de-duplicate logic in DEG_id_tag_update() and flushing where we
need to translate depsgraph tag or component type to ID level recalc flag.
Currently unused, but is required for Blender 2.8.
Not only this helps merges form master to the branch, but also:
- Allows us to production-check changes as soon as possible.
- Avoids some unnecessary editors update about ID changes.
- Adds small optimization on queue size by always keeping one of the pointers
outside of the queue.
The idea is to allow iterating over ID nodes in exact order of their
construction, and in order which will not change dependent on memory
pointers or anything.
Now we stick to a single button, when data is directly linked, clicking
on it will make a local copy, while shift-clicking on it will make a
static override.
When data is a static override, icon is the DATA_OVERRIDE one, and clicking
on the button will make it a fully borring local data-block.
Code also handling auto-generation of static overrides.
Aside from some naming consistency cleanup, this commit:
* Is the first step addressing the 'operator' issue with static
overrides, by implementing a first version of the 'restore from
reference' behavior.
* Fixes several issues that were discovered on the way in enhanced
RNA comparision code, like the 'zero-length dynamic array' case, or some
infinite looping caused by some non-ID pointers (that for some
mysterious reasons did not show up previously...).
* Factorizes a bit said RNA comparison code (auto-static override
generation and comparison/check were essentially doing the same thing).
This flag means that the pointer does not 'own' the data it references.
This is the case of nearly all ID RNA pointers (NodeTrees will probably
again be some nasty exception here :( ), but also several other cases.
That kind of information is mandatory for complex processing over whole
data-blocks done in RNA, like some static override tasks (advanced
comparison...).
