The compositor backdrop in certain files always have a size of 256x256
regardless of the actual size of the viewer image. That's because the
compositor writes its result to a different image buffer than the one
the image engine reads its image buffer from. And the image engine
assumes a default size of 256x256. The reason is a bit involved.
For non multi-view images, the image module uses the special cache index
value of IMA_NO_INDEX for the compositor backdrop, which works fine if
the image was detected as a non multi-view image in the first place.
However, this detection fails because the compositor may still write
multi-view images even for non multi-view renders.
In particular, before the compositor writes its viewer image, it ensures
correct views by calling BKE_image_ensure_viewer_views, which first
checks if we need to recreate the views of the viewer image if they
don't match the render views. And in the case of non multi-view image,
that check fails in one case.
Functions like BKE_image_is_multiview checks if a single unnamed view
exists in the image, unnamed being the keyword here. The root issue is
that BKE_image_ensure_viewer_views only checks that a single view
exists, while it should also check that it is unnamed. Which happens
when the user enabled multi-view, added only one view, then disabled
multi-view again.
To fix this, we add a check for the name of the view in case of non
multi-view images. And additionally pull the view matching code into its
own documented utility function for clarity.
Pull Request: https://projects.blender.org/blender/blender/pulls/132348
Previously, the code was O(n^2) because it iterated over all interface sockets,
and for each it tried to find the corresponding index by iterating over all
inputs again. Now, a `VectorSet` is used to make finding the index `O(1)`. The
new utility function may also be useful elsewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/132272
The image user of the Cryptomatte node does not have an up to date frame
number. That's because the BKE image user walker function which is used
to update image user frames numbers was missing handling for the node.
To fix this, add a case for the Cryptomatte node.
This is a partial fix for #132210.
Pull Request: https://projects.blender.org/blender/blender/pulls/132271
This renames the `Strip` struct to `StripData` and also renames
the `Sequence::strip` member to `Sequence::data`.
This is a first step towards naming the `Sequence` struct to `Strip`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132165
When moving UV seams from special custom data types to attributes,
I considered them similar to mesh selection or visibility which are
"internal" attributes that aren't accessible procedurally and are
hidden from the UI. In retrospect that was the wrong decision; users
expect UV seams to behave more like bevel weights, and that makes sense.
This PR makes UV seams accessible in modifiers (geometry nodes) by
removing the leading period from the attribute name that indicated their
internal status.
The change of the attribute name is a breaking change of the API to some
extent, even though it's technically only mesh data. To mitigate that
issue, the `mesh.attributes["name"]` lookup function is modified to
support both the old and new names. Versioning code renames the
attribute to the new name when loading older files, and renames the
new name to the old name when saving files. That handling will be
removed as a breaking change in 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/129803
This patch refactors the BKE distortion deltas bound computation to
compute each of the bounds independently. This is done to support cases
where the distortion is not symmetric and thus would need to grow the
image in a non-symmetric way.
This patch multi-threads the distortion bounds delta computations.
Additionally, it removes the 5-step approximation which was used. The
result of this function will be cached in the compositor and the problem
domain is relatively small.
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
Work-around the issue until we actually have correct refcounting usage
handling of Objects: For now, consider all linked objects used by
another used ID as used, even if their usercount is null.
NOTE: This _may_ have side-effects on liboverride (especially the resync
process), by leaving more 'unused' data behind. Since these are linked
though, and presumably not instanced in the Scene, this is probably an
acceptable compromise.
Pull Request: https://projects.blender.org/blender/blender/pulls/132076
We have two uses of identical code that checks to see if we have a
current preferences file (false for first run of new version). This PR
extracts that to new function `blender::bke::preferences::exists()` as
there will soon be a third use (#132046). Otherwise no behavior change.
Pull Request: https://projects.blender.org/blender/blender/pulls/132140
Currently there are three entry points to building BVH trees for mesh
ata: the caches on the mesh, an older set of functions used in the mesh
remap code, and a new set of functions used in some geometry nodes
sampling nodes. This commit unifies their implementations and switches
some functions from bit spans to index masks for representing a
selection of geometry.
A followup for 5e7f3e5c84.
Make the NOD_static_types.h file less important by moving `enum_name_legacy`
to be defined in the register function of every node. This helps our gradual transition
away from this file.
Also add a fallback to the node idname so that newly added nodes no longer need
to define the string value.
Pull Request: https://projects.blender.org/blender/blender/pulls/132131
Action Slots point to the IDs they animate, and after swapping IDs they
also need some swappage (as the Action that first animated `id_a` will
now animate `id_b`, and vice versa).
Instead of doing this in the `id_swap()` function (and requiring
knowledge of how that's supposed to be done), just mark these pointers
as dirty so that they're rebuilt at first use.
This commit contains a little more code than strictly necessary, to add
a function in BKE for this cache invalidation. This avoids having to
have a dependency on the animrig module just for this purpose.
Fixes: #130136
Pull Request: https://projects.blender.org/blender/blender/pulls/131809
Change how `action_foreach_id()` reports action slot users. This contains
two changes:
- Report the correct pointer reference, so that the ID remapping code
can actually change the pointers in the cache (necessary, for example,
to nil pointers to deleted IDs).
- Never report anything when it's known the slot user cache is dirty.
Pull Request: https://projects.blender.org/blender/blender/pulls/131808
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
Mistake in 5f9f3116db, ID name needs to be removed from the runtime ID
name cache data _before_ its library pointer is modified.
Library is an important part of an ID 'namesapce', so trying to remove
it after its library has been changed is trying to remove it from the
wrong namespace, leaving it in the original one.
Pull Request: https://projects.blender.org/blender/blender/pulls/132080
The returned pointer shouldn't be passed to a function expecting
a null terminated C string. Use the StringRef::copy function instead
which is more efficient anyway since it doesn't have to measure the
size of the string again.
Caused by 024d7d12e2.
I forgot that the BVH cache value isn't reset to default if it isn't
shared, which can happen after remeshing in some cases. To fix this,
switch to unique_ptr which handles ownership properly on assignment,
removing this class of bug from this code.
Pull Request: https://projects.blender.org/blender/blender/pulls/132040
The new --disable-liboverride-auto-resync commandline option will prevent
running liboverride auto-resync immediately after loading a blendfile.
This is an alternative way to setting the User Preferences Debug option
`No Override Auto Resync`.
-------
Some quick performances tests:
Loading a Gold production file goes from 26.5s to 25.9s.
Combined with the recent `--disable-depsgraph-on-file-load` option, it
goes from 3.5s to 2.9s, so another nice extra 15% speedup when only
bare-metal blendfile loading is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132017
The realize instances code didn't have a way to use the existing
`#BuiltinAttributeProvider::default_value()`s to initialize attributes that
have to be created.
Now this writes default values of builtin attributes to the curve `attribute_fallbacks`.
Removes the need for the code to explicitly write the `resolution` and
`nurbs_weight`.
The other attributes that are written explicitly (like `radius`) don't have
builtin default values unfortunately. Ideally those would also just be provided
by the respective `BuiltinAttributeProvider`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131799
The `double inittime` attribute on strokes is truncated to a `uint32_t`
range. This wasn't done explicitly and the code only did a cast.
The `double` should be clamped to a legal `uint32_t` value before
casting it.
Pull Request: https://projects.blender.org/blender/blender/pulls/131625
The code tried to sync the playback to audio in two places:
1. In the screen_animation_step_invoke function in screen_ops.cc
2. In wm_event_do_handlers which would trigger on every screen refresh/event
However because of some oversight on how the Audaspace API worked,
the wm_event_do_handlers code was only triggered for JACK and CoreAudio.
Remove this code as we shouldn't need to update the current scene frame
in two places.
The wm_event_do_handlers way would also lead to bugs as it would try to
sync regardless if we were playing back audio or not.
The type check there should not be necessary anymore nowadays. It looks like it
might have been necessary when it was introduced in
eed45d2a23. Back then the object was still passed
into `BKE_mesh_wrapper_ensure_subdivision`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131857
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
Previously, the number of material slots on the geometry (e.g. mesh) was the
ground truth. However, this had limitations in the case when the object had more
material slots than the evaluated geometry. All extra slots on the object were
ignored.
This patch changes the definition so that the number of materials used for
rendering is the maximum of the number of material slots on the geometry and on
the object. This also implies that one always needs a reference to an object
when determining that number, but that was fairly straight forward to achieve in
current code.
This patch also cleans up the material count handling a fair amount by using the
`BKE_object_material_*_eval` API more consistently instead of manually accessing
`totcol`. Cycles uses the the same API indirectly through RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/131869
UNICODE code points were named "ascii" or "cha",
use the term "charcode" as used elsewhere in BLF and FreeType.
Also use char32_t internally and add a utility function to apply the
small-caps flag.
