The GP_STROKE_RECALC_CACHE identifier was changed to GP_STROKE_RECALC_GEOMETRY because the previous name was confusing and could be confused with the recalculation of the Draw Manager cache.
Instead of link toggle with enum, use a single popover that contains
both settings. The code for this isn't nice - needing 3x panels for now.
See D4075
rBa520e7c85c83 defined T_OVERRIDE_CENTER(1 << 25)
which was already in use T_PROP_PROJECTED(1 << 25)
thus skipping center calculation
Fixes T58882, T59518
Reviewers: campbellbarton, brecht
Maniphest Tasks: T58882, T59518
Differential Revision: https://developer.blender.org/D4100
This commit makes it so curve path parent solving accepts an explicit
arguments for both time and curve speed flag, making it so we don't
have to mock around with scene's frame.
One unfortunate issue still is that if the instancing object is used
for something else, we might be running into a threading conflict.
Possible solution would be to create a temp copy of an object, but
then it will be an issue of preventing drivers from modifying other
datablocks.
At least the original issue is fixed now, and things behave same as
in older Blender version. Additionally, the global variable which
was defining curve speed flag behavior is gone now!
This aims to resolve a conflict where some users want to keep keyboard
axis setting global, even when the orientation is set to something else.
Move/rotate/scale can optionally each have a separate orientation.
Some UI changes will be made next.
- Use the user orientation when pressing XYZ keys,
second press switches to global.
- Pressing again switches to global, or local
if you're have global orientation set.
The option for gizmos to have their own orientations will be added,
see: D4075
This has been unbelievably painful to understand... And solution is only
partially good actually, we may even want a single axis for all the
islands in that case? But for now this is giving much better results
already, compared to the random crazyness it used to produce.
This resolves this issue where users would enable a snapping mode
besides incremental (vertex for eg), then notice strange behavior w/
rotate and scale.
While this ability can be useful, it's quite an obscure use case.
Now changing snap-modes keeps rotate and scale using incremental snap,
with the option for these modes to be affected by other snapping modes.
D4022 by @kioku w/ own minor edits.
