tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/intern/cycles/scene/scene.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1008 lines
28 KiB
C++
Raw Normal View History

License headers: use SPDX-FileCopyrightText in intern/cycles
2023-06-14 08:52:36 +02:00
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
*
* SPDX-License-Identifier: Apache-2.0 */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
#include <stdlib.h>
Cycles: Add CPU+GPU rendering support with OptiX Adds support for building multiple BVH types in order to support using both CPU and OptiX devices for rendering simultaneously. Primitive packing for Embree and OptiX is now standalone, so it only needs to be run once and can be shared between the two. Additionally, BVH building was made a device call, so that each device backend can decide how to perform the building. The multi-device for instance creates a special multi-BVH that holds references to several sub-BVHs, one for each sub-device. Reviewed By: brecht, kevindietrich Differential Revision: https://developer.blender.org/D9718
2020-12-10 14:18:25 +01:00
#include "bvh/bvh.h"
Cleanup: `make format` after SortedIncludes change
2020-03-19 09:33:03 +01:00
#include "device/device.h"
Cycles: changes to source code folders structure * Split render/ into scene/ and session/. The scene/ folder now contains the scene and its nodes. The session/ folder contains the render session and associated data structures like drivers and render buffers. * Move top level kernel headers into new folders kernel/camera/, kernel/film/, kernel/light/, kernel/sample/, kernel/util/ * Move integrator related kernel headers into kernel/integrator/ * Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/ For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "scene/alembic.h"
#include "scene/background.h"
#include "scene/bake.h"
#include "scene/camera.h"
#include "scene/curves.h"
Cleanup: make format
2023-04-25 20:18:44 +02:00
#include "scene/devicescene.h"
Cycles: changes to source code folders structure * Split render/ into scene/ and session/. The scene/ folder now contains the scene and its nodes. The session/ folder contains the render session and associated data structures like drivers and render buffers. * Move top level kernel headers into new folders kernel/camera/, kernel/film/, kernel/light/, kernel/sample/, kernel/util/ * Move integrator related kernel headers into kernel/integrator/ * Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/ For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "scene/film.h"
#include "scene/integrator.h"
#include "scene/light.h"
#include "scene/mesh.h"
#include "scene/object.h"
#include "scene/osl.h"
#include "scene/particles.h"
Cycles: pointcloud rendering This add support for rendering of the point cloud object in Blender, as a native geometry type in Cycles that is more memory and time efficient than instancing sphere meshes. This can be useful for rendering sand, water splashes, particles, motion graphics, etc. Points are currently always rendered as spheres, with backface culling. More shapes are likely to be added later, but this is the most important one and can be customized with shaders. For CPU rendering the Embree primitive is used, for GPU there is our own intersection code. Motion blur is suppored. Volumes inside points are not currently supported. Implemented with help from: * Kévin Dietrich: Alembic procedural integration * Patrick Mourse: OptiX integration * Josh Whelchel: update for cycles-x changes Ref T92573 Differential Revision: https://developer.blender.org/D9887
2021-12-01 17:30:46 +01:00
#include "scene/pointcloud.h"
Cycles: changes to source code folders structure * Split render/ into scene/ and session/. The scene/ folder now contains the scene and its nodes. The session/ folder contains the render session and associated data structures like drivers and render buffers. * Move top level kernel headers into new folders kernel/camera/, kernel/film/, kernel/light/, kernel/sample/, kernel/util/ * Move integrator related kernel headers into kernel/integrator/ * Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/ For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "scene/procedural.h"
#include "scene/scene.h"
#include "scene/shader.h"
#include "scene/svm.h"
#include "scene/tables.h"
#include "scene/volume.h"
#include "session/session.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "util/foreach.h"
#include "util/guarded_allocator.h"
#include "util/log.h"
#include "util/progress.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
CCL_NAMESPACE_BEGIN
Code refactor: pass device to scene, check OSL with device info.
2017-10-20 05:08:26 +02:00
Scene::Scene(const SceneParams &params_, Device *device)
Fix (harmless) use of uninitialized variables in Cycles
2020-03-18 17:54:24 +01:00
: name("Scene"),
Fix (apparently harmless) Cycles asan warnings
2021-03-15 18:52:45 +01:00
bvh(NULL),
Fix (harmless) use of uninitialized variables in Cycles
2020-03-18 17:54:24 +01:00
default_surface(NULL),
default_volume(NULL),
default_light(NULL),
default_background(NULL),
default_empty(NULL),
device(device),
dscene(device),
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
params(params_),
Fix (apparently harmless) Cycles asan warnings
2021-03-15 18:52:45 +01:00
update_stats(NULL),
kernels_loaded(false),
/* TODO(sergey): Check if it's indeed optimal value for the split kernel. */
max_closure_global(1)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
{
Cycles: Cleanup, silence strict compiler warning There is one legit place in the code where memcpy was used as an optimization trick. Was needed for older version of GCC, but now it should be re-evaluated and checked if it still helps to have that trick. In other places it's somewhat lazy programming to zero out all object members. That is absolutely unsafe, at the moment when less trivial class is used as a member in that object things will break. Other cases were using memcpy into an object which comes from an external library. We don't control that object, and we can not guarantee it will always be safe for such memory tricks and debugging bugs caused by such low level access is far fun. Ideally we need to use more proper C++, but needs to be done with big care, including benchmarks of each change, For now do annoying but simple cast to void*.
2018-06-11 12:54:17 +02:00
memset((void *)&dscene.data, 0, sizeof(dscene.data));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Add basic support for using OSL with OptiX This patch generalizes the OSL support in Cycles to include GPU device types and adds an implementation for that in the OptiX device. There are some caveats still, including simplified texturing due to lack of OIIO on the GPU and a few missing OSL intrinsics. Note that this is incomplete and missing an update to the OSL library before being enabled! The implementation is already committed now to simplify further development. Maniphest Tasks: T101222 Differential Revision: https://developer.blender.org/D15902
2022-11-09 14:25:32 +01:00
shader_manager = ShaderManager::create(
device->info.has_osl ? params.shadingsystem : SHADINGSYSTEM_SVM, device);
Fix (apparently harmless) Cycles asan warnings
2021-03-15 18:52:45 +01:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
light_manager = new LightManager();
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager = new GeometryManager();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
object_manager = new ObjectManager();
Code refactor: pass device to scene, check OSL with device info.
2017-10-20 05:08:26 +02:00
image_manager = new ImageManager(device->info);
Fix for #32184 and redesign of particle storage in Cycles. The particle data used by the Particle Info node was stored in cycles as a list in each object. This is a problem when the particle emitter mesh is hidden: Objects in cycles are only intended as instances of renderable meshes, so when hiding the emitter mesh the particle data doesn't get stored either. Also the particle data can potentially be copied to multiple instances of the same object, which is a waste of texture space. The solution in this patch is to make a completely separate list of particle systems in the Cycles scene data. This way the particle data can be generated even when the emitter object itself is not visible.
2012-08-31 19:27:08 +02:00
particle_system_manager = new ParticleSystemManager();
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 22:05:07 +01:00
bake_manager = new BakeManager();
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
procedural_manager = new ProceduralManager();
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Fix (apparently harmless) Cycles asan warnings
2021-03-15 18:52:45 +01:00
/* Create nodes after managers, since create_node() can tag the managers. */
camera = create_node<Camera>();
dicing_camera = create_node<Camera>();
lookup_tables = new LookupTables();
film = create_node<Film>();
background = create_node<Background>();
integrator = create_node<Integrator>();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: add a Pass Node The Pass struct is now a Node and the passes are moved from the Film class to the Scene class. The Pass Node only has `type` and `name` as sockets as those seem to be the only properties settable by exporters (other properties are implicit and depend on the pass type). This is part of T79131. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8591
2020-08-18 12:15:46 +02:00
film->add_default(this);
Cycles: add internal default volume shader, to be used for new volume object This is mostly straightforward, but required some refactoring to ensure that the default volume material does not always turn on the volume feature for GPU rendering.
2020-03-11 17:49:00 +01:00
shader_manager->add_default(this);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
}
Scene::~Scene()
{
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
free_memory(true);
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
void Scene::free_memory(bool final)
{
Cycles: Add CPU+GPU rendering support with OptiX Adds support for building multiple BVH types in order to support using both CPU and OptiX devices for rendering simultaneously. Primitive packing for Embree and OptiX is now standalone, so it only needs to be run once and can be shared between the two. Additionally, BVH building was made a device call, so that each device backend can decide how to perform the building. The multi-device for instance creates a special multi-BVH that holds references to several sub-BVHs, one for each sub-device. Reviewed By: brecht, kevindietrich Differential Revision: https://developer.blender.org/D9718
2020-12-10 14:18:25 +01:00
delete bvh;
bvh = NULL;
Cycles: add reference counting to Nodes This adds a reference count to Nodes which is incremented or decremented whenever they are added to or removed from a socket, which will help us track used Nodes throughout the scene graph generically without having to add an explicit count or flag on specific Node types. This is especially useful to track Nodes defined through Procedurals out of Cycles' control. This also modifies the order in which nodes are deleted to ensure that upon deletion, a Node does not attempt to decrement the reference count of another Node which was already freed or deleted. This is not currently used, but will be in the next commit. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:23:34 +02:00
/* The order of deletion is important to make sure data is freed based on possible dependencies
* as the Nodes' reference counts are decremented in the destructors:
*
* - Procedurals can create and hold pointers to any other types.
* - Objects can hold pointers to Geometries and ParticleSystems
* - Lights and Geometries can hold pointers to Shaders.
*
* Similarly, we first delete all nodes and their associated device data, and then the managers
* and their associated device data.
*/
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
foreach (Procedural *p, procedurals)
delete p;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
foreach (Object *o, objects)
delete o;
Cycles: add reference counting to Nodes This adds a reference count to Nodes which is incremented or decremented whenever they are added to or removed from a socket, which will help us track used Nodes throughout the scene graph generically without having to add an explicit count or flag on specific Node types. This is especially useful to track Nodes defined through Procedurals out of Cycles' control. This also modifies the order in which nodes are deleted to ensure that upon deletion, a Node does not attempt to decrement the reference count of another Node which was already freed or deleted. This is not currently used, but will be in the next commit. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:23:34 +02:00
foreach (Geometry *g, geometry)
delete g;
Fix for #32184 and redesign of particle storage in Cycles. The particle data used by the Particle Info node was stored in cycles as a list in each object. This is a problem when the particle emitter mesh is hidden: Objects in cycles are only intended as instances of renderable meshes, so when hiding the emitter mesh the particle data doesn't get stored either. Also the particle data can potentially be copied to multiple instances of the same object, which is a waste of texture space. The solution in this patch is to make a completely separate list of particle systems in the Cycles scene data. This way the particle data can be generated even when the emitter object itself is not visible.
2012-08-31 19:27:08 +02:00
foreach (ParticleSystem *p, particle_systems)
delete p;
Cycles: add reference counting to Nodes This adds a reference count to Nodes which is incremented or decremented whenever they are added to or removed from a socket, which will help us track used Nodes throughout the scene graph generically without having to add an explicit count or flag on specific Node types. This is especially useful to track Nodes defined through Procedurals out of Cycles' control. This also modifies the order in which nodes are deleted to ensure that upon deletion, a Node does not attempt to decrement the reference count of another Node which was already freed or deleted. This is not currently used, but will be in the next commit. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:23:34 +02:00
foreach (Light *l, lights)
delete l;
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
foreach (Pass *p, passes)
delete p;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry.clear();
Fix #34121: OSL + persistent images option was not freeing shader memory properly, causing memory to increase continuously during animation render.
2013-02-14 17:11:47 +01:00
objects.clear();
lights.clear();
particle_systems.clear();
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
procedurals.clear();
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
passes.clear();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
if (device) {
Cycles: Support user-defined shutter curve Previously shutter was instantly opening, staying opened for the shutter time period of time and then instantly closing. This isn't quite how real cameras are working, where shutter is opening with some curve. Now it is possible to define user curve for how much shutter is opened across the sampling period of time. This could be used for example to make motion blur trails softer.
2015-10-27 09:16:04 +01:00
camera->device_free(device, &dscene, this);
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 22:26:43 +02:00
film->device_free(device, &dscene, this);
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
background->device_free(device, &dscene);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
integrator->device_free(device, &dscene, true);
Cycles: add reference counting to Nodes This adds a reference count to Nodes which is incremented or decremented whenever they are added to or removed from a socket, which will help us track used Nodes throughout the scene graph generically without having to add an explicit count or flag on specific Node types. This is especially useful to track Nodes defined through Procedurals out of Cycles' control. This also modifies the order in which nodes are deleted to ensure that upon deletion, a Node does not attempt to decrement the reference count of another Node which was already freed or deleted. This is not currently used, but will be in the next commit. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:23:34 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: add reference counting to Nodes This adds a reference count to Nodes which is incremented or decremented whenever they are added to or removed from a socket, which will help us track used Nodes throughout the scene graph generically without having to add an explicit count or flag on specific Node types. This is especially useful to track Nodes defined through Procedurals out of Cycles' control. This also modifies the order in which nodes are deleted to ensure that upon deletion, a Node does not attempt to decrement the reference count of another Node which was already freed or deleted. This is not currently used, but will be in the next commit. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:23:34 +02:00
if (final) {
delete camera;
delete dicing_camera;
delete film;
delete background;
delete integrator;
}
/* Delete Shaders after every other nodes to ensure that we do not try to decrement the reference
* count on some dangling pointer. */
foreach (Shader *s, shaders)
delete s;
shaders.clear();
/* Now that all nodes have been deleted, we can safely delete managers and device data. */
if (device) {
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
object_manager->device_free(device, &dscene, true);
geometry_manager->device_free(device, &dscene, true);
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 22:26:52 +02:00
shader_manager->device_free(device, &dscene, this);
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
light_manager->device_free(device, &dscene);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
particle_system_manager->device_free(device, &dscene);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 22:05:07 +01:00
bake_manager->device_free(device, &dscene);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (final) {
Code refactor: simplify image device memory allocation.
2017-10-20 04:20:37 +02:00
image_manager->device_free(device);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else {
Code refactor: simplify image device memory allocation.
2017-10-20 04:20:37 +02:00
image_manager->device_free_builtin(device);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 22:26:43 +02:00
lookup_tables->device_free(device, &dscene);
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
if (final) {
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 22:26:43 +02:00
delete lookup_tables;
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
delete object_manager;
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
delete geometry_manager;
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
delete shader_manager;
delete light_manager;
delete particle_system_manager;
delete image_manager;
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 22:05:07 +01:00
delete bake_manager;
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
delete update_stats;
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
delete procedural_manager;
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
}
void Scene::device_update(Device *device_, Progress &progress)
{
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (!device) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
device = device_;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
bool print_stats = need_data_update();
Cycles: Revert all host update specific changes The approach didn't turn out to be that useful after all as there are unavoidable dependencies of data from the device. For example, to know whether object intersects volume or not it is required to run displacement kernels. The way of splitting host and device updates caused state where some data is not yet available, causing confusion and leaving code to be error-prone.
2021-10-21 14:52:34 +02:00
if (update_stats) {
update_stats->clear();
}
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
scoped_callback_timer timer([this, print_stats](double time) {
if (update_stats) {
update_stats->scene.times.add_entry({"device_update", time});
if (print_stats) {
printf("Update statistics:\n%s\n", update_stats->full_report().c_str());
}
}
});
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
/* The order of updates is important, because there's dependencies between
* the different managers, using data computed by previous managers.
*
* - Image manager uploads images used by shaders.
Spelling
2014-08-02 08:53:52 +02:00
* - Camera may be used for adaptive subdivision.
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
* - Displacement shader must have all shader data available.
Fix T38526: crash using blackbody node on background with multiple importance sampling.
2014-02-06 21:09:46 +01:00
* - Light manager needs lookup tables and final mesh data to compute emission CDF.
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
* - Lookup tables are done a second time to handle film tables
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
*/
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
if (film->update_lightgroups(this)) {
light_manager->tag_update(this, ccl::LightManager::LIGHT_MODIFIED);
object_manager->tag_update(this, ccl::ObjectManager::OBJECT_MODIFIED);
Fix #117586: Cycles: World Lightgroup not updated when creating/deleting LGs
2024-02-04 16:25:52 +01:00
background->tag_modified();
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
}
Fix T103170: missing Cycles viewport light threshold update after exposure edit
2022-12-15 19:13:55 +01:00
if (film->exposure_is_modified()) {
integrator->tag_modified();
}
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
progress.set_status("Updating Shaders");
shader_manager->device_update(device, &dscene, this, progress);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
procedural_manager->update(this, progress);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel()) {
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 16:56:19 +01:00
progress.set_status("Updating Background");
background->device_update(device, &dscene, this);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 16:56:19 +01:00
Cycles: Solve dependency between camera and object synchronization IN theory object might depend on camera location (spatial adaptive subdivisions for example) which became not possible to achieve after camera in volume support. Should be no functional changes for artists.
2015-02-02 18:06:31 +01:00
progress.set_status("Updating Camera");
camera->device_update(device, &dscene, this);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Solve dependency between camera and object synchronization IN theory object might depend on camera location (spatial adaptive subdivisions for example) which became not possible to achieve after camera in volume support. Should be no functional changes for artists.
2015-02-02 18:06:31 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: Solve dependency between camera and object synchronization IN theory object might depend on camera location (spatial adaptive subdivisions for example) which became not possible to achieve after camera in volume support. Should be no functional changes for artists.
2015-02-02 18:06:31 +01:00
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager->device_update_preprocess(device, this, progress);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cycles: Fix wrong initialization order of mesh flags and object transform
2016-03-31 17:54:03 +02:00
progress.set_status("Updating Objects");
object_manager->device_update(device, &dscene, this, progress);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Fix T53833: Particle Info node and Displacement Crash The displacement shared was running before particle data was copied to the device causing bad memory access when the particle info node was used. Fix is simply to move particle update before mesh update so the data is available to displacement shaders. (Altho this fixes the crash the particle info node is still mostly useless with displacement for now...)
2018-01-19 04:40:48 +01:00
progress.set_status("Updating Particle Systems");
particle_system_manager->device_update(device, &dscene, this, progress);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Fix T53833: Particle Info node and Displacement Crash The displacement shared was running before particle data was copied to the device causing bad memory access when the particle info node was used. Fix is simply to move particle update before mesh update so the data is available to displacement shaders. (Altho this fixes the crash the particle info node is still mostly useless with displacement for now...)
2018-01-19 04:40:48 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Fix T53833: Particle Info node and Displacement Crash The displacement shared was running before particle data was copied to the device causing bad memory access when the particle info node was used. Fix is simply to move particle update before mesh update so the data is available to displacement shaders. (Altho this fixes the crash the particle info node is still mostly useless with displacement for now...)
2018-01-19 04:40:48 +01:00
Cycles: Fix wrong order in object flags calculations Object flags are depending on bounding box which is only available after mesh synchronization. This was broken since 7fd4c44 which happened quite close to the release and oddly enough was not sopped by anyone. Render test is coming for this. Was spotted by Thomas Dinges while working on another patch.
2015-04-29 22:07:38 +02:00
progress.set_status("Updating Meshes");
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager->device_update(device, &dscene, this, progress);
Cycles: Decouple object flags update to a separate update step This way there's much less cross-references between objects and meshes device update functions. The only thing remained s the object bounds calculation which is needed by bvh update. This could also be decoupled, but it's not that crucial yet because its's how it used to be for ages now.
2014-10-03 12:11:19 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: Decouple object flags update to a separate update step This way there's much less cross-references between objects and meshes device update functions. The only thing remained s the object bounds calculation which is needed by bvh update. This could also be decoupled, but it's not that crucial yet because its's how it used to be for ages now.
2014-10-03 12:11:19 +02:00
Cycles: Fix wrong order in object flags calculations Object flags are depending on bounding box which is only available after mesh synchronization. This was broken since 7fd4c44 which happened quite close to the release and oddly enough was not sopped by anyone. Render test is coming for this. Was spotted by Thomas Dinges while working on another patch.
2015-04-29 22:07:38 +02:00
progress.set_status("Updating Objects Flags");
object_manager->device_update_flags(device, &dscene, this, progress);
Fix T43311: using displacement shader crashes blender Issue was caused by wrong order of scene device update, which could lead to missing object flags in shader kernel. This patch solves a bit more than that making sure objects flags are always properly updated, so adding/removing volume BSDF will properly reflect on viewport where camera might become being in volume and so.
2015-01-19 15:08:58 +01:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: MetalRT support (kernel side) This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code: - MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`. - MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers. - Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13353
2021-11-29 16:06:22 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: MetalRT support (kernel side) This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code: - MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`. - MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers. - Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D13353
2021-11-29 16:06:22 +01:00
progress.set_status("Updating Primitive Offsets");
object_manager->device_update_prim_offsets(device, &dscene, this);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Fix T43311: using displacement shader crashes blender Issue was caused by wrong order of scene device update, which could lead to missing object flags in shader kernel. This patch solves a bit more than that making sure objects flags are always properly updated, so adding/removing volume BSDF will properly reflect on viewport where camera might become being in volume and so.
2015-01-19 15:08:58 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Fix T43311: using displacement shader crashes blender Issue was caused by wrong order of scene device update, which could lead to missing object flags in shader kernel. This patch solves a bit more than that making sure objects flags are always properly updated, so adding/removing volume BSDF will properly reflect on viewport where camera might become being in volume and so.
2015-01-19 15:08:58 +01:00
Cycles: Synchronize images after building mesh BVH This way memory overhead caused by the BVH building is not so visible and peak memory usage will be reduced. Implementing this idea is not so straightforward actually, because we need to synchronize images used for true displacement before meshes. Detecting whether image is used for true displacement is not so striaghtforward, so for now all all displacement types will synchronize images used for them. Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after the patch). Reviewers: campbellbarton, juicyfruit, brecht Subscribers: eyecandy Differential Revision: https://developer.blender.org/D1217
2015-04-02 17:37:57 +02:00
progress.set_status("Updating Images");
Code refactor: simplify image device memory allocation.
2017-10-20 04:20:37 +02:00
image_manager->device_update(device, this, progress);
Cycles: Synchronize images after building mesh BVH This way memory overhead caused by the BVH building is not so visible and peak memory usage will be reduced. Implementing this idea is not so straightforward actually, because we need to synchronize images used for true displacement before meshes. Detecting whether image is used for true displacement is not so striaghtforward, so for now all all displacement types will synchronize images used for them. Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after the patch). Reviewers: campbellbarton, juicyfruit, brecht Subscribers: eyecandy Differential Revision: https://developer.blender.org/D1217
2015-04-02 17:37:57 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Synchronize images after building mesh BVH This way memory overhead caused by the BVH building is not so visible and peak memory usage will be reduced. Implementing this idea is not so straightforward actually, because we need to synchronize images used for true displacement before meshes. Detecting whether image is used for true displacement is not so striaghtforward, so for now all all displacement types will synchronize images used for them. Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after the patch). Reviewers: campbellbarton, juicyfruit, brecht Subscribers: eyecandy Differential Revision: https://developer.blender.org/D1217
2015-04-02 17:37:57 +02:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: Synchronize images after building mesh BVH This way memory overhead caused by the BVH building is not so visible and peak memory usage will be reduced. Implementing this idea is not so straightforward actually, because we need to synchronize images used for true displacement before meshes. Detecting whether image is used for true displacement is not so striaghtforward, so for now all all displacement types will synchronize images used for them. Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after the patch). Reviewers: campbellbarton, juicyfruit, brecht Subscribers: eyecandy Differential Revision: https://developer.blender.org/D1217
2015-04-02 17:37:57 +02:00
Cycles: Solve dependency between camera and object synchronization IN theory object might depend on camera location (spatial adaptive subdivisions for example) which became not possible to achieve after camera in volume support. Should be no functional changes for artists.
2015-02-02 18:06:31 +01:00
progress.set_status("Updating Camera Volume");
camera->device_update_volume(device, &dscene, this);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Solve dependency between camera and object synchronization IN theory object might depend on camera location (spatial adaptive subdivisions for example) which became not possible to achieve after camera in volume support. Should be no functional changes for artists.
2015-02-02 18:06:31 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cleanup: trailing space
2018-11-24 22:01:14 +01:00
Fix T38526: crash using blackbody node on background with multiple importance sampling.
2014-02-06 21:09:46 +01:00
progress.set_status("Updating Lookup Tables");
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
lookup_tables->device_update(device, &dscene, this);
Fix T38526: crash using blackbody node on background with multiple importance sampling.
2014-02-06 21:09:46 +01:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Fix T38526: crash using blackbody node on background with multiple importance sampling.
2014-02-06 21:09:46 +01:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
progress.set_status("Updating Lights");
light_manager->device_update(device, &dscene, this, progress);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Fix T47813: Cycles Standalone not respecting integrator sample_clamp_direct
2016-04-13 10:39:21 +02:00
progress.set_status("Updating Integrator");
integrator->device_update(device, &dscene, this);
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
Fix T47813: Cycles Standalone not respecting integrator sample_clamp_direct
2016-04-13 10:39:21 +02:00
progress.set_status("Updating Film");
film->device_update(device, &dscene, this);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
progress.set_status("Updating Lookup Tables");
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
lookup_tables->device_update(device, &dscene, this);
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Fix T39114: cycles lamp ray visibility not working. Thanks to Thomas for finding the cause.
2014-03-12 18:20:42 +01:00
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 22:05:07 +01:00
progress.set_status("Updating Baking");
bake_manager->device_update(device, &dscene, this, progress);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (progress.get_cancel() || device->have_error()) {
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
return;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 22:05:07 +01:00
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
if (device->have_error() == false) {
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
dscene.data.volume_stack_size = get_volume_stack_size();
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
progress.set_status("Updating Device", "Writing constant memory");
Cleanup: renaming and consistency for kernel data * Rename "texture" to "data array". This has not used textures for a long time, there are just global memory arrays now. (On old CUDA GPUs there was a cache for textures but not global memory, so we used to put all data in textures.) * For CUDA and HIP, put globals in KernelParams struct like other devices. * Drop __ prefix for data array names, no possibility for naming conflict now that these are in a struct.
2022-06-17 17:16:37 +02:00
device->const_copy_to("data", &dscene.data, sizeof(dscene.data));
Cycles: Early output from Scene::device_update when device error occurs This way for example we wouldn't wait a fortune while BVH is building after GPU run out of memory when loading images just to see the render failure message.
2014-12-05 17:00:05 +01:00
}
Cycles: Report system memory usage and peak after scene device update This only happens when built with WITH_CYCLES_DEBUG flag, memory statistics is coming from guarded STL allocator.
2015-02-14 15:39:14 +01:00
Cycles: Apple Silicon optimization to specialize intersection kernels The Metal backend now compiles and caches a second set of kernels which are optimized for scene contents, enabled for Apple Silicon. The implementation supports doing this both for intersection and shading kernels. However this is currently only enabled for intersection kernels that are quick to compile, and already give a good speedup. Enabling this for shading kernels would be faster still, however this also causes a long wait times and would need a good user interface to control this. M1 Max samples per minute (macOS 13.0): PSO_GENERIC PSO_SPECIALIZED_INTERSECT PSO_SPECIALIZED_SHADE barbershop_interior 83.4 89.5 93.7 bmw27 1486.1 1671.0 1825.8 classroom 175.2 196.8 206.3 fishy_cat 674.2 704.3 719.3 junkshop 205.4 212.0 257.7 koro 310.1 336.1 342.8 monster 376.7 418.6 424.1 pabellon 273.5 325.4 339.8 sponza 830.6 929.6 1142.4 victor 86.7 96.4 96.3 wdas_cloud 111.8 112.7 183.1 Code contributed by Jason Fielder, Morteza Mostajabodaveh and Michael Jones Differential Revision: https://developer.blender.org/D14645
2022-07-12 15:32:46 +02:00
device->optimize_for_scene(this);
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
if (print_stats) {
Cycles: Add human readable sizes to debug output Some of these values can get quite large and are hard to read, adding this makes it easy to read them at a glance. Reviewed By: sergey Differential Revision: https://developer.blender.org/D2039
2016-05-30 00:02:05 +02:00
size_t mem_used = util_guarded_get_mem_used();
size_t mem_peak = util_guarded_get_mem_peak();
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_INFO << "System memory statistics after full device sync:\n"
<< " Usage: " << string_human_readable_number(mem_used) << " ("
<< string_human_readable_size(mem_used) << ")\n"
<< " Peak: " << string_human_readable_number(mem_peak) << " ("
<< string_human_readable_size(mem_peak) << ")";
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
}
Cycles: add support for volume motion blur This adds support for rendering motion blur for volumes, using their velocity field. This works for fluid simulations and imported VDB volumes. For the latter, the name of the velocity field can be set per volume object, with automatic detection of velocity fields that are split into 3 scalar grids. A new parameter is also added to scale velocity for more artistic control. Like for Alembic and USD caches, a parameter to set the unit of time in which the velocity vectors are expressed is also added. For Blender gas simulations, the velocity unit should always be in seconds, so this is only exposed for volume objects which may come from external OpenVDB files. These parameters are available under the `Render` panels for the fluid domain and the volume object data properties respectively. Credits: kernel advection code from Tangent Animation's Blackbird based on earlier work by Geraldine Chua Differential Revision: https://developer.blender.org/D14629
2022-04-19 16:28:14 +02:00
Scene::MotionType Scene::need_motion() const
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
{
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (integrator->get_motion_blur()) {
Code cleanup: remove test code to disable motion blur, no longer useful.
2018-01-12 19:56:52 +01:00
return MOTION_BLUR;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else if (Pass::contains(passes, PASS_MOTION)) {
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
return MOTION_PASS;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else {
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
return MOTION_NONE;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
}
Cycles: add support for motion blurring of fluid meshes. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2063
2016-07-16 18:56:59 +02:00
float Scene::motion_shutter_time()
{
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (need_motion() == Scene::MOTION_PASS) {
Cycles: add support for motion blurring of fluid meshes. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2063
2016-07-16 18:56:59 +02:00
return 2.0f;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else {
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
return camera->get_shuttertime();
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: add support for motion blurring of fluid meshes. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2063
2016-07-16 18:56:59 +02:00
}
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
bool Scene::need_global_attribute(AttributeStandard std)
{
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (std == ATTR_STD_UV) {
Cycles: add a Pass Node The Pass struct is now a Node and the passes are moved from the Film class to the Scene class. The Pass Node only has `type` and `name` as sockets as those seem to be the only properties settable by exporters (other properties are implicit and depend on the pass type). This is part of T79131. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8591
2020-08-18 12:15:46 +02:00
return Pass::contains(passes, PASS_UV);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else if (std == ATTR_STD_MOTION_VERTEX_POSITION) {
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
return need_motion() != MOTION_NONE;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
else if (std == ATTR_STD_MOTION_VERTEX_NORMAL) {
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
return need_motion() == MOTION_BLUR;
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: add support for volume motion blur This adds support for rendering motion blur for volumes, using their velocity field. This works for fluid simulations and imported VDB volumes. For the latter, the name of the velocity field can be set per volume object, with automatic detection of velocity fields that are split into 3 scalar grids. A new parameter is also added to scale velocity for more artistic control. Like for Alembic and USD caches, a parameter to set the unit of time in which the velocity vectors are expressed is also added. For Blender gas simulations, the velocity unit should always be in seconds, so this is only exposed for volume objects which may come from external OpenVDB files. These parameters are available under the `Render` panels for the fluid domain and the volume object data properties respectively. Credits: kernel advection code from Tangent Animation's Blackbird based on earlier work by Geraldine Chua Differential Revision: https://developer.blender.org/D14629
2022-04-19 16:28:14 +02:00
else if (std == ATTR_STD_VOLUME_VELOCITY || std == ATTR_STD_VOLUME_VELOCITY_X ||
std == ATTR_STD_VOLUME_VELOCITY_Y || std == ATTR_STD_VOLUME_VELOCITY_Z)
{
return need_motion() != MOTION_NONE;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
return false;
}
void Scene::need_global_attributes(AttributeRequestSet &attributes)
{
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
for (int std = ATTR_STD_NONE; std < ATTR_STD_NUM; std++) {
if (need_global_attribute((AttributeStandard)std)) {
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
attributes.add((AttributeStandard)std);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
}
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 14:49:26 +02:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
bool Scene::need_update()
{
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
return (need_reset() || film->is_modified());
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
}
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
bool Scene::need_data_update()
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
{
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
return (background->is_modified() || image_manager->need_update() ||
object_manager->need_update() || geometry_manager->need_update() ||
light_manager->need_update() || lookup_tables->need_update() ||
integrator->is_modified() || shader_manager->need_update() ||
particle_system_manager->need_update() || bake_manager->need_update() ||
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
film->is_modified() || procedural_manager->need_update());
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
}
Cycles: add Path Guiding on CPU through Intel OpenPGL This adds path guiding features into Cycles by integrating Intel's Open Path Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the render properties. This feature helps reduce noise in scenes where finding a path to light is difficult for regular path tracing. The current implementation supports guiding directional sampling decisions on surfaces, when the material contains a least one diffuse component, and in volumes with isotropic and anisotropic Henyey-Greenstein phase functions. On surfaces, the guided sampling decision is proportional to the product of the incident radiance and the normal-oriented cosine lobe and in volumes it is proportional to the product of the incident radiance and the phase function. The incident radiance field of a scene is learned and updated during rendering after each per-frame rendering iteration/progression. At the moment, path guiding is only supported by the CPU backend. Support for GPU backends will be added in future versions of OpenPGL. Ref T92571 Differential Revision: https://developer.blender.org/D15286
2022-09-21 17:58:34 +02:00
bool Scene::need_reset(const bool check_camera)
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
{
Cycles: add Path Guiding on CPU through Intel OpenPGL This adds path guiding features into Cycles by integrating Intel's Open Path Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the render properties. This feature helps reduce noise in scenes where finding a path to light is difficult for regular path tracing. The current implementation supports guiding directional sampling decisions on surfaces, when the material contains a least one diffuse component, and in volumes with isotropic and anisotropic Henyey-Greenstein phase functions. On surfaces, the guided sampling decision is proportional to the product of the incident radiance and the normal-oriented cosine lobe and in volumes it is proportional to the product of the incident radiance and the phase function. The incident radiance field of a scene is learned and updated during rendering after each per-frame rendering iteration/progression. At the moment, path guiding is only supported by the CPU backend. Support for GPU backends will be added in future versions of OpenPGL. Ref T92571 Differential Revision: https://developer.blender.org/D15286
2022-09-21 17:58:34 +02:00
return need_data_update() || (check_camera && camera->is_modified());
Cycles: Reduce verbosity of logging Mainly makes logging less verbose when doing progressive sampling in viewport. Such kind of verbosity is not really possible to be filtered out with `grep` so let's reshuffle few lines of code.
2016-04-22 10:55:26 +02:00
}
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
void Scene::reset()
{
Fix #34121: OSL + persistent images option was not freeing shader memory properly, causing memory to increase continuously during animation render.
2013-02-14 17:11:47 +01:00
shader_manager->reset(this);
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
shader_manager->add_default(this);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
/* ensure all objects are updated */
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
camera->tag_modified();
dicing_camera->tag_modified();
film->tag_modified();
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
background->tag_modified();
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
background->tag_update(this);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
integrator->tag_update(this, Integrator::UPDATE_ALL);
object_manager->tag_update(this, ObjectManager::UPDATE_ALL);
geometry_manager->tag_update(this, GeometryManager::UPDATE_ALL);
light_manager->tag_update(this, LightManager::UPDATE_ALL);
Fix T40429: cycles CUDA + use persistent images problem.
2014-06-05 17:39:16 +02:00
particle_system_manager->tag_update(this);
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
procedural_manager->tag_update();
Cycles: persistent images option This option enables keeping loaded images in the memory in-between of rendering. Implemented by keeping render engine alive for until Render structure is being freed. Cycles will free all data when render finishes, optionally keeping image manager untouched. All shaders, meshes, objects will be re-allocated next time rendering happens. Cycles cession and scene will be re-created from scratch if render/ scene parameters were changed. This will also allow to keep compiled OSL shaders in memory without need to re-compile them again. P.S. Performance panel could be cleaned up a bit, not so much happy with it's vertical alignment currently but not sure how to make it look better. P.P.S. Currently the only way to free images from the device is to disable Persistent Images option and start rendering.
2012-11-09 09:46:53 +01:00
}
void Scene::device_free()
{
free_memory(false);
}
Cycles: Initial implementation of detailed statistics 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
2018-07-27 15:46:13 +02:00
void Scene::collect_statistics(RenderStats *stats)
{
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager->collect_statistics(this, stats);
Cycles: Initial implementation of detailed statistics 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
2018-07-27 15:46:13 +02:00
image_manager->collect_statistics(stats);
}
Cycles: add time statistics to scene update Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update. The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.). This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas. The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8596
2020-10-01 23:16:01 +02:00
void Scene::enable_update_stats()
{
if (!update_stats) {
update_stats = new SceneUpdateStats();
}
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
void Scene::update_kernel_features()
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
{
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
if (!need_update()) {
return;
}
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Fix frozen image editor when Cycles compiles kernels It is possible that the image editor redraw happens prior to the "Loading render kernels" status is reported from status but after the display driver is created. This will make the image editor to wait on the scene mutex to update the display pass in the film. If it happens to be that the kernels are actually to be compiled then the Blender interface appears to be completely frozen, without any information line in the image editor. This change makes it so the amount of time the scene mutex is held during the kernel compilation is minimal. It is a bit unideal to unlock and re-lock the scene mutex in the middle of update, while nested reset mutex is held, but this is already what is needed for the OptiX denoiser optimization some lines below. We can probably reduce the lifetime of some locks, avoiding such potential out-of-order re-locking. Doing so is outside of the scope of this patch. The scene update only happens from the single place in the session, which makes it easy to ensure the kernels are loaded prior the rest of the scene update. Not only this change makes it so that the "Loading render kernels" status appears in the image editor, but also allows to pan and zoom in the image editor, potentially allowing artists to re-adjust their point of interest. Differential Revision: https://developer.blender.org/D16581
2022-11-22 18:59:32 +01:00
thread_scoped_lock scene_lock(mutex);
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
/* These features are not being tweaked as often as shaders,
* so could be done selective magic for the viewport as well. */
uint kernel_features = shader_manager->get_kernel_features(this);
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
bool use_motion = need_motion() == Scene::MotionType::MOTION_BLUR;
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
kernel_features |= KERNEL_FEATURE_PATH_TRACING;
if (params.hair_shape == CURVE_THICK) {
kernel_features |= KERNEL_FEATURE_HAIR_THICK;
}
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
Cleanup: spelling in comments
2022-06-30 04:14:22 +02:00
/* Figure out whether the scene will use shader ray-trace we need at least
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
* one caustic light, one caustic caster and one caustic receiver to use
Cleanup: spelling in comments
2022-06-30 04:14:22 +02:00
* and enable the MNEE code path. */
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
bool has_caustics_receiver = false;
bool has_caustics_caster = false;
bool has_caustics_light = false;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
foreach (Object *object, objects) {
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
if (object->get_is_caustics_caster()) {
has_caustics_caster = true;
}
else if (object->get_is_caustics_receiver()) {
has_caustics_receiver = true;
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
Geometry *geom = object->get_geometry();
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
if (use_motion) {
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
if (object->use_motion() || geom->get_use_motion_blur()) {
kernel_features |= KERNEL_FEATURE_OBJECT_MOTION;
}
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
if (object->get_is_shadow_catcher()) {
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
kernel_features |= KERNEL_FEATURE_SHADOW_CATCHER;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
if (geom->is_mesh()) {
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
#ifdef WITH_OPENSUBDIV
Cleanup: compiler warning when building without OpenSubdiv
2021-10-26 15:38:37 +02:00
Mesh *mesh = static_cast<Mesh *>(geom);
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
if (mesh->get_subdivision_type() != Mesh::SUBDIVISION_NONE) {
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
kernel_features |= KERNEL_FEATURE_PATCH_EVALUATION;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
#endif
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
else if (geom->is_hair()) {
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
kernel_features |= KERNEL_FEATURE_HAIR;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles: pointcloud rendering This add support for rendering of the point cloud object in Blender, as a native geometry type in Cycles that is more memory and time efficient than instancing sphere meshes. This can be useful for rendering sand, water splashes, particles, motion graphics, etc. Points are currently always rendered as spheres, with backface culling. More shapes are likely to be added later, but this is the most important one and can be customized with shaders. For CPU rendering the Embree primitive is used, for GPU there is our own intersection code. Motion blur is suppored. Volumes inside points are not currently supported. Implemented with help from: * Kévin Dietrich: Alembic procedural integration * Patrick Mourse: OptiX integration * Josh Whelchel: update for cycles-x changes Ref T92573 Differential Revision: https://developer.blender.org/D9887
2021-12-01 17:30:46 +01:00
else if (geom->is_pointcloud()) {
kernel_features |= KERNEL_FEATURE_POINTCLOUD;
}
Fix hiding receiver disabling light/shadow linking Turns out it is not enough to check for the receiver/blocker set, as the object might be hidden. This should not change the light behavior. Pull Request: https://projects.blender.org/blender/blender/pulls/108307
2023-05-26 12:21:44 +02:00
if (object->has_light_linking()) {
Cycles: light and shadow linking With light linking, lights can be set to affect only specific objects in the scene. Shadow linking additionally gives control over which objects acts a shadow blockers for a light. Usage: https://wiki.blender.org/wiki/Reference/Release_Notes/4.0/Cycles Implementation: https://wiki.blender.org/wiki/Source/Render/Cycles/LightLinking Ref #104972 Co-authored-by: Brecht Van Lommel <brecht@blender.org>
2023-05-24 13:36:13 +02:00
kernel_features |= KERNEL_FEATURE_LIGHT_LINKING;
}
Fix hiding receiver disabling light/shadow linking Turns out it is not enough to check for the receiver/blocker set, as the object might be hidden. This should not change the light behavior. Pull Request: https://projects.blender.org/blender/blender/pulls/108307
2023-05-26 12:21:44 +02:00
if (object->has_shadow_linking()) {
Cycles: light and shadow linking With light linking, lights can be set to affect only specific objects in the scene. Shadow linking additionally gives control over which objects acts a shadow blockers for a light. Usage: https://wiki.blender.org/wiki/Reference/Release_Notes/4.0/Cycles Implementation: https://wiki.blender.org/wiki/Source/Render/Cycles/LightLinking Ref #104972 Co-authored-by: Brecht Van Lommel <brecht@blender.org>
2023-05-24 13:36:13 +02:00
kernel_features |= KERNEL_FEATURE_SHADOW_LINKING;
}
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
foreach (Light *light, lights) {
if (light->get_use_caustics()) {
has_caustics_light = true;
}
Fix hiding receiver disabling light/shadow linking Turns out it is not enough to check for the receiver/blocker set, as the object might be hidden. This should not change the light behavior. Pull Request: https://projects.blender.org/blender/blender/pulls/108307
2023-05-26 12:21:44 +02:00
if (light->has_light_linking()) {
kernel_features |= KERNEL_FEATURE_LIGHT_LINKING;
}
if (light->has_shadow_linking()) {
kernel_features |= KERNEL_FEATURE_SHADOW_LINKING;
}
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
}
dscene.data.integrator.use_caustics = false;
if (has_caustics_caster && has_caustics_receiver && has_caustics_light) {
dscene.data.integrator.use_caustics = true;
Fix Cycles MNEE not working for Metal Move MNEE to own kernel, separate from shader ray-tracing. This does introduce the limitation that a shader can't use both MNEE and AO/bevel, but that seems like the better trade-off for now. We can experiment with bigger kernel organization changes later. Differential Revision: https://developer.blender.org/D15070
2022-05-30 18:04:14 +02:00
kernel_features |= KERNEL_FEATURE_MNEE;
Cycles: approximate shadow caustics using manifold next event estimation This adds support for selective rendering of caustics in shadows of refractive objects. Example uses are rendering of underwater caustics and eye caustics. This is based on "Manifold Next Event Estimation", a method developed for production rendering. The idea is to selectively enable shadow caustics on a few objects in the scene where they have a big visual impact, without impacting render performance for the rest of the scene. The Shadow Caustic option must be manually enabled on light, caustic receiver and caster objects. For such light paths, the Filter Glossy option will be ignored and replaced by sharp caustics. Currently this method has a various limitations: * Only caustics in shadows of refractive objects work, which means no caustics from reflection or caustics that outside shadows. Only up to 4 refractive caustic bounces are supported. * Caustic caster objects should have smooth normals. * Not currently support for Metal GPU rendering. In the future this method may be extended for more general caustics. TECHNICAL DETAILS This code adds manifold next event estimation through refractive surface(s) as a new sampling technique for direct lighting, i.e. finding the point on the refractive surface(s) along the path to a light sample, which satisfies Fermat's principle for a given microfacet normal and the path's end points. This technique involves walking on the "specular manifold" using a pseudo newton solver. Such a manifold is defined by the specular constraint matrix from the manifold exploration framework [2]. For each refractive interface, this constraint is defined by enforcing that the generalized half-vector projection onto the interface local tangent plane is null. The newton solver guides the walk by linearizing the manifold locally before reprojecting the linear solution onto the refractive surface. See paper [1] for more details about the technique itself and [3] for the half-vector light transport formulation, from which it is derived. [1] Manifold Next Event Estimation Johannes Hanika, Marc Droske, and Luca Fascione. 2015. Comput. Graph. Forum 34, 4 (July 2015), 87–97. https://jo.dreggn.org/home/2015_mnee.pdf [2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport Wenzel Jakob and Steve Marschner. 2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages. https://www.cs.cornell.edu/projects/manifolds-sg12/ [3] The Natural-Constraint Representation of the Path Space for Efficient Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages. https://cg.ivd.kit.edu/english/HSLT.php The code for this samping technique was inserted at the light sampling stage (direct lighting). If the walk is successful, it turns off path regularization using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells the integrator not to blur the brdf roughness further down the path (in a child ray created from BSDF sampling). In addition, using a cascading mechanism of flag values, we cull connections to caustic lights for this and children rays, which should be resolved through MNEE. This mechanism also cancels the MIS bsdf counter part at the casutic receiver depth, in essence leaving MNEE as the only sampling technique from receivers through refractive casters to caustic lights. This choice might not be optimal when the light gets large wrt to the receiver, though this is usually not when you want to use MNEE. This connection culling strategy removes a fair amount of fireflies, at the cost of introducing a slight bias. Because of the selective nature of the culling mechanism, reflective caustics still benefit from the native path regularization, which further removes fireflies on other surfaces (bouncing light off casters). Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
}
Cycles: add Path Guiding on CPU through Intel OpenPGL This adds path guiding features into Cycles by integrating Intel's Open Path Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the render properties. This feature helps reduce noise in scenes where finding a path to light is difficult for regular path tracing. The current implementation supports guiding directional sampling decisions on surfaces, when the material contains a least one diffuse component, and in volumes with isotropic and anisotropic Henyey-Greenstein phase functions. On surfaces, the guided sampling decision is proportional to the product of the incident radiance and the normal-oriented cosine lobe and in volumes it is proportional to the product of the incident radiance and the phase function. The incident radiance field of a scene is learned and updated during rendering after each per-frame rendering iteration/progression. At the moment, path guiding is only supported by the CPU backend. Support for GPU backends will be added in future versions of OpenPGL. Ref T92571 Differential Revision: https://developer.blender.org/D15286
2022-09-21 17:58:34 +02:00
if (integrator->get_guiding_params(device).use) {
kernel_features |= KERNEL_FEATURE_PATH_GUIDING;
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
if (bake_manager->get_baking()) {
kernel_features |= KERNEL_FEATURE_BAKING;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
kernel_features |= film->get_kernel_features(this);
Cleanup: compiler warnings
2021-10-26 15:30:12 +02:00
kernel_features |= integrator->get_kernel_features();
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
dscene.data.kernel_features = kernel_features;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
/* Currently viewport render is faster with higher max_closures, needs investigating. */
const uint max_closures = (params.background) ? get_max_closure_count() : MAX_CLOSURE;
dscene.data.max_closures = max_closures;
dscene.data.max_shaders = shaders.size();
}
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
bool Scene::update(Progress &progress)
{
if (!need_update()) {
return false;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
Cycles: Revert all host update specific changes The approach didn't turn out to be that useful after all as there are unavoidable dependencies of data from the device. For example, to know whether object intersects volume or not it is required to run displacement kernels. The way of splitting host and device updates caused state where some data is not yet available, causing confusion and leaving code to be error-prone.
2021-10-21 14:52:34 +02:00
/* Upload scene data to the GPU. */
progress.set_status("Updating Scene");
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
MEM_GUARDED_CALL(&progress, device_update, device, progress);
return true;
}
static void log_kernel_features(const uint features)
{
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_INFO << "Requested features:\n";
VLOG_INFO << "Use BSDF " << string_from_bool(features & KERNEL_FEATURE_NODE_BSDF) << "\n";
VLOG_INFO << "Use Emission " << string_from_bool(features & KERNEL_FEATURE_NODE_EMISSION)
<< "\n";
VLOG_INFO << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_NODE_VOLUME) << "\n";
VLOG_INFO << "Use Bump " << string_from_bool(features & KERNEL_FEATURE_NODE_BUMP) << "\n";
VLOG_INFO << "Use Voronoi " << string_from_bool(features & KERNEL_FEATURE_NODE_VORONOI_EXTRA)
<< "\n";
VLOG_INFO << "Use Shader Raytrace " << string_from_bool(features & KERNEL_FEATURE_NODE_RAYTRACE)
<< "\n";
Clean up: Fix spacing on Cycles debug message "Use MNEE" This changes the Cycles Debug message for "Use MNEE" from: "Use MNEEFalse" to "Use MNEE False" Pull Request: https://projects.blender.org/blender/blender/pulls/107269
2023-04-24 08:49:14 +02:00
VLOG_INFO << "Use MNEE " << string_from_bool(features & KERNEL_FEATURE_MNEE) << "\n";
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_INFO << "Use Transparent " << string_from_bool(features & KERNEL_FEATURE_TRANSPARENT)
<< "\n";
VLOG_INFO << "Use Denoising " << string_from_bool(features & KERNEL_FEATURE_DENOISING) << "\n";
VLOG_INFO << "Use Path Tracing " << string_from_bool(features & KERNEL_FEATURE_PATH_TRACING)
<< "\n";
VLOG_INFO << "Use Hair " << string_from_bool(features & KERNEL_FEATURE_HAIR) << "\n";
VLOG_INFO << "Use Pointclouds " << string_from_bool(features & KERNEL_FEATURE_POINTCLOUD)
<< "\n";
VLOG_INFO << "Use Object Motion " << string_from_bool(features & KERNEL_FEATURE_OBJECT_MOTION)
<< "\n";
VLOG_INFO << "Use Baking " << string_from_bool(features & KERNEL_FEATURE_BAKING) << "\n";
VLOG_INFO << "Use Subsurface " << string_from_bool(features & KERNEL_FEATURE_SUBSURFACE) << "\n";
VLOG_INFO << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_VOLUME) << "\n";
VLOG_INFO << "Use Patch Evaluation "
<< string_from_bool(features & KERNEL_FEATURE_PATCH_EVALUATION) << "\n";
VLOG_INFO << "Use Shadow Catcher " << string_from_bool(features & KERNEL_FEATURE_SHADOW_CATCHER)
<< "\n";
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
}
Fix frozen image editor when Cycles compiles kernels It is possible that the image editor redraw happens prior to the "Loading render kernels" status is reported from status but after the display driver is created. This will make the image editor to wait on the scene mutex to update the display pass in the film. If it happens to be that the kernels are actually to be compiled then the Blender interface appears to be completely frozen, without any information line in the image editor. This change makes it so the amount of time the scene mutex is held during the kernel compilation is minimal. It is a bit unideal to unlock and re-lock the scene mutex in the middle of update, while nested reset mutex is held, but this is already what is needed for the OptiX denoiser optimization some lines below. We can probably reduce the lifetime of some locks, avoiding such potential out-of-order re-locking. Doing so is outside of the scope of this patch. The scene update only happens from the single place in the session, which makes it easy to ensure the kernels are loaded prior the rest of the scene update. Not only this change makes it so that the "Loading render kernels" status appears in the image editor, but also allows to pan and zoom in the image editor, potentially allowing artists to re-adjust their point of interest. Differential Revision: https://developer.blender.org/D16581
2022-11-22 18:59:32 +01:00
bool Scene::load_kernels(Progress &progress)
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
{
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
update_kernel_features();
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
const uint kernel_features = dscene.data.kernel_features;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
if (!kernels_loaded || loaded_kernel_features != kernel_features) {
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
progress.set_status("Loading render kernels (may take a few minutes the first time)");
scoped_timer timer;
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
log_kernel_features(kernel_features);
if (!device->load_kernels(kernel_features)) {
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
string message = device->error_message();
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
if (message.empty()) {
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
message = "Failed loading render kernel, see console for errors";
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 01:01:48 +02:00
}
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
progress.set_error(message);
progress.set_status(message);
progress.set_update();
return false;
}
kernels_loaded = true;
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
loaded_kernel_features = kernel_features;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
return true;
}
return false;
}
int Scene::get_max_closure_count()
{
if (shader_manager->use_osl()) {
/* OSL always needs the maximum as we can't predict the
* number of closures a shader might generate. */
return MAX_CLOSURE;
}
int max_closures = 0;
for (int i = 0; i < shaders.size(); i++) {
Shader *shader = shaders[i];
Cycles: use reference count to detect used shaders Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.). This usage detection is done before updating the Scene, however it fails at detecting Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party applications), as Procedurals are only updated after the shaders are compiled. To remedy this, we now use the Node reference counting mechanism to detect whether a Shader is used and therefore should be compiled. This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however, since it would also update the Shader ids, this is now performed in `ShaderManager::device_update`, and a new virtual `device_update_specific` method was added to handle device updates for SVM and OSL. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:34:56 +02:00
if (shader->reference_count()) {
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
int num_closures = shader->graph->get_num_closures();
max_closures = max(max_closures, num_closures);
}
}
max_closure_global = max(max_closure_global, max_closures);
if (max_closure_global > MAX_CLOSURE) {
/* This is usually harmless as more complex shader tend to get many
* closures discarded due to mixing or low weights. We need to limit
* to MAX_CLOSURE as this is hardcoded in CPU/mega kernels, and it
* avoids excessive memory usage for split kernels. */
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_WARNING << "Maximum number of closures exceeded: " << max_closure_global << " > "
<< MAX_CLOSURE;
Cycles: move some Scene related methods out of Session This moves `Session::get_requested_device_features`, `Session::load_kernels`, and `Session::update_scene` out of `Session` and into `Scene`, as mentioned in D8544. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8590
2020-08-18 10:46:12 +02:00
max_closure_global = MAX_CLOSURE;
}
return max_closure_global;
}
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
int Scene::get_volume_stack_size() const
{
Cycles: Improve volume stack size calculation Only count volume objects after shader optimization. Allows to discard objects which don't have effective volume BSDF connected to the shader output (i.e. constant folded, or non-volume BSDF used by mistake). Solves memory regression reported in T92014. There is still possibility to improve memory even further for cases when there are a lot of non-intersecting volume objects, but that requires a deeper refactor of update process. Will happen as a followup development. Differential Revision: https://developer.blender.org/D12797
2021-10-08 16:38:40 +02:00
int volume_stack_size = 0;
/* Space for background volume and terminator.
* Don't do optional here because camera ray initialization expects that there is space for
* at least those elements (avoiding extra condition to check if there is actual volume or not).
*/
volume_stack_size += 2;
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
/* Quick non-expensive check. Can over-estimate maximum possible nested level, but does not
* require expensive calculation during pre-processing. */
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
bool has_volume_object = false;
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
for (const Object *object : objects) {
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
if (!object->get_geometry()->has_volume) {
continue;
}
if (object->intersects_volume) {
/* Object intersects another volume, assume it's possible to go deeper in the stack. */
/* TODO(sergey): This might count nesting twice (A intersects B and B intersects A), but
Cleanup: clang-tidy, spelling
2021-10-25 13:25:50 +02:00
* can't think of a computationally cheap algorithm. Dividing my 2 doesn't work because of
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
* Venn diagram example with 3 circles. */
++volume_stack_size;
}
else if (!has_volume_object) {
/* Allocate space for at least one volume object. */
Cycles: Improve volume stack size calculation Only count volume objects after shader optimization. Allows to discard objects which don't have effective volume BSDF connected to the shader output (i.e. constant folded, or non-volume BSDF used by mistake). Solves memory regression reported in T92014. There is still possibility to improve memory even further for cases when there are a lot of non-intersecting volume objects, but that requires a deeper refactor of update process. Will happen as a followup development. Differential Revision: https://developer.blender.org/D12797
2021-10-08 16:38:40 +02:00
++volume_stack_size;
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
}
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
has_volume_object = true;
Cycles: Improve volume stack size calculation Only count volume objects after shader optimization. Allows to discard objects which don't have effective volume BSDF connected to the shader output (i.e. constant folded, or non-volume BSDF used by mistake). Solves memory regression reported in T92014. There is still possibility to improve memory even further for cases when there are a lot of non-intersecting volume objects, but that requires a deeper refactor of update process. Will happen as a followup development. Differential Revision: https://developer.blender.org/D12797
2021-10-08 16:38:40 +02:00
if (volume_stack_size == MAX_VOLUME_STACK_SIZE) {
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
break;
}
}
Cycles: Improve volume stack size calculation Only count volume objects after shader optimization. Allows to discard objects which don't have effective volume BSDF connected to the shader output (i.e. constant folded, or non-volume BSDF used by mistake). Solves memory regression reported in T92014. There is still possibility to improve memory even further for cases when there are a lot of non-intersecting volume objects, but that requires a deeper refactor of update process. Will happen as a followup development. Differential Revision: https://developer.blender.org/D12797
2021-10-08 16:38:40 +02:00
volume_stack_size = min(volume_stack_size, MAX_VOLUME_STACK_SIZE);
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_WORK << "Detected required volume stack size " << volume_stack_size;
Cycles: More accurate volume stack size calculation The idea is to allow having a lot of non-intersecting volumes without allocating volume stack to its full size. With the F11285472 file the memory usage goes from 1400 MiB to 1000 on the RTX6000 card. The fix makes it so the integrator work memory is allocated after scene update which has downside of possible less efficient update when some textures don't fit GPU memory, but has an advantage of making proper decision and having a clear and consistent internal API. Fixes memory part of T92014. Differential Revision: https://developer.blender.org/D12966
2021-10-22 14:20:22 +02:00
Cycles: Improve volume stack size calculation Only count volume objects after shader optimization. Allows to discard objects which don't have effective volume BSDF connected to the shader output (i.e. constant folded, or non-volume BSDF used by mistake). Solves memory regression reported in T92014. There is still possibility to improve memory even further for cases when there are a lot of non-intersecting volume objects, but that requires a deeper refactor of update process. Will happen as a followup development. Differential Revision: https://developer.blender.org/D12797
2021-10-08 16:38:40 +02:00
return volume_stack_size;
Fix T91922: Cycles artifacts with high volume nested level Make volume stack allocated conditionally, potentially based on the actual nested level of objects in the scene. Currently the nested level is estimated by number of volume objects. This is a non-expensive check which is probably enough in practice to get almost perfect memory usage and performance. The conditional allocation is a bit tricky. For the CPU we declare and define maximum possible volume stack, because there are only that many integrator states on the CPU. On the GPU we declare outer SoA to have all volume stack elements, but only allocate actually needed ones. The actually used volume stack size is passed as a pre-processor, which seems to be easiest and fastest for the GPU state copy. There seems to be no speed regression in the demo files on RTX6000. Note that scenes with high nested level of volume will now be slower but correct. Differential Revision: https://developer.blender.org/D12759
2021-10-05 15:05:12 +02:00
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
bool Scene::has_shadow_catcher()
{
if (shadow_catcher_modified_) {
has_shadow_catcher_ = false;
for (Object *object : objects) {
if (object->get_is_shadow_catcher()) {
has_shadow_catcher_ = true;
break;
}
}
shadow_catcher_modified_ = false;
}
return has_shadow_catcher_;
}
void Scene::tag_shadow_catcher_modified()
{
shadow_catcher_modified_ = true;
}
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
template<> Light *Scene::create_node<Light>()
{
Light *node = new Light();
node->set_owner(this);
lights.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
light_manager->tag_update(this, LightManager::LIGHT_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
template<> Mesh *Scene::create_node<Mesh>()
{
Mesh *node = new Mesh();
node->set_owner(this);
geometry.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::MESH_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
template<> Hair *Scene::create_node<Hair>()
{
Hair *node = new Hair();
node->set_owner(this);
geometry.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::HAIR_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
template<> Volume *Scene::create_node<Volume>()
{
Volume *node = new Volume();
node->set_owner(this);
geometry.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::MESH_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
Cycles: pointcloud rendering This add support for rendering of the point cloud object in Blender, as a native geometry type in Cycles that is more memory and time efficient than instancing sphere meshes. This can be useful for rendering sand, water splashes, particles, motion graphics, etc. Points are currently always rendered as spheres, with backface culling. More shapes are likely to be added later, but this is the most important one and can be customized with shaders. For CPU rendering the Embree primitive is used, for GPU there is our own intersection code. Motion blur is suppored. Volumes inside points are not currently supported. Implemented with help from: * Kévin Dietrich: Alembic procedural integration * Patrick Mourse: OptiX integration * Josh Whelchel: update for cycles-x changes Ref T92573 Differential Revision: https://developer.blender.org/D9887
2021-12-01 17:30:46 +01:00
template<> PointCloud *Scene::create_node<PointCloud>()
{
PointCloud *node = new PointCloud();
node->set_owner(this);
geometry.push_back(node);
geometry_manager->tag_update(this, GeometryManager::POINT_ADDED);
return node;
}
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
template<> Object *Scene::create_node<Object>()
{
Object *node = new Object();
node->set_owner(this);
objects.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
object_manager->tag_update(this, ObjectManager::OBJECT_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
template<> ParticleSystem *Scene::create_node<ParticleSystem>()
{
ParticleSystem *node = new ParticleSystem();
node->set_owner(this);
particle_systems.push_back(node);
particle_system_manager->tag_update(this);
return node;
}
template<> Shader *Scene::create_node<Shader>()
{
Shader *node = new Shader();
node->set_owner(this);
shaders.push_back(node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
shader_manager->tag_update(this, ShaderManager::SHADER_ADDED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
return node;
}
Cycles: internal support for Alembic procedurals The implementation is currently optimized to load animation sequences once and then quickly scrubbing through them. Later on an option should be added to optimize for memory usage and only load the current frame into memory. Currently mesh and curve objects are supported, including support for UV and vertex color attributes. Missing still is support for arbitrary attributes and motion blur, as well as better handling of changing topology. Shader assignments are made using FaceSets found in the Alembic archive. The animation (and constant) data of the objects inside the Alembic archive is loaded at once at the beginning of the render and kept inside a cache. At each frame change we simply update the right socket of the corresponding Cycles node if the data is animated. This allows for fast playback in the viewport (depending on the scene size and compute power). Note this is not yet exposed in the Blender UI, it's a feature that is still under development and not ready for general use. Ref T79174, D3089
2021-01-25 15:12:00 +01:00
template<> AlembicProcedural *Scene::create_node<AlembicProcedural>()
{
#ifdef WITH_ALEMBIC
AlembicProcedural *node = new AlembicProcedural();
node->set_owner(this);
procedurals.push_back(node);
procedural_manager->tag_update();
return node;
#else
return nullptr;
#endif
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
template<> Pass *Scene::create_node<Pass>()
{
Pass *node = new Pass();
node->set_owner(this);
passes.push_back(node);
film->tag_modified();
return node;
}
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
template<typename T> void delete_node_from_array(vector<T> &nodes, T node)
{
for (size_t i = 0; i < nodes.size(); ++i) {
if (nodes[i] == node) {
std::swap(nodes[i], nodes[nodes.size() - 1]);
break;
}
}
nodes.resize(nodes.size() - 1);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
delete node;
}
template<> void Scene::delete_node_impl(Light *node)
{
delete_node_from_array(lights, node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
light_manager->tag_update(this, LightManager::LIGHT_REMOVED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
template<> void Scene::delete_node_impl(Mesh *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::MESH_REMOVED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
template<> void Scene::delete_node_impl(Hair *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::HAIR_REMOVED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
template<> void Scene::delete_node_impl(Volume *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::MESH_REMOVED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
Cycles: pointcloud rendering This add support for rendering of the point cloud object in Blender, as a native geometry type in Cycles that is more memory and time efficient than instancing sphere meshes. This can be useful for rendering sand, water splashes, particles, motion graphics, etc. Points are currently always rendered as spheres, with backface culling. More shapes are likely to be added later, but this is the most important one and can be customized with shaders. For CPU rendering the Embree primitive is used, for GPU there is our own intersection code. Motion blur is suppored. Volumes inside points are not currently supported. Implemented with help from: * Kévin Dietrich: Alembic procedural integration * Patrick Mourse: OptiX integration * Josh Whelchel: update for cycles-x changes Ref T92573 Differential Revision: https://developer.blender.org/D9887
2021-12-01 17:30:46 +01:00
template<> void Scene::delete_node_impl(PointCloud *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
geometry_manager->tag_update(this, GeometryManager::POINT_REMOVED);
}
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
template<> void Scene::delete_node_impl(Geometry *node)
{
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
uint flag;
if (node->is_hair()) {
flag = GeometryManager::HAIR_REMOVED;
}
else {
flag = GeometryManager::MESH_REMOVED;
}
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
delete_node_from_array(geometry, node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, flag);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
template<> void Scene::delete_node_impl(Object *node)
{
delete_node_from_array(objects, node);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
object_manager->tag_update(this, ObjectManager::OBJECT_REMOVED);
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
template<> void Scene::delete_node_impl(ParticleSystem *node)
{
delete_node_from_array(particle_systems, node);
particle_system_manager->tag_update(this);
}
Cycles: use reference count to detect used shaders Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.). This usage detection is done before updating the Scene, however it fails at detecting Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party applications), as Procedurals are only updated after the shaders are compiled. To remedy this, we now use the Node reference counting mechanism to detect whether a Shader is used and therefore should be compiled. This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however, since it would also update the Shader ids, this is now performed in `ShaderManager::device_update`, and a new virtual `device_update_specific` method was added to handle device updates for SVM and OSL. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:34:56 +02:00
template<> void Scene::delete_node_impl(Shader *shader)
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
{
/* don't delete unused shaders, not supported */
Cycles: use reference count to detect used shaders Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.). This usage detection is done before updating the Scene, however it fails at detecting Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party applications), as Procedurals are only updated after the shaders are compiled. To remedy this, we now use the Node reference counting mechanism to detect whether a Shader is used and therefore should be compiled. This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however, since it would also update the Shader ids, this is now performed in `ShaderManager::device_update`, and a new virtual `device_update_specific` method was added to handle device updates for SVM and OSL. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:34:56 +02:00
shader->clear_reference_count();
Cycles: introduce an ownership system to protect nodes from unwanted deletions. Problem: the Blender synchronization process creates and tags nodes for usage. It does this by directly adding and removing nodes from the scene data. If some node is not tagged as used at the end of a synchronization, it then deletes the node from the scene. This poses a problem when it comes to supporting procedural nodes who can create other nodes not known by the Blender synchonization system, which will remove them. Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods found on the owners. `delete_node` will assert that the owner is the right one. Whenever a scene level node is created or deleted, the appropriate node manager is tagged for an update, freeing this responsability from BlenderSync or other software exporters. Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they only keep track of which nodes are used, employing the scene to create and delete them. To achieve this, the ParticleSystem is now a Node, although it does not have any sockets. This is part of T79131. Reviewed By: #cycles, brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
}
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
template<> void Scene::delete_node_impl(Procedural *node)
{
delete_node_from_array(procedurals, node);
procedural_manager->tag_update();
}
Cycles: internal support for Alembic procedurals The implementation is currently optimized to load animation sequences once and then quickly scrubbing through them. Later on an option should be added to optimize for memory usage and only load the current frame into memory. Currently mesh and curve objects are supported, including support for UV and vertex color attributes. Missing still is support for arbitrary attributes and motion blur, as well as better handling of changing topology. Shader assignments are made using FaceSets found in the Alembic archive. The animation (and constant) data of the objects inside the Alembic archive is loaded at once at the beginning of the render and kept inside a cache. At each frame change we simply update the right socket of the corresponding Cycles node if the data is animated. This allows for fast playback in the viewport (depending on the scene size and compute power). Note this is not yet exposed in the Blender UI, it's a feature that is still under development and not ready for general use. Ref T79174, D3089
2021-01-25 15:12:00 +01:00
template<> void Scene::delete_node_impl(AlembicProcedural *node)
{
#ifdef WITH_ALEMBIC
delete_node_impl(static_cast<Procedural *>(node));
#else
(void)node;
#endif
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
template<> void Scene::delete_node_impl(Pass *node)
{
delete_node_from_array(passes, node);
film->tag_modified();
}
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
template<typename T>
static void remove_nodes_in_set(const set<T *> &nodes_set,
vector<T *> &nodes_array,
const NodeOwner *owner)
{
size_t new_size = nodes_array.size();
for (size_t i = 0; i < new_size; ++i) {
T *node = nodes_array[i];
if (nodes_set.find(node) != nodes_set.end()) {
std::swap(nodes_array[i], nodes_array[new_size - 1]);
assert(node->get_owner() == owner);
delete node;
i -= 1;
new_size -= 1;
}
}
nodes_array.resize(new_size);
(void)owner;
}
template<> void Scene::delete_nodes(const set<Light *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, lights, owner);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
light_manager->tag_update(this, LightManager::LIGHT_REMOVED);
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
}
template<> void Scene::delete_nodes(const set<Geometry *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, geometry, owner);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
geometry_manager->tag_update(this, GeometryManager::GEOMETRY_REMOVED);
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
}
template<> void Scene::delete_nodes(const set<Object *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, objects, owner);
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
object_manager->tag_update(this, ObjectManager::OBJECT_REMOVED);
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
}
template<> void Scene::delete_nodes(const set<ParticleSystem *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, particle_systems, owner);
particle_system_manager->tag_update(this);
}
Cycles: use reference count to detect used shaders Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.). This usage detection is done before updating the Scene, however it fails at detecting Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party applications), as Procedurals are only updated after the shaders are compiled. To remedy this, we now use the Node reference counting mechanism to detect whether a Shader is used and therefore should be compiled. This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however, since it would also update the Shader ids, this is now performed in `ShaderManager::device_update`, and a new virtual `device_update_specific` method was added to handle device updates for SVM and OSL. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:34:56 +02:00
template<> void Scene::delete_nodes(const set<Shader *> &nodes, const NodeOwner * /*owner*/)
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
{
/* don't delete unused shaders, not supported */
Cycles: use reference count to detect used shaders Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.). This usage detection is done before updating the Scene, however it fails at detecting Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party applications), as Procedurals are only updated after the shaders are compiled. To remedy this, we now use the Node reference counting mechanism to detect whether a Shader is used and therefore should be compiled. This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however, since it would also update the Shader ids, this is now performed in `ShaderManager::device_update`, and a new virtual `device_update_specific` method was added to handle device updates for SVM and OSL. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10965
2021-05-02 02:34:56 +02:00
for (Shader *shader : nodes) {
shader->clear_reference_count();
}
Fix T82129: Cycles "Persistent Images" incorrectly retains scene data The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created. Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated. To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called. Reviewed By: brecht Maniphest Tasks: T82129 Differential Revision: https://developer.blender.org/D9378
2020-10-29 14:40:29 +01:00
}
Cycles: internal support for the concept of procedurals Procedurals are nodes in the scene that can generate an arbitrary number of other nodes at render time. This will be used to implement an Alembic procedural that can load an Alembic file into Cycles nodes. In the future we also expect to have a USD procedural. Direct loading of such files at render time is a standard feature in other production renderers. Reasons to support this are memory usage and performance, delayed loading of heavy scene data until rendering, Cycles standalone rendering using standard file formats beyond our XML files, and shared functionality for Cycles integration in multiple 3D apps. Ref T79174, D3089
2021-01-25 14:56:57 +01:00
template<> void Scene::delete_nodes(const set<Procedural *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, procedurals, owner);
procedural_manager->tag_update();
}
Cycles: merge of cycles-x branch, a major update to the renderer 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/Cycles https://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
2021-09-20 17:59:20 +02:00
template<> void Scene::delete_nodes(const set<Pass *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, passes, owner);
film->tag_modified();
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 13:58:34 +02:00
CCL_NAMESPACE_END