Implemented the following methods:
* SIMCURHAND_TYPE
* SIMCURHAND_RADIUS
* SIMCURHAND_WEIGHT
* SIMCURHAND_DIRECTION
Limits:
* DIRECTION does not support surfaces, because `BKE_nurb_bpoint_calc_normal`
does not work with Nurbs of type `CU_CARDINAL`. This also didn't work prior
to this patch, so we wait until surfaces are properly supported in EditMode.
* Also DIRECTION should take scaling into consideration. We need our own
versions of BKE_nurb_bpoint_calc_normal/bezt.
* Threshold default is too large. Not sure if it's better to change the default
or scale the threshold in code.
Differential Revision: https://developer.blender.org/D3846
Changes from committer (Dalai Felinto):
* Moved nurb_bpoint_direction_worldspace_get/bezt to functions.
* Comments hinting at the mode (direction) that require scaling to be
taken into account - to be addressed by patch creator in a future
patch.
Although the normal was normalized when evaluating the lighting, the normal
is often used for other purpose. In this case using the non normalized
normal maybe the source of errors.
Was temporarily replace with code that used the tool-system,
bring back logic which cycles and toggles brushes.
Tool slots are used for the initial brush,
after that toggle or cycle is used.
* Area and Workspace duplicate.
* Toggle Area Fullscreen
* Operator Search
* Workspace reorder to front/back (arrows help to know which direction means front/back)
From own changes in that area... Now we also enforce handling shortcuts
in case relevant drawflag of searchbutton is set. Should allow to cover
all cases, hopefully.
The Nearest Surface Point shrink method, while fast, is neither
smooth nor continuous: as the source point moves, the projected
point can both stop and jump. This causes distortions in the
deformation of the shrinkwrap modifier, and the motion of an
animated object with a shrinkwrap constraint.
This patch implements a new mode, which, instead of using the simple
nearest point search, iteratively solves an equation for each triangle
to find a point which has its interpolated normal point to or from the
original vertex. Non-manifold boundary edges are treated as infinitely
thin cylinders that cast normals in all perpendicular directions.
Since this is useful for the constraint, and having multiple
objects with constraints targeting the same guide mesh is a quite
reasonable use case, rather than calculating the mesh boundary edge
data over and over again, it is precomputed and cached in the mesh.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3836
Not all three sides of a tesselated mesh triangle are guaranteed
to be original mesh edges, so a somewhat complicated check is
required to detect which ones are real. It seems that until now
there was no utility function for that, only some example code.
Simple find_nearest relies on a heuristic for efficient culling of
the BVH tree, which involves a fast callback that always updates the
result, and the caller reusing the result of the previous find_nearest
to prime the process for the next vertex.
If the callback is slow and/or applies significant restrictions on
what kind of nodes can qualify for the result, the heuristic can't
work. Thus for such tasks it is necessary to order and prune nodes
before the callback at BVH tree level using a priority queue.
Since, according to code history, for simple find_nearest the
heuristic approach is faster, this mode has to be an option.
This reverts back to the 2.79 situation. The better solution would be to make
physics caching somehow simulate the skipped frames. But for now the more
important thing is to have working physics.
Ref T54943, T56352.
RNA's ViewLayer would present 'first level' of layer collection as a
list (collection property), when it is actually now only a single item,
same as the scene's master collection.
Note: did not try to update view_layer python tests, those are already
fully broken for quiet some time I guess (they still assume
view_layer.collections to be mutable e.g.)...
This reverts reverting commit rB55324b8a2e6799300, and do proper 'cleanup' (sigh)
in gtest as well.
Sorry for the noise, did not understood what had happened here
immediately. :/
"Type of active data to display and edit" is a bit too descriptive and takes
away from reading which context we're actually viewing. Also minor tweaks to
context description.
Now it is forumlated in terms of deltas, and consists of the
following steps:
- Original displacement at the reshape level are being backed up.
- New displacement is being written by the reshape routines.
- Delta of the displacement is calculated.
- Deltas are propagated to the higher levels, which also includes
their interpolation/
- Original displacement is restored.
- New interpolated displacements are added to the original ones.
This is a base ground for the upcoming change related on using
Catmull-Clark smoothing for the deltas instead of linear
interpolation. Currently is no changes for artists, just preparing
for upcoming work.
This is a nasty bug. Because the node does not get properlly tagged as SSS
(sss_id is 0) but is still evaluated (so tagging the GPUMaterial as having
SSS). The sssProfile UBO is still declared and we need to bind something
to it.
