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

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

767 lines
22 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>
Cleanup: `make format` after SortedIncludes change
2020-03-19 09:33:03 +01:00
#include "device/device.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"
#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_tri_index(device, "__prim_tri_index", MEM_GLOBAL),
prim_tri_verts(device, "__prim_tri_verts", 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),
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),
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"),
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_),
update_stats(NULL)
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
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
camera = create_node<Camera>();
dicing_camera = create_node<Camera>();
Cycles: code refactoring to add generic lookup table memory.
2013-04-01 20:26:43 +00:00
lookup_tables = new LookupTables();
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
film = create_node<Film>();
background = create_node<Background>();
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();
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
integrator = create_node<Integrator>();
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: 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
kernels_loaded = false;
/* TODO(sergey): Check if it's indeed optimal value for the split kernel. */
max_closure_global = 1;
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);
Fix #33405: preview render getting stuck in a particular .blend file, ObjectKey operator< had wrong brackets, changed it now to be more clear. Fix #33404: crash GPU rendering with OSL option still enabled. There was a check to disable OSL in this case, but it shouldn't have modified scene->params because this is used for comparison in scene->modified().
2012-12-04 07:48:09 +00:00
/* OSL only works on the CPU */
Code refactor: pass device to scene, check OSL with device info.
2017-10-20 05:08:26 +02:00
if (device->info.has_osl)
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 = ShaderManager::create(params.shadingsystem);
Fix #33405: preview render getting stuck in a particular .blend file, ObjectKey operator< had wrong brackets, changed it now to be more clear. Fix #33404: crash GPU rendering with OSL option still enabled. There was a check to disable OSL in this case, but it shouldn't have modified scene->params because this is used for comparison in scene->modified().
2012-12-04 07:48:09 +00:00
else
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 = ShaderManager::create(SHADINGSYSTEM_SVM);
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 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 (Shader *s, shaders)
delete s;
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
foreach (Geometry *g, geometry)
delete g;
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;
foreach (Light *l, lights)
delete l;
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;
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 #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
shaders.clear();
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();
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);
integrator->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
object_manager->device_free(device, &dscene);
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager->device_free(device, &dscene);
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
Further fix for #34121: OSL + persistent images could crash in some cases still.
2013-02-14 16:48:43 +00:00
if (!params.persistent_data || 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 camera;
Cycles: add offscreen dicing scale and dicing camera. The offscreen dicing scale helps to significantly reduce memory usage, by reducing the dicing rate for objects the further they are outside of the camera view. The dicing camera can be specified now, to keep the geometry fixed and avoid crawling artifacts in animation. It is also useful for debugging, to see the tesselation from a different camera location. Differential Revision: https://developer.blender.org/D2891
2018-01-12 00:50:34 +01:00
delete dicing_camera;
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 film;
delete background;
delete integrator;
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: 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: 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
if (update_stats) {
update_stats->clear();
}
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
* - Film needs light manager to run for use_light_visibility
* - 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 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) {
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 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 (background->is_modified() || image_manager->need_update || object_manager->need_update ||
Cleanup: `make format` Remember to run `make format` after cleanups/renames/...
2020-02-07 15:26:35 +01:00
geometry_manager->need_update || light_manager->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
lookup_tables->need_update || integrator->is_modified() || shader_manager->need_update ||
particle_system_manager->need_update || bake_manager->need_update ||
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_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: 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);
integrator->tag_update(this);
Fix T40429: cycles CUDA + use persistent images problem.
2014-06-05 17:39:16 +02:00
object_manager->tag_update(this);
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
geometry_manager->tag_update(this);
Fix T40429: cycles CUDA + use persistent images problem.
2014-06-05 17:39:16 +02:00
light_manager->tag_update(this);
particle_system_manager->tag_update(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
}
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: 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
DeviceRequestedFeatures Scene::get_requested_device_features()
{
DeviceRequestedFeatures requested_features;
shader_manager->get_requested_features(this, &requested_features);
/* This features are not being tweaked as often as shaders,
* so could be done selective magic for the viewport as well.
*/
bool use_motion = need_motion() == Scene::MotionType::MOTION_BLUR;
requested_features.use_hair = false;
requested_features.use_hair_thick = (params.hair_shape == CURVE_THICK);
requested_features.use_object_motion = false;
requested_features.use_camera_motion = use_motion && camera->use_motion();
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 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
requested_features.use_object_motion |= object->use_motion() | geom->get_use_motion_blur();
requested_features.use_camera_motion |= geom->get_use_motion_blur();
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: 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
requested_features.use_shadow_tricks = true;
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
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: 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
requested_features.use_patch_evaluation = true;
}
#endif
requested_features.use_true_displacement |= mesh->has_true_displacement();
}
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: 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
requested_features.use_hair = true;
}
}
requested_features.use_background_light = light_manager->has_background_light(this);
requested_features.use_baking = bake_manager->get_baking();
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
requested_features.use_integrator_branched = (integrator->get_method() ==
Integrator::BRANCHED_PATH);
if (film->get_denoising_data_pass()) {
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
requested_features.use_denoising = true;
requested_features.use_shadow_tricks = true;
}
return requested_features;
}
bool Scene::update(Progress &progress, bool &kernel_switch_needed)
{
/* update scene */
if (need_update()) {
/* Updated used shader tag so we know which features are need for the kernel. */
shader_manager->update_shaders_used(this);
/* Update max_closures. */
KernelIntegrator *kintegrator = &dscene.data.integrator;
if (params.background) {
kintegrator->max_closures = get_max_closure_count();
}
else {
/* Currently viewport render is faster with higher max_closures, needs investigating. */
kintegrator->max_closures = MAX_CLOSURE;
}
/* Load render kernels, before device update where we upload data to the GPU. */
bool new_kernels_needed = load_kernels(progress, false);
progress.set_status("Updating Scene");
MEM_GUARDED_CALL(&progress, device_update, device, progress);
DeviceKernelStatus kernel_switch_status = device->get_active_kernel_switch_state();
kernel_switch_needed = kernel_switch_status == DEVICE_KERNEL_FEATURE_KERNEL_AVAILABLE ||
kernel_switch_status == DEVICE_KERNEL_FEATURE_KERNEL_INVALID;
if (kernel_switch_status == DEVICE_KERNEL_WAITING_FOR_FEATURE_KERNEL) {
progress.set_kernel_status("Compiling render kernels");
}
if (new_kernels_needed || kernel_switch_needed) {
progress.set_kernel_status("Compiling render kernels");
device->wait_for_availability(loaded_kernel_features);
progress.set_kernel_status("");
}
return true;
}
return false;
}
bool Scene::load_kernels(Progress &progress, bool lock_scene)
{
thread_scoped_lock scene_lock;
if (lock_scene) {
scene_lock = thread_scoped_lock(mutex);
}
DeviceRequestedFeatures requested_features = get_requested_device_features();
if (!kernels_loaded || loaded_kernel_features.modified(requested_features)) {
progress.set_status("Loading render kernels (may take a few minutes the first time)");
scoped_timer timer;
VLOG(2) << "Requested features:\n" << requested_features;
if (!device->load_kernels(requested_features)) {
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;
}
progress.add_skip_time(timer, false);
VLOG(1) << "Total time spent loading kernels: " << time_dt() - timer.get_start();
kernels_loaded = true;
loaded_kernel_features = requested_features;
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];
if (shader->used) {
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;
}
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);
light_manager->tag_update(this);
return node;
}
template<> Mesh *Scene::create_node<Mesh>()
{
Mesh *node = new Mesh();
node->set_owner(this);
geometry.push_back(node);
geometry_manager->tag_update(this);
return node;
}
template<> Hair *Scene::create_node<Hair>()
{
Hair *node = new Hair();
node->set_owner(this);
geometry.push_back(node);
geometry_manager->tag_update(this);
return node;
}
template<> Volume *Scene::create_node<Volume>()
{
Volume *node = new Volume();
node->set_owner(this);
geometry.push_back(node);
geometry_manager->tag_update(this);
return node;
}
template<> Object *Scene::create_node<Object>()
{
Object *node = new Object();
node->set_owner(this);
objects.push_back(node);
object_manager->tag_update(this);
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);
shader_manager->need_update = true;
return node;
}
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);
delete node;
}
template<> void Scene::delete_node_impl(Light *node)
{
delete_node_from_array(lights, node);
light_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Mesh *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
geometry_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Hair *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
geometry_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Volume *node)
{
delete_node_from_array(geometry, static_cast<Geometry *>(node));
geometry_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Geometry *node)
{
delete_node_from_array(geometry, node);
geometry_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Object *node)
{
delete_node_from_array(objects, node);
object_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(ParticleSystem *node)
{
delete_node_from_array(particle_systems, node);
particle_system_manager->tag_update(this);
}
template<> void Scene::delete_node_impl(Shader * /*node*/)
{
/* don't delete unused shaders, not supported */
}
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);
light_manager->tag_update(this);
}
template<> void Scene::delete_nodes(const set<Geometry *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, geometry, owner);
geometry_manager->tag_update(this);
}
template<> void Scene::delete_nodes(const set<Object *> &nodes, const NodeOwner *owner)
{
remove_nodes_in_set(nodes, objects, owner);
object_manager->tag_update(this);
}
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);
}
template<> void Scene::delete_nodes(const set<Shader *> & /*nodes*/, const NodeOwner * /*owner*/)
{
/* don't delete unused shaders, not supported */
}
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