Display statistics from CCG structure.
This makes values to be different from what is shown in object
mode, since CCG is operating on individual grids, and object
mode will stitch those grids. But on another, those values from
CCG is what sculpt mode is actually "sees" or "uses".
The number of faces should be the same in both sculpt and object
modes.
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.
This is a second attempt to get the crash fixed. The original fix
worked, but it was reverted by d3e0d7f082.
Now the logic goes as:
- All pointers which we can not have shared (the ones which are
owned by the runtime) are cleared.
- The rest of runtime stays untouched.
This seems to be enough to keep particles happy.
This commit adds support for new curve tool and adds more functionalities to the existing primitives, including new handles, editing, stroke thickness curve, noise, preview of the real stroke, etc.
Thanks to @charlie for his great contribution to this improvement.
NLA strips support using the keyframe values in a variety of ways:
adding, subtracting, multiplying, linearly mixing with the result
of strips located below in the stack. This is intended for layering
tweaks on top of a base animation.
However, when inserting keyframes into such strips, it simply inserts
the final value of the property, irrespective of these settings. This
in fact makes the feature nearly useless.
To fix this it is necessary to evaluate the NLA stack below the
edited strip and correctly compute the raw key that would produce
the intended final value, according to the mode and influence.
Differential Revision: https://developer.blender.org/D3927
The issue was caused by a special code in node tree freeing function
which will free extra fields in the case when tree is not in bmain.
This is how old code was dealing with "nested" trees, but is now
making behavior different from other datablocks. This is exactly
what was confusing copy-on-write logic.
Ideally, ntreeFreeTree() need to behave same as all other datablocks,
ad freeing of data of nested trees should be up to the owner of the
tree (this way it's all explicit and does not depend on check of
some special flag.
This restores the object->data to a non-modifier evaluated state.
So this allow us to change evaluated object modifier stack directly and
get BKE_mesh_new_from_object() for the evalauted object.
This enables ffmpeg to encode each frame in its own thread. However in most
cases Blender does not pass frames to ffmpeg fast enough to actually use the
more than two threads. In some tests the speed was measured to be about 20%.
If other parts of the video sequencer get optimized, this should improve.
Differential Revision: https://developer.blender.org/D4031
Applying the effect of bone parent is much more complicated than
simple matrix multiplication because of the various flags like
Inherit Scale. Thus it is reasonable to provide access to this
math from Python for complicated rest pose related manipulations.
The simple case of this is handled by Object.convert_space, so
the new method is only needed for complex tasks.
Differential Revision: https://developer.blender.org/D4053
Basically, armature update is not supposed to be run in edit mode.
This worked in master and new dependency graph because nobody was
tagging armature for an update.
But with all those copy-on-write and other things we can't ensure
tag doesn't happen (and we shouldn't). So now we ensure unwanted
code is not run from the code itself.
P.S. Deeper reason of this goes to the optimization of not updating
pose channels when in edit mode. Since pose doesn't define anything
there we don't want to be bothered with a pose update after every
operation which changes it.
Textures are now hooked up to the RESET operation of particle
settings, which ensures particles being re-distributed when
texture is changed.
This is limited to a direct user modifications, which matches
old behavior in 2.79.
Seriously... There is no point in having those subversions if one does
not take advantage of them to reduce doversion work on file load! Now we
have to raise subversion again just for that. :(
We cannot let those data be generated on-the-fly in RBW evaluation
anymore, since those would be added to CoW eval object and never ported
back to orig objects.
We *could* get orig objects in eval code, of course, but as in
constratints, this is not really threadsafe and future proof, depsgraph
evaluation should really write back to orig data as little as possible.
So instead, add code to ensure required data is generated to objects
when their collection is added to rigidbody world.
Note that we *may* want to clean that up once collection is no more used
by RB? On the other hand, people might want to keep those data around to
be able to switch between different setups easily... So think it's OK to
keep them at least for now.
