This was re-enabled because it made copy-on-write bugs hard to
track down.
Since copy-on-write implementation has been simplified
this isn't a problem anymore.
At least on windows we do not re-run datatoc when the .glsl files change.
To test is simple, just change edit_mesh_overlay_common_lib.glsl
remove lines, write plain text, ..., now rebuild and go in edit mode
with the default cube.
I also had to remove the entry in gpu/CMakeLists.txt for
gpu_shader_material.glsl since this was being tracked directly, as well
as running data_to_c_simple (otherwise CMake raises an error for
duplicated entries).
We probably want to do the same for the other datatoc functions.
Reviewers: LazyDodo, brecht
Differential Revision: https://developer.blender.org/D3803
You can now add the target from the non-active armature when they are
both in pose mode.
There were different ways of going about those operators:
* We could create one constraint on each active bone of each object.
That wouldn't follow what creating constraints from the UI does
though.
* We could change the selection/active order and create a constraint for
all the selected bones, to the active bone. However this would change
the design of changing only the active bone (which also is the one we
see in the buttons editor).
But in the end I think it makes more sense to let users set a constraint
from a charactor to a prop in a handy way.
This is pretty much what we had in 2.7x. There we would go for the
selected objects, if no selected bone was found in the active object.
In 2.8, however, we need this change to make things working as
before/intended.
This brings a big difference to meshes with edit cage adjusted for modifiers.
In my tests, the suzanne with subdivision modifier level 3 went from 4.80ms to 3.05ms.
By the tests I could only observe a considerable difference in the peformanse when the vertex size is 30.
Vertice 3 showed no difference in a suzzane with subdivision modifier level 3 + show-on-cage.
Point Size 30: 7.29ms vs 2.55ms
Reviewers: fclem
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D3805
At least on windows we do not re-run datatoc when the .glsl files change.
To test is simple, just change edit_mesh_overlay_common_lib.glsl
remove lines, write plain text, ..., now rebuild and go in edit mode
with the default cube.
I also had to remove the entry in gpu/CMakeLists.txt for
gpu_shader_material.glsl since this was being tracked directly, as well
as running data_to_c_simple (otherwise CMake raises an error for
duplicated entries).
We probably want to do the same for the other datatoc functions.
Reviewers: LazyDodo, brecht
Differential Revision: https://developer.blender.org/D3803
It was cycling both in the brush system and tool system which conflicted.
Now it uses just the tool system. This is more of a temporary fix until
the new tool/brush decoupled design is in place.
Computation of hold blocks was done by storing ranges (with start and
an end, and likely overlapping) in a tree keyed only by the block start.
This cannot work well, and there even were comments that it is not
reliable in complex cases.
A much better way to deal with it is to split all ranges so they don't
overlap. The most thorough way of doing this is to split at all and every
known keyframe, and in this case the data can actually be stored in the
key column data structures, avoiding the need for a second tree.
In practice, splitting requires a pass to copy this data to newly added
keys, and the necessity to loop over all keyframes in the range being
added. Both are linear and don't add excess algorithmic complexity.
The new implementation also calls BLI_dlrbTree_linkedlist_sync for
its own needs, so the users of the *_to_keylist functions don't have
to do it themselves anymore.
Differential Revision: https://developer.blender.org/D3790
Problem was that the event was not `NULL` even though the `context` is `WM_OP_EXEC_*`.
I noticed this problem when dropping .blend files into Blender.
Instead of only executing `WM_OT_open_mainfile`, it was invoked (opening a file selector).
The `wm_operator_invoke`, which also executes operators, always invokes operators when `event != NULL`. So setting `event` to `NULL` tells `wm_operator_invoke` not to invoke but to execute the operator.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3799
