- Use 'BKE_object_material_*', 'BKE_id_material_*' prefix
for functions that operate on Object and ID types.
- Use '_len' suffix for length (matching BLI naming).
- Use '_p' suffix for functions that return a pointer to values
where the value would typically be returned.
Functions renamed:
- BKE_object_material_resize was BKE_material_resize_object
- BKE_object_material_remap was BKE_material_remap_object
- BKE_object_material_remap_calc was BKE_material_remap_object_calc
- BKE_object_material_array_p was BKE_object_material_array
- BKE_object_material_len_p was BKE_object_material_num
- BKE_id_material_array_p was BKE_id_material_array
- BKE_id_material_len_p was BKE_id_material_num
- BKE_id_material_resize was BKE_material_resize_id
- BKE_id_material_append was BKE_material_append_id
- BKE_id_material_pop was BKE_material_pop_id
- BKE_id_material_clear was BKE_material_clear_id
This commit adds bounding box support for emission objects - similarly to flow objects. Before, each effector object had to iterate over the entire domain. Bake times of scenes with multiple obstacles improved significantly with this optimization.
Other improvements that were implemented alongside the bbox feature:
- Option for subframe sampling for effector objects
- Option to enable / disable effectors (can be animated)
- Optimization for static objects. If a flow or effector object does not move and the adaptive domain is not in use, the bake time will be optimized further by reusing the flow / effector grids from the previous frame (no recalculation).
not work for unlocking
Special case for when we do this on "lock":
- locked sequences are not in "selected_editable_sequences"
- use "selected_sequences" in that case
Maniphest Tasks: T74434
Differential Revision: https://developer.blender.org/D7023
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
After switching tools, the active vertex can be the same and the cursor
won't update the previews, so the pose_ik_chain_preview will be null.
This often happens in low poly meshes where chances of hovering the same
vertex are high.
Reviewed By: sergey
Maniphest Tasks: T74426
Differential Revision: https://developer.blender.org/D7021
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
fails
Exposed by rB50d5c03e2d14.
This was only a problem when _only_ 'Object Data' was made local.
If also e.g. 'Object' or 'Materials' was checked, these were already
making sure realations were updated [DEG_relations_tag_update(bmain)].
Now also call DEG_relations_tag_update(bmain) for the 'Object Data'
case.
I assume the underlying issue is that there is some ID_NEW_REMAP
happening in 'single_obdata_users()' -- including that for 'me-
>texcomesh', which might be responsible for the glitches in selection/
editing? Also not entirely sure why this wasnt a problem prior to
rB50d5c03e2d14.(I assume this was somewhat hidden by the fact this was
always called with a default action being nothing, the user would always
need to access the redo panel. So this might have been hidden by an Undo
step involved?)
Maniphest Tasks: T73797
Differential Revision: https://developer.blender.org/D7020
This would happen when done from editmode, on a mesh with any modifier,
after adding/removing geometry in editmode.
Similar to rBba0870713b9b (which did this for weightpaint and sculpt
already), ensure an evaluated depsgraph, otherwise
'runtime.mesh_deform_eval' would not be up to date causing problems
later.
Maniphest Tasks: T72028
Differential Revision: https://developer.blender.org/D7011
This does not affect the RNA access API, since how the boolean is read from
DNA abstracted away in the API.
Differential Revision: https://developer.blender.org/D7002
USD is being included before the blender headers.
USD includes TBB, which includes the windows headers
which define rad2 as a constant conflicting with a field
with that exact name in the MetaElem dna struct.
Added `-DWIN32_LEAN_AND_MEAN` to keep the windows headers
from defining rad2.
It was missing this local space conversion before calculating the rake
angle.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7008
Metaballs are exported as evaluated polygonal mesh.
USDExporterContext::depsgraph was made non-const to allow calling
`BKE_mesh_new_from_object()`. The alternative was to make the depsgraph
parameter of that function const, but that would be too intrusive as
that would require even more functions to accept a const depsgraph
pointer.
Made an explicit call to the exec function be a blocking call and a call
from invoke (or otherwise) be nonblocking.
Reviewed By: Bastien
Differential Revision: http://developer.blender.org/D7006
Both partial derivatives were evaluated to 0 for a special vertex on
Suzanne model: this is happening on a vertex where two adjacent faces
with 2 common edges are connected (in the nose of Suzanne).
This was breaking multires in this point since tangent matrix is all
zeroes, and hence no displacement can be applied in that vertex.
into account for duplicating actions
Previously actions remained linked after duplication, now this is based
on the User Preferences (PreferencesEdit.use_duplicate_action).
note: default is ON here, so this changes default behavior of separate
operators.
First intuition was to respect _all_ preferences here (e.g. also
duplicating materials if chosen in the User Preferences) but after
consideration this is probably not what the User would expect from such
'modeling' opertions (e.g. separate by loose parts resulting in possibly
many duplicate materials)
Fixes T71038
Maniphest Tasks: T71038
Differential Revision: https://developer.blender.org/D6120
Object Scale was not taken into account.
This lead to reports like T74247 where the user scaled the envelope
distance and radii to the supposedly right values inthe viewport, but
these were actually 'wrong' under the hood. Assigning weights from bone
envelopes seemed like it would fail, but this code would actually take
the armature scaling into account when checking envelope distance and
weight.
ref T74247
Maniphest Tasks: T74247
Differential Revision: https://developer.blender.org/D6964
