- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
Compared to usual cddm one, ccgdm one was not applying the
ob->derivedDeform deformation to the pbvh generated from the
original mesh geometry, when possible.
We can only support painting from subsurf DM in a limited subset of
cases, others (like multiple subsurf, or topology-modyfying ones,
break mapping to original geometry).
This is not the most ideal fix (ideally, we should always be able to get
a mapping to original geometry from any point in modifiers stack...).
Brushes themselves are still affected by the mask, but the viewport is not
showing the mask. This way it's easier to see details while sculpting.
Studio request by Julien Kaspar
Gives about 40% speedup of object which has simple-ish deformation applied
on top of subdivided mesh.
This might easily happen with single character animation.
Mutex is now local to particular CCGDM, and guarding edge hash which is only
used by a single function only. There is no need to acquire read lock after
edge hash was created.
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,
Notes:
- Changes in paint_vertex.c were simple to merge, mainly related on passing
evaluation context.
- Conflicts in EditDM and drawmesh.c are solved using code from blender2.8
branch. Those areas are deprecated and not to be used in final release.
However, it's possible that some reference code from master is lost, so
keep attention when adding alpha support for vertex painting.
2016 GSOC project by @nathanvollmer, see D2150
- Mirrored painting and radial symmetry, like in sculpt mode.
- Volume based splash prevention,
which avoids painting vertices far away from the 3D brush location.
- Normal based splash prevention,
which avoids painting vertices with normals opposite the normal
at the 3D brush location.
- Blur mode now uses a nearest neighbor average.
- Average mode, which averages the color/weight
of the vertices within the brush
- Smudge mode, which pulls the colors/weights
along the direction of the brush
- RGB^2 color blending, which gives a more accurate
blend between two colors
- multithreading support. (PBVH leaves are painted in parallel.)
- Foreground/background color picker in vertex paint
Even if pointer assignment may be atomic, it does not prevent reordering
and other nifty compiler tricks, we need a memory barrier to ensure not
only that transferring pointer from wip array to final one is atomic,
but also that all previous writing to memory are “flushed” to
(visible by) all CPUs...
Thanks @sergey for finding the potential (though quite unlikely) issue.
Tentative fix, since I cannot reproduce thenissue for some reason here
on linux.
Core of the problem is pretty clear though, thanks to Germano Cavalcante
(@mano-wii): another thread could try to use looptris data after worker
one had allocated it, but before it had actually computed looptris.
So now, we use a temp 'wip' pointer to store looptris being computed
(since this is protected by a mutex, other threads will have to wait on
it, no possibility for them to double-compute the looptris here).
This should probably be backported to 2.79a if done.
Note: this commit seems to work as expected (also with transform
snapping etc.). However, it is rather unsafe - not enough for 2.79 at
least, unless we get much more testing on it. It also depends on three
previous ones.
Note that using a global lock here is far from ideal, we should rather
have a lock per DM, but that will do for now, whole DM thing is doomed
to oblivion anyway in 2.8.
Also, we may need a `DM_DIRTY_LOOPTRIS` dirty flag at some point. Looks
like we can survive without it for now though... Probably because cached
looptris are never copied accross DM's?
- Derived-mesh drawing.
- All non UV members of TexFace structs.
MTexPoly is now redundant but keeping with a dummy member,
will check on complete removal later.
In ccgDM and emDM, looptri array recalculation was being handled
directly by `*DM_getLoopTriArray` (`getLoopTriArray` callback), while
`*DM_recalcLoopTri` (`recalcLoopTri` callback) was doing nothing.
This results in the array not being recalculated when other functions
that depend on the array data called the recalc function.
This moves all the recalculation code to `*DM_recalcLoopTri` and makes
`*DM_getLoopTriArray` call that.
This commit also makes a minor change to the `getNumLoopTri` function,
so that it returns the correct number without having to recalculate the
looptri array.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2375
ccgDM_drawMappedFacesMat was missig a smooth shade model restore, some other
functions were redundantly setting it since we can assume it to be the default
state already.
