| 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.
|
|
Also remove unused struct member.
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
This is a bit annoying to have per-DM locking, but it's way better (as in, up to
4 times better) for playback speed when having lots of subsurf objects,
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D2977
|
|
|
|
|
|
The issue was caused by threading conflict around looptris: it was possible
that DM will return non-NULL but non-initialized array of looptris.
Thanks Campbell for second pair of eyes!
|
|
Was intersecting same triangle twice.
|
|
Use more watertight and robust intersection test.
It uses now ray to triangle intersection, but it's all fine because segment was
covering the whole bounding box anyway.
|
|
|
|
Addon's were also ignored
|
|
Avoids complicating the common case
|
|
|
|
Loading startup file always loads the UI now.
|
|
|
|
only contained a single key (on the last real frame of the action).
|
|
Differential Revision: https://developer.blender.org/D2935
|
|
|
|
|
|
|
|
This way we can easily re-use bits of code for new dependency graph.
Currently should be no functional changes.
|
|
The issue actually goes a bit deeper, converting curve to mesh will
change texture space just because font and bezier curves are using CV
to calculate texture space.
So now when those objects are converted to mesh, we disable auto
texture space and copy evaluated space over.
|
|
Based on report from Talos Security Advisory.
|
|
|
|
|
|
faces.
Odd nobody noticed this earlier, was obvious bug in code logic here... :/
To be backported to 2.79a.
|
|
When saving templates had wrong return value.
|
|
D2841 by @uvwxyz w/ edits
|
|
|
|
D2955 by @GonVas
|
|
|
