This adds a cycles.denoise_animation operator, which denoises an animation
sequence or individual file. Renders must be saved as multilayer EXR files
with denoising data passes.
By default file path and frame range come from the current scene, and EXR
files are denoised in-place. Alternatively, a different input and/or output
file path can be provided.
Denoising settings come from the current view layer. Renders can be denoised
again with different settings, as the original noisy image is preserved along
with other passes and metadata.
There is no user interface yet for this feature, that comes later.
Code by Lukas with modifications by Brecht. This feature was originally
developed for Tangent Animation, thanks for the support!
This is a request by the studio here to make it possible to see how
many samples were used to render a specific shot or a frame. It is a
bit more tricky than simply stamping number of samples from a scene
since rendering is happening in multiple ranges of samples.
This change makes it so Cycles saves configured number of samples for
the specific view layer, and also stores start sample and number of
samples when rendering only a subrange of all samples.
The format used is "cycles.<view_layer_name>.><field>", which allows
to have information about all layers in a multi-layer EXR file.
Ideally we can store simplified "cycles.<field>" if we know that there
is only one render layer in the file, but detecting this is somewhat
tricky since Cycles operates on an evaluated scene which always have
single view layer.
The metadata is shown in the Metadata panels for clip, image and
sequencer spaces.
Example screenshot which shows the metadata:
{F6527727}
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4311
Prefiltering of feature passes will happen during rendering, which can
then be used for denoising immediately or written as a render pass for
later (animation) denoising.
The number of denoising data passes written is reduced because of this,
leaving out the feature variance passes. The passes are now Normal,
Albedo, Depth, Shadowing, Variance and Intensity.
Ref D3889.
When using `--cycles-resumable-num-chunks N` to render a subset of the
samples, having N close to the total number of samples causes rounding
issues.
For example, a file configured for 250 samples and 150 chunks should
have 1.6666 sample per chunk. The old code rounded this to 2 samples per
chunk, which would result in too many samples being rendered. When
rendering a single chunk this doesn't matter much, but when larger chunk
ranges are rendered with `--cycles-resumable-start-chunk` and
`--cycles-resumable-end-chunk` the rounding errors start to add up.
By multiplying with the number of chunks to render first, and only round
to integers after that, this issue is solved. In the above example,
rendering 3 chunks will correctly render 5 samples rather than 6.
When the requested number of chunks is larger than the number of samples
there will be duplicate samples (that is, sample N appearing both in
chunk M and M+1). In this case a warning is printed to stderr.
This is needed for T50977 Progressive render: use non-uniform sample
chunks.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D4282
This is a quick workaround to prevent the crashes with multi-view.
The ultimate solution can be plenty, and would turn around refactoring
Cycles to handle multi-view internally, so that depsgraph could be freed
before render with no problems.
Reviewers: brecht, sergey
For the complete discussion check: https://developer.blender.org/D4239
This commit adds a sample-based profiler that runs during CPU rendering and collects statistics on time spent in different parts of the kernel (ray intersection, shader evaluation etc.) as well as time spent per material and object.
The results are currently not exposed in the user interface or per Python yet, to see the stats on the console pass the "--cycles-print-stats" argument to Cycles (e.g. "./blender -- --cycles-print-stats").
Unfortunately, there is no clear way to extend this functionality to CUDA or OpenCL, so it is CPU-only for now.
Reviewers: brecht, sergey, swerner
Reviewed By: brecht, swerner
Differential Revision: https://developer.blender.org/D3892
Currently this is possible after built-in images are loaded in memory.
Allows to save memory used by dependency graph and copy-on-write.
In practice this lowers peak system memory usage from 52GB to 42GB on
a production file of spring 03_035_A.lighting.
Note, that this only applies to F12 and command line renders.
Bigger note, that this optimization is currently only possible if
there are no grease pencil objects to be rendered.
Now it shows more compact info below the view/object name. Render time and
memory usage is left out, as in most cases this is not so important. These
could be added back optionally if needed.
Needed for the animation denoiser since the denoising filter is done separately there.
Reviewers: brecht, sergey
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3833
This allows for extra output passes that encode automatic object and material masks
for the entire scene. It is an implementation of the Cryptomatte standard as
introduced by Psyop. A good future extension would be to add a manifest to the
export and to do plenty of testing to ensure that it is fully compatible with other
renderers and compositing programs that use Cryptomatte.
Internally, it adds the ability for Cycles to have several passes of the same type
that are distinguished by their name.
Differential Revision: https://developer.blender.org/D3538
Gathers information about object geometry and textures. Very basic at
this moment, but need to start somewhere.
Things which needs to be included still:
- "Runtime" information, like BVH. While it is not directly controllable
by artists, it's still important to know.
- Device array sizes. Again, not under artists control, but is added to
the overall size.
- Memory peak at different synchronization stages.
At this point it simply prints info to the stdout after F12 is done,
need better control over that too.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3566
I've limited it to just the RGB<->XYZ stuff for now, correct image handling is the next step.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D3478
With copy-on-write we can no longer assumes the point density data is
available after Cycles synchronization with Blender data is done. So
force it to be loaded earlier, even if it's not great for interactivity.
This introduces a new depsgraph API for getting updated datablocks,
rather than getting it from bpy.data.
* depsgraph.ids_updated gives a list of all datablocks in the depsgraph
which have been updated.
* depsgraph.id_type_updated('TYPE') is true if any datablock of the given
type has been added, removed or modified.
More API updates are coming to properly handle multiple depsgraphs and
finer update granularity, but this should make Cycles work again.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
Now the only missing bit seems to be in Cycles to pass depsgraph to
builtin_image_float_pixels().
Ideally we could get evaluation context instead of using depsgraph + settings.
But for the other rna EvaluationContext functions this is how we are doing.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3087
User notes
----------
Compositing, rendering of multi-layers in Eevee should be fully working now.
Development notes
-----------------
Up until now we were still using the same depsgraph for rendering and viewport
evaluation. And we had to go out of our ways to be sure the depsgraphs were
updated.
Now we iterate over the (to be rendered) view layers and create a depsgraph to
each one, fully evaluated and call the render engines (Cycles, Eevee, ...) with
this viewlayer/depsgraph/evaluation context.
At this time we are not handling data persistency, Depsgraph is created from
scratch prior to rendering each frame. So I got rid of most of the partial
update calls we had during the render pipeline.
Cycles: Brecht Van Lommel did a patch to tackle some of the required Cycles
changes but this commit mark these changes as TODOs. Basically Cycles needs to
render one layer at a time.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3073
