The usual issue of non-trivial C++ data being allocated with C-style
`alloc` code.
Also added more default initializers to some generic RNA-related structs
that embded some `PointerRNA` members.
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Add proper checks for editable ID to image pack/unpack and file_browse
operators.
Also add similar check to `unpack_item` operator, although in that case
the check has to happen in exec callback, as poll function would not
have required info.
This addresses the 'Resize UDIM sequences' feature from issue #109820
If the user needs to resize all UDIMs in an image, they currently need
to go through a tedious process of switching through all the UDIMs and
resizing them individually.
Now, when the user resizes an image, they can choose to apply the
operation to all UDIM tiles in the image.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/132524
- In the context of mesh extrusion, "Fill" means "Fill the rim of an
extruded edge loop" (verb).
- In the context of the file browser, it means select every file
between beginning and end.
- In the context of an image, fill the tile with generated image.
Issue reported by Hoang Duy Tran.
- 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
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
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
Similar issues to previous problems in `IMAGE_OT_open` and the
`BKE_image` API... Relative filepaths of linked editable IDs must be
relative to the ID's library blendfile, not the current 'local'
blendfile.
Use new `_in_lib` BKE_image API to re-use or load an image from/in the
expected library, including using the library path as root path for
relative file paths handling.
Using the new `BKE_image..._in_lib` API also allows to get rid of the
`check_exists` 'hack' introduced in `image_open_exec` (when support to
edit some linked data was added, in 5f9f3116db) to avoid re-using local
Image IDs for editable linked data (brush assets), since
`BKE_image_load_exists_in_lib` will now ensure to only re-use an Image
ID if it matches the target library.
This commit also simplifies/makes `ED_image_filesel_detect_sequences`
signature more to the point. It replaces the `Main` parameter by a mere
`root_path` string. The given `bmain` was indeed only used to extract
(again) a base for relative paths.
NOTE: The general idea of this fix is the same as in PR !130058, thanks
to Sean Kim for the investigation and initial fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/130197
This commit refactors `BKE_image_load` and `BKE_image_load_exists` APIs:
* Remove the `_ex` versions (the 'exist' boolean return pointer can have
default `nullptr` value instead).
* Add `_in_lib` versions, which match signature and behavior of the
generic ID creation code to allow to find or create a new image ID
directly in a library 'namespace' (as linked data).
This is required by upcommig fixes for Brush Assets, which are using
linked but editable data-blocks.
Fix#130194: When trying to add a new image from the UI (e.g. for a new
texture) for a local ID, if that same exact image was already loaded by
a linked ID, it would trigger an assert in `BKE_id_move_to_same_lib`,
because `BKE_image_load_exists` would return the matching linked Image ID
instead of creating a new local one. In release builds with no assert,
it would result in making a linked ID 'local', while still being used by
original other linked data.
Passing around the intended final destination of the new Image (local or
in a given library) allows `BKE_image_load_exists` to be more specific
when searching for an already loaded matching image ID, and ensures that
a new local Image ID is created in the case described above.
Pull Request: https://projects.blender.org/blender/blender/pulls/130195
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Follow what was already done with the "reload" operator and tag the
Image ID during "replace".
A tag of "0" is used for now until we can investigate why the other more
appropriate values are not working.
Pull Request: https://projects.blender.org/blender/blender/pulls/129619
API: merged IMB_scalefastImBuf, IMB_scaleImBuf, IMB_scaleImBuf_threaded
into one function IMB_scale with enum IMBScaleFilter {Nearest, Bilinear, Box}
and bool "threaded" param.
Performance:
- Box filtering (nee IMB_scaleImBuf) can be multi-threaded now.
- Nearest filtering (nee IMB_scalefastImBuf) can be multi-threaded now.
Also fix performance regression on float images caused by fix in #126234
- Bilinear filtering (nee IMB_scaleImBuf_threaded) is several times faster now.
Correctness:
- Nearest and Box filtering: no longer loses half of edge pixels when scaling
up.
- Box: fixed garbage results (and possible out of bounds reads) for non-4
channel float images.
- Bilinear: no longer shifts image when scaling up.
- Bilinear: properly filters when scaling down by 2x2.
Test coverage:
- Add gtest coverage for various IMB_scale modes.
- Add a IMB_performance_test performance test, ran manually.
More details, images and performance numbers in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126390
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Extract
- Cycles denoiser enum.
- Extensions user preferences UI.
- Node operator poll message from new node function.
Improve
- Split "(Enabled|Disabled) on startup, overriding the preference."
into two messages.
Disambiguate
- "Add" when describing the action of adding something should use the
Operator context.
- "Dimensions", in noise textures.
- "Transform" as a noun, the matrix transform type of Geometry Nodes,
as opposed to the verb to move things in space.
- "Parent" as a noun or verb (the parent of an object, to parent an
object to another).
Some issues reported by Satoshi Yamasaki, deathblood, and Gabriel Gazzán.
Pull Request: https://projects.blender.org/blender/blender/pulls/122969
Non-editable is mostly linked (besides some incoming exception for the
Brush Asset project).
If the Image is linked but not packed, conceptually it does not really
make a difference (edits for a linked vs local image would still end up
in the same external file when saved). However when it is linked and
packed we are running into Undo crashes (#122131). Also the image
remains linked, so data remains to be read/loaded from the packed
version from the library (so any edits are lost).
For consistency, disallow image operations for all non-editable images.
ref. #122131
ref. #122033
Pull Request: https://projects.blender.org/blender/blender/pulls/122209
These remain linked, so data remains to be read/loaded from the packed
version from the library (making this a useless and wasteful
duplication, also changes could be perceived as lost)
Continuation of !122092 which came up in #122033 -- but spread to more
operators / API so it is consistent everywhere
For operators, first intuition was to do it in a poll function, but that
isnt possible because the actual ID might depend on a given (to the
operator) ID name.
NOTE: Still not 100% in which scenarios linked data could still be
editable, but using ID_IS_EDITABLE for this now.
c6aa1fec2b / 918d34a9ed are related
Pull Request: https://projects.blender.org/blender/blender/pulls/122204
For the brush assets, this mechanism makes brush, texture, node tree and
image datablocks editable even when library linked.
This commit should introduce no functional change yet, as the code to
actually tag such libraries as editable will come later.
* These libraries and their datablocks are preserved when loading a new
blend file, much like the UI can be preserved.
* Operators that create new datablocks to be assigned to such datablocks
will put the datablocks in the same library immediately. This was
implemented for datablocks relevant for brush assets.
* RNA does not allow assignment of pointers from such linked datablocks
to local datablocks.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121920
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
For the brush assets project (#116337) all editors with brushes are
getting an asset shelf, and the brush tools are combined, with
individual brushes accessed in the shelf. That design seems way
overkill for UV sculpting which is just three very simple tools.
In order to avoid one editor with inconsistent use of brushes, which
would significantly increase the complexity of the system after the
brush assets merge, port the three UV sculpt tools to be regular
modal operators that don't use the brush or paint system at all.
To be clear, this is a compromise that doesn't feel ideal, but no
one could think of a better solution. Theoretically this removes
some flexibility from UV edit "sculpting", in practice it probably
won't be a noticeable change.
Pull Request: https://projects.blender.org/blender/blender/pulls/120797
How to reproduce:
- Have image editor and GPU compositor backdrop enabled and showing the same image
- In image editor, apply operator flip horizontally
- Notice how image editor gets updated but compositor backdrop doesn't
Fixes backdrop for GPU compositor for the following operations:
- image -> transform -> Flip horizontally
- image -> transform -> Flip vertically
- image -> transform -> Rotate 90° clockwise
- image -> transform -> Rotate 90° counter-clockwise
- image -> transform -> Rotate 180°
Pull Request: https://projects.blender.org/blender/blender/pulls/119819
How to reproduce:
- Have image editor and GPU compositor backdrop enabled and showing the same image
- In image editor, apply inver image colors operator
- Notice how image editor gets updated but compositor backdrop doesn't
Fixes backdrop updates for GPU compositor for the following operators:
- Image -> Invert -> Invert image colors
- Image -> Invert -> Invert red channel
- Image -> Invert -> Invert green channel
- Image -> Invert -> Invert blue channel
- Image -> Invert -> Invert alpha channel
Pull Request: https://projects.blender.org/blender/blender/pulls/119820
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
