* Fixed crash in debug draw code. Apparently this is
only used by PBVH draw?
* Debug draw code can now be forcibly enabled in release
mode (i.e. RelWithDebugInfo) by uncommenting a commented
out #define.
* Fixed colors in debug draw mode.
* PBVH node boxes in debug mode now flash a different color
when they are updated.
In complex scenes featuring thousands of connections between IDs in
their liboverride hierarchies (e.g. Heist files), the time required to
check if tree items were available (before allocated a new one) would
become insanely long (O(n^2)).
This commit brings it back to roughly a constant time, only re-checking
the whole array for unused items once in a while (once every 10k times
currently), since in almost all cases is the index after `lastused`
value is not unused, and you have reached the end of the currently used
array of items, you actually need to 'allocate' a new one anyway.
It also improves the handling of `lastused` index, in particular in
`tse_group_add_element`.
This makes switching to the Outliner override hierarchy view in Heist
scenes from virtually infinite time (more than 30mins for sure) to about
20 seconds on my machine. Still far from being effectively usable.
Note that this is only a bandaid fix anyway, root of the issue is that
this view has to deal with way too many items in its tree, current code
is not designed for that. Either outliner has to improve its tree
handling (by only building subsets of the whole tree maybe?), or we have
to cull/filter out some of the ID relationships between overridden IDs
to make this view actually usable. Maybe limit the depth of the tree?
In some cases, there is a chance code already knows who might be the
owner of the given ID, in which case it can be more efficient to check
it first (especially in cases like embedded node trees or scene
collections, where the only other way is to loop over all possible
owners currently).
Will be used in next commit in some Outliner fix.
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. The `.` prefix
means they are "UI attributes", so they still contain original data
edited by users, but they aren't meant to be accessed procedurally by
the user in arbitrary situations. They are also be hidden in the
spreadsheet and the attribute list by default,
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
The fix from c0fdf16561 was missing in one place. We don't
want to free the edit mode pointers, those are just copied because the
edit mode changes aren't present in the actual original data-block.
The fix from c0fdf16561 was missing in one place. We don't
want to free the edit mode pointers, those are just copied because the
edit mode changes aren't present in the actual original data-block.
Always use the image datablock filepath for saving. The only apparent reason
use the image buffer file path is image sequences, for which the current frame
filepath is now computed.
In {rB0ef8a6179d2a773b2570352bd0cb7eb18b666da2} the parameter name was
changed to match the header declaration (slot) but it missed updating
the variable name inside the function correctly in one instance.
This prevents slot 0 from being cleared if the last slot to be rendered
was not also 0.
Differential Revision: https://developer.blender.org/D15620
After recent refactors to mesh normals (cfa53e0fbe), they are no
longer stored in CustomData. A mechanism to compute them eagerly
should be implemented another way.
- batch rename
- keyframe settings
- tool name in Tool properties header
- tool name in Tool properties Drag (fake) enum
- new file templates
- new preset
- new text datablock
- new collection datablock
- new geometry nodes (modifier and node group)
- new grease pencil data (layers and materials)
Ref. T43295
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15533
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
This changes makes it possible to copy evaluated result and put it
to the original bmain.
Prior to this change from the API point of view there was false
perception that it is possible, while in practice it was very fragile:
it only worked if the ID did not reference any evaluated IDs.
This change makes it so `id.copy()` Python API call will make it so
the copied ID only references original data-blocks. This sounds a bit
implicit, so here is motivational aspect why it is considered better
approach to all other:
- There needs to be a way to support the described scenario, in the
lest fragile way. Requiring to always use an explicit function call
or an argument is too verbose and is easy to be missed.
- The `id.copy()` is already doing implicit thing: it always adds the
result to the bmain. So it might as well ensure the copied result
does not reference evaluated data-blocks.
- Added clarity in the documentation should address possible confusion.
The limitation of this change is that the copy() of evaluated geometry
will clear its reference to the shape key. This is because the key is
only referenced for validness of RNA paths for drivers and the key
itself might not match topology of evaluated geometry due to modifiers.
Differential Revision: https://developer.blender.org/D15611
