The main goal of this patch is to cleanup the interface of every modifier. More specifically the interface of modifiers should be DerivedMesh-free.
Internally some modifiers still use DerivedMesh. However I think it is better when the wrappers are in the modifiers so that higher level functions can use the simplified interface.
This patch removes the applyModifier_DM and applyModifierEM_DM functions. In a previous patch (rB3614d9d) the other functions that used DerivedMesh have been removed.
Reviewers: brecht
There are following reasons to do so:
- The plan is to replace it with some sort of object or viewport option,
so we can apply OpenSubdiv subdivisions on top of modifier stack and
keep modifier stack purely CPU side.
This will solve issues when adding some relation in scene will force
modifier to be evaluated on CPU.
- With new upcoming OpenSubdiv based CPU modifier implementation we can
cache topology similar to what GPU side was doing, which will already
be reasonably faster.
- OpenSubdiv GPU does not work since the OpenGL version bump, and is
to be rewritten with all the adaptive refine options kept in mind.
Since OpenSubdiv GPU was already broken and was only causing object
to become invisible, there is no reason to keep having that option in
the modifier.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3598
`mesh_get_eval_final` and friends could call `mesh_build_data`, which in
paint/sculpt mode would call `BKE_sculpt_update_mesh_elements` which
would call `mesh_get_eval_final`... ugly!
Would compare evaluated ob pointer to original one...
Found while investigating some errors in incomming cleanup, but this was
probably generating lost of other issues in some cases...
The function definitions still reside in DerivedMesh.c. Once we're done
porting all the DerivedMesh use to Mesh, we'll move the still-relevant
functions to mesh_runtime.c. This move is now cumbersome due to shared
statically-declared utility functions in DerivedMesh.c
Make it more reliable and predictable way of getting pointer to
an original mesh which came from copy-on-write engine.
Related change: made it (hopefully) more clear name for flags.
After discussion with Sergey and Dalai, we have decided to remove
this option completely. We're getting to the point where it is almost
impossible to really use 2.8 without COW, and keeping the old option
running ends up diverting dev resources away towards tracking down
and fixing problems with a parallel system that will be going away.
Saves quite a bit of CPU ticks per mesh update, giving measurable
speedup for file from T55228.
Memory usage goes up a it, most likely due to evaluated mesh having
more custom data layers than corresponding DM does.
*Always* use BKE_library API to handle IDs allocation and freeing,
unless you have a very, very, very good reason not to do so - and
perfectly know what you are doing.
This flag is copied when converting between DM and Mesh.
This flag is set to true in get_mesh(), to mimick the behaviour of
CDDM_from_mesh_ex. This is necessary for the particle system to work
correctly.
This ports the main modifier eval loop.
A few things haven't been ported yet: tessface and shapekey related code. As
far as I can tell, shapekey code was never entered into.
https://developer.blender.org/D3342
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.
This commit introduces `EditMeshData`. The fields in this struct are
extracted from `EditDerivedBMesh` into their own struct `EditMeshData`,
which can then also be used by the `Mesh` struct. This allows passing
deformed vertices efficiently to the draw routines.
The modifier code constructs a new Mesh instead of writing to ob->data;
even when ob->data is a CoW copy, it can still be used by different
objects and thus shouldn't be modified by a modifier.
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
