| 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.
|
|
|
|
Avoid access from bpy when it's already declared.
|
|
|
|
|
|
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
|
|
Allow overriding gzip open w/ elbeem.
|
|
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!
|
|
This part of 212a8d9e needed to be ported over for 2ca933f to work.
|
|
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.
|
|
|
|
Namely, the issue would happen when CPU device was never used before.
Issue with wrong merge conflict resolution.
|
|
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.
|
|
|
|
We can not store pointers to elements of collection property in the
case we modify that collection. This is like storing pointers to
elements of array before calling realloc().
|
|
|
|
The issue was caused by light sample being evaluated to nan at some point.
This is root of the cause which is to be fixed, but is very hard to trace down
especially via ssh (the issue only happens on AVX2 release build). Will give it
a closer look when back to my AVX2 machine.
For until then this is a good check to have anyway, it corresponds to what's
happening in regular radiance sum.
|
|
feature from master.
Was making unittests unhappy.
|
|
This reverts commit bf58ec9265eef8c6cd3dc350557829151995ef28.
|
|
Our own implementation was behaving different comparing to OSL and GPU,
namely on the border pixels OSL and CUDA was doing interpolation with
black, but we were clamping coordinate.
This partially fixes issue reported in T53452.
Similar change should also be done for 3D interpolation perhaps, but this
is to be investigated separately.
|
|
|
|
|
|
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
|
|
|
