Clear delta transform value after applying transform.
Include delta location while applying transform.
Use `copy_v3_fl` for resetting object scale
Reviewed By: mano-wii
Maniphest Tasks: T99070
Differential Revision: https://developer.blender.org/D15270
This patch makes constant size a default for size edit operator of voxel remesh.
In turn, pressing CTRL now enables relative scale, the old default.
Patch also changes workspace status text entry with new additions. Note that it is a simple text and not an array of keymaps (for that further changes are needed)
{F13082567}
Reviewed By: Julien Kaspar & Joseph Eagar
Differential Revision: https://developer.blender.org/D14975
Ref D14975
Baking assumed that color attributes could only have two configurations:
float color data type on vertices, or byte color type on face corners.
In reality the options can be combined to make four total options.
This commit handles the four cases explicitly with a somewhat
more scaleable approach (though this should really be C++ code).
This commit also changes some related error messages, tooltips,
and an enum name, in order to make the functionality more obvious.
Differential Revision: https://developer.blender.org/D15244
This commit:
* Removes the popup to choose the root collection when called with a
linked object selected (in typical cases there is only one valid
option, if more then the operator fails and report to the user).
* Ensures that the linked reference of newly overridden collections are
also removed from the ViewLayer (i.e. their local parent collections).
Introduces an option for BKE_unit_value_as_string to skip stripping of zeroes, thus reducing flickering when using edit voxel size widget.
{F13125416}
Reviewed By: Julien Kaspar & Joseph Eagar
Differential Revision: https://developer.blender.org/D15085
Ref D15085
This implements the new way to attach curves to a mesh surface using
a uv map (based on the recent discussion in T95776).
The curves data block now not only stores a reference to the surface object
but also a name of a uv map on that object. Having a uv map is optional
for most operations, but it will be required later for animation (when the
curves are supposed to be deformed based on deformation of the surface).
The "Empty Hair" operator in the Add menu sets the uv map name automatically
if possible. It's possible to start working without a uv map and to attach the
curves to a uv map later on. It's also possible to reattach the curves to a new
uv map using the "Curves > Snap to Nearest Surface" operator in curves sculpt
mode.
Note, the implementation to do the reverse lookup from uv to a position on the
surface is trivial and inefficient now. A more efficient data structure will be
implemented separately soon.
Differential Revision: https://developer.blender.org/D15125
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
In the editmode sidebar, pasting a particular vertex's weight in a
single group was not behaving the same as copying for all groups [in
that the former dis not copy to unassigned vertices whereas the later
did copy to unassigned vertices].
This behaves like this since the introduction in {rB70fd2320c8d2}, but
there does not seem to be a good reason for this?
Now make this consistent and use `BKE_defvert_copy_index` in both cases
(instead of earlying out if unassigned, this will make sure this will
also copy to unassigned).
Maniphest Tasks: T98459
Differential Revision: https://developer.blender.org/D15062
The problem was that copying a `CDDerivedMesh` (`CDDM_copy`) doesn't
copy the `vert_normals` reference that it takes from a mesh. Since this
entire area is almost completely broken anyway (mainly in terms of
ownership handling), for now we can just avoid copying the `DerivedMesh`
in the zero levels case.
Longer term, this area should be refactored to remove `DerivedMesh`
and use the newer subdivision evaluation system.
Differential Revision: https://developer.blender.org/D15099
Add `bpy.app.is_job_running(job_type)` as high-level indicator. Job
types currently exposed are `WM_JOB_TYPE_RENDER`,
`WM_JOB_TYPE_RENDER_PREVIEW`, and `WM_JOB_TYPE_OBJECT_BAKE`, as strings
with the `WM_JOB_TYPE_` prefix removed. The functions can be polled by
Python code to determine whether such background work is still ongoing
or not.
Furthermore, new app handles are added for
`object_bake_{pre,complete,canceled}`, which are called respectively
before an object baking job starts, completes sucessfully, and stops due
to a cancellation.
Motivation: There are various cases where Python can trigger the
execution of a background job, without getting notification that that
background job is done. As a result, it's hard to do things like
cleanups, or auto-quitting Blender after the work is done.
The approach in this commit can easily be extended with other job types,
when the need arises. The rendering of asset previews is one that's
likely to be added sooner than later, as there have already been
requests about this.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D14587
Crash happened because code could not find a valid base in current scene
after adding the object, added some checks for that.
Root of the issue was wrong assumptions in `BKE_object_add` logic, which
would pick the first valid ancestor collection in case initially
selected collection was not editable. In some case, this could pick a
collection not instanced in the current scene's view layer, leading to
not getting a valid base for the newly added object.
Addressed this by adding a new variant of `BKE_collection_object_add`,
`BKE_collection_viewlayer_object_add`, which ensures final collection is
in given viewlayer.
The operator assumed it was called on a mesh object, which has
mostly been the case because of lack of support for other object
types, but the new curves object is supported, which is the situation
in the report.
Differential Revision: https://developer.blender.org/D15063
Add the following macros for enums as support for these features wasn't
all that obvious and there were some inconsistencies in their use.
- RNA_ENUM_ITEM_HEADING(name, description)
- RNA_ENUM_ITEM_SEPR
- RNA_ENUM_ITEM_SEPR_COLUMN
Dropping would pass the name of the ID to drop to the properties of the
drop operator. This would then lookup the ID by name. With linking
and/or library overrides, multiple IDs of the same name and type may
exist, which is why the session UUID should be used instead. All
operators used for dropping support this now and the drop code passes
the session UUID instead of the name.
Also see 917c096be6 and 8f79fa9c67.
Some drop operators were already using the session UUIDs. This converts
the remaining ones. The "name" property is kept working as before, since
some scripts use this.
Side-effect: The "Name" property won't show up in the Adjust Last
Operation anymore, which was the case for some of these operators, and
its value won't be remembered over multiple executions of the operator.
Both were not at all useful from what I can tell, and I doubt this was
done intentionally.
There are now some generalized helpers for passing IDs from drag & drop
to operators via operator properties, mostly introduced in 917c096be6
and 8f79fa9c67. These can be used in a bunch of places to reduce
duplicated code and explicitly share a common solution.
Side-effect: The "Name" property won't show up in the Adjust Last
Operation anymore, and its value won't be remembered over multiple
executions of the operator. Both were not at all useful from what I can
tell, and I doubt this was done intentionally.
8f79fa9c67 was an attempt to fix this already, but it didn't quite
work. Problem was that the tooltip was messing with the drop-box and
operator properties, setting the name property for its own internal
logic. This name property would then be used rather than the session
UUID to query the material, which gave the wrong material (linking can
result in multiple IDs of the same type with the same name). A followup
commit will further sanitize this.
More and more of the drop operations are being switched to use the ID's
session UUID rather than the name, but the cleanup after a drop operator
was cancelled assumed they would set the name. They will now first
attempt to use the session UUID and fallback to the name if needed.
Add notifier such that the Motion Paths panel in the Object Properties tab
gets redrawn, after using the Create Motion Path button.
The reason it didn't update was that the button actually triggers a popup,
and then executes in the context of that popup. It now actually emits a
`ND_DRAW_ANIMVIZ` notifier, and ensures that the panel redraws on that.
917c096be6 applied to objects only, this also applies the same fix for
the general 3D View drop operations, e.g. used for dragging materials,
images, worlds, etc.
This is needed to fix T95706, but apparently something else is still
going on. Needs further investigation.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
Avoids having to manually enable data-blocks for user-edition when you
do not care about what should be edited by whom. Similar to default
behavior before introduction of system overrides (aka non-user-editable
overrides).
Existing code for the `Move` operator, and some `Collections` panel
operations (Object properties) was absolutely not override-safe, and
sometimes not even linked-data safe.
Inherited from older versions of the code, not needed anymore in most
common cases (like making override from a local empty instantiating a
collection, or if the active object is directly overridable).
Knowing when layers are retrieved for write access will be essential
when adding proper copy-on-write support. This commit makes that
clearer by adding `const` where the retrieved data is not modified.
Ref T95842
Add a property to the **Shade Smooth** operator to quickly enable the Mesh `use_auto_smooth` option.
The `Angle` property is exposed in the **Adjust Last Operation** panel to make it easy to tweak on multiple objects without having to go to the Properties editor.
The operator is exposed in the `Object` menu and `Object Context Menu`.
=== Demo ===
{F13066173, size=full}
Regarding the implementation, there are multiple ways to go about this (like making a whole new operator altogether), but I think a property is the cleanest/simplest.
I imagine there are simpler ways to achieve this without duplicating the `use_auto_smooth` property in the operator itself (getting it from the Mesh props?), but I couldn't find other operators doing something similar.
Reviewed By: #modeling, mont29
Differential Revision: https://developer.blender.org/D14894
