griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
fd477e738dfd65f7bb0f06c1d91c3259ed26295d
test/intern/cycles/render/scene.cpp

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

962 lines
28 KiB
C++
Raw Normal View History

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 11:58:34 +00:00
/*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Copyright 2011-2013 Blender Foundation
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 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
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 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* http://www.apache.org/licenses/LICENSE-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 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
Cleanup: Fix Cycles Apache header. This was already mixed a bit, but the dot belongs there.
2014-12-25 02:50:24 +01:00
* limitations under the License.
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 11:58:34 +00: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: 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
#include "render/alembic.h"
Cycles: Make all #include statements relative to cycles source directory The idea is to make include statements more explicit and obvious where the file is coming from, additionally reducing chance of wrong header being picked up. For example, it was not obvious whether bvh.h was refferring to builder or traversal, whenter node.h is a generic graph node or a shader node and cases like that. Surely this might look obvious for the active developers, but after some time of not touching the code it becomes less obvious where file is coming from. This was briefly mentioned in T50824 and seems @brecht is fine with such explicitness, but need to agree with all active developers before committing this. Please note that this patch is lacking changes related on GPU/OpenCL support. This will be solved if/when we all agree this is a good idea to move forward. Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner Reviewed By: lukasstockner97, maiself, nirved, dingto Subscribers: brecht Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
#include "render/background.h"
#include "render/bake.h"
#include "render/camera.h"
#include "render/curves.h"
#include "render/film.h"
#include "render/integrator.h"
#include "render/light.h"
#include "render/mesh.h"
#include "render/object.h"
#include "render/osl.h"
#include "render/particles.h"
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
#include "render/procedural.h"
Cycles: Make all #include statements relative to cycles source directory The idea is to make include statements more explicit and obvious where the file is coming from, additionally reducing chance of wrong header being picked up. For example, it was not obvious whether bvh.h was refferring to builder or traversal, whenter node.h is a generic graph node or a shader node and cases like that. Surely this might look obvious for the active developers, but after some time of not touching the code it becomes less obvious where file is coming from. This was briefly mentioned in T50824 and seems @brecht is fine with such explicitness, but need to agree with all active developers before committing this. Please note that this patch is lacking changes related on GPU/OpenCL support. This will be solved if/when we all agree this is a good idea to move forward. Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner Reviewed By: lukasstockner97, maiself, nirved, dingto Subscribers: brecht Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
#include "render/scene.h"
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
#include "render/session.h"
Cycles: Make all #include statements relative to cycles source directory The idea is to make include statements more explicit and obvious where the file is coming from, additionally reducing chance of wrong header being picked up. For example, it was not obvious whether bvh.h was refferring to builder or traversal, whenter node.h is a generic graph node or a shader node and cases like that. Surely this might look obvious for the active developers, but after some time of not touching the code it becomes less obvious where file is coming from. This was briefly mentioned in T50824 and seems @brecht is fine with such explicitness, but need to agree with all active developers before committing this. Please note that this patch is lacking changes related on GPU/OpenCL support. This will be solved if/when we all agree this is a good idea to move forward. Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner Reviewed By: lukasstockner97, maiself, nirved, dingto Subscribers: brecht Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
#include "render/shader.h"
#include "render/svm.h"
#include "render/tables.h"
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
#include "render/volume.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 11:58:34 +00:00
Cycles: Make all #include statements relative to cycles source directory The idea is to make include statements more explicit and obvious where the file is coming from, additionally reducing chance of wrong header being picked up. For example, it was not obvious whether bvh.h was refferring to builder or traversal, whenter node.h is a generic graph node or a shader node and cases like that. Surely this might look obvious for the active developers, but after some time of not touching the code it becomes less obvious where file is coming from. This was briefly mentioned in T50824 and seems @brecht is fine with such explicitness, but need to agree with all active developers before committing this. Please note that this patch is lacking changes related on GPU/OpenCL support. This will be solved if/when we all agree this is a good idea to move forward. Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner Reviewed By: lukasstockner97, maiself, nirved, dingto Subscribers: brecht Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
#include "util/util_foreach.h"
#include "util/util_guarded_allocator.h"
#include "util/util_logging.h"
#include "util/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 11:58:34 +00:00
CCL_NAMESPACE_BEGIN
Code refactor: store device/interp/extension/type in each device_memory.
2017-10-20 23:31:13 +02:00
DeviceScene::DeviceScene(Device *device)
Cleanup: add device_texture for images, distinct from other global memory There was too much image texture specific stuff in device_memory, and too much code duplication between devices.
2020-03-12 15:22:18 +01:00
: bvh_nodes(device, "__bvh_nodes", MEM_GLOBAL),
bvh_leaf_nodes(device, "__bvh_leaf_nodes", MEM_GLOBAL),
object_node(device, "__object_node", MEM_GLOBAL),
prim_type(device, "__prim_type", MEM_GLOBAL),
prim_visibility(device, "__prim_visibility", MEM_GLOBAL),
prim_index(device, "__prim_index", MEM_GLOBAL),
prim_object(device, "__prim_object", MEM_GLOBAL),
prim_time(device, "__prim_time", MEM_GLOBAL),
Cycles: fully decouple triangle and curve primitive storage from BVH2 Previously the storage here was optimized to avoid indirections in BVH2 traversal. This helps improve performance a bit, but makes performance and memory usage of Embree and OptiX BVHs a bit worse also. It also adds code complexity in other parts of the code. Now decouple triangle and curve primitive storage from BVH2. * Reduced peak memory usage on all devices * Bit better performance for OptiX and Embree * Bit worse performance for CUDA * Simplified code: ** Intersection.prim/object now matches ShaderData.prim/object ** No more offset manipulation for mesh displacement before a BVH is built ** Remove primitive packing code and flags for Embree and OptiX ** Curve segments are now stored in a KernelCurve struct * Also happens to fix a bug in baking with incorrect prim/object Fixes T91968, T91770, T91902 Differential Revision: https://developer.blender.org/D12766
2021-02-28 23:23:24 +01:00
tri_verts(device, "__tri_verts", MEM_GLOBAL),
Cleanup: add device_texture for images, distinct from other global memory There was too much image texture specific stuff in device_memory, and too much code duplication between devices.
2020-03-12 15:22:18 +01:00
tri_shader(device, "__tri_shader", MEM_GLOBAL),
tri_vnormal(device, "__tri_vnormal", MEM_GLOBAL),
tri_vindex(device, "__tri_vindex", MEM_GLOBAL),
tri_patch(device, "__tri_patch", MEM_GLOBAL),
tri_patch_uv(device, "__tri_patch_uv", MEM_GLOBAL),
curves(device, "__curves", MEM_GLOBAL),
curve_keys(device, "__curve_keys", MEM_GLOBAL),
Cycles: fully decouple triangle and curve primitive storage from BVH2 Previously the storage here was optimized to avoid indirections in BVH2 traversal. This helps improve performance a bit, but makes performance and memory usage of Embree and OptiX BVHs a bit worse also. It also adds code complexity in other parts of the code. Now decouple triangle and curve primitive storage from BVH2. * Reduced peak memory usage on all devices * Bit better performance for OptiX and Embree * Bit worse performance for CUDA * Simplified code: ** Intersection.prim/object now matches ShaderData.prim/object ** No more offset manipulation for mesh displacement before a BVH is built ** Remove primitive packing code and flags for Embree and OptiX ** Curve segments are now stored in a KernelCurve struct * Also happens to fix a bug in baking with incorrect prim/object Fixes T91968, T91770, T91902 Differential Revision: https://developer.blender.org/D12766
2021-02-28 23:23:24 +01:00
curve_segments(device, "__curve_segments", MEM_GLOBAL),
Cleanup: add device_texture for images, distinct from other global memory There was too much image texture specific stuff in device_memory, and too much code duplication between devices.
2020-03-12 15:22:18 +01:00
patches(device, "__patches", MEM_GLOBAL),
objects(device, "__objects", MEM_GLOBAL),
object_motion_pass(device, "__object_motion_pass", MEM_GLOBAL),
object_motion(device, "__object_motion", MEM_GLOBAL),
object_flag(device, "__object_flag", MEM_GLOBAL),
Cycles: change volume step size controls, auto adjust based on voxel size By default it will now set the step size to the voxel size for smoke and volume objects, and 1/10th the bounding box for procedural volume shaders. New settings are: * Scene render/preview step rate: to globally adjust detail and performance * Material step rate: multiplied with auto detected per-object step size * World step size: distance to steo for world shader Differential Revision: https://developer.blender.org/D1777
2020-03-07 14:38:52 +01:00
object_volume_step(device, "__object_volume_step", MEM_GLOBAL),
Cleanup: add device_texture for images, distinct from other global memory There was too much image texture specific stuff in device_memory, and too much code duplication between devices.
2020-03-12 15:22:18 +01:00
camera_motion(device, "__camera_motion", MEM_GLOBAL),
attributes_map(device, "__attributes_map", MEM_GLOBAL),
attributes_float(device, "__attributes_float", MEM_GLOBAL),
attributes_float2(device, "__attributes_float2", MEM_GLOBAL),
attributes_float3(device, "__attributes_float3", MEM_GLOBAL),
attributes_uchar4(device, "__attributes_uchar4", MEM_GLOBAL),
light_distribution(device, "__light_distribution", MEM_GLOBAL),
lights(device, "__lights", MEM_GLOBAL),
light_background_marginal_cdf(device, "__light_background_marginal_cdf", MEM_GLOBAL),
light_background_conditional_cdf(device, "__light_background_conditional_cdf", MEM_GLOBAL),
particles(device, "__particles", MEM_GLOBAL),
svm_nodes(device, "__svm_nodes", MEM_GLOBAL),
shaders(device, "__shaders", MEM_GLOBAL),
lookup_table(device, "__lookup_table", MEM_GLOBAL),
sample_pattern_lut(device, "__sample_pattern_lut", MEM_GLOBAL),
ies_lights(device, "__ies", MEM_GLOBAL)
Code refactor: store device/interp/extension/type in each device_memory.
2017-10-20 23:31:13 +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 *)&data, 0, sizeof(data));
Code refactor: store device/interp/extension/type in each device_memory.
2017-10-20 23:31:13 +02:00
}
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 11:58:34 +00: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
Fix (apparently harmless) Cycles asan warnings
2021-03-15 18:52:45 +01:00
/* OSL only works on the CPU */
if (device->info.has_osl)
shader_manager = ShaderManager::create(params.shadingsystem);
else
shader_manager = ShaderManager::create(SHADINGSYSTEM_SVM);
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 11:58:34 +00: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 11:58:34 +00: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 17:27:08 +00: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 19:05:07 -02: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 11:58:34 +00: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 08:46:53 +00: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 11:58:34 +00: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 08:46:53 +00: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 11:58:34 +00: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 17:27:08 +00: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 16:11:47 +00: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 08:46:53 +00: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 13:16:04 +05:00
camera->device_free(device, &dscene, this);
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 20:26:43 +00: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 08:46:53 +00: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 20:26:52 +00: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 08:46:53 +00: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 08:46:53 +00: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 19:05:07 -02: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
Render: faster animation and re-rendering with Persistent Data For Cycles, when enabling the Persistent Data option, the full render data will be preserved from frame-to-frame in animation renders and between re-renders of the scene. This means that any modifier evaluation, BVH building, OpenGL vertex buffer uploads, etc, can be done only once for unchanged objects. This comes at an increased memory cost. Previously there option was named Persistent Images and had a more limited impact on render time and memory. When using multiple view layers, only data from a single view layer is preserved to keep memory usage somewhat under control. However objects shared between view layers are preserved, and so this can speedup such renders as well, even single frame renders. For Eevee and Workbench this option is not available, however these engines will now always reuse the depsgraph for animation and multiple view layers. This can significantly speed up rendering. These engines do not support sharing the depsgraph between re-renders, due to technical issues regarding OpenGL contexts. Support for this could be added if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
if (final)
Code refactor: simplify image device memory allocation.
2017-10-20 04:20:37 +02:00
image_manager->device_free(device);
Fix T40195: cycles smoke + persistent images animation render not working correct.
2014-05-19 14:45:52 +02:00
else
Code refactor: simplify image device memory allocation.
2017-10-20 04:20:37 +02:00
image_manager->device_free_builtin(device);
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 20:26:43 +00: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 08:46:53 +00: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 08:46:53 +00:00
if (final) {
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 20:26:43 +00: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 08:46:53 +00: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 08:46:53 +00: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 19:05:07 -02: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 08:46:53 +00: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 11:58:34 +00:00
}
void Scene::device_update(Device *device_, Progress &progress)
{
if (!device)
device = device_;
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 11:58:34 +00: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 16:53:52 +10: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 11:58:34 +00: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 11:58:34 +00:00
*/
progress.set_status("Updating Shaders");
shader_manager->device_update(device, &dscene, this, progress);
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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);
if (progress.get_cancel())
return;
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);
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 22:06:31 +05:00
progress.set_status("Updating Camera");
camera->device_update(device, &dscene, this);
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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 11:58:34 +00: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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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-18 22:40:48 -05:00
progress.set_status("Updating Particle Systems");
particle_system_manager->device_update(device, &dscene, this, progress);
if (progress.get_cancel() || device->have_error())
return;
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-30 01:07:38 +05: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
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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-30 01:07:38 +05: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 19:08:58 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 20:37:57 +05: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 20:37:57 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 22:06:31 +05:00
progress.set_status("Updating Camera Volume");
camera->device_update_volume(device, &dscene, this);
if (progress.get_cancel() || device->have_error())
return;
Cleanup: trailing space
2018-11-25 08:01:14 +11: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
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00:00
progress.set_status("Updating Lights");
light_manager->device_update(device, &dscene, this, progress);
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 11:58:34 +00: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
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 19:05:07 -02:00
progress.set_status("Updating Baking");
bake_manager->device_update(device, &dscene, this, progress);
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 21:00:05 +05:00
if (progress.get_cancel() || device->have_error())
return;
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 19:05:07 -02: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 21:00:05 +05: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 21:00:05 +05:00
progress.set_status("Updating Device", "Writing constant memory");
device->const_copy_to("__data", &dscene.data, sizeof(dscene.data));
}
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 19:39:14 +05: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
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-29 18:02:05 -04:00
size_t mem_used = util_guarded_get_mem_used();
size_t mem_peak = util_guarded_get_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
VLOG(1) << "System memory statistics after full device sync:\n"
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-29 18:02:05 -04:00
<< " 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 11:58:34 +00:00
}
Code cleanup: remove test code to disable motion blur, no longer useful.
2018-01-12 19:56:52 +01:00
Scene::MotionType Scene::need_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 12:49:26 +00: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 (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;
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
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 12:49:26 +00:00
return MOTION_PASS;
else
return MOTION_NONE;
}
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()
{
if (need_motion() == Scene::MOTION_PASS)
return 2.0f;
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();
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 12:49:26 +00:00
bool Scene::need_global_attribute(AttributeStandard std)
{
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: Some else if for attribute code.
2014-05-12 10:20:20 +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: Some else if for attribute code.
2014-05-12 10:20:20 +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;
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 12:49:26 +00:00
return false;
}
void Scene::need_global_attributes(AttributeRequestSet &attributes)
{
for (int std = ATTR_STD_NONE; std < ATTR_STD_NUM; std++)
if (need_global_attribute((AttributeStandard)std))
attributes.add((AttributeStandard)std);
}
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 11:58:34 +00: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 11:58:34 +00: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 11:58:34 +00: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 11:58:34 +00: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_reset()
{
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_data_update() || 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 08:46:53 +00: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 16:11:47 +00: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 08:46:53 +00: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 08:46:53 +00: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 08:46:53 +00: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 08:46:53 +00: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
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;
}
if (use_motion && camera->use_motion()) {
kernel_features |= KERNEL_FEATURE_CAMERA_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
foreach (Object *object, objects) {
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;
}
if (geom->get_use_motion_blur()) {
kernel_features |= KERNEL_FEATURE_CAMERA_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
Mesh *mesh = static_cast<Mesh *>(geom);
#ifdef WITH_OPENSUBDIV
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: 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);
Cycles: add additive AO support through Fast GI settings Add a Fast GI Method, either Replace for the existing behavior, or Add to add ambient occlusion like the old world settings. This replaces the old Ambient Occlusion settings in the world properties.
2021-10-21 17:42:15 +02:00
kernel_features |= integrator->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
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
/* Load render kernels, before device update where we upload data to the GPU. */
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
load_kernels(progress, false);
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)
{
VLOG(2) << "Requested features:\n";
VLOG(2) << "Use BSDF " << string_from_bool(features & KERNEL_FEATURE_NODE_BSDF) << "\n";
VLOG(2) << "Use Principled BSDF " << string_from_bool(features & KERNEL_FEATURE_PRINCIPLED)
<< "\n";
VLOG(2) << "Use Emission " << string_from_bool(features & KERNEL_FEATURE_NODE_EMISSION) << "\n";
VLOG(2) << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_NODE_VOLUME) << "\n";
VLOG(2) << "Use Hair " << string_from_bool(features & KERNEL_FEATURE_NODE_HAIR) << "\n";
VLOG(2) << "Use Bump " << string_from_bool(features & KERNEL_FEATURE_NODE_BUMP) << "\n";
VLOG(2) << "Use Voronoi " << string_from_bool(features & KERNEL_FEATURE_NODE_VORONOI_EXTRA)
<< "\n";
VLOG(2) << "Use Shader Raytrace " << string_from_bool(features & KERNEL_FEATURE_NODE_RAYTRACE)
<< "\n";
VLOG(2) << "Use Transparent " << string_from_bool(features & KERNEL_FEATURE_TRANSPARENT) << "\n";
VLOG(2) << "Use Denoising " << string_from_bool(features & KERNEL_FEATURE_DENOISING) << "\n";
VLOG(2) << "Use Path Tracing " << string_from_bool(features & KERNEL_FEATURE_PATH_TRACING)
<< "\n";
VLOG(2) << "Use Hair " << string_from_bool(features & KERNEL_FEATURE_HAIR) << "\n";
VLOG(2) << "Use Object Motion " << string_from_bool(features & KERNEL_FEATURE_OBJECT_MOTION)
<< "\n";
VLOG(2) << "Use Camera Motion " << string_from_bool(features & KERNEL_FEATURE_CAMERA_MOTION)
<< "\n";
VLOG(2) << "Use Baking " << string_from_bool(features & KERNEL_FEATURE_BAKING) << "\n";
VLOG(2) << "Use Subsurface " << string_from_bool(features & KERNEL_FEATURE_SUBSURFACE) << "\n";
VLOG(2) << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_VOLUME) << "\n";
VLOG(2) << "Use Patch Evaluation "
<< string_from_bool(features & KERNEL_FEATURE_PATCH_EVALUATION) << "\n";
VLOG(2) << "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
}
bool Scene::load_kernels(Progress &progress, bool lock_scene)
{
thread_scoped_lock scene_lock;
if (lock_scene) {
scene_lock = thread_scoped_lock(mutex);
}
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();
if (message.empty())
message = "Failed loading render kernel, see console for errors";
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. */
VLOG(2) << "Maximum number of closures exceeded: " << max_closure_global << " > "
<< MAX_CLOSURE;
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 22:25:50 +11: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
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
VLOG(3) << "Detected required volume stack size " << volume_stack_size;
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;
}
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
}
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 11:58:34 +00:00
CCL_NAMESPACE_END
Reference in New Issue Copy Permalink