| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Because some modifiers' actual code is in BKE... Also renamed to more
BKE-valid name BKE_modifier_get_evaluated_mesh_from_object.
|
|
There is still an issue with the modified mesh not being updated until you
disable and re-enable the modifier. However, after that it'll now also work
while editing the deformation mesh.
|
|
|
|
This also changes signature of modifier copy callback, first (source)
parameter is now a const, which is saner anyway!
|
|
This modifier still has issues that are not related to this port:
- While editing the deformation mesh, the deformed mesh doesn't update.
This update only happens after exiting edit mode, making editing
cumbersome.
- Binding doesn't work yet. It works fine when binding in master and
loading pre-bound in 2.8. This was also an issue before this port, and
will be investigated separately.
|
|
The contents of the ModifierEvalContext struct are constant while iterating
over the modifier stack. The struct thus should be only created once, outside
any loop over the modifiers.
|
|
Makes the follow changes:
- Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers.
- Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary
- Update the rest of Blender to be aware and make use of these new functions
The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed.
Reviewers: campbellbarton, sergey, mont29
Subscribers: sybren
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3155
|
|
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
|
|
These cases should not depend on the view layer.
|
|
This caused too many problems syncing object modes
with multiple objects/windows/workspaces, see: D3130 for details.
|
|
|
|
Makes it easier to add or remove fields needed to update relations.
|
|
Add ED_screen_window_find, BKE_workspace_edit_object
|
|
|
|
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
|
|
|
|
Allow threading using subset of all available threads. Makes it faster to
evaluate lower resolution mesh but with complex deform groups and such.
|
|
|
|
Those pointers are never to be aliased, so let's be explicit about this and hope
compiler does save some CPU ticks.
|
|
|
|
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
|
|
Wrap all arguments into TLS type of argument. Avoids some branching and also
makes it easier to extend things in the future.
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/depsgraph.c
source/blender/blenkernel/intern/library_query.c
|
|
Better to have clear way to tell whether flag is parameter for
BKE_library_foreach_ID_link(), parameter for its callback function, or
return value from this callback function.
|
|
|
|
Add flag for modifiers that support lattice
|
|
Based on usages so far:
- Split callback worker func in two, 'basic' and 'extended' versions. The former goes back
to the simplest verion, while the later keeps the 'userdata_chunk', and gets the thread_id too.
- Add use_threading to simple BLI_task_parallel_range(), turns out we need this pretty much systematically,
and allows to get rid of most usages of BLI_task_parallel_range_ex().
- Now BLI_task_parallel_range() expects 'basic' version of callback, while BLI_task_parallel_range_ex()
expectes 'extended' version of the callback.
All in all, this should make common usage of BLI_task_parallel_range simpler (less verbose), and add
access to advanced callback to thread id, which is mandatory in some (future) cases.
|
|
Binding code was re-building its own DM for the cage, now it uses given one instead.
I cannot see really any good reason not to use 'visual' modified cage for binding process,
using base mesh instead was breaking any 'advanced' binding as described in the report.
|
|
This mimics OpenMP's 'firstprivate' feature. It is sometimes handy to have some persistent local data during a whole chunk.
Reviewers: sergey
Reviewed By: sergey
Subscribers: campbellbarton
Differential Revision: https://developer.blender.org/D1635
|
|
since some IDs (objects) are not 'refcounted' while others (textures) are...
Partial merge from id-remap branch.
|
|
Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
|
|
- place return args last position
- move crazyspace function out of DerivedMesh header
- use bool for args
- flow control on own lines to ease debugging
|
|
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 :)
|
|
This is mainly to make physics modifiers being able to work
with it. For other cases this main is not needed.
|
|
|
|
The issue was caused by render engine duplicating the curve object because
it then converts the object to mesh. The mesh deform duplication code didn't
duplicate binded data, so after duplication modifier is no longer applyable.
So now copyData of mesh deform would copy data needed for binding. This solves
reported render bug and also solves possible frustration when duplicating an
object with mesh deform in the viewport with Shift-D.
Checked other modifiers and laplacian deform already was copying binded data.
Didn't see other modifiers which might also need to copy extra data.
|
|
It now supports different scheduling schemas: dynamic and static.
Static one is the default and it splits work into equal number of
range iterations.
Dynamic one allocates chunks of 32 iterations which then being
dynamically send to a thread which is currently idling.
This gives slightly better performance. Still some tricks are
possible to have. For example we can use some smarter static scheduling
when one thread might steal tasks from another threads when it runs
out of work to be done.
Also removed unneeded spin lock in the mesh deform evaluation,
on the first glance it seemed to be a reduction involved here but
int fact threads are just adding value to the original vertex
coordinates. No write access to the same element of vertexCos
happens from separate threads.
|
|
Mostly harmless things, though the 'multires' error was a real bug.
|
|
|
|
Quite straightforward change, don't think some extra explanation is needed.
This gives about 15% speedup of the modifier evaluation on my laptop.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D836
|
|
This commit switches meshdeform modifier to use threads to evaluate
the vertices positions using the central task scheduler.
SO now we've got an utility function to help splitting the for loop
into tasks using BLI_task module which is pretty straightforward to
use: it gets range (which is an integer lower and higher bounds) and
the function and userdata to be invoked for each of the iterations.
The only weak point for now is the passing the data to the callback,
this isn't so trivial to improve in pure C.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D838
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
