Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This was added at the start of the project, as a way for the source
library to control what would be overridable by the user of the data
(production files).
The implementation never went beyond the experimental area, and only
exposed in the python API then. The idea has been superseeded by the
'cherry-pick' design, so there is no point in keeping this code any
longer.
This refactors how volume grids are stored with the following new goals in mind:
* Get a **stand-alone volume grid** data structure that can be used by geometry nodes.
Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block.
* Support **implicit sharing of grids and trees**. Previously, it was possible to share data
when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was
not flexible enough.
* Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls
to some "load" function all the time.
* Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block.
* Get a **tiered API** for different levels of `openvdb` involvement:
* No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that
still work in this case. This makes it possible to write high level code for volumes that does
not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`.
* Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care
is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as
much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`.
* "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned
out to be not necessary for the common API. So this is only used for task specific APIs.
At the core of the new API is the `VolumeGridData` type. It's a wrapper around an
`openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading.
Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid.
Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit
sharing. At highest level we currently have the `Volume` data-block which contains a list of
`VolumeGrid`.
```mermaid
flowchart LR
Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid
```
The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes
it easy to load and reuse entire files and individual grids from disk. It also supports caching
simplify levels for grids on disk.
An important new concept are the "tree access tokens". Whenever some code wants to work
with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`.
This access token has to be kept alive for as long as the code works with the grid data. The same
token is valid for read and write access. The purpose of these access tokens is to make it possible
to detect when some code is currently working with the openvdb tree. This allows freeing it if it's
possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by
multiple owners, but only no one is actively working with. In some sense, this is similar to the
existing `ImageUser` concept.
The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`.
Most other changes are updates to existing code to use the new API.
Pull Request: https://projects.blender.org/blender/blender/pulls/116315
Form a logic PoV, it makes more sense to have all 'debug' options
disabled as the 'normal' situation.
This commit merely invert the RNA-exposition of two settings (Asset
Indexer and Override auto-resync).
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
When the Asset shelf is active but hidden, the mouse cursor will give
feedback about a moveable edge above the asset shelf area. This just
alters `region_azone_edge_poll` to check for edges belonging to
regions that hide with a previous region that is now hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/116233
Extract:
- Compositor error messages.
- `bUnitDef`s were broken after cleanup commit 2b77cd726d. Since each
unit's "display name" is now preceded by a consistent "name_display"
comment, the regex which extracts the unit is greatly simplified.
It now relies on the presence of the comment instead of the struct
order.
- "Preset" menu and "Apply Preset" button from the curveprofile
template.
- Operator labels from the catalog context menu.
Disambiguate:
- "Bake Data": can mean "Which data to bake" (verb), or "The data that
were baked" (noun).
- "Cache" in the Simulation Nodes panel is a verb, not a noun.
- "Mix" in the snapping menu is a noun, not a verb.
- "Top" and "Bottom" can mean the upper part of an object or the
highest point or element of something like a menu or list.
Pull Request: https://projects.blender.org/blender/blender/pulls/115963
After doing regular movie frame decoding, there's a "postprocess" step for
each incoming frame, that does deinterlacing if needed, then YUV->RGB
conversion, then vertical image flip and additional interlace filtering if
needed. While this postprocess step is not the "heavy" part of movie
playback, it still takes 2-3ms per each 1080p resolution input frame that
is being played.
This PR does two things:
- Similar to #116008, uses multi-threaded `sws_scale` to do YUV->RGB
conversion.
- Reintroduces "do vertical flip while converting to RGB", where possible.
That was removed in 2ed73fc97e due to issues on arm64 platform, and
theory that negative strides passed to sws_scale is not an officially
supported usage.
My take on the last point: negative strides to sws_scale is a fine and
supported usage, just ffmpeg had a bug specifically on arm64 where they
were accidentally not respected. They fixed that for ffmpeg 6.0, and
backported it to all versions back to 3.4.13 -- you would not backport
something to 10 releases unless that was an actual bug fix!
I have tested the glitch_480p.mp4 that was originally attached to the
bug report #94237 back then, and it works fine both on x64 (Windows)
and arm64 (Mac).
Timings, ffmpeg_postprocess cost for a single 1920x1080 resolution movie
strip inside VSE:
- Windows/VS2022 Ryzen 5950X: 3.04ms -> 1.18ms
- Mac/clang15 M1 Max: 1.10ms -> 0.71ms
Pull Request: https://projects.blender.org/blender/blender/pulls/116309
This was caused by 5c76c7bf84, which only updated sound when tagged by
`ID_RECALC_AUDIO`. On undo or rendering, this flag is missing.
Update equalizer when recalc is flagged by `ID_RECALC_COPY_ON_WRITE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116282
A similar issue was fixed in the commit below for inserting implicit
conversions for links, but it wasn't corrected for conversions in
muted nodes.
Caused by e1d0d70911
Similar to 64e955f522 (but extended a bit).
Fix by preventing access of non-existent (or out of bounds)
`TexPaintSlot`.
In the future, we should probably even prevent it further by using
`RNA_def_property_int_funcs` (but that is for a later commit).
Pull Request: https://projects.blender.org/blender/blender/pulls/116345
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
According to the issue not all legacy AMD platforms that required the
high quality normals workaround where enabled. I have not been able to
reproduce the issue due hardware availability.
This PR will enable the workaround for all HD ATI GPUs.
Pull Request: https://projects.blender.org/blender/blender/pulls/116340
Previously, attribute values were only visualized as color overlay in the 3d viewport.
Now it's possible to optionally show the attribute values as text. This can be enabled
in the `Viewer Node` overlay settings in the 3d view.
This is just the first initial version. More work towards making it look better
will be done next.
Pull Request: https://projects.blender.org/blender/blender/pulls/115664