In previous Blender version the tile highlight was stored in the
full frame (un-cropped) space. This was changed with the Cycles X
development and now the tiles and render result are always measured
relative to the cropped region.
Differential Revision: https://developer.blender.org/D12779
Previously we would only free animation strip data when doing final
renders. If not doing a final render or simply just playing back videos
in the VSE, we would not free decoders or non VSE cache data from the
strips.
This would lead to memory usage exploding in complex VSE scenes.
Now we instead use the dumb apporach of freeing everything that is not
currently visible.
The related issue which is fixed by this change is the missing noisy
image pass when denoising and border render is used,
Need to allocate passes after the passes has been copied from the
original render result.
Previously this was only loading built-in render passes. Now instead of trying
to load the scene render passes, load whatever passes exist in the cache file.
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
Run into it when was re-working tiles in the Cycles X project.
Make sure the storage of highlighted tiles is emptied when the
render is finished or cancelled).
The error is only possible to happen if the engine did not do
something correct, but is still good to deal with such situations
more gracefully.
Should be no visible change on user side.
Preparing for render parts removal as part of Cycles X project.
Differential Revision: https://developer.blender.org/D12317
The idea is to only allocate pixel storage only when there is an actual
data to be written to them.
This moves the code forward a better support of high-res rendering when
pixel storage is not allocated until render engine is ready to provide
pixel data.
Is expected to be no functional changes for neither users no external
engines. The only difference is that the motion and depth passes will
be displayed as transparent for until render engine provides any tile
result (at which point the pixels will be allocated and initialized to
infinite depth).
Differential Revision: https://developer.blender.org/D12195
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
Also:
* added BMLog function to save mesh IDs.
- Used by SCULPT_UNDO_DYNTOPO_BEGIN/END instead of
saving the whole mesh, which was the previous behavior.
* SCULPT_UNDO_DYNTOPO_BEGIN no longer pushes a non-dyntopo
geomtry undo node, as this is no longer necassary.
This greatly speeds up going into/out of sculpt mode
with dyntopo enabled, as before it was copying
the mesh twice.
This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
In this bug report it resulted in rendering animations stopping too early,
but this affected more areas.
After the previous cleanup commit, it becomes clear that frame and ctime
values were mixed up.
Confusingly, BKE_scene_frame_get did not match the frame number as expected by
BKE_scene_frame_set. Instead it return the value after time remapping, which
is commonly named "ctime".
* Rename BKE_scene_frame_get to BKE_scene_ctime_get
* Add a new BKE_scene_frame_get that matches BKE_scene_frame_set
* Use int/float depending if fractional frame is expected
- Multi-thread BKE_mesh_recalc_looptri.
- Add BKE_mesh_recalc_looptri_with_normals,
this skips having to calculate normals for ngons.
Exact performance depends on number of faces, size of ngons and
available CPU cores.
For high poly meshes the isolated improvement to BKE_mesh_recalc_looptri
in my tests was between 6.7x .. 25.0x, with the largest gains seen in
meshes containing ngons with many sides.
The overall speedup for high poly meshes containing quads and triangles
is only ~20% although ngon heavy meshes can be much faster.
For some custom rendering engines it's advantageous not to write the image files to disk.
An example would be a network rendering engine which does it's own image writing.
This feature is only supported when bl_use_postprocess is also disabled, since render
engines can't influence the saving behavior of the sequencer or compositor.
Differential Revision: https://developer.blender.org/D11512
