Outliner `do_item_rename` has checks so linked or overridden IDs cannot
be renamed.
A `TreeStoreElem`s ID can point to other data than "real" IDs though
(see how `outliner_add_element` casts to an ID from an arbitrary void
pointer and cases marked `/* NO ID */` in code). In those cases,
`ID_IS_LINKED` or `ID_IS_OVERRIDE_LIBRARY` _could_ return true and a the
renaming operation would fail.
Now also check if this is a real ID (`TSE_IS_REAL_ID`), so code can
continue.
Also add a proper notifier, so track renaming from the Outliner will
update the NLA immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/111110
Reason was a difference in poll functions (dropbox poll function vs.
operator poll function).
So the dropbox was actually recognized as being active (see
`dropbox_active`) but then when actually dropping, the corresponding
operator wasnt called (but instead another operator was).
In detail, the way `wm_handlers_do_intern` works, it checks all
dropboxes poll function if one succeeds it calls the dropbox operator.
But if that operators poll function fails, `wm_handlers_do_intern`
happily continues and "ends" the drop operations in a way we dont
actually get to the "real" dropbox & operator that was also recognized
as being active.
In the case of the report:
- dropbox for `UI_OT_drop_name` is active
- dropbox poll for `NODE_OT_add_object` (`node_object_drop_poll`)
succeeds though
- operator poll for `NODE_OT_add_object` (`node_add_object_poll`) fails
(it checks `UI_but_active_drop_name` already)
So in order to make this work, add the check for `UI_but_active_drop_name` to two dropbox poll
functions (and remove from the operator polls).
Probably good for LTS as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/110929
Some code attempted to use `BIFIconID` instead of `int` to pass around
icon-ids. Problem is, that this is just a subset of the allowed ids,
more icons may be created at runtime and extend the range of valid
icon-ids. Such icons could give runtime warning prints.
Idea is to use a `using BIFIconID = int;` instead. This way there is
still a descriptive type name, while the whole dynamic range of possible
icon-ids is supported.
Additionally multiple `using BIFIconID = int;` declarations are valid,
so we can place these in multiple headers and use the type name in APIs
instead of just `int`, whithout having to include a single header
defining them. A type mismatch (one instance differs from the others)
will result in a compiler error.
Pull Request: https://projects.blender.org/blender/blender/pulls/111052
Also semantically separate draw_lock and draw_unlock, as it
is more clear than a single method with a boolean argument.
Should be no functional changes.
This logic has not been working since 2014 [0] although it was briefly
fixed (by accident) when TARGETDIR_VER was made an absolute directory
[1] (since reverted as that caused problems with CPACK/WIN32).
"file(REMOVE_RECURSE ${TARGETDIR_VER})" would attempt to remove:
- "${CMAKE_BINARY_DIR}/${TARGETDIR_VER}" instead of
- "${CMAKE_INSTALL_PREFIX}/${TARGETDIR_VER}".
While this could be re-enabled by correcting the path,
it slows down the install target by copying files every "install".
This could be made to detect changes and only cleaning files in this
case however this ends up being fairly involved, see: PR !111084.
As stale files haven't been causing problems as far as I'm aware,
remove this code.
[0]: e43c5fa005
[1]: d605cc7574
Use the installed executable location instead of the build location,
this would work in situations when the build location had relevant
files accessible but this is often not the case.
This simple function just performed a null check and an array lookup.
Just writing it in the few places its used works fine too, and avoiding
the function call per triangle can improve and make the check clearer.
Also, avoiding the abstraction makes the "node fully visible" check
when building the PBVH more obvious; that has been refactored here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111072
The goal is to move to more data oriented design, reducing memory
usage and simplifying code by clarifying data access, avoiding
unnecessary levels of abstraction, and reusing code.
- Simplify threading with the C++ threading API
- Pass the faces to update with an IndexMask instead of a pointer array
- IndexMask uses less memory and simplifies masking and iteration
- Store the grid to face map with indices instead of pointers
- Now this is exactly the same as `build_loop_to_face_map`
Use the variable instead of "." for the install destination.
While they're equivalent, it's not discoverable where the value
for "." is set.
It also results in paths containing "/./", while valid isn't so nice
if the paths are copied from the terminal for use elsewhere.
After 12ef20990b, attributes and vertex group names were checked
simultaneously to fix the name collision. But this results in crash when
new attribute is added to curve object (it searches for vertex group
list). To avoid the crash, check for supported id types in new function
`BKE_id_supports_vertex_groups`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111036
Part 2 of the patch I wrote moving USD over to the new Attributes API
for Colors: https://projects.blender.org/blender/blender/pulls/105347
This patch adds support for more types of generic Mesh Attributes.
Attribute Types and Domains are converted to their USD counterparts
where possible. For example, float Attributes used for modifying
shader masks or int Attributes for grouping are now able to be
round-tripped. Due to the differences in the two systems some
conversions are necessary, but attempts were made to keep data
loss to a minimum.
If you export to USDA, you'll find the Attributes get prefixed with
a "primvars:" namespace; this is expected behavior and identifies
the exported Attributes as different from other USD Schema.
Not supported:
- Edge domain. There doesn't seem to be a proper conversion for
this in USD. One exception is for creasing and sharpness, but if
they are desired I can add them in a future patch.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/109518
The split face code relied a lot of the edges added to the weld context.
But with 113004687d, some edges are removed from context. And even more
edges can be removed (reducing loops and arrays).
Removing the dependence on edges decreases the array and time spent in
loops.
Furthermore, the corner edge array should not be needed for the
merge by distance operation.
So this commit redoes the face/loops iterator which previously
needed the `loop_next` member to skip loops depending on the previous
one (possibly linked to the edge whose vertex will be merged) and now
uses the `switch_to` member to switch loops instead of skipping and
depend on the former.
With the end goal of simplifying ownership and memory management,
and allowing the use of `get_name` in contexts without statically
allocated strings, use `std::string` for the return values of these two
operator type callbacks instead of `const char *` and `char *`.
In the meantime things get uglier in some places. I'd expect `std::string`
to be used more in the future elsewhere in Blender though.
Pull Request: https://projects.blender.org/blender/blender/pulls/110823
