Certain packed images, like those loaded directly into memory with
`BKE_image_packfiles_from_mem`, would cause USD to process the images as
"in memory" rather than as "packed" because the API was not removing the
IMG_GEN_TILE flag.
Additionally, be sure to use the packed filepath whenever possible
rather than the name given to the Image datablock as this ensures the
correct file names are used inside the USD file and for the resulting
file on disk after export.
This also fixes 2 render tests which now match when compared to the
native renders.
Pull Request: https://projects.blender.org/blender/blender/pulls/145749
When rendering to an image/video file, check whether the recursive
directory creation actually succeeded. If not, log an error and stop,
instead of trying to write the file.
This results in easier to understand error messages, and will help to
triage some (what we think are) race conditions with the Blender Studio
render farm.
Pull Request: https://projects.blender.org/blender/blender/pulls/145118
* PROP_COLOR_GAMMA is sRGB, not display space
* Hex colors are always sRGB
* Image byte buffers are in byte_buffer.colorspace
Fixes for sequencer text, image painting, render stamp and tooltips.
The default display space is sRGB, so this change will not be noticed
in most files.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
Replaces the `FPS` macro with `scene->frames_per_second()`.
The macro has two major issues:
* It hides that it depends on a `Scene *` variable named `scene`.
* It makes debugging harder.
This is now replaced with a member function on the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/144127
Originally reported for ProRes codec, but it affects multiple
other codecs: any format which is read as >= 10bit had the issue.
A regression since 93be12fde0.
The cause of the issue is that movie clip and image data-blocks
did linearization on their side, which was quite hidden to find.
Now the color management is done on the movie reader level.
Additionally, added regression test to catch such issues early
on in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/143435
Part of https://projects.blender.org/blender/blender/pulls/141278
Blend files compatibility:
If a World exists and "Use Nodes" is disabled, we add new nodes to the
existing node tree (or create one if it doesn't) that emulates the
behavior of a world without a node tree. This ensures backward and
forward compatibility.
Python API compatibility:
- `world.use_nodes` was removed from Python API => **Breaking change**
- `world.color` is still being used by Workbench, so it stays there,
although it has no effect anymore when using Cycles or EEVEE.
Python API changes:
Creating a World using `bpy.data.worlds.new()` now creates a World with
an empty (embedded) node tree. This was necessary to enable Python
scripts to add nodes without having to create a node tree (which is
currently not possible, because World node trees are embedded).
Pull Request: https://projects.blender.org/blender/blender/pulls/142342
Ever since [0], ReportList is not actually used in any DNA structs.
That makes sense, since reports are conceptually only necessary
at runtime. Move the definition of the struct to BKE_report.hh, and
fix a bunch of include errors where types were previously available
transitively. Besides adding some clarity, theoretically this change
could reduce compile times because of less header parsing.
[0]: 1bf6d8b0b9
Pull Request: https://projects.blender.org/blender/blender/pulls/138872
Blender expects float buffers to be in scene linear space, which was
violated bu the 1012bit movie reading code. While such image buffers
can be displayed correctly, performing operations in various areas
of Blender might lead to unexpected results.
The non-linear colorspace for ImBuf is expected to be "internal-only"
to a specific area, like VSE.
This is only done for Image and MovieClip data-blocks, sequencer still
reads movie files in their original colorspace as it helps performance and
sequencer can not be referenced from places where linear colorspace
for float buffer is really important.
Pull Request: https://projects.blender.org/blender/blender/pulls/141603
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Add render category, which is automatically enabled when using -f or -a
command line flags for background rendering.
* Add extra logs to mention scene, view layer and frame ahead of time rather
than including it in every line.
* Remaining time was removed from Cycles, this will be added back for animations
at the render pipeline level.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
Removes various image filtering/mipmapping leftovers from
pre-2.80 days.
Code: removes all mipmap handling from ImBuf (which is about half of
ImBuf struct size), removes now unused "sample procedural texture
with mipmaps" code, now-unused FELINE filter, etc. The osatex
parameter to various CPU texture sampling functions is never
actually used, which means none of the mipmap code was ever executing.
User visible part: there were settings on the legacy Texture data
block (as used by Brushes etc.), under Sampling section: "MIP Map",
"Gaussian Filter", "Filter Type", "Eccentricity", "Minimum Size" --
they had no effect anywhere, so they are gone, and what remains is
only "Interpolation" and "Size".
RNA / Python API part: removes the ImageTexture RNA properties
corresponding to the above: filter_type, use_mipmap, use_mipmap_gauss,
filter_lightprobes, filter_eccentricity, use_filter_size_min.
Pull Request: https://projects.blender.org/blender/blender/pulls/139978
Check if either the memory is zero or already matches the default value,
and copy. This simplifies a common pattern to a single line.
Preparing for default initializers in DNA (#134531).
Pull Request: https://projects.blender.org/blender/blender/pulls/138830
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
Like other runtime structs, it doesn't make sense to write this
data to files. And moving it out of DNA to an allocated C++ struct
means we can use other C++ features in it, like the new Mutex
type which I switched to in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/138551
Ref: #132179
Renames:
- `Editing.act_seq` -> `Editing.act_strip`
- `SequenceModifierData` -> `StripModifierData`
- Its member `mask_sequence` is now `mask_strip`.
- `MetaStack.parseq` -> `MetaStack.parent_strip`
- Remaining function names/parameters that were not dealt with in #132748
- Various references to `seq` or `sequence` throughout code and docs when
referring to a strip
Also moves `_get` to the end of the renamed function names where
applicable for standardization (unless "by" or "from" are used).
There should be no changes to current behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/138077
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
Add a "Pixel Density" sub-panel to render output settings which
can be used to set the density (as pixels per inch for example).
This is then written to images that support pixel density.
Details:
- The scene has two values a PPM factor and a and base unit.
- The base unit defaults to pixels per inch as this is the most
common unit used.
- Unit presets for pixels per inch/centimeter/meter are included.
- The pixel density is stored in the render result & EXR cache.
- For non 1:1 aspect renders, the density increases on the axis
which looks "stretched", so the PPM will print the correct
aspect with non-square pixels.
Ref !127831
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136134
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
This patch refactors static cache invalidation of images by tracking an
update count. Images now store a runtime update count that is updated
every time the image is tagged for update. Cached images store a copy of
the update count at the moment they were cached, and are invalidated if
if it changed.
Compared to #134878, this is simpler and more robust, since update IDs
are isolated to images only and not to the DEG update count. Though this
only supports images specifically because they are not covered by the
copy-on-evaluation system, which means #134878 will cause multiple
depsgraph to fight over images.
Pull Request: https://projects.blender.org/blender/blender/pulls/134905
This would be done when the frame, layer, pass or view changes compared to
the previous value. But for cases like old files without these members or
loading the image datablock into a different scene, this considered the image
to be always be changed on file load.
Now always reset this state on file load, and don't consider the initial
state as an image update.
This could also happen in the middle of GPU rendering, causing the GPU
texture to be freed while still in use.
Pull Request: https://projects.blender.org/blender/blender/pulls/134198
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
Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
