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
Since the collision modifier cannot be disabled, it causes a constant
hit on the viewport animation playback FPS. Most of this overhead can
be automatically removed in the case when the collider is static.
The updates are only skipped when the collider was stationary during
the preceding update as well, so the state is stored in a field.
Knowing that the collider is static can also be used to disable similar
BVH updates for substeps in the actual cloth simulation code.
Differential Revision: https://developer.blender.org/D2277
Note that the collision modifier doesn't have any use for Loop indices,
so to avoid duplicating the loop array too,
MVertTri has been added which simply stores vertex indices (runtime only).
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
* The old collisions code detected particle collisions by calculating the
collision times analytically from the collision mesh faces. This was
pretty accurate, but didn't support rotating/deforming faces at all, as
the equations for these quickly become quite nasty.
* The new code uses a simple "distance to plane/edge/vert" function and
iterates this with the Newton-Rhapson method to find the closest particle
distance during a simulation step.
* The advantage in this is that the collision object can now move, rotate,
scale or even deform freely and collisions are still detected reliably.
* For some extreme movements the calculation errors could stack up so much
that the detection fails, but this can be easily fixed by increasing the
particle size or simulation substeps.
* As a side note the algorithm doesn't really do point particles anymore,
but uses a very small radius as the particle size when "size deflect" isn't
selected.
* I've also updated the collision response code a bit, so now the particles
shouldn't leak even from tight corners.
All in all the collisions code is now much cleaner and more robust than before!
most local modifier,GPU,ImBuf and Interface functions are now static.
also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
Used a crazyspace approach (like in edit mode), but only modifiers with
deformMatricies are allowed atm (currently shapekeys and armature modifiers only).
All the rest modifiers had an warning message that they aren't applied because
of sculpt mode. Deformation of multires is also unsupported.
With all this restictions users will always see the actual "layer" (or maybe
mesh state would be more correct word) they are sculpting on.
Internal changes:
- All modifiers could have deformMatricies callback (the same as deformMatriciesEM but
for non-edit mode usage)
- Added function to build crazyspace for sculpting (sculpt_get_deform_matrices), but it
could be generalized for usage in other painting modes (particle edit mode, i.e)
Todo:
- Implement crazyspace correction to support all kinds of deformation modifiers
- Maybe deformation of multires isn't so difficult?
- And maybe we could avoid extra bad-level-stub for ED_sculpt_modifiers_changed
without code duplicating?
When there are 2+ consecutive deform modifiers, the second modifier was getting incorrect normals, this only showed up for the displace modifier since its the only deform modifier that uses vertex normals.
It would have been easy to fix this by always calculating normals on deform modifiers, but slow.
To fix this I added a function to check if a deform modifier needs normals, so the normal calculation function only runs if there are 2 modifiers in a row and the second uses normals.
