Patch by @sergey.
Note that this is really a bad thing actually, ideally we should never
get that situation (IDs in Main referencing temp IDs outside of it).
That can lead to many possible similar cases...
Fixing that is not trivial though, so for now we'll have to live with
it, until we have migrated *all* of our temp datablocks generation
outside of Main's.
This introduce the wireframe batches. Creating the indices buffer does
not seems to slow down the sculpt in my testing (but it is kind of hard to
test reliably)
This includes a bit of cleanup in gpu_buffers.c.
- Makes it possible to show a vertical line for every marker in the graph editor.
- Makes the marker line visiblity optional in the sequencer and graph editor.
Request from @hjalti.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4348
This affects point, spot and area lights. Sun light strength remains without
a unit. This change does not affect .blend file compatibility in any way, as
with the rest of the unit system it's purely a display and editing feature.
Not used for Cycles yet, that will be done after unifying the settings with
Eevee.
At some I unified the "move to collection" with the remove from all collections
functionality. That meant that even when we were still to keep the object in one
of the collections we would clear its rigid body data.
Now why to even remove the rigidbody data when removing an object from all
collections? That mimics the 2.79 behaviour when we were to unlink an
object from a scene. I suspect it has to do with the rigid body data
being tied to the scene rigid body. Which is a strange design anyways
(add to the list?) since an object can be in more than one scene.
This was caused by curves pointing to each other
creating a cyclic dependency.
While the dependency graph detects this, generating a mesh for render
recursively generates data which cashes in this case.
Add in a check to detect cyclic links.
Note, this bug exists in 2.7x too - but only crashes on render
since 2.7x didn't use 'for_render' when converting data.
Usual legacy/history crap in NodeTree code... Datablocks's specific
freeing code should never, ever do refcounting management, this is
handled by higher-level code from BKE_library area.
Nuke away old nodeCopyNode(), much better to use new BKE_node_copy_ex(),
which behaves as expected for the various optional flags that can be passed.
This also removes the need to handle ID refcounting in calling code
(ugly!) and allows us to remove an even uglier name from our codebase! :D
Note that this fixes three related issues actually, that bug was also
affecting copy/paste of nodes, and 'Separate with copy' operator (the
latter being actually fully wrong, since it was not refcounting
anything, not even node->id pointer...).
More or less same code was being executed twice during ID copying.
Makes no sense to add yet another switch-by-ID-type to handle
specificaly runtime data during ID copying, we already have
BKE_xxx_copy_data() functions for that.
Using ID_LIGHT or ID_ID for "Lamp" meaning, "Light" without context
being for 'not heavy'.
That rename of data-block was not really nice on that side of things :/
Related to T43295.
It is supposed to be already evaluated. If for some reason it's not
doing such direct evaluation will not be reliable anyway (indirect
dependencies for example).
This fixes an assert part of T61431.
`BKE_modifier_get_evaluated_mesh_from_evaluated_object()` used by
modifiers needing access to other objects' geometry probably skipped out
of the radar when cage and final evaluated meshes were added to
BMEditMesh? In any case, we do not need to duplicate (and then free!) a
temp mesh from editdata anymore, and we can even add instead a parameter
to get cage instead of final. Also makes modifiers code a bit simpler.
We may want to use 'TEST' BCode in the future for including data
besides thumbnails. This allows negative values to be used w/o
attempting to load a thumbnail.
