Now, the internal data is recalculated when add or remove a point.
The change in the API affect to stroke.points.add() that now requires a datablock parameter. This parameter is required to identify the datablock affected.
For example: stroke.points.add(gpencil, 1) instead of stroke.points.add(1)
This is the second try to fix T59600
For strokes:
myframe.strokes.update(mystroke)
For datablock:
gpencil = bpy.data.grease_pencil['gpencil']
gpencil.update()
Still need a manual refresh of viewport.
The perspective effect deformed the stroke. Now when you are in camera view and the lock axis is not enabled, the stroke is reprojected flat over the view to remove any deformation.
Also fixed reproject operator to use the origin set in topbar and not cursor 3D always.
Another case where editstr from search button would be used, when we
actually have desired pointer itself already available in button.
Am growing tired of doing bandaids fixes on that search menu stuff,
whole thing would require some real re-coding imho, to get rid of that
tantacular dependency over string 'identifier' only (when we should also
have access to at the very least, the active index, and also probably
active data pointer itself...).
And/or clearly separate string identifier from 'UI' string shown to user.
- Silence harmless error print about relation.
Object with particle system which doesn't use physics will
not have point cache component.
- Tag relations for update when particle system physics type
change.
This ensures correct state of point cache component.
This is all part of T59258.
There is no point having operations that iterate over the whole
bit array as macros, so convert BLI_BITMAP_SET_ALL to a function.
Also, add more utilities for copying and manipulating masks.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D4101
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
NLA requires a usable default value for all properties that
are to be animated via it, without any exceptions. This is
the real cause of T36496: using the default of 0 for a scale
related custom property obviously doesn't work.
Thus, to really fix this it is necessary to support configurable
default values for custom properties, which are very frequently
used in rigs for auxiliary settings. For common use it is enough
to support this for scalar float and integer properties.
The default can be set via the custom property configuration
popup, or a right click menu option. In addition, to help in
updating old rigs, an operator that saves current values as
defaults for all object and bone properties is added.
Reviewers: campbellbarton, brecht
Differential Revision: https://developer.blender.org/D4084
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!
