Currently it's effectively a boolean for file-select handlers.
Prepare for refactoring event handlers into their own types (keymap,
operator, gizmo, ui & dropbox) to help make logic easier to follow.
Committing this since it does fix broken logic (previously in that
condition obdata would always be set to NULL, since
`BKE_object_runtime_reset()` is called before).
However, this has presumably been broken that way since 05/2018, so
maybe that whole condition is not needed anymore? Or NULL pointer was
working as well here?
@sergey eyes are required here I guess ;)
Caused by rBae2b677dcb5a70f5, Object.runtime has lot of weird specific
handlings in depsgraph...
For now modified `deg_backup_object_runtime()` and
`deg_restore_object_runtime()` to mimic previous behavior regarding
Object bbox (i.e. pass it around, instead of wiping it clean).
Reported in T61660.
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.
The initial idea of using char pointer was to save some
memory since the dependency graph was kind of the one
with the main database.
Nowadays dependency graph should be separatable from the
main database and being self-sustainable.
Other issue which was caused by this pointer is the
re-tagging of operations during relations update: it is
possible to have node which as tagged for update but had
the owner of the name removed (i.e. driver or bone was
removed).
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.
Previously, hair strands of zero length of too few control
points would have been ignored. This is fine for a render
without motion blur. But once motion blur is enabled it is
becoming more tricky to match topology.
Even more, it was causing access (and possibly writes) past
the array boundaries in case when time step 0 ignored some
strands and steps around it did not.
If this is becoming problematic for BVH to do reliable
intersections this is to be solved on the BVH builder side.
The export from Blender to Cycles shouldn't really make
decisions there.
Was happening when image buffer had cryptomatte pass, which can easily
exceed 530 bytes used by the buffer.
Now default buffer is bumped to 1K, and also allowed to be heap-allocated
when really need bigger buffer.
Possible optimization is to allocate buffer once, but in practice those
re-allocations will not happen often, so keeping code simpler is not an
issue. Just something for a rainy day.
* Added a TL;DR first paragraph summarizing that one shall not keep any
reference to Blender data when modifying its container.
* Added some info about fact that adding items to some data containers
(like Collection) can also invalidate existing items (due to array
re-allocation).
* Added a Do/Don't example which shows a crash after adding some items
to a collection.
Related to T61297.
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.
