There was some invalid state in the screen here, some areas had
sa->full set even though no screen was maximized, which then caused
a restore from the wrong (empty) area, which then led to spacedata
being empty and a crash.
This fix properly clears the sa->full after restore, and also fixes
existing .blend files in such an invalid state.
Only the camera from View3D.localvd is used,
other pointers may be invalid.
Longer term we should probably clear these to ensure no accidents.
For now just follow the rest of Blender's code and don't access.
Baking rigid body cache was broken if some cached frames already
existed.
This is just a band aid for release, the logic need to be looked into
further.
Since the change to prevent shader recompilation at every update, we got
a regression when clearcoat was used.
Basically at the shader build time we would determine if the shader
needed clear coat, and if it didin't, it would build a different GLSL
program.
However if later the user updated the clearcoat value so that it would
then require the full clearcoat shader, the user wouldn't get it until
manually forcing the shader to recompile, or reopening the file.
We now handle the optimization in the GLSL code. That adds a minimum
overhead due to branching. But the overall performance seems unchanged
(tested on linux in AMD and NVidia).
Reviewers: pascal, brecht, fclem
Differential Revision: https://developer.blender.org/D2822
Operators and their properties are two different types
Previously both operators and their properties are added
causing C operators to access the properties, Python the classes.
Favor consistency in this case so only Python classes are added.
A single diagonal axis was used for sorting coordinates,
the algorithm relied on users not having vertices axis aligned.
Use BLI_kdtree to remove doubles instead.
Overall speed varies, it's more predictable than the previous method.
Some typical tests gave speedup of ~1.4x - 1.7x.
For example, if you have two keyframes:
k1 = 1px, k2 = 10px
it was doing:
1px, 9px, 8px, ..., 3px, 2px, 10px
instead of:
1px, 2px, 3px, ..., 8px, 9px, 10px
This reverts commit 134e927965.
Writing into const event is very bad,
but this change broke compositor manipulators.
Will look into better solution eventually.
For some specific pipelines (e.g., holographic rendering) you can easily
need over a million frames (1k * 1k view angles).
It seems a corner case, but there is no real reason not to allow users
doing that.
That said we do loose subframe precision in the highest frame range. Which can
affect motionblur. The current maximum sub-frame precision we have is 16.
While the previous limit of 500k frames has a precision of 32.
Thanks to Campbell Barton for the help here.
To be backported to 2.79
