Changes to overlay_shader.cc workaround a bug in GCC-12.2
(likely a duplicate of [0]). As the workaround involved removing
a local variable which most functions already didn't assign,
remove it for all functions.
An alternative is to add (otherwise redundant) parenthesis, e.g.
`&(e_data.sh_data[sh_cfg])`, but this would need to be noted in
code-comments, so opt for removing the intermediate variable.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
This makes `GVArrayImpl` and `VArrayImpl` more similar.
Only passing the pointer instead of the span also increases
efficiency a little bit. The downside is that a few asserts had
to be removed as well. However, in practice the same asserts
are in place at a higher level as well (in `VArrayCommon`).
In most cases it is currently not used, so always having it there
causes unnecessary overhead. In my test file that causes
a 2 % performance improvement.
Previously, `ParamsBuilder` lazily allocated an array for an
output when it was unused, but the called multi-function
wanted to access it. Now, whether the multi-function supports
an output to be unused is part of the signature. This way, the
allocation can happen earlier when the parameters are build.
The benefit is that this makes all methods of `MFParams`
thread-safe again, removing the need for a mutex.
`std::get` could not be used due to restrictions on macos.
However, the minimum requirement has been lifted in
{rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
Currently you can retrieve a mutable array from a const CustomData.
That makes code unsafe since the compiler can't check for correctness
itself. Fix that by introducing a separate function to retrieve mutable
arrays from CustomData. The new functions have the `_for_write`
suffix that make the code's intention clearer.
Because it makes retrieving write access an explicit step, this change
also makes proper copy-on-write possible for attributes.
Notes:
- The previous "duplicate referenced layer" functions are redundant
with retrieving layers with write access
- The custom data functions that give a specific index only have
`for_write` to simplify the API
Differential Revision: https://developer.blender.org/D14140
Fixes bugs where UV islands with `mark seam` would tear at boundaries.
Modify seam_connected to search both it's edges instead of only one,
as this could fail if the edge was a seam or did not fan to the other loop.
Also fixes bug in `seam_connected_recursive`:
- `loop->prev == needle` changed to `loop == needle`
Maniphest Tasks: T103787
Reviewed By: Campbell Barton
Differential Revision: https://developer.blender.org/D16992
Test File: F14145477, F14137755, T79304
Avoid using components that can contain null pointer.
Getting attibute should avoid trying to do it for a null mesh.
This fix bypasses working with components.
Differential Revision: https://developer.blender.org/D16997
The crease custom data layer was added to a mutable version of the mesh,
but that wasn't used in the rest of the operation. Also the layer wasn't
retrieved properly with write access from the custom data API (fixed
separately as part of D14140). Also clean up a bit by retrieving
attributes from the mesh directly and by tweaking naming a bit.
Timecodes were generated from read packets, but applied to decoded
frames. This works as long as delay between packet read and decoded
frame is less than GOP size or if packet does not produce multiple
frames. In this case it did not work.
Use `pkt_pos`, `pkt_dts` and `pts` from `AVFrame` instead of `AVPacket`.
This way delay can be eliminated and timecode files are more reliable.
Effectively this disables two volume modifiers for the new curves
object and the point cloud object types. The aim is to simplify the
process of using these object types to prove out a node-group-based
workflow integrated with the asset browser. We're making the assumption
that these two modifiers were used very rarely on the new curves type
since that wasn't its purpose, so this breaks backwards compatibility.
Similar to the corresponding properties on node sockets, only adjust
the soft range. Because group nodes only have soft limits, groups
should generally be able to accept these inputs anyway. The benefit
of only using a soft range is that it allows choosing a more user-
friendly default range while keeping flexibility.
A proper boolean custom property type is commonly requested. This
commit simply adds a new `IDP_BOOLEAN` type that can be used for
boolean and boolean array custom properties. This can also be used
for exposing boolean node sockets in the geometry nodes modifier.
I've just extended the places existing IDProperty types are used, and
tested with the custom property edit operator and the python console.
Adding another IDProperty type is a straightforward extension of the
existing design.
Differential Revision: https://developer.blender.org/D12815
- `Interpolate Domain` -> `Evaluate on Domain`
- `Field at Index` -> `Evaluate at Index`
These names, discussed in recent geometry nodes submodule meetings,
describe actions rather than nouns, which is generally how nodes are
supposed to be named. The names are consistent, which is helpful
because they're similar conceptually. They also don't require knowledge
of the field concept, which we generally try to keep out of the UI in
favor of more beginner-friendly concepts.
We hope to add the ability to search for nodes with multiple
names for 3.5, so the old names can still have search items.
Caused by {rBd397ecae325}.
Above commit added a new socket, so
`version_geometry_nodes_primitive_uv_maps` was getting the wrong sockect
with `->next`.
Now get the right one with yet another `->next` (might not be ideal, but
searching the right socket with other methods might be overhead?)
Maniphest Tasks: T103837
Differential Revision: https://developer.blender.org/D16994
When idle, each 3D view made two calls CTX_data_mode_enum(C) from the
WM_main loop. While not causing problems it complicated troubleshooting
high CPU use while idle in other areas.
Access the object via the view layer, giving approx 40x speedup.
The new C++ OBJ importer was missing "split by objects" / "split by
groups" import settings of the older Python importer.
Implements T103839.
Added test coverage for all 4 possible combinations of these two
options.
This is caused by the partial derivatives not being precise enough to
take the tube shape into account. For now we just disable displacement
bump for this type of geometry to match cycles.
Fixes T101175 Eevee displacement behavior changed
In patch D16759 cleanup a else was removed by error which
deals with situations where current gpf was copied,
so that previous gpf may have MORE strokes than current gpf.
Reviewed By: antoniov
Differential Revision: https://developer.blender.org/D16986
Remove the unused function `pose_propagate_fcurve`
It was missed in D16771
Reviewed By: Jacques Lucke
Differential Revision: https://developer.blender.org/D16937
Ref: D16937
In case there is only 1 key on the FCurve,
the operator can run into a situation where it divides by 0.
It now skips the curve in that case
Reviewed by: Sybren A. Stüvel
Differential Revision: https://developer.blender.org/D16982
Ref: D16982
For some reason the Armature modifier in the Multi-Modifier mode
interpreted the vertex group in a way essentially opposite to the
regular mode. Moreover, this depended not on the Multi-Modifier
checkbox, but on whether the mode was actually active.
This fixes the flip and adds versioning code to patch old files.
One difficulty is that whether the Multi-Modifier flag is valid
can be different between the viewport and render. The versioning
code assumes any modifier enabled in either to be active.
This change is not forward compatible, so min version is also bumped.
Differential Revision: https://developer.blender.org/D16787
Replace the pointers in the MeshEdge with indexes, removing MeshPrimitive and MeshVertex.
Code cleanup proposed by the geometry nodes to make the data structures more reusable by
other areas of Blender as well. Old implementation was to focused to the texture painting.
Initial the idea was to do the same with the data structures in UVIslands, but there some
concerns were raised that requires a different design than expected from a clean-up patch.
Concerns raised about converting UVIslands:
* Maps between UVPrimitive, UVEdge and UVVertex will be stored inside the UVIsland.
During UVIsland extraction detected islands can be merged. When they are merged all
Indexes should be updated.
* It is not possible to pre-allocate all buffers as they grow, what will lead to more re-allocations. The current
implementation uses a VectorList to ensure that re-allocations don't require the data to be
moved to the newly allocated memory. We could store some information about last used
sizes in runtime data to reduce the re-allocation overhead.
* Solution would require index based access inside a VectorList, which might increase the
complexity.
* UVIslands during 3d texturing is used as intermediate data, the final data is stored as PackedPixelRows.
We could proceed converting UVIslands as well, but that would lower the performance noticeably.
3D texturing has performance requirements, so when doing so we should make sure that
it matches that as well.
Reviewed By: HooglyBoogly
Maniphest Tasks: T101740
Differential Revision: https://developer.blender.org/D16752
Added an extrude mode enum to the trim operators to
control extrusion: "project" and "fixed." "Fixed" just
extrudes along a fixed normal and is the new default.
