Age | Commit message (Collapse) | Author |
|
This would use uninitialized filename variable,
looked into supporting this however generating proxies currently only
works for movies.
|
|
Was accessing past the array boundaries.
Should be safe for 2.79a.
|
|
We shouldn't mix image pool acuisition with and without user provided,
the fact that internally image.c uses last frame from Image datablock
confuses the logic.
|
|
Enter release state and make spacing to "a" more sane.
There is still at least one fix we want to get in, before declaring we are
ready for release.
|
|
|
|
|
|
Keep mode checks simple, nest other checks in their body.
|
|
Also remove unused struct member.
|
|
bli_fileops.h was using uint64_t without including the proper header.
issue triggered by rBb0af44fa4d7a2e134b315c49a4fbdf573f781004
|
|
D2976 by @dertom
|
|
Also add code example in docs.
|
|
This can be very slow if it contains a big texture, and it's not
necessarily setup in a useful way anyway, and materials can be used
in multiple scenes.
|
|
mode.
We did not clear preview or smoothscroll timers pointers in copy code...
|
|
Was happening when viewport visibility on the particle system is disabled.
This became an issue after c45afcf, but the actual issue goes a bit deeper
and the following aspects were involved:
- Relations builder for particle system was ignoring particle system if
it's visibility is not enabled for viewport. This is something what
shouldn't have been done -- depsgraph relations are supposed to be the
same no matter if it's viewport or render.
- Relation builder was only dealing with duplication set to object, but
was ignoring group duplication.
This is NOT a regression since 2.79, but a regression since 2.79a-rc1.
|
|
Epic fail from recent 'security' fixes (rBe04d7c49dca9). ;)
To be backported to 2.79a!
|
|
Failure in own code from last December, thanks @sergey for finding it.
To be backported to 2.79a.
|
|
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.
|
|
|
|
Forgot to add that in previous commit, also related to T53003.
|
|
Move restricted 'reasonable' range to ui_range, and allow wider values
for manual settings.
|
|
FFMPEG uses int for the numerator, while Blender uses a short. So in
cases people gave weird exotic framerate values and we cannot reduce
enough the numerator, we'd get totally weird values (even negative frame
rates sometimes!)
Now we add checks for short overflow and approximate as best as possible
in that case (error should not matter unless you have shots of at least
several hundreds of hours ;) ).
|
|
This reverts commit dc2617130b2e1d7d2b9892fbd7c6e7b60caafb66, which disabled
writing of previews for undo. While this uses some memory, re-rendering all
previews is very expensive, especially if for example you have lots of materials
using high-res image textures.
|
|
|
|
This way release checker used by Linux release environment is corrected.
|
|
|
|
|
|
The idea is to avoid any threading overhead when we start pushing tasks in a
loop. Similarly to how we do it from the new dependency graph. Gives couple of
percent of speedup here, but also improves scalability.
|
|
|
|
This reverts commit bf58ec9265eef8c6cd3dc350557829151995ef28.
|
|
|
|
This would lead to sock.default_value pointing to the wrong data type,
possibly causing crashes. Unfortunately, this bug will still exist for
older Blender versions that try to load newer files, which makes
changing the type of a node socket problematic.
|
|
Entering particle edit mode w/ the weight brush enabled crashed
on non-hair particle systems.
|
|
Drawing hair weights read before the hair array start.
This code could be improved since it currently copy-pastes,
from do_particle_interpolation, but this would need larger changes.
For now just correct existing logic.
|
|
5b25605761fb7
|
|
Solves these security issues from T52924:
CVE-2017-12102
CVE-2017-12103
CVE-2017-12104
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
|
|
Solves these security issues from T52924:
CVE-2017-12081
CVE-2017-12082
CVE-2017-12086
CVE-2017-12099
CVE-2017-12100
CVE-2017-12101
CVE-2017-12105
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
|
|
|
|
Fixes CVE-2017-2908 from T52924.
Differential Revision: https://developer.blender.org/D3001
|
|
Solves these security issues from T52924:
CVE-2017-2899
CVE-2017-2900
CVE-2017-2901
CVE-2017-2902
CVE-2017-2903
CVE-2017-2904
CVE-2017-2905
CVE-2017-2906
CVE-2017-2907
CVE-2017-2918
Differential Revision: https://developer.blender.org/D2999
|
|
Header drawing accesses the scene too.
|
|
This reverts commit d0e0f33f57b02fecf75c08f3c144d07915367781.
Requested by author, since it raised new issues, better not have it in
bugfix release!
|
|
Differential Revision: https://developer.blender.org/D2981
|
|
|
|
Integer Overflow Code Execution Vulnerability.
Reader no longer crashes on corrupt images (from own fuzz testing).
|
|
Harmless but causes warnings
|
|
|
|
|
|
When the edge is aligned with it's own normals,
transform orientation wasn't aligned with the edge.
|
|
|
|
|