| Age | Commit message (Collapse) | Author |
|---|
|
When hiding the curve handles/points previously, the control points would still be drawn (loose verts).
Now we hide everything related to the handle if it is hidden.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D4373
|
|
Now that we are looping over all image users that were previously ignored,
it shows some scene pointers are invalid. Always clear them on load, and
don't keep scene permanently in the image user except for the image editor.
Otherwise the pointer can go out of date.
|
|
This commit only contains some of the changes in the diff.
Some require more discussion/work.
Differential Revision: https://developer.blender.org/D4337
|
|
Do not instance linked object immediately in scene, this was never a
good idea and is doomed to fail nowadays, with complex relations between
objects, collections and scenes.
Instead, this commit refactors a bit linking code to add loose objects
to current scene *after* everything has been imported, and ID pointers
have been properly remapped to new ones - i.e. once new linked data is
supposed to be fully valid, just like we were already doing with
collections.
As a bonus, it means we do not have to pass around scene, view3d etc. to
`BLO_library_link_named_part_ex()` and co.
|
|
Was caused by the wrong de-initialization order, here is
an ASAN log just in case P916.
|
|
Viewport and scissor were never initialized prior to
window move/resize.
|
|
|
|
|
|
|
|
Illuminate dead code, using wmEventHandler_KeymapFn from gizmo handler
type where it was never set.
|
|
|
|
|
|
|
|
|
|
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.
|
|
The term 'eval' is often used by depsgraph result,
where this is just used for drawing.
|
|
When the first handle was hidden, all others would show as hidden too.
|
|
|
|
The term color is misleading, it's an integer id that happens to be
written to a color in some cases, then converted back to an integer.
|
|
Was confusing, unrelated to:
colbits, col_mask, col_group, actcol & totcol.
|
|
`deg_backup_object_runtime()`
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.
|
|
Now that bbox is in runtime, no need to explicitely clear it when we
call BKE_object_runtime_reset() two lines below.
|
|
`bpy.data.user_map()`
Would add undesired keys...
|
|
Would crash when passing some kind of invalid parameters, e.g.:
>>>D.user_map(key_types={'brush'})
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Original and localized particle settings were sharing some
of the runtime pointers.
|
|
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.
|
|
|
|
|
|
|
|
Some GPUs complain about `error C7011: implicit cast from "int" to "uint"` even if the cast is explicit.
|
|
|
|
The issue was caused by original f-curves being re-allocated
without informing dependency graph about this.
Was reported in T61636#622757
|
|
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).
|
|
|
|
|
|
This removes the overhead of rendering the object one more time.
|
|
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 is related to T61660, but actually does not fix that specific issue
(which is even worse - outside-of-Main ID using inside-of-Main IDs... yuck).
|
|
|
|
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.
|
