We had several reports where users would create rigid bodies by accident
and then wonder why transformations behave differently.
Since these actions aren't used that often, just remove the shortcuts.
This makes the tabs slightly larger, increases the text size slightly, and adjusts the colors a bit to improve overall contrast. It also makes inactive tabs draw with a full tab shape, improving the readability at a glance, particularly when tabs are very small.
The users most affected will be those on smaller displays, where previously tabs were very difficult to read.
Reviewers: @billrey, @campbellbarton
Differential Revision: https://developer.blender.org/D170
This adds an ImageUser to such empties with all the typical settings.
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D108
this allows for updating icons without committing a new PNG each time
(which is inefficient with git). The data files are converted into a
PNG at builds time and used just as they were before.
It was a missing fcurve evaluation in scene update function which lead to
materials only being updated on frame change.
Added the same exception as we've got for the scene animation. It only
runs when there're materials tagged for the update, so wouldn't expect
speed regressions or so.
Issue was caused by cache limitor removing viewer image buffer
from the memory during compositing. Now made it so all viewer
images are persistent in the memory.
This solves the crash mentioned above and also makes it so
render/compo results are never lost.
Further tweaks are possible, but pretty much happy now, at
least no stoppers for work are there.
Same as mballs and curves it was only to work around DAG stupidness
which hopefully was fixed in one of the previous commits.
From quick tests everything works fine, if something is broken now
poke me to find a proper solution.
There were couple of reasons why it wasn't safe for usage from
multiple threads.
First of all, it was trying to cache BVH in derived mesh, which
wasn't safe because multiple threads might have requested BVH
tree and simultaneous reading and writing to the cache became a
big headache.
Solved this with RW lock so now access to BVH cache is safe.
Another issue is causes by the fact that it's not guaranteed
DM to have vert/edge/face arrays pre-allocated and when one
was calling functions like getVertDataArray() array could
have been allocated and marked as temporary. This is REALLY
bad, because NO ONE is ever allowed to modify data which
doesn't belong to him. This lead to situations when multiple
threads were using BVH tree and they run into race condition
with this temporary allocated arrays.
Now bvhtree owns allocated arrays and keeps track of them, so
no race condition happens with temporary data stored in the
derived mesh. This solved threading issues and likely wouldn't
introduce noticeable slowdown. Even when DM was keeping track
of this arrays, they were re-allocated on every BVH creation
anyway, because those arrays were temporary and were freed
with dm->release() call.
We might re-consider this a bit and make it so BVH trees are
allocated when DM itself is being allocated based on the DAG
layout, but that i'd consider an optimization and not something
we need to do 1st priority.
Fixes crash happening with 05_4g_track.blend from Mango after
the threaded object update landed to master.
