The dependency graph now handles updating image users to point to the current
frame, and tags images to be refreshed on the GPU. The image editor user is
still updated outside of the dependency graph.
We still do not support multiple image users using a different current frame
in the same image, same as 2.7. This may require adding a GPU image texture
cache to keep memory usage under control. Things like rendering an animation
while the viewport stays fixed at the current frame works though.
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.
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.
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.
