The vector pass and potentially other vectors that store 4 values are
stored wrongly, in particular, the last channel is ignored. To fix this
we identify if a vector pass is 4D and store the information in the
result meta data, then use this information to either save a 3D or a 4D
pass in the File Output node.
This is a partial fix for the GPU compositor only. The complete fix for
the CPU compositor will be submitted separately as it is not
straightforward and will likely require a refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124522
This patch adds support for meta data in the GPU compositor much like
the mechanism that already exist in the CPU compositor. Only Cryptomatte
meta data is handled at the moment because that is the only meta data
that the compositor supports.
The is_data member of the result was moved to the meta data structure for
consistency with the CPU compositor.
Fixes#124222.
Pull Request: https://projects.blender.org/blender/blender/pulls/124460
The BLI_spin APIs use a `SpinLock` typedef whose underlying type is
contingent on the precense of `WITH_TBB`. Since our projects did not
consistently define the `WITH_TBB` definition, multiple `SpinLock` types
would end up in our final binary creating ODR violations.
Pull Request: https://projects.blender.org/blender/blender/pulls/124285
This patch cleanup and refactors the render pipeline compositor render
code to deduplicate code and clarify usage.
The unused this_scene arguemenet was removed, per-node functions were
introduced to simplify loops, C++ Set was used instead of GSet, and
scene change is now detected by any rendered scene in the set.
Pull Request: https://projects.blender.org/blender/blender/pulls/124028
Blender doesn't render the scene even though a Cryptomatte node exists.
That's because Blender only considers Render Layer nodes, but
Cryptomatte node can reference scenes as well. This patch fixes that by
putting Cryptomatte nodes into consideration.
Pull Request: https://projects.blender.org/blender/blender/pulls/123814
Blender crashes when rendering a scene strip that references a scene
with a GPU compositor active. This is because when rendering a scene
strip, a new render with a nullptr system GPU context is created for the
scene it references, which is then used for compositing.
Ideally, the strip scene would have its own context, but we can't ensure
its context because we are not in the main thread. The alternative is to
then identify scenes that will be rendered before hand and set their
renders before starting the job, which doesn't seem like a great
solution. So for now, we just use the DST context in those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/123057
Currently, during baking each pixel stores a seed input that comes from the
Blender side. This is only needed for vertex color baking, however -
for regular image baking, we can just as well hash the pixel coordinates.
Therefore, we can save some memory (4 byte per pixel) by splitting the seed
info out into a separate pass and only storing it when needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122806
This change adds the ability to export MaterialX networks into the resulting
USD layer.
Details:
A new export option has been added to the USD export to enable MaterialX
export. It is off by default currently due to reasons in the caveats
section.
When enabled, it exports the MaterialX shading network alongside the
UsdPreviewSurface network, on the same USD Material. This allows the same
material to be used by renderers that don't support MaterialX, using the
USDPreviewSurface as a fallback. This is similar to setups in other DCC
packages, and matches the format we've used in our Reality Composer Pro
asset library.
It uses the existing MaterialX framework used to generate MaterialX
documents for rendering, to act as the basis for the USD graph. In this
process it also re-uses the existing texture export code as well if provided
and necessary.
Once the MaterialX document is created, use usdMtlx to generate a USD
shading network. Unfortunately, usdMtlx generates a graph that is unlike
what other DCCs that support MaterialX-embedded-in-USD generates. It
generates several extra prim hierarchies, and externalizes all shader
inputs, making them difficult to edit in other MaterialX graph editors.
To workaround this, generate the MaterialX shading network onto a
temporary stage, where we then run various pre-processing steps to prevent
prim collisions and to reflow the paths once they're converted.
The PrimSpecs are then copied over to their new path. The resulting prim
hierarchy matches what many artists we've worked with prefer to work with.
Caveats:
The Export MaterialX check is off by default. When using the Principled
BSDF, the resulting graph is very usable. However, when using some of the
other BSDFs, the shading networks generated by the existing MaterialX
framework in Blender generate some shading graphs that are difficult for
usdview and other DCC's to understand. The graph is still correct, but
because we're trying to prioritize compatibility, the default is off.
In future PRs we can aim to make the graphs for those other BSDFs play
better with other DCCs.
Other Implementation Details:
As part of this commit we've also done the following:
* Place some of the materialx graphs inside a passthrough nodegraph to
avoid node conflicts.
* Better handle some shader output types , and better handle some
conflict cases.
* Moved the ExportTextureFunction to materials.h due to some difficult
to resolve header ordering issues. This has no effect on any runtime code.
* There is a test for the MaterialX export that does some basic checking to
make sure we get an export out the other end that matches our expectations
Authored by Apple: Dhruv Govil
This PR is based on an earlier implementation by Brecht van Lommel , as well
as Brian Savery and his teams' work at AMD to implement the general
MaterialX framework within Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/122575
The system context is expected to be bound prior to the Blender
can be properly initialized. Otherwise GHOST will be doing OpenGL
calls without system context bound.
This follows code from DRW_render_context_enable().
Pull Request: https://projects.blender.org/blender/blender/pulls/122708
Blender crashes when the interactive GPU compositor is running in a node
editor while rendering. This is because the GPU compositor is sharing
the same GPU context used for rendering, which is not allowed. To fix
this, we use a dedicated render list for interactive compositing, to use
its dedicated GPU context.
This is implemented by keeping another render list for the purpose of
compositing and similarly clearing its context when it is no longer
needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122472
This patch refactors the GPU context handing in the GPU compositor.
First, GPU context handling in the GPU compositor constructor was
removed, that's because the constructor does nothing GPU related.
Second, the destructor and the execute methods were unified to use the
global DST context for main thread execution and a dedicated system GPU
context for threaded execution. The former is the case for blocking
rendering as well as background mode, so the blocking due to the global
DST is not an issue, but it makes the code more robust to implementation
errors like #122070.
Pull Request: https://projects.blender.org/blender/blender/pulls/122389
The "render_stats" handler now includes the message line that was
written to stdout as the first arg (using `BKE_callback_exec_string`
instead of just `BKE_callback_exec_null`).
This can be useful to track render progress (and people were relying on
parsing stdout in the past).
Was a request in chat.
This also corrects possible output from the callback being written in
between message parts in `do_write_image_or_movie` (which was probably a
mistake in 93d5e106aa).
Pull Request: https://projects.blender.org/blender/blender/pulls/119789
This patch adds support for timing GPU compositor executions. This was
previously not possible since there was no mechanism to measure GPU
calls, which is still the case. However, since 2cf8b5c4e1, we now flush
GPU calls immediately for interactive editing, so we can now measure the
GPU evaluation on the host, which is not a very accurate method, but it
is better than having no timing information. Therefore, timing is only
implemented for interactive editing.
This is different from the CPU implementation in that it measures the
total evaluation time, including any preprocessing of the inputs like
implicit type conversion as well as things like previews.
The profiling implementation was moved to the realtime compositor since
the compositor module is optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/122230
The issue has been introduced by #122105
The image save operator does exactly the thing which was not supported by
the change and was not caught during development or view: it acquires and
releases image buffers while a render result of the Image data-block is
held acquired.
The solution is to implement a simple user-counter for the render result.
Currently it is only used by the image's render result acquire/release API,
as it is the most important case for now. The render pipeline uses its own
way of protecting the result, for which the user counter is not needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122231
The issue originates to the change in default view transform from Filmic
to AgX, which does slightly different clipping, and clips color to black
if there is any negative values.
This change implements an idea of skipping view transform for viewer
node when it is connected to the Pick output of the cryptomatte node.
It actually goes a bit deeper than this and any operation can tag its
result as a non-color data, and the viewer node will respect that.
It is achieved by passing some extra meta-data along the evaluation
pipeline. For the CPU compositor it is done via MetaData, and for the
GPU compositor it is done as part of Result.
Connecting any other node in-between of viewer and Cryptomatte's Pick
will treat the result as color values, and apply color management.
Connecting Pick to the Composite output will also consider it as color,
since there is no concept of non-color-managed render result.
An alternative approaches were tested, including:
- Doing negative value clamping at the viewer node.
It does not work for legacy cryptomatte node, as it needs to have
access to original non-modified Pick result.
- Change the order of components, and store ID in another channel.
Using one of other of Green or Blue channels might work for some view
transforms, but it does not work for AgX.
Using Alpha channel seemingly works better, but it is has different
issues caused by the fact that display transform de-associates alpha,
leading to over-exposed regions which are hard to see in the file from
the report. And might lead to the similar issues as the initial report
with other objects or view transforms.
- Use positive values in the Pick channel.
It does make things visible, but they are all white due to the nature
of how AgX works, making it not so useful as a result.
Pull Request: https://projects.blender.org/blender/blender/pulls/122177
Blender crashes when calling the python render operator when GPU
compositor execution is enabled. This is due to a missing system GPU
context, which is not initialized for blocking rendering. So this patch
ensures the system GPU context before compositing. Additionally, it
removes the assert that ensures a non main thread execution, since the
assumption apparently does not really hold.
Pull Request: https://projects.blender.org/blender/blender/pulls/122176
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Effectively, make GPU compositor available without need to enable
an experimental feature set.
The compositor device is now exposed in the Performance panel of
Render Buttons. It is also still available in the compositor's
N-panel, together with some other options which are more about how
editing works, and not exactly related to render performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/121398
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
This allows to expose these settings in the Performance panel in the
render buttons. Also moves compositor-specific options away from the
generic node tree structure.
For the backwards-compatibility the options are still present in the
DNA for the bNodeTree. This is to minimize the impact on the Studio
which has used the GPU compositor for a while now. They can be
removed in a future release.
There is no functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/121583
This should get all of the tests to pass on Windows ARM64 platforms.
Sadly it needs disabling for hydra/USD stuff as currently it doesn't play nicely with the new preprocessor. @LazyDodo suggested a USD version update may fix this, which is something I can investigate in due course - right now, let's get daily builds up and working :)
Pull Request: https://projects.blender.org/blender/blender/pulls/121361
The compositor execute functions have a `rendering` argument to specify
if the compositor is executing as part of the render pipeline. But the
render context argument is null if we are not rendering, so the
`rendering` arguement is redundant and can be removed.
Additionally, we no longer use use_file_output as a hack to detect
rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/120659
This patch improves the interactivity of the GPU compositor for
interactive node tree edits by waiting on GPU work to finish to support
more granular canceling.
This does have a performance penalty, but it does not affect final
rendering and it seems worth it because even though it is slower it will
feel faster for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/120656
Seems like scene `RenderData` only gets synched once from `Scene` to
`BaseRender` in `RE_InitState` .
Animation on it is only evaluating on the scene, so the the `BaseRender`
`RenderData` is not properly updated here.
However `R_STAMP_DRAW` is part of that and it is the `BaseRender`
`RenderData` that is checked in `do_render_full_pipeline` (not the
`Scene` one) to determine if we want to stamp.
Later calls to `BKE_render_result_stamp_info` / `renderresult_stampinfo`
/ `stampdata` always get passed the scene, so individual animation stamp
details (such as Render Time) work properly.
So to resolve, use the `Scene` `RenderData` (rather than the
`BaseRender` one) for proper animation update.
NOTE: this (not updating animation of members of `RenderData`) might
actually be a problem elsewhere, too -- havent checked on this in detail
though
Pull Request: https://projects.blender.org/blender/blender/pulls/120429
The File Output node produces wrong output when the output is set to BW.
This is because the image saving logic assumes float buffers always have
4 channels and ignores the image buffer channels member. So for single
channel images, the code weighted sum neighbouring pixels and asigned
them as a single pixel, producing bleeding at best and crashes at worst.
To fix this, we skip Color to BW conversion if the image is already BW.
And, we fix the functions that assume 4 channels for float buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/120206
The issue seems to be caused with the recent NVidia drivers, which will
crash if OptiX context is created prior to the OpenGL context on Linux.
This happens with drivers 545.29.06, 550.54.14, 550.67 and kernel 6.8
on Ubuntu 24.04, and also happens with NVidia driver 550.67 on Gentoo.
While it does seem the issue is likely on the driver side, the timeline
for it being resolved there is unknown. Until then it is possible to
apply workaround on Blender side, which will initialize GPU context
prior to rendering with an external render engine when it is known the
GPU context will be needed later on.
Note this is not a complex fix, because in general it's still possible to
render a frame without and then with grease pencil, in which case OptiX
will still be initialized first. But we don't want to always initialize
OpenGL, and we can't predict future operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/120026
FILE_CACHE_MAX was meant to be larger than FILE_MAX to make room
for additional layers in the path. An error in the define used
`FILE_MAXFILE + FILE_MAXFILE` instead of `FILE_MAXDIR + FILE_MAXFILE`
causing the value to be smaller allowing a buffer overflow when passing
the string into BLI_path_abs.
Correct the define and call on the directory component before
the file is added so it doesn't clamp the string length unnecessarily.
Note that some values weren't correct since the original commit [0],
although [1] moved them to a shared incorrect define.
[0]: 78cdc707ab
[1]: cef1b9c30f
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
This commit fixes the following assert:
mtl_command_buffer.mm:165, submit(), at 'MTLBackend::get()->is_inside_render_boundary()'
It happens when toggling rendered state of viewport on macOS, and is
caused by incorrect order of setting active GPU context to null and
calling GPU_render_end.
This change makes the flow of GPU_render_{beign, end} and GPU context
activation closer to what it is in the draw manager's functions
DRW_render_context_{enable, disable}.
Pull Request: https://projects.blender.org/blender/blender/pulls/119868
