| Age | Commit message (Collapse) | Author |
|---|
|
|
|
No functional changes.
|
|
This is basically done by ignoring override operations from old override
affecting ID pointer properties, when the new (destination) one is not
NULL.
Fix T86501: New object added to overridden collection doesn't show up in linking file on Resync.
This is more of a work-around actually, since there is no real way to
fix the issue in a fully automated and consistent way, it is caused by
older blender files being saved with 'broken' overrides.
WARNING: This cannot ensure that some purposedly edited/overridden ID
pointer properties won't be lost in the process.
|
|
Code would end up freeing some of the newly created overrides, which
were assigned to the matching linked ID's `newid` pointer, accessed
again further down the code.
Note that this is not a normal expected situation, and it won't give a
proper resync result anyway, but it might happen in some complicated
corner cases, and also quite often when dealing with older .blend files.
|
|
In some cases (advanced, low-level), we also want to remap pointers like
`ID.newid` or `ID.orig_id`.
Only known case currently is `id_delete`, to avoid leaving potential access to freed memory. See next commit and T86501.
|
|
In some cases (advanced, low-level code) we also want to process ID
pointers like `ID.newid` or `ID.orig_id`.
|
|
Baking to Vertex Colors would always bake to sculpt vertex colors (if
such a layer is present) even if those are not enabled in the
experimental preferences. This would bake without an error but leave the
user without a result to look in the viewport.
Now check if sculpt vertex colors are enabled and only bake to them in
that case.
Maniphest Tasks: T86455
Differential Revision: https://developer.blender.org/D10692
|
|
This is no longer needed for MSVC-2017.
|
|
While this happened to be corrected by code that runs afterwards,
leaving this in an invalid state could cause problems in the future.
|
|
- Add notes on portability.
- Use encoding argument for all file IO.
- Use integer math to calculate major/minor version, while float
division should be fine prefer matching Blender.
|
|
Also correct typo.
|
|
|
|
|
|
|
|
This type, CacheLookupResult, holds the data for the current time, or an
explanation as to why no data is available (already loaded, or simply
nothing available). This is useful to document the behavior of the code
but also, in future changes, to respond appropriately for missing data.
|
|
Inside of the procedural, instances are AlembicObjects which point to
the AlembicObject that they instance.
In Alembic, an instance is an untyped Object pointing to the original
(instanced) one through its source path. During the archive traversal we
detect such instances and, only if the instanced object is asked to be
rendered, set the instance's AlembicObject to point to the original's
AlembicObject.
Cycles Object Nodes are created for each AlembicObject, but only for
non-instances are Geometries created, which are then shared between
Object Nodes. It is supposed, and expected, that all instances share the
same shaders, which will be set to be the ones found on the original
object.
As for caching, the data cache for an AlembicObject is only valid for
non-instances and should not be read to or from as it is implicitly
shared.
|
|
This will help support instancing as cache building is now decoupled
from the logic to update the Nodes' sockets as data (and cache) will
need to be shared by different Geometries somehow, and also simplify
implementing different data caching methods by centralizing this
operation.
|
|
We need to explicitely tag the Attribute and AttributeSet as modified if
we change or add/remove data. This is more of a bandaid until attributes
handling is refactored to be able to reuse routines from the Attribute
API.
|
|
|
|
This can happen during user edits or with files missing the global scale
property.
|
|
Nodes: Add Attribute Remove Node D10697
|
|
This patch adds a node, that removes an attribute if possible,
otherwise it adds an error message.
Differential Revision: https://developer.blender.org/D10697
|
|
|
|
|
|
|
|
This patch fixes a visual bug related to connecting an output socket to
a Multi-Input Socket, that already has a link to that same output.
In this case, the drag link got a new index and snapped to a new
position. This path makes the drag link snap to the same position as the
first link between the two sockets.
Differential Revision: https://developer.blender.org/D10689
|
|
Caused by 46aa70cb486d.
RNA would send property update notifiers with the owner ID as `reference` data.
Since above's commit we'd only send the notifiers to editors if the reference
data address matches the space's address. So editors wouldn't get the notifiers
at all.
The owner ID for space properties is always the screen AFAIK. So allow
notifiers with the screen as reference to be passed to editors as well, think
this is reasonable to do either way.
For example, steps to reproduce were:
* Open Asset Browser
* Mark some data-blocks of different types as assets (e.g. object & its
material)
* Switch between the categories in the Asset Browser. The asset list wouldn't
be updated.
|
|
No functional changes.
|
|
This limitation was necessary in older versions, but now can be removed.
|
|
|
|
When adding a notifier, `reference` data can be passed. The notifier system
uses this to filter out listeners, for example if data of a scene changes,
windows showing a different scene won't get the notifiers sent to their
listeners.
For the `NC_SPACE` notifiers, a number of places also passed the space as
`reference`, but that wasn't used at all. The notifier would still be sent to
all listeners in all windows (and the listeners didn't use it either). Causing
some unnecessary updates (e.g. see ed2c4825d3e2344).
With this commit, passing a space will make sure the notifier is only sent to
that exact space. Some code seems to already have expected that to be the case.
However there were some cases that passed the space as `reference` without
reason, which would break with this commit (meaning they wouldn't redraw or
update correctly).
Corrected these so they don't pass the space anymore.
|
|
Steps to reproduce were:
* Open an Asset Browser
* "Mark Asset" on some data-block
* Change the Asset Browser into a different editor (not File Browser!)
* "Clear Asset" on the data-block again, or mark another asset
* Change back to the Asset Browser, it will show an outdated list
Now the file-browser reloads local file data after spaces were changed. Note
that the current notifier code doesn't limit the space-change notifiers to the
affected spaces, so changing any visible space will trigger this. That's an
issue to be fixed separately.
|
|
In some situations the strokes could be tagged before filling, so it's necessary to reset before.
|
|
The check for undo-depth increment/decrement assumed a newly loaded
window manager would have a different pointer.
This broke bl_animation_fcurves test indirectly,
the change to undo-depth caused the redo panel to attempt to popup
in background mode - which isn't supported.
Now the pointer is unchanged, the undo-depth is assumed to match
the value used when calling the operator.
The undo-depth is now properly maintained between file loads,
which is an improvement on the original behavior which reset it.
|
|
Differential Revision: https://developer.blender.org/D10694
|
|
It turns out that on official arm64 devices (not DevKit) the linker
warnings still show up. So just leaving this as is.
Ref D9002
|
|
|
|
Keep the pointer location from the initial window-manager
between file load operations.
This is needed as the Python API may hold references to keymaps for e.g.
which are transferred to the newly loaded window manager,
without their `PointerRNA.owner_id` fields being updated.
Since there is only ever one window manager, keep the memory at the same location so the Python ID pointers stay valid.
Reviewed By: mont29
Ref D10690
|
|
Previously many operations would run on file load, even if the file
did not load. Pre/post load handlers were called, timers canceled,
all undo data freed, editors exited ... etc.
Now keep the blend file in it's current state.
This simplifies updating this area of code as there is one less
possible situation to account for.
|
|
Currently file loading performs almost all reloading logic
even in the case loading the file fails, causing the file to be in
a state that isn't well defined: undo is cleared, timers are canceled &
scripts are re-registered.
|
|
- Don't set G.relbase_valid until the file is loaded.
- Remove unnecessary string pointer comparison.
- Remove unused filename being passed to 'setup_app_data'.
|
|
|
|
Part of T83811 & D10649.
|
|
`BKE_lib_override_library_main_resync` uses
`LIB_TAG_LIB_OVERRIDE_NEED_RESYNC` tags set by RNA override apply code,
and perform detection for the remaining cases (those were new overrides
need to be created for data that was not present before in the library).
And then it actually resync all needed local overrides.
Part of T83811 & D10649.
|
|
We can fairly easily detect some resync-needed cases when applying the
overrides operations on a Pointer RNA property.
This should cover all cases where an existing override's ID pointer is
changed in its linked data.
We still have to add code to detect when a not-yet-overridden linked ID
needs to become overridden (because its relations to other data-blocks
changed in a way that requires it).
Part of T83811 & D10649.
|
|
user-edited.
Ultimately those will be listed with a special icon in the upcomming
Outliner overrides view.
Part of T83811 & D10649.
|
|
Part of T83811 & D10649.
|
|
This patch changes the `MEM_DEVICE_ONLY` type to only allocate on the device and fail if
that is not possible anymore because out-of-memory (since OptiX acceleration structures may
not be allocated in host memory). It also fixes high peak memory usage during OptiX
acceleration structure building.
Reviewed By: brecht
Maniphest Tasks: T85985
Differential Revision: https://developer.blender.org/D10535
|
|
Explains how we can get rid of implicit assumptions and `void *`
arguments/storage in the future.
|
|
Rather than letting the `TreeElementAnimData` constructor take an ID from which
we get the animation-data based on an assumption on how it's stored, let the
constructor take the animation-data directly. That way we further centralize
the assumptions on the data passed to the element creation to
`tree_element_create()`.
The following commit will add a comment explaining the plan to entirely get rid
of those assumptions in the future.
|
