could happen when used on multiple objects with multi edit, and skin
modifier was not present on all participating objects
Reviewers: brecht
Maniphest Tasks: T66311
Differential Revision: https://developer.blender.org/D5165
The issue was that the end point would be extrapolated and it would lead to
very high values if the curve had a near inf slope. Now we use the actual end
point value and only extrapolate values that are outside of the start and
endpoint range.
Differential Revision: https://developer.blender.org/D5151
The root of the issue comes to the fact that part of dependency graph
is being removed, without doing any further remapping.
This was happening because only materials used by objects were pulled
in, so when material mode is changed some material became unused and
removed from the dependency graph and freed, causing object or its
data to point to a freed memory in its materials array.
Simplest and safest way to solve this is to pull materials referenced
by both object and object data. This causes somewhat higher memory
usage but keeps evaluated state of scene in an always consistent state,
without any need to tag/update object's data on material mode change.
Don't think it is a problem in practice.
Reviewers: brecht, fclem
Reviewed By: brecht, fclem
Differential Revision: https://developer.blender.org/D5172
CDData checking on file load was not taking into account deprecated
CD_MTEXPOLY datatype, which unfortunately shows same weird glitch as
CD_PAINT_MASK and CD_FACEMAP ones...
Note that it was annoying (due to amount of warnings in console), but
totally harmless, since that data type is just deleted anyway.
This commit also generally cleans up the CD_MTEXPOLY deprecation code, we
have a system to handle that, let's use it, instead of defining local
static values to replace it...
Two issues here:
- Evaluated object data is to only be updated for selection only after modifier
stack is done its job. Otherwise it's possible to have selection batch update
called on an input data, at the same time as original object data is being
evaluated.
- If object's modifier stack did not create its own evaluated mesh (in case
when there is no effective modifiers, for example) can not update selection
on object's data, as it might cause threading issues between objects sharing
same data.
When we create the cage procedurally, we need to remove any edge split
modifiers. Since the new depsgraph in 2.80 we were removing the
modifiers straight from the evaluated object (it is a copy anyways).
On top of that we need to reset its eval data state (BKE_object_eval_reset)
to make sure the call to BKE_object_to_mesh to generate the cage would take the
new modifier stack state into account.
However doing so was freeing the low poly mesh we use later to convert
the normal space.
The solution (and this patch in fact ;) ) as suggested by Sergey Sharybin is to
use BKE_mesh_new_from_object() directly as well as force the modifiers to be
recalculated when any edge split modifier is removed.
The root cause seems to be an assumption in
[generate_video_frame()](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/writeffmpeg.c)
that we're always using 4 bytes per pixel. This is not true when using
QTRLE in RGB mode, because that uses the RGB24 pixel format (so 3 bytes
per pixel). Just updating the `linesize` property doesn't fix it though,
but just creates a crash somewhere else.
This at least fixes the crash by always forcing RGBA to be written, even
when the user selects RGB.
There are several aspects to the fix:
- Always calculate bounding box for meshes and curves from dependency
graph evaluation function.
There is a reason why mesh was tagged for geometry update, so can not
be spare here in attempts to avoid calculation.
- Copy bounding box and texture space to original object for active
dependency graph.
This matches object-level bounding box and allows to remove bounding
box evaluation from RNA.
As Usual...
Note that we have to edit each C-defined of those callbacks that set
Node->id pointer, instead of just moving the generic call to
`id_us_plus()` in `node_init()` below the call to
`ntype->initfunc_api()`, since that one manipulates RNA pointers, which
are supposed to already handle usercounts themselves on assignment.
The C callbacks are moving back to manipulating directly DNA, so it's
their responsability to handle user count then (Py code should do that
automatically through RNA assignement).
... instead of overiding it (previous behavior).
In practice it's not really noticeable.
This means an object with alpha will never be more opaque when enabling
xray.
