Regression from 9e0b673467.
Not sure why the extra undo step is required after changing active object
(maybe because the mode switching to Sculpt mode of the new object
generates a 'Sculpt' undo step and not a 'Global' one?).
Pull Request: https://projects.blender.org/blender/blender/pulls/130472
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
This adds a `write_bhead` utility function and also reduces the scope of
some `BHead` variables. The separate `write_bhead` function was quite
useful for #129751 and will likely be useful in a potential separate
implementation too.
Pull Request: https://projects.blender.org/blender/blender/pulls/130457
This is to make sure duplicate libomp/libiomp5 runtime conflicts are
detected as soon as a second runtime is initialized. Otherwise, it may
not crash until Blender's OpenMP runtime is initialized by a feature
that uses it, making such issues possibly go unnoticed. Such a conflict
can happen when an add-on has a native module that uses OpenMP and links
to a different libomp runtime, as was the case in #125255.
Currently Blender only ships with libomp on MacOS.
---
When libomp detects such an issue it should abort and print the following message:
```
OMP: Error #15: Initializing libomp.a, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/130407
The bug occurred when the user changed the camera of the scene.
The lineart modifier was not updating when changing the camera, but only
when changing other elements in the scene or moving the camera.
This is resolved by adding a depsgraph update for scene parameters, such
as when changing the camera.
Testing:
Add two cameras, add a Grease Pencil Collection Line Art, go into camera
perspective view and then switch to the other camera.
The Grease Pencil Line Art now updates automatically.
Co-authored-by: YimingWu <chengdulittlea@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/129935
CMake 3.31+ have begun emitting warnings when you feed install()
paths that are not normalized (ie have, '.' or '..' in them) easiest
fix is just not use them.
This cleans up the windows sections of the build system, the other
platform devs will have to take a look on their respective platforms.
Adds the option `merge_parent_xform` to the USD export operator and
panels so the transform and shapes are merged into a single USD Prim.
Without the option (existing default), a top-level mesh would be
exported as a top-level `Xform` that has a `Mesh` child:
```
def Xform "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
def Mesh "MyBlenderMeshData"
{
}
}
```
This matches the Blender data model, where a transformable object
contains a geometric shape (like a mesh). This structure is also very
valid in USD, where we don't want to directly instantiate geometric
primitives[1]
However, "since number of prims on a stage is one of the primary factors
that governs how USD scale"[2], to reduce the number of prims in a
stage, geometric primitives *are transformable* themselves (see the
inheritence diagram[3]).
As such, the new export option allows to export geometric primitives
without the parent transform:
```
def Mesh "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
}
```
This MR adds a the `is_object_data_context` flag to the
`HierarchyContext` context structure. The point of this change is to
make unambiguous in `USDHierarchyIterator::create_usd_export_context`
the fact that an `object` or a `data` is currently being exported: the
new `merge_parent_xform` option is meaningless for `object`. Only `data`
can be exported with a parent `Xform` or as a child of said `Xform`.
Ideally this flag would not be needed at all: the final USD prim path
*could* be computed in an override of the virtual
`AbstractHierarchyIterator::get_object_data_path` method. However, this
would mean that an `object` and a `data` would have the same export path.
This does not currently play well with
`AbstractHierarchyIterator::ensure_writer`, where `writers` are cached
*by their export path*: it would cache a transform writer, but will skip
the subsequent data writer.
Additionally, another new `is_parent` flag is added to handle the case
where merging the Xform is invalid: objects that are parents to other
objects should remain unmerged as otherwise that would yield invalid USD
files.
[1] https://openusd.org/release/glossary.html#usdglossary-gprim
[2] https://openusd.org/release/glossary.html#usdglossary-instancing
[3] https://openusd.org/release/api/class_usd_geom_xformable.html
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
The selection framebuffer can be very small which leads
to different pixel density than the regular viewport.
Under this circumstance, gl_PointSize is a multiplier
of the viewport size in terms of selection radius.
Make sure `gl_PointSize` is set to 1 for selection.
Code used to only report the number of explicitely copied objects (i.e.
the selected ones), while some dependency objects (e.g. parents) would
also be copied, and included in the reported number of pasted objects.
When everything is selected, the `.selection` attribute is removed as
an optimization. In `ed::greasepencil::selection_update` for
`SEL_OP_SET` and `SEL_OP_AND`, the current selection needs to
be set to `false`. The issue is that the code checked if the attribute
exists, but does nothing when it doesn't.
The fix ensures that the attribute is created and filled with `false`.
Pull Request: https://projects.blender.org/blender/blender/pulls/130522
Dynamic rendering is a Vulkan 1.3 feature. Most platforms have support
for them, but there are several legacy platforms that don't support dynamic
rendering or have driver bugs that don't allow us to use it.
This change will make dynamic rendering optional allowing legacy
platforms to use Vulkan.
**Limitations**
`GPU_LOADACTION_CLEAR` is implemented as clear attachments.
Render passes do support load clear, but adding support to it would
add complexity as it required multiple pipeline variations to support
suspend/resume rendering. It isn't clear when which variation should
be used what lead to compiling to many pipelines and branches in the
codebase. Using clear attachments doesn't require the complexity
for what is expected to be only used by platforms not supported by
the GPU vendors.
Subpass inputs and dual source blending are not supported as
Subpass inputs can alter the exact binding location of attachments.
Fixing this would add code complexity that is not used.
Ref: #129063
**Current state**
Pull Request: https://projects.blender.org/blender/blender/pulls/129062
`grease_pencil_edit_batch_ensure` will not create a valid batch when
there's no visible edit geometries (e.g. Current frame is before any of
the GPv3 key frames), this would lead to GPv3 passes drawing an empty
batch. This fix prevent empty edit batch from being put in the pass
drawing command list.
Pull Request: https://projects.blender.org/blender/blender/pulls/130493
This adds support for constructing a `Map` directly from key-value-pairs.
If the same key exists multiple times, only the first one is taken into account.
Note: the keys and values are copied into the map (not moved). This is because
an `std::initializer_list` is read-only. If move-behavior is needed, it is better to
use the existing `map.add*` functions.
```cpp
Map<int, std::string> map = {{1, "where"}, {3, "when"}, {5, "why"}};
````
Pull Request: https://projects.blender.org/blender/blender/pulls/130470
There is not really a good definition for what an "attribute kind". There are
many possibilities, it could include domain, type, geometry type, default value,
usage, ...
So it's better not to use this generic name. With the current name, one always
has to look at the definition again to be sure what it contains and what it does
not.
The name `AttributeDomainAndType` is way more explicit and does not have the
same problems. It's a bit longer, but that does not seem to be a problem in the
places where we use it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130505
Previously, the attribute accessor were defined in the `geometry_component_*.cc`
files. This made sense back in the day, because this attribute API was only used
through `GeometryComponent`. However, nowadays this attribute API is independent
of `GeometryComponent`. E.g. one can use `mesh.attributes()` without ever
creating a component.
The refactor contains the following changes:
* Move attribute accessors to separate files for each geometry type. E.g. from
`geometry_component_mesh.cc` to `mesh_attributes.cc`.
* Move implementations of e.g. `Mesh::attributes()` to `mesh.cc`.
* Provide access to the `AttributeAccessorFunctions` without actually having a
geometry. This will be useful to e.g. implement
`attribute_is_builtin_on_component_type` without dummy components.
Pull Request: https://projects.blender.org/blender/blender/pulls/130516
In multiple parts (framebuffer and shader) the render areas/viewport could be
copied in an array of 16 structs, when only one is needed. This PR will use builder
patters so we don't over-allocate. Would spend less CPU cycles when constructing
render info, render passes/framebuffers, shaders.
Cleanup was part of !129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130515
Shader interface used shader create info bind types to communicate bind
types to descriptor sets. However Vulkan supports more bind types than
Blender exposes in its API. Current implementation resulted that next to
the bind type the actual resource was queried to find out what needed to
be done.
This PR makes it more clear to convert the shader create info bind type
to `VKBindType` that contains the vulkan bind types we support.
Pull Request: https://projects.blender.org/blender/blender/pulls/130509
OpenGL & Vulkan has workarounds when gl_Layer/gl_ViewportIndex isn't
supported. In this case a geometry shader will is generated. This
geometry shader doesn't follow the GLSL standard and doesn't work on
some platforms. This has not been an issue as the platforms that
don't support gl_Layer/gl_ViewportIndex don't show the issue.
According to the specs gl_Layer and gl_ViewportIndex should be set for
each call to EmitVertex. A shader should not rely on that EmitVertex
reuses the same memory.
Ref https://www.khronos.org/opengl/wiki/Geometry_Shader#Layered_rendering
```
Warning: gl_Layer and gl_ViewportIndex are GS output variables. As such, every time
you call EmitVertex, their values will become undefined. Therefore, you must set
these variables every time you loop over outputs.
```
Issue detected during development of !129062
Pull Request: https://projects.blender.org/blender/blender/pulls/130506
The `add_layers_with_empty_drawings_for_eval` function incremented the
user count of the drawings twice because `add_empty_drawings` creates
drawings with one user.
Pull Request: https://projects.blender.org/blender/blender/pulls/130514
Cleanup to simplify code by using common terms like _first_ and _last_ in context
of predicate applying in a range just like we do for spans and range containers.
Pull Request: https://projects.blender.org/blender/blender/pulls/130380
Looks like the initial version of this struct was copied from Alembic.
Remove the fields that were never ultimately used and initialize the
remaining fields inline.
Pull Request: https://projects.blender.org/blender/blender/pulls/130492
GPv3 build modifier in "Nature Drawing Speed" mode didn't finish
building a frame when the time it took to draw those strokes by hand is
greater than the frame duration. Previous fix#129894 is only effective
for "Number of Frames" build mode. This fix moved the timing scaling
into `get_build_factor` and `get_factor_from_draw_speed` for more
granulated control in different modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130199
This member was only really used by `transform_convert_object.cc` and
`transform_convert_object_texspace.cc`.
So instead of using a super-specialized member, use `TransData::extra`
instead.
