By default it will now set the step size to the voxel size for smoke and
volume objects, and 1/10th the bounding box for procedural volume shaders.
New settings are:
* Scene render/preview step rate: to globally adjust detail and performance
* Material step rate: multiplied with auto detected per-object step size
* World step size: distance to steo for world shader
Differential Revision: https://developer.blender.org/D1777
This feature takes some inspiration from
"RenderMan: An Advanced Path Tracing Architecture for Movie Rendering" and
"A Hierarchical Automatic Stopping Condition for Monte Carlo Global Illumination"
The basic principle is as follows:
While samples are being added to a pixel, the adaptive sampler writes half
of the samples to a separate buffer. This gives it two separate estimates
of the same pixel, and by comparing their difference it estimates convergence.
Once convergence drops below a given threshold, the pixel is considered done.
When a pixel has not converged yet and needs more samples than the minimum,
its immediate neighbors are also set to take more samples. This is done in order
to more reliably detect sharp features such as caustics. A 3x3 box filter that
is run periodically over the tile buffer is used for that purpose.
After a tile has finished rendering, the values of all passes are scaled as if
they were rendered with the full number of samples. This way, any code operating
on these buffers, for example the denoiser, does not need to be changed for
per-pixel sample counts.
Reviewed By: brecht, #cycles
Differential Revision: https://developer.blender.org/D4686
When running with debug enabled ('-d' argument),
warnings are printed for add-ons which are not yet updated.
Reminder to name things based on what they do,
not the technologies they use :)
This sampling pattern is particularly suited to adaptive sampling, and will
be used for that upcoming feature.
Based on "Progressive Multi-Jittered Sample Sequences" by Per Christensen,
Andrew Kensler and Charlie Kilpatrick.
Ref D4686
This patch adds a new user-configurable option to change at which sample viewport
denoising should kick in. Setting it to zero retains previous behavior (start immediately), while
other values will defer denoising until the particular sample has been reached. Default is now
at one, to avoid the weirdness that is AI denoising at small resolutions.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6906
This simplifies compositors setups and will be consistent with Eevee render
passes from D6331. There's a continuum between these passes and it's not clear
there is much advantage to having them available separately.
Differential Revision: https://developer.blender.org/D6848
The OptiX denoiser can be a great help when rendering in the viewport, since it is really fast
and needs few samples to produce convincing results. This patch therefore adds support for
using any Cycles denoiser in the viewport also (but only the OptiX one is selectable because
the NLM one is too slow to be usable currently). It also adds support for denoising on a
different device than rendering (so one can e.g. render with the CPU but denoise with OptiX).
Reviewed By: #cycles, brecht
Differential Revision: https://developer.blender.org/D6554
This patch adds support for the OptiX denoiser as an alternative to the existing NLM denoiser in Cycles. It's re-using the same denoising architecture based on tiles and therefore implicitly also works with multiple GPUs.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6395
Custom render passes are added in the Shader AOVs panel in the view layer
settings, with a name and data type. In shader nodes, an AOV Output node
is then used to output either a value or color to the pass.
Arbitrary names can be used for these passes, as long as they don't conflict
with built-in passes that are enabled. The AOV Output node can be used in both
material and world shader nodes.
Implemented by Lukas, with tweaks by Brecht.
Differential Revision: https://developer.blender.org/D4837
The cryptomatte sockets were incorrectly numbered using a step size of two. While the increment by two is necessary to get the correct number of render passes, they should be numbered consecutively matching the socket names of the cryptomatte node.
Reviewed By: lukasstockner97
Differential Revision: https://developer.blender.org/D6185
This diff will add support for local view to Cycles rendered preview mode.
Currently the implementation shows same results as EEVEE does. This entails
a difference with Blender 2.79, where lights were automatically added to the
local view. {T69780} describes this should be solved before the next release.
This patch also solves missing `owner_id` issues when using the RNA CPP Api
from Cycles. Cycles didn't provide the `owner_id` making some functionality
fail, what then was worked around in Blender. It also fixes an issue in
`makesrna` where incorrect CPP code was generated when only `PARM_RNAPTR`
was provided.
An optional `view_layer` parameter is added to the `Object.local_view_get`
method to reduce lookups.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5753
This change allows the user to select a renderpass in the 3d viewport.
Added support for external renderers to extend the `View3DShading` struct.
This way Blender doesn't need to know the features an external render engine wants to support.
Note that the View3DShading is also available in the scene->display.shading; although this is
supported, it does not make sense for render engines to put something here as it is really
scene/workbench related.
Currently cycles assumes that it always needs to calculate the combined pass; it ignores the
`pass_flag` in KernelFilm. We could optimize this but that was not in scope of this change
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5689
Add option to change the Intensity of the HDRI in the 3d viewport. This works for both EEVEE and Cycles
Reviewed By: brecht, fclem
Differential Revision: https://developer.blender.org/D5674
This change implements the basics as described in {T68312} for the
shading modes.
* LookDev shading mode is renamed to Material Preview. It always uses Eevee as renderer, and is intended to provide a fast material preview suitable for texture painting, and texture and material setup.
* Rendered shading gains "Use Scene Lights" and "Use Scene World" options similar to current Material Preview. These will be enabled by default. When Use Scene World is turned off, HDRIs will be used for lighting instead. These options are available for EEVEE and Cycles.
* Renderers will be able to customize the shading settings panel and add additional settings.
Reviewed By: brecht, fclem
Differential Revision: https://developer.blender.org/D5612
We want users to go to the current version for their current version
when possible if not point to latest.
/dev should really only be for development related work. End users
should not be browsing /dev unless they are reading about upcoming
features ahead of time.
Am not even sure that it is possible to use fstrings at all when UI
translation is required (that is, is a sensible, reasonable way that
does not make things even more complicated than they already are), but
one thing is certain, this won't be trivial to get it working, so
definitively not a job for now.
Instead just do not use fstrings for UI translatable strings.
This is enabled with bl_use_eevee_viewport = True. It allows external engines
to generate an Cycles/Eevee shader node setup to emulate their materials in
the realtime viewport, or to leave it to users to do manually.
Removed bl_use_exclude_layers and bl_use_shading_nodes that did nothing
anymore. This should not break API compatibility, any scripts setting those
should continue to work the same as before.
Also adds descriptions for some RenderEngine settings.
There is now a checkbox to enable/disable depth of field per camera. For Eevee
this replace the scene level setting. For Cycles there is now only an F-Stop
value, no longer a Radius.
Existing files are converted based on Cycles or Eevee being set in the scene.
Differential Revision: https://developer.blender.org/D4882
For existing files, it will use the setting from Cycles or Eevee depending on
the render engine in the scene.
Differential Revision: https://developer.blender.org/D4874
We can not access ensured-to-be-evaluated dependency graph from the
render API: some of it is running from within evaluation which makes
it possible for engines to access list of evaluated IDs.
Solved by passing dependency graph to viewport functions, similar to
the final render functions.
Main goal here is to make it obvious and predictable about
what is going on.
Summary of changes.
- Access to dependency graph is now only possible to a fully evaluated
graph. This is now done via context.evaluated_depsgraph_get().
The call will ensure both relations and datablocks are updated.
This way we don't allow access to some known bad state of the graph,
and also making explicit that getting update dependency graph is not
cheap.
- Access to evaluated ID is now possible via id.evaluated_get().
It was already possible to get evaluated ID via dependency graph,
but that was a bit confusing why access to original is done via ID
and to evaluated via depsgraph.
If datablock is not covered by dependency graph it will be returned
as-is.
- Similarly, request for original from an ID which is not evaluated
will return ID as-is.
- Removed scene.update().
This is very expensive to update all the view layers.
- Added depsgraph.update().
Now when temporary changes to objects are to be done, this is to
happen on original object and then dependency graph is to be
updated.
- Changed object.to_mesh() to behave the following way:
* When is used for original object modifiers are ignored.
For meshes this acts similar to mesh-copy, not very useful but
allows to keep code paths similar (i.e. for exporter which has
Apply Modifiers option it's only matter choosing between original
and evaluated object, the to_mesh() part can stay the same).
For curves this gives a mesh which is constructed from displist
without taking own modifiers and modifiers of bevel/taper objects
into account.
For metaballs this gives empty mesh.
Polygonization of metaball is not possible from a single object.
* When is used for evaluated object modifiers are always applied.
In fact, no evaluation is happening, the mesh is either copied
as-is, or constructed from current state of curve cache.
Arguments to apply modifiers and calculate original coordinates (ORCO,
aka undeformed coordinates) are removed. The ORCO is to be calculated
as part of dependency graph evaluation.
File used to regression-test (a packed Python script into .blend):
{F7033464}
Patch to make addons tests to pass:
{F7033466}
NOTE: I've included changes to FBX exporter, and those are addressing
report T63689.
NOTE: All the enabled-by-default addons are to be ported still, but
first want to have agreement on this part of changes.
NOTE: Also need to work on documentation for Python API, but, again,
better be done after having agreement on this work.
Reviewers: brecht, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D4834
This is the angular diameter as seen from earth, which is between 0.526° and
0.545° in reality. Sharing the size with other light types did not make much
sense and meant the unit was unclear.
Differential Revision: https://developer.blender.org/D4819
Cycles lights now use strength and color properties of the light outside
of the shading nodes, just like Eevee. The shading nodes then act as a
multiplier on this, and become optional unless textures, fallof or other
effects are desired.
Backwards compatibility is not exact, as we can't be sure which renderer
the .blend was designed for or even if it was designed for a single one.
If the render engine in the active scene is set to Cycles, lights are
converted to ensure overall light strength remains the same, and removing
unnecessary shader node setups that only included a single emission node.
If the engine is set to Eevee, we increase strength to remove the automatic
100x multiplier that was there to match Cycles.
Differential Revision: https://developer.blender.org/D4588
This panel is arguably the most important in the ViewLayer properties, so
the concept of "1 panel open per context" doesn't work. Especially since
the first panel (View Layer) contains only two settings.
This also registers the Passes panels before filter/override so it's sorted in the same way as EEVEE.
This never really worked as it was supposed to. The main goal of this is to
turn noise from sampling tiny hairs into multiple layers of transparency that
do not need to be sampled stochastically. However the implementation of this
worked by randomly discarding hair intersections in BVH traversal, which
defeats the purpose.
If it ever comes back, it's best implemented outside the kernel as a preprocess
that changes hair radius before BVH building. This would also make it work with
Embree, where it's not supported now. But it's not so clear anymore that with
many AA samples and GPU rendering this feature is as helpful as it once was for
CPU raytracers with few AA samples.
The benefit of removing this feature is improved hair ray tracing performance,
tested on NVIDIA Titan Xp:
bmw27: +0.37%
classroom: +0.26%
fishy_cat: -7.36%
koro: -12.98%
pabellon: -0.12%
Differential Revision: https://developer.blender.org/D4532
Shader nodes are now shared with Eevee, so makes more sense to have it in
the core and not be Cycles specific.
Fix T62415: issues with append/link of old Cycles settings.
