| 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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
We tried to do as much as possible in a single threaded callback, which
lead to using some nasty tricks like fake atomic-based spinlocks to
perform some operations (like float addition, which has no atomic
intrinsics).
While OK with 'standard' low number of working threads (8-16), because
collision were rather rare and implied memory barrier not *that* much
overhead, this performed poorly with more powerful systems reaching the
100 of threads and beyond (like workstations or render farm hardware).
There, both memory barrier overhead and more frequent collisions would
have significant impact on performances.
This was addressed by splitting further the process, we now have three
loops, one over polys, loops and vertices, and we added an intermediate
storage for weighted loop normals. This allows to avoid completely any
atomic operation in body of threaded loops, which should fix scalability
issues. This costs us slightly higher temp memory usage (something like
50Mb per million of polygons on average), but looks like acceptable
tradeoff.
Further more, tests showed that we could gain an additional ~7% of speed
in computing normals of heavy meshes, by also parallelizing the last two
loops (might be 1 or 2% on overall mesh update at best...).
Note that further tweaking in this code should be possible once Sergey
adds the 'minimum batch size' option to threaded foreach API, since very
light loops like the one on loops (mere v3 addition) require much bigger
batches than heavier code (like the one on polys) to keep optimal
performances.
|
