After testing in the studio and extending the event system for
drag events, we've agreed on adjustments to the new keymap,
see: T55162
- Tab: Edit-mode toggle.
- Tab + Cursor Drag: mode switching pie menu.
- Accent/Grave: for 3D view pie menu.
- F3: Search
- 1..3, Shift-1..3: Edit mesh vertex/edge/face toggle.
Other minor changes were made, however they aren't part of the design.
- Ctrl-Shift-S: Image editor Save-As (was F3)
- Ctrl-Alt-R: Repeat history (was F3)
Notes:
* Really need to address RNA setters case, end up adding way too much
G.main here these days... :/
* Added Main pointer into bAnimContext, helps a lot in anim code ;)
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
This commit restores support for Motion Path drawing in 2.8 (as it wasn't ported over
to the new draw engines earlier, and the existing space_view3d/drawanimviz.c code was
removed during the Blender Internal removal).
Notes:
* Motion Paths are now implemented as an overlay (enabled by default).
Therefore, you can turn all of them on/off from the "Overlays" popover
* By and large, we have kept the same draw style as was used in 2.7
Further changes can happen later following further design work.
* One change from 2.7 is that thicker lines are used by default (2px vs 1px)
Todo's:
* There are some bad-level calls introduced here (i.e. the actgroup_to_keylist() stuff).
These were introduced to optimise drawing performance (by avoiding full keyframes -> keylist
conversion step on each drawcall). Instead, this has been moved to the calculation step
(in blenkernel). Soon, there will be some cleanups/improvements with those functions,
so until then, we'll keep the bad level calls.
Credits:
* Clément Foucault (fclem) - Draw Engine magic + Shader Conversion/Optimisation
* Joshua Leung (Aligorith) - COW fixes, UI integration, etc.
Revision History:
See "tmp-b28-motionpath_drawing" branch (rBa12ab5b2ef49ccacae091ccb54d72de0d63f990d)
This includes:
- Skip OB_RECALC_TIME tag from object duplicate operator
not sure why it is needed: even if original object was
animated, duplicating it will copy evaluated values.
- Don't tag whole ID for update when updating it after
relations rebuilt. Use the same trickery to detect
whether animation is to be re-evaluated or not as is
done for update flag=0.
- Don't tag datablocks which are expanded for update
of copy-on-write.
- Avoid flush along relation from copy-on-write
operation in action. This will not invalidate any
pointers in the copied datablock since we don't
reference anything in the action.
This way we allow animation system to make decisions based on which
context dependency graph is coming from, and whether it belongs to
an active edit window or not.
Use the same key for pose & weight paint mode (instead of texture paint)
This makes more sense since pose/weight paint modes
are often used in combination.
- Use Tab key for search.
- Number keys switch modes.
- The number of the current mode can open a submode menu
(currently only works for edit-mode)
- Ctrl-Tab, Ctrl-Shift-Tab - cycle workspaces.
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
