A few places already calculated vertex normals with better contextual
information to improve performance. To allow changing the storage of
vertex normals more (mostly for improved caching), change some code
from "get normals, set values, clear dirty flag" to "make vertex
normals data, give to mesh". This makes the API less awkward too,
since previously the "get for write" and "clear dirty" calls always
had to be separated.
Pull Request: https://projects.blender.org/blender/blender/pulls/110754
Implement invalid sample points filling. Improves invalid regions
but introduce light leak.
Grid sample points are considered invalid if they have a ratio of
front-face ray hit under the given threshold. This is a post-processing
pass on the baked lighting that fills dark regions produced by
invalid sample location (e.g.: inside walls) with valid neighbor
samples data.
Two new parameters are added:
- Dilation Threshold: Validity threshold under which grid samples are
considered invalid. Invalid samples will gather valid lighting data
from valid neighbors inside the dilation radius.
- Dilation Radius: Radius of the dilation process. Expressed in grid
sample distance.
The validity of each point is progressively refined just like the
lighting data during the baking process.
The dilation process is implemented as a post-processing pass during
the loading of the grid data into the irradiance atlas. This allows
live tweaking the dilation parameters.
Pull Request: https://projects.blender.org/blender/blender/pulls/110386
Recently a user expressed interest in exporting baked animation
with B-Bone segments. Currently the python API already exposes
segment matrices via a PoseBone method, but there is no access
to the mapping of vertices to the segments.
Although currently the math is simple and easy to re-implement,
forcing Python add-ons to do that would cause a maintenance issue
if the mapping is ever changed later (it's quite dumb, ignoring
the rest pose curve, and there definitely is room for improvement).
This patch extracts the relevant math into a BKE function, and
exposes it in the python API as a new PoseBone method.
Pull Request: https://projects.blender.org/blender/blender/pulls/105419
`NLASTRIP_TYPE_TRANSITION` was being used incorrectly as a flag, having
`NLASTRIP_TYPE_TRANSITION=1` and `NLASTRIP_TYPE_SOUND=3` in the enum
`eNlaStrip_Type`, when evaluating `NLASTRIP_TYPE_SOUND &
NLASTRIP_TYPE_TRANSITION` gives a invalid truish value.
Also `strips` that can't be placed were freed, but no removed from the
`strips list`, this will cause a error if the `strip` is at begin
or end of the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/110605
In `Layer::remove_frame` there is a case where the frame is not removed,
but overridden by a null-frame. In this case, the frames map was not
tagged, when it should have been.
Changing the frames map would lead to a crash later in undo.
This was because the `frames_storage` was not written to file corectly.
When the `frames_storage` was tagged dirty, it recreated the
`frames_storage.num` as well as the `keys` and `values` pointers.
The `keys` and `values` pointers were written after the update, but
since the `num` is just an `int` in the embeded struct, it was written
before being updated. This lead to an out-of-sync state and later
to the crash.
The fix makes sure we write the struct *after* updating it.
This was because the `ob->runtime.geometry_set_eval` was populated
with the new `GreasePencilComponent` but
`GeometrySet::compute_boundbox_without_instances()` did not compute
the bounding box of the grease pencil geometry.
Thus the bounding box was not correctly set and the object not
correctly rendered.
Whenever `grow_array` in
`blender/source/blender/blenkernel/intern/grease_pencil.cc` was called,
it would not free the original array after relocating the data to the
newly allocated memory. This fixes the memory leak.
Adaptation of the operator `ACTION_OT_keyframe_insert` to take into account grease pencil channels.
Grease pencil keyframes can now be inserted in blank mode, or in additive mode (duplicate the current frame in the new keyframe).
Two API functions were added :
* `add_duplicate_drawings` which copies the data of a drawing to creates a duplicate, and
* `insert_duplicate_frame` which creates a duplicate frame of an existing one either by copy or instance.
The additive mode option is also added to the UI.
The Layer method `frame_key_at` previously private was set to public.
Pull Request: https://projects.blender.org/blender/blender/pulls/110649
Replace `BKE_mesh_face_flip_ex()` with `bke::mesh_flip_faces()`.
This gives better performance since it avoids custom data name
lookups for every face index, and processes data in a more cache
friendly way. Also remove the `CustomData_swap` API function
as mentioned in 09b6eac5c4.
Flipping 16 million faces, I observed a 3.25x speedup, from 760 to 230 ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/110702
Caused by 91b27ab637, which caused the final position
arrays to be returned in more situations (in this case, when the final
result is a non-wrapper mesh). Instead, use the cage mesh, which
is more correct anyway-- it just wasn't always available before.
Each of the four algorithms is different, and not all of them will
parallelize linearly, but for large meshes these "flushing" operations
begin to become noticeable compared to other multithreaded code.
For example, flushing visibility to vertices and edges after a change
to faces became 3.75x faster, from 90 to 24 ms.
Also avoid duplicating selection interpolation logic, use the attribute
API instead.
The aim is to replace the `BKE_mesh_faces_flip` functions with
this newer C++ function using the attribute API. But that is must
be called by RNA, so move this to blenkernel to avoid a circular
dependency between the geometry module and RNA.
Instead of the default `add` and `remove` functions for the frames map,
use `add_new` and `remove_contained` for when it is known that a value
is or isn't in the map already. This should be slightly more efficient
(and just better practice overall).
Adds a user count to drawings to track how many frames use the drawing.
If the user count hits `0` the drawing should be deleted.
Also adds a function to delete a frame in a layer. This will
decrement the user count of the drawing and delete it if there are no
users left. This is consistent with the way GPv2 worked.
Pull Request: https://projects.blender.org/blender/blender/pulls/110579
Support configurations where there is no dedicated None display
and try to use Raw view of the default display.
This allows to preserve compatibility with old files and the new
upcoming AgX configuration.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110581
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
The issue was that `CustomData_swap` modifies all layers, but does not ensure
that the layers are actually mutable. This resulted in it modifying shared layers.
Now it ensures that the layers are mutable first (which copies the layers if they
are shared).
Longer term, it would be good to remove `CustomData_swap` since it's not a
good API performance wise, but that is outside of the scope of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/110678
Reduce overhead of copying attribute data into GPU buffers when the
PBVH is active. The existing lambda with a FunctionRef callback had
a significant overhead. While that was reduced by 25917f0165
already, even making the `foreach_faces` lambda into a template gave
significant overhead compared to simpler loops. Instead, separate
value conversion and iteration over visible triangles in a way that the
compiler is able to optimize more easily.
According to the GPU module, it's also better to use raw data access
than `GPU_vertbuf_raw_step`, since the data format strides aren't
meant to vary by platform, and the runtime stride can have a
noticeable performance impact.
Also avoid recalculating face normals, since they're already used to
calculate vertex normals anyway (since ac02f94caf).
I tested the runtime of the initial data-upload after entering sculpt
mode with a 16 million vertex mesh. Before, that took 1350 ms, after
it took 680 ms, which is almost a 2x improvement. In my tests, the
performance improvement was only observable for the initial data
upload, theoretically it is a more general change though.
It's possible that a similar optimization could be applied to multires
or dynamic topology sculpting, but that can be looked at later too.
Pull Request: https://projects.blender.org/blender/blender/pulls/110621
The goal is to reuse the same bake items for simulation and normal baking (#110137).
Previously, the bake data was tied to a simulation state which made it harder to reuse.
Now the code for the following things can be reused easily:
- Convert geometry node socket values into bake items and back.
- Serialize and deserialize bake items.
Pull Request: https://projects.blender.org/blender/blender/pulls/110577
This commit adds modifier support for Grease Pencil 3.
The `BKE_grease_pencil_data_update` function evaluates the modifiers by
first creating a `GeometrySet` from the grease pencil data,
then evaluating the modifiers, and finally reading the
resulting `GreasePencilComponent` component and assigning
the evaluated object data.
Pull Request: https://projects.blender.org/blender/blender/pulls/110500
Dynamic topology drawing can now use the smooth status saved in each
edge. Because of that, the "Smooth Shading" draw option is unnecessary
and just adds confusion because of inconsistency between dynamic
topology drawing and other modes.
Fixes#109191
Pull Request: https://projects.blender.org/blender/blender/pulls/110548
Similar to 79115c5c56, but for multires sculpting. Improves
the PBVH build time for a 16 million vert multires sculpt by about 100ms
(from 470ms to 370ms). That itself is just a small portion of the time
spent entering sculpt mode though.
