2023-06-14 16:52:36 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0 */
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2024-12-26 17:53:57 +01:00
|
|
|
#include <cstdlib>
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2020-12-10 14:18:25 +01:00
|
|
|
#include "bvh/bvh.h"
|
2025-08-11 19:36:26 +02:00
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "device/device.h"
|
2025-08-11 19:36:26 +02:00
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/background.h"
|
|
|
|
|
#include "scene/bake.h"
|
|
|
|
|
#include "scene/camera.h"
|
|
|
|
|
#include "scene/curves.h"
|
2023-04-25 20:18:44 +02:00
|
|
|
#include "scene/devicescene.h"
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/film.h"
|
2024-12-26 17:53:59 +01:00
|
|
|
#include "scene/hair.h"
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/integrator.h"
|
|
|
|
|
#include "scene/light.h"
|
|
|
|
|
#include "scene/mesh.h"
|
|
|
|
|
#include "scene/object.h"
|
|
|
|
|
#include "scene/osl.h"
|
|
|
|
|
#include "scene/particles.h"
|
2021-12-01 17:30:46 +01:00
|
|
|
#include "scene/pointcloud.h"
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/procedural.h"
|
|
|
|
|
#include "scene/scene.h"
|
|
|
|
|
#include "scene/shader.h"
|
|
|
|
|
#include "scene/svm.h"
|
|
|
|
|
#include "scene/tables.h"
|
|
|
|
|
#include "scene/volume.h"
|
2025-08-11 19:36:26 +02:00
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "session/session.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "util/guarded_allocator.h"
|
|
|
|
|
#include "util/log.h"
|
|
|
|
|
#include "util/progress.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
Scene ::Scene(const SceneParams ¶ms_, Device *device)
|
2020-03-18 17:54:24 +01:00
|
|
|
: name("Scene"),
|
2024-12-26 17:53:55 +01:00
|
|
|
default_surface(nullptr),
|
|
|
|
|
default_volume(nullptr),
|
|
|
|
|
default_light(nullptr),
|
|
|
|
|
default_background(nullptr),
|
|
|
|
|
default_empty(nullptr),
|
2020-03-18 17:54:24 +01:00
|
|
|
device(device),
|
|
|
|
|
dscene(device),
|
2020-10-01 23:16:01 +02:00
|
|
|
params(params_),
|
2024-12-26 17:53:55 +01:00
|
|
|
update_stats(nullptr),
|
2021-03-15 18:52:45 +01:00
|
|
|
kernels_loaded(false),
|
2024-12-29 17:32:00 +01:00
|
|
|
/* TODO(sergey): Check if it's indeed optimal value for the split kernel.
|
|
|
|
|
*/
|
2021-03-15 18:52:45 +01:00
|
|
|
max_closure_global(1)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
2018-06-11 12:54:17 +02:00
|
|
|
memset((void *)&dscene.data, 0, sizeof(dscene.data));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-03-04 17:27:10 +01:00
|
|
|
osl_manager = make_unique<OSLManager>(device);
|
|
|
|
|
shader_manager = ShaderManager::create(device->info.has_osl ? params.shadingsystem :
|
|
|
|
|
SHADINGSYSTEM_SVM);
|
2021-03-15 18:52:45 +01:00
|
|
|
|
2024-12-29 23:13:45 +01:00
|
|
|
light_manager = make_unique<LightManager>();
|
|
|
|
|
geometry_manager = make_unique<GeometryManager>();
|
|
|
|
|
object_manager = make_unique<ObjectManager>();
|
|
|
|
|
image_manager = make_unique<ImageManager>(device->info);
|
|
|
|
|
particle_system_manager = make_unique<ParticleSystemManager>();
|
|
|
|
|
bake_manager = make_unique<BakeManager>();
|
|
|
|
|
procedural_manager = make_unique<ProceduralManager>();
|
2024-11-29 12:20:56 +01:00
|
|
|
volume_manager = make_unique<VolumeManager>();
|
2020-08-18 10:46:12 +02:00
|
|
|
|
2021-03-15 18:52:45 +01:00
|
|
|
/* Create nodes after managers, since create_node() can tag the managers. */
|
|
|
|
|
camera = create_node<Camera>();
|
|
|
|
|
dicing_camera = create_node<Camera>();
|
2024-12-29 23:13:45 +01:00
|
|
|
lookup_tables = make_unique<LookupTables>();
|
2021-03-15 18:52:45 +01:00
|
|
|
film = create_node<Film>();
|
|
|
|
|
background = create_node<Background>();
|
|
|
|
|
integrator = create_node<Integrator>();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2024-12-26 17:53:59 +01:00
|
|
|
ccl::Film::add_default(this);
|
|
|
|
|
ccl::ShaderManager::add_default(this);
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Scene::~Scene()
|
|
|
|
|
{
|
2012-11-09 08:46:53 +00:00
|
|
|
free_memory(true);
|
|
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
void Scene::free_memory(bool final)
|
|
|
|
|
{
|
2024-12-29 23:13:45 +01:00
|
|
|
bvh.reset();
|
2020-12-10 14:18:25 +01:00
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
/* The order of deletion is important to make sure data is freed based on
|
|
|
|
|
* possible dependencies as the Nodes' reference counts are decremented in the
|
|
|
|
|
* destructors:
|
2021-05-02 02:23:34 +02:00
|
|
|
*
|
|
|
|
|
* - Procedurals can create and hold pointers to any other types.
|
|
|
|
|
* - Objects can hold pointers to Geometries and ParticleSystems
|
|
|
|
|
* - Lights and Geometries can hold pointers to Shaders.
|
|
|
|
|
*
|
2024-12-29 17:32:00 +01:00
|
|
|
* Similarly, we first delete all nodes and their associated device data, and
|
|
|
|
|
* then the managers and their associated device data.
|
2021-05-02 02:23:34 +02:00
|
|
|
*/
|
2024-12-30 02:20:36 +01:00
|
|
|
procedurals.clear();
|
2013-02-14 16:11:47 +00:00
|
|
|
objects.clear();
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.clear();
|
2013-02-14 16:11:47 +00:00
|
|
|
particle_systems.clear();
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
passes.clear();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
if (device) {
|
2015-10-27 13:16:04 +05:00
|
|
|
camera->device_free(device, &dscene, this);
|
2013-04-01 20:26:43 +00:00
|
|
|
film->device_free(device, &dscene, this);
|
2012-11-09 08:46:53 +00:00
|
|
|
background->device_free(device, &dscene);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
integrator->device_free(device, &dscene, true);
|
2021-05-02 02:23:34 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-05-02 02:23:34 +02:00
|
|
|
if (final) {
|
2024-12-30 02:20:36 +01:00
|
|
|
cameras.clear();
|
|
|
|
|
integrators.clear();
|
|
|
|
|
films.clear();
|
|
|
|
|
backgrounds.clear();
|
|
|
|
|
|
|
|
|
|
camera = nullptr;
|
|
|
|
|
dicing_camera = nullptr;
|
|
|
|
|
integrator = nullptr;
|
|
|
|
|
film = nullptr;
|
|
|
|
|
background = nullptr;
|
2021-05-02 02:23:34 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
/* Delete Shaders after every other nodes to ensure that we do not try to
|
|
|
|
|
* decrement the reference count on some dangling pointer. */
|
2021-05-02 02:23:34 +02:00
|
|
|
shaders.clear();
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
/* Now that all nodes have been deleted, we can safely delete managers and
|
|
|
|
|
* device data. */
|
2021-05-02 02:23:34 +02:00
|
|
|
if (device) {
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
object_manager->device_free(device, &dscene, true);
|
|
|
|
|
geometry_manager->device_free(device, &dscene, true);
|
2013-04-01 20:26:52 +00:00
|
|
|
shader_manager->device_free(device, &dscene, this);
|
2025-03-04 17:27:10 +01:00
|
|
|
osl_manager->device_free(device, &dscene, this);
|
2012-11-09 08:46:53 +00:00
|
|
|
light_manager->device_free(device, &dscene);
|
|
|
|
|
particle_system_manager->device_free(device, &dscene);
|
2014-01-02 19:05:07 -02:00
|
|
|
bake_manager->device_free(device, &dscene);
|
2024-11-29 12:20:56 +01:00
|
|
|
volume_manager->device_free(&dscene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (final) {
|
2017-10-20 04:20:37 +02:00
|
|
|
image_manager->device_free(device);
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
|
|
|
|
else {
|
2017-10-20 04:20:37 +02:00
|
|
|
image_manager->device_free_builtin(device);
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-04-01 20:26:43 +00:00
|
|
|
lookup_tables->device_free(device, &dscene);
|
2012-11-09 08:46:53 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
if (final) {
|
2024-12-29 23:13:45 +01:00
|
|
|
lookup_tables.reset();
|
|
|
|
|
object_manager.reset();
|
|
|
|
|
geometry_manager.reset();
|
|
|
|
|
shader_manager.reset();
|
2025-03-04 17:27:10 +01:00
|
|
|
osl_manager.reset();
|
2024-12-29 23:13:45 +01:00
|
|
|
light_manager.reset();
|
|
|
|
|
particle_system_manager.reset();
|
|
|
|
|
image_manager.reset();
|
|
|
|
|
bake_manager.reset();
|
|
|
|
|
update_stats.reset();
|
|
|
|
|
procedural_manager.reset();
|
2024-11-29 12:20:56 +01:00
|
|
|
volume_manager.reset();
|
2012-11-09 08:46:53 +00:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Scene::device_update(Device *device_, Progress &progress)
|
|
|
|
|
{
|
2023-09-17 09:01:48 +10:00
|
|
|
if (!device) {
|
2011-04-27 11:58:34 +00:00
|
|
|
device = device_;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2016-04-22 10:55:26 +02:00
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
const bool print_stats = need_data_update();
|
2025-08-29 13:23:56 +02:00
|
|
|
bool kernels_reloaded = false;
|
2016-04-22 10:55:26 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
while (true) {
|
2020-10-01 23:16:01 +02:00
|
|
|
if (update_stats) {
|
2025-08-29 13:23:56 +02:00
|
|
|
update_stats->clear();
|
2020-10-01 23:16:01 +02:00
|
|
|
}
|
|
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
const scoped_callback_timer timer([this, print_stats](double time) {
|
|
|
|
|
if (update_stats) {
|
|
|
|
|
update_stats->scene.times.add_entry({"device_update", time});
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
if (print_stats) {
|
|
|
|
|
printf("Update statistics:\n%s\n", update_stats->full_report().c_str());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
});
|
2022-04-02 00:11:11 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
/* The order of updates is important, because there's dependencies between
|
|
|
|
|
* the different managers, using data computed by previous managers. */
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
if (film->update_lightgroups(this)) {
|
|
|
|
|
light_manager->tag_update(this, ccl::LightManager::LIGHT_MODIFIED);
|
|
|
|
|
object_manager->tag_update(this, ccl::ObjectManager::OBJECT_MODIFIED);
|
|
|
|
|
background->tag_modified();
|
|
|
|
|
}
|
|
|
|
|
if (film->exposure_is_modified()) {
|
|
|
|
|
integrator->tag_modified();
|
|
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
/* Compile shaders and get information about features they used. */
|
|
|
|
|
progress.set_status("Updating Shaders");
|
|
|
|
|
osl_manager->device_update_pre(device, this);
|
|
|
|
|
shader_manager->device_update_pre(device, &dscene, this, progress);
|
2025-04-09 19:33:57 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2025-04-09 19:33:57 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
/* Passes. After shader manager as this depends on the shaders. */
|
|
|
|
|
film->update_passes(this);
|
|
|
|
|
|
|
|
|
|
/* Update kernel features. After shaders and passes since those affect features. */
|
|
|
|
|
update_kernel_features();
|
|
|
|
|
|
|
|
|
|
/* Load render kernels, before uploading most data to the GPU, and before displacement and
|
|
|
|
|
* background light need to run kernels.
|
|
|
|
|
*
|
|
|
|
|
* Do it outside of the scene mutex since the heavy part of the loading (i.e. kernel
|
|
|
|
|
* compilation) does not depend on the scene and some other functionality (like display
|
|
|
|
|
* driver) might be waiting on the scene mutex to synchronize display pass.
|
|
|
|
|
*
|
|
|
|
|
* This does mean the scene might have gotten updated in the meantime, in which case
|
|
|
|
|
* we have to redo the first part of the scene update. */
|
|
|
|
|
const uint kernel_features = dscene.data.kernel_features;
|
|
|
|
|
scene_updated_while_loading_kernels = false;
|
|
|
|
|
if (!kernels_loaded || loaded_kernel_features != kernel_features) {
|
|
|
|
|
mutex.unlock();
|
|
|
|
|
kernels_reloaded |= load_kernels(progress);
|
|
|
|
|
mutex.lock();
|
|
|
|
|
}
|
2025-04-09 19:33:57 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!scene_updated_while_loading_kernels) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2025-04-09 19:33:57 +02:00
|
|
|
}
|
|
|
|
|
|
2025-04-11 19:14:14 +02:00
|
|
|
/* Upload shaders to GPU and compile OSL kernels, after kernels have been loaded. */
|
|
|
|
|
shader_manager->device_update_post(device, &dscene, this, progress);
|
|
|
|
|
osl_manager->device_update_post(device, this, progress, kernels_reloaded);
|
|
|
|
|
|
|
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-25 14:56:57 +01:00
|
|
|
procedural_manager->update(this, progress);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel()) {
|
2021-01-25 14:56:57 +01:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2021-01-25 14:56:57 +01:00
|
|
|
|
2013-12-28 16:56:19 +01:00
|
|
|
progress.set_status("Updating Background");
|
|
|
|
|
background->device_update(device, &dscene, this);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2013-12-28 16:56:19 +01:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Camera will be used by adaptive subdivision, so do early. */
|
2015-02-02 22:06:31 +05:00
|
|
|
progress.set_status("Updating Camera");
|
|
|
|
|
camera->device_update(device, &dscene, this);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2015-02-02 22:06:31 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2015-02-02 22:06:31 +05:00
|
|
|
|
2020-02-02 12:04:19 +01:00
|
|
|
geometry_manager->device_update_preprocess(device, this, progress);
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Update objects after geometry preprocessing. */
|
2016-03-31 17:54:03 +02:00
|
|
|
progress.set_status("Updating Objects");
|
|
|
|
|
object_manager->device_update(device, &dscene, this, progress);
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2018-01-18 22:40:48 -05:00
|
|
|
progress.set_status("Updating Particle Systems");
|
|
|
|
|
particle_system_manager->device_update(device, &dscene, this, progress);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2018-01-18 22:40:48 -05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2018-01-18 22:40:48 -05:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Camera and shaders must be ready here for adaptive subdivision and displacement. */
|
2015-04-30 01:07:38 +05:00
|
|
|
progress.set_status("Updating Meshes");
|
2020-02-02 12:04:19 +01:00
|
|
|
geometry_manager->device_update(device, &dscene, this, progress);
|
2014-10-03 12:11:19 +02:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2014-10-03 12:11:19 +02:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Update object flags with final geometry. */
|
2015-04-30 01:07:38 +05:00
|
|
|
progress.set_status("Updating Objects Flags");
|
|
|
|
|
object_manager->device_update_flags(device, &dscene, this, progress);
|
2015-01-19 19:08:58 +05:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2021-11-29 15:06:22 +00:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2021-11-29 15:06:22 +00:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Update BVH primitive objects with final geometry. */
|
2021-11-29 15:06:22 +00:00
|
|
|
progress.set_status("Updating Primitive Offsets");
|
|
|
|
|
object_manager->device_update_prim_offsets(device, &dscene, this);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2015-01-19 19:08:58 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2015-01-19 19:08:58 +05:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Images last, as they should be more likely to use host memory fallback than geometry.
|
2025-04-12 19:21:41 +10:00
|
|
|
* Some images may have been uploaded early for displacement already at this point. */
|
2015-04-02 20:37:57 +05:00
|
|
|
progress.set_status("Updating Images");
|
2017-10-20 04:20:37 +02:00
|
|
|
image_manager->device_update(device, this, progress);
|
2015-04-02 20:37:57 +05:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2015-04-02 20:37:57 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2015-04-02 20:37:57 +05:00
|
|
|
|
2024-11-29 12:20:56 +01:00
|
|
|
/* Evaluate volume shader to build volume octrees. */
|
|
|
|
|
progress.set_status("Updating Volume");
|
|
|
|
|
volume_manager->device_update(device, &dscene, this, progress);
|
|
|
|
|
|
|
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-02 22:06:31 +05:00
|
|
|
progress.set_status("Updating Camera Volume");
|
|
|
|
|
camera->device_update_volume(device, &dscene, this);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2015-02-02 22:06:31 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2018-11-25 08:01:14 +11:00
|
|
|
|
2014-02-06 21:09:46 +01:00
|
|
|
progress.set_status("Updating Lookup Tables");
|
2020-10-01 23:16:01 +02:00
|
|
|
lookup_tables->device_update(device, &dscene, this);
|
2014-02-06 21:09:46 +01:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2014-02-06 21:09:46 +01:00
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
/* Light manager needs shaders and final meshes for triangles in light tree. */
|
2011-04-27 11:58:34 +00:00
|
|
|
progress.set_status("Updating Lights");
|
|
|
|
|
light_manager->device_update(device, &dscene, this, progress);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2016-04-13 10:39:21 +02:00
|
|
|
progress.set_status("Updating Integrator");
|
|
|
|
|
integrator->device_update(device, &dscene, this);
|
2014-03-12 18:20:42 +01:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2014-03-12 18:20:42 +01:00
|
|
|
|
2016-04-13 10:39:21 +02:00
|
|
|
progress.set_status("Updating Film");
|
|
|
|
|
film->device_update(device, &dscene, this);
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2025-04-12 19:21:41 +10:00
|
|
|
/* Update lookup tables a second time for film tables. */
|
2014-03-12 18:20:42 +01:00
|
|
|
progress.set_status("Updating Lookup Tables");
|
2020-10-01 23:16:01 +02:00
|
|
|
lookup_tables->device_update(device, &dscene, this);
|
2014-03-12 18:20:42 +01:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2014-03-12 18:20:42 +01:00
|
|
|
|
2014-01-02 19:05:07 -02:00
|
|
|
progress.set_status("Updating Baking");
|
|
|
|
|
bake_manager->device_update(device, &dscene, this, progress);
|
|
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (progress.get_cancel() || device->have_error()) {
|
2014-12-05 21:00:05 +05:00
|
|
|
return;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2014-01-02 19:05:07 -02:00
|
|
|
|
2014-12-05 21:00:05 +05:00
|
|
|
if (device->have_error() == false) {
|
2021-10-22 14:20:22 +02:00
|
|
|
dscene.data.volume_stack_size = get_volume_stack_size();
|
|
|
|
|
|
2014-12-05 21:00:05 +05:00
|
|
|
progress.set_status("Updating Device", "Writing constant memory");
|
2022-06-17 17:16:37 +02:00
|
|
|
device->const_copy_to("data", &dscene.data, sizeof(dscene.data));
|
2014-12-05 21:00:05 +05:00
|
|
|
}
|
2015-02-14 19:39:14 +05:00
|
|
|
|
2022-07-12 15:32:46 +02:00
|
|
|
device->optimize_for_scene(this);
|
|
|
|
|
|
2016-04-22 10:55:26 +02:00
|
|
|
if (print_stats) {
|
2024-12-29 17:32:00 +01:00
|
|
|
const size_t mem_used = util_guarded_get_mem_used();
|
|
|
|
|
const size_t mem_peak = util_guarded_get_mem_peak();
|
2016-05-29 18:02:05 -04:00
|
|
|
|
2025-07-10 19:44:14 +02:00
|
|
|
LOG_INFO << "System memory statistics after full device sync:\n"
|
|
|
|
|
<< " Usage: " << string_human_readable_number(mem_used) << " ("
|
|
|
|
|
<< string_human_readable_size(mem_used) << ")\n"
|
|
|
|
|
<< " Peak: " << string_human_readable_number(mem_peak) << " ("
|
|
|
|
|
<< string_human_readable_size(mem_peak) << ")";
|
2016-04-22 10:55:26 +02:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
|
2022-04-19 16:28:14 +02:00
|
|
|
Scene::MotionType Scene::need_motion() const
|
2012-04-30 12:49:26 +00:00
|
|
|
{
|
2023-09-17 09:01:48 +10:00
|
|
|
if (integrator->get_motion_blur()) {
|
2018-01-12 19:56:52 +01:00
|
|
|
return MOTION_BLUR;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
if (Pass::contains(passes, PASS_MOTION)) {
|
2012-04-30 12:49:26 +00:00
|
|
|
return MOTION_PASS;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
return MOTION_NONE;
|
2012-04-30 12:49:26 +00:00
|
|
|
}
|
|
|
|
|
|
2016-07-16 18:56:59 +02:00
|
|
|
float Scene::motion_shutter_time()
|
|
|
|
|
{
|
2023-09-17 09:01:48 +10:00
|
|
|
if (need_motion() == Scene::MOTION_PASS) {
|
2016-07-16 18:56:59 +02:00
|
|
|
return 2.0f;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
return camera->get_shuttertime();
|
2016-07-16 18:56:59 +02:00
|
|
|
}
|
|
|
|
|
|
2012-04-30 12:49:26 +00:00
|
|
|
bool Scene::need_global_attribute(AttributeStandard std)
|
|
|
|
|
{
|
2023-09-17 09:01:48 +10:00
|
|
|
if (std == ATTR_STD_UV) {
|
2020-08-18 12:15:46 +02:00
|
|
|
return Pass::contains(passes, PASS_UV);
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
if (std == ATTR_STD_MOTION_VERTEX_POSITION) {
|
2014-03-29 13:03:46 +01:00
|
|
|
return need_motion() != MOTION_NONE;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
if (std == ATTR_STD_MOTION_VERTEX_NORMAL) {
|
2014-03-29 13:03:46 +01:00
|
|
|
return need_motion() == MOTION_BLUR;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2024-12-26 17:53:59 +01:00
|
|
|
if (std == ATTR_STD_VOLUME_VELOCITY || std == ATTR_STD_VOLUME_VELOCITY_X ||
|
|
|
|
|
std == ATTR_STD_VOLUME_VELOCITY_Y || std == ATTR_STD_VOLUME_VELOCITY_Z)
|
2022-04-19 16:28:14 +02:00
|
|
|
{
|
|
|
|
|
return need_motion() != MOTION_NONE;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-30 12:49:26 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Scene::need_global_attributes(AttributeRequestSet &attributes)
|
|
|
|
|
{
|
2023-09-17 09:01:48 +10:00
|
|
|
for (int std = ATTR_STD_NONE; std < ATTR_STD_NUM; std++) {
|
|
|
|
|
if (need_global_attribute((AttributeStandard)std)) {
|
2012-04-30 12:49:26 +00:00
|
|
|
attributes.add((AttributeStandard)std);
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
|
|
|
|
}
|
2012-04-30 12:49:26 +00:00
|
|
|
}
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
bool Scene::need_update()
|
|
|
|
|
{
|
2020-11-04 11:17:38 +01:00
|
|
|
return (need_reset() || film->is_modified());
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
|
2016-04-22 10:55:26 +02:00
|
|
|
bool Scene::need_data_update()
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
return (background->is_modified() || image_manager->need_update() ||
|
|
|
|
|
object_manager->need_update() || geometry_manager->need_update() ||
|
|
|
|
|
light_manager->need_update() || lookup_tables->need_update() ||
|
|
|
|
|
integrator->is_modified() || shader_manager->need_update() ||
|
|
|
|
|
particle_system_manager->need_update() || bake_manager->need_update() ||
|
2021-01-25 14:56:57 +01:00
|
|
|
film->is_modified() || procedural_manager->need_update());
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-21 17:58:34 +02:00
|
|
|
bool Scene::need_reset(const bool check_camera)
|
2016-04-22 10:55:26 +02:00
|
|
|
{
|
2022-09-21 17:58:34 +02:00
|
|
|
return need_data_update() || (check_camera && camera->is_modified());
|
2016-04-22 10:55:26 +02:00
|
|
|
}
|
|
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
void Scene::reset()
|
|
|
|
|
{
|
2025-03-04 17:27:10 +01:00
|
|
|
osl_manager->reset(this);
|
2025-03-04 18:08:17 +01:00
|
|
|
ShaderManager::add_default(this);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
/* ensure all objects are updated */
|
2020-11-04 11:17:38 +01:00
|
|
|
camera->tag_modified();
|
|
|
|
|
dicing_camera->tag_modified();
|
|
|
|
|
film->tag_modified();
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
background->tag_modified();
|
|
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
background->tag_update(this);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
integrator->tag_update(this, Integrator::UPDATE_ALL);
|
|
|
|
|
object_manager->tag_update(this, ObjectManager::UPDATE_ALL);
|
|
|
|
|
geometry_manager->tag_update(this, GeometryManager::UPDATE_ALL);
|
|
|
|
|
light_manager->tag_update(this, LightManager::UPDATE_ALL);
|
2014-06-05 17:39:16 +02:00
|
|
|
particle_system_manager->tag_update(this);
|
2021-01-25 14:56:57 +01:00
|
|
|
procedural_manager->tag_update();
|
2012-11-09 08:46:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Scene::device_free()
|
|
|
|
|
{
|
|
|
|
|
free_memory(false);
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-27 15:46:13 +02:00
|
|
|
void Scene::collect_statistics(RenderStats *stats)
|
|
|
|
|
{
|
2020-02-02 12:04:19 +01:00
|
|
|
geometry_manager->collect_statistics(this, stats);
|
2018-07-27 15:46:13 +02:00
|
|
|
image_manager->collect_statistics(stats);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-01 23:16:01 +02:00
|
|
|
void Scene::enable_update_stats()
|
|
|
|
|
{
|
|
|
|
|
if (!update_stats) {
|
2024-12-29 23:13:45 +01:00
|
|
|
update_stats = make_unique<SceneUpdateStats>();
|
2020-10-01 23:16:01 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
void Scene::update_kernel_features()
|
2020-08-18 10:46:12 +02:00
|
|
|
{
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
if (!need_update()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2020-08-18 10:46:12 +02:00
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
/* These features are not being tweaked as often as shaders,
|
|
|
|
|
* so could be done selective magic for the viewport as well. */
|
|
|
|
|
uint kernel_features = shader_manager->get_kernel_features(this);
|
2020-08-18 10:46:12 +02:00
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
const bool use_motion = need_motion() == Scene::MotionType::MOTION_BLUR;
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
kernel_features |= KERNEL_FEATURE_PATH_TRACING;
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
|
2025-07-24 13:27:20 +02:00
|
|
|
/* Track the max prim count in case the backend needs to rebuild BVHs or
|
|
|
|
|
* kernels to support different limits. */
|
|
|
|
|
size_t kernel_max_prim_count = 0;
|
|
|
|
|
|
2022-06-30 12:14:22 +10:00
|
|
|
/* Figure out whether the scene will use shader ray-trace we need at least
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
* one caustic light, one caustic caster and one caustic receiver to use
|
2022-06-30 12:14:22 +10:00
|
|
|
* and enable the MNEE code path. */
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
bool has_caustics_receiver = false;
|
|
|
|
|
bool has_caustics_caster = false;
|
|
|
|
|
bool has_caustics_light = false;
|
|
|
|
|
|
2024-12-26 19:41:25 +01:00
|
|
|
for (Object *object : objects) {
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
if (object->get_is_caustics_caster()) {
|
|
|
|
|
has_caustics_caster = true;
|
|
|
|
|
}
|
|
|
|
|
else if (object->get_is_caustics_receiver()) {
|
|
|
|
|
has_caustics_receiver = true;
|
|
|
|
|
}
|
2020-11-04 11:17:38 +01:00
|
|
|
Geometry *geom = object->get_geometry();
|
2020-08-18 10:46:12 +02:00
|
|
|
if (use_motion) {
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
if (object->use_motion() || geom->get_use_motion_blur()) {
|
|
|
|
|
kernel_features |= KERNEL_FEATURE_OBJECT_MOTION;
|
|
|
|
|
}
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
2025-02-28 17:40:03 +01:00
|
|
|
if (object->get_is_shadow_catcher() && !geom->is_light()) {
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
kernel_features |= KERNEL_FEATURE_SHADOW_CATCHER;
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
2025-03-09 03:07:29 +01:00
|
|
|
if (geom->is_hair()) {
|
2025-08-11 19:36:26 +02:00
|
|
|
const Hair *hair = static_cast<const Hair *>(geom);
|
|
|
|
|
kernel_features |= (hair->curve_shape == CURVE_RIBBON) ? KERNEL_FEATURE_HAIR_RIBBON :
|
|
|
|
|
KERNEL_FEATURE_HAIR_THICK;
|
|
|
|
|
kernel_max_prim_count = max(kernel_max_prim_count, hair->num_segments());
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
2021-12-01 17:30:46 +01:00
|
|
|
else if (geom->is_pointcloud()) {
|
|
|
|
|
kernel_features |= KERNEL_FEATURE_POINTCLOUD;
|
2025-07-24 13:27:20 +02:00
|
|
|
kernel_max_prim_count = max(kernel_max_prim_count,
|
|
|
|
|
static_cast<PointCloud *>(geom)->num_points());
|
|
|
|
|
}
|
|
|
|
|
else if (geom->is_mesh()) {
|
|
|
|
|
kernel_max_prim_count = max(kernel_max_prim_count,
|
|
|
|
|
static_cast<Mesh *>(geom)->num_triangles());
|
2021-12-01 17:30:46 +01:00
|
|
|
}
|
2025-02-24 23:44:14 +01:00
|
|
|
else if (geom->is_light()) {
|
|
|
|
|
const Light *light = static_cast<const Light *>(object->get_geometry());
|
|
|
|
|
if (light->get_use_caustics()) {
|
|
|
|
|
has_caustics_light = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-05-26 12:21:44 +02:00
|
|
|
if (object->has_light_linking()) {
|
2023-05-24 13:36:13 +02:00
|
|
|
kernel_features |= KERNEL_FEATURE_LIGHT_LINKING;
|
|
|
|
|
}
|
2023-05-26 12:21:44 +02:00
|
|
|
if (object->has_shadow_linking()) {
|
2023-05-24 13:36:13 +02:00
|
|
|
kernel_features |= KERNEL_FEATURE_SHADOW_LINKING;
|
|
|
|
|
}
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
|
|
|
|
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
dscene.data.integrator.use_caustics = false;
|
2024-06-26 14:15:01 +02:00
|
|
|
if (device->info.has_mnee && has_caustics_caster && has_caustics_receiver && has_caustics_light)
|
|
|
|
|
{
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
dscene.data.integrator.use_caustics = true;
|
2022-05-30 18:04:14 +02:00
|
|
|
kernel_features |= KERNEL_FEATURE_MNEE;
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
}
|
|
|
|
|
|
2022-09-21 17:58:34 +02:00
|
|
|
if (integrator->get_guiding_params(device).use) {
|
|
|
|
|
kernel_features |= KERNEL_FEATURE_PATH_GUIDING;
|
|
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
if (bake_manager->get_baking()) {
|
|
|
|
|
kernel_features |= KERNEL_FEATURE_BAKING;
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
kernel_features |= film->get_kernel_features(this);
|
2021-10-26 15:30:12 +02:00
|
|
|
kernel_features |= integrator->get_kernel_features();
|
2025-04-25 19:27:30 +02:00
|
|
|
kernel_features |= camera->get_kernel_features();
|
2020-08-18 10:46:12 +02:00
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
dscene.data.kernel_features = kernel_features;
|
2020-08-18 10:46:12 +02:00
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
/* Currently viewport render is faster with higher max_closures, needs
|
|
|
|
|
* investigating. */
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
const uint max_closures = (params.background) ? get_max_closure_count() : MAX_CLOSURE;
|
|
|
|
|
dscene.data.max_closures = max_closures;
|
|
|
|
|
dscene.data.max_shaders = shaders.size();
|
2025-07-24 13:27:20 +02:00
|
|
|
|
|
|
|
|
/* Inform the device of the BVH limits. If this returns true, all BVHs
|
|
|
|
|
* and kernels need to be rebuilt. */
|
|
|
|
|
if (device->set_bvh_limits(objects.size(), kernel_max_prim_count)) {
|
|
|
|
|
kernels_loaded = false;
|
|
|
|
|
for (Geometry *geom : geometry) {
|
|
|
|
|
geom->need_update_rebuild = true;
|
|
|
|
|
geom->tag_modified();
|
|
|
|
|
}
|
|
|
|
|
}
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
}
|
2020-08-18 10:46:12 +02:00
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
bool Scene::update(Progress &progress)
|
|
|
|
|
{
|
|
|
|
|
if (!need_update()) {
|
|
|
|
|
return false;
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
|
2021-10-21 14:52:34 +02:00
|
|
|
/* Upload scene data to the GPU. */
|
|
|
|
|
progress.set_status("Updating Scene");
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
MEM_GUARDED_CALL(&progress, device_update, device, progress);
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-04-09 19:33:57 +02:00
|
|
|
bool Scene::update_camera_resolution(Progress &progress, int width, int height)
|
|
|
|
|
{
|
|
|
|
|
if (!camera->set_screen_size(width, height)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
camera->device_update(device, &dscene, this);
|
|
|
|
|
|
|
|
|
|
progress.set_status("Updating Device", "Writing constant memory");
|
|
|
|
|
device->const_copy_to("data", &dscene.data, sizeof(dscene.data));
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
static void log_kernel_features(const uint features)
|
|
|
|
|
{
|
2025-07-10 19:44:14 +02:00
|
|
|
LOG_INFO << "Requested features:";
|
|
|
|
|
LOG_INFO << "Use BSDF " << string_from_bool(features & KERNEL_FEATURE_NODE_BSDF);
|
|
|
|
|
LOG_INFO << "Use Emission " << string_from_bool(features & KERNEL_FEATURE_NODE_EMISSION);
|
|
|
|
|
LOG_INFO << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_NODE_VOLUME);
|
|
|
|
|
LOG_INFO << "Use Bump " << string_from_bool(features & KERNEL_FEATURE_NODE_BUMP);
|
|
|
|
|
LOG_INFO << "Use Voronoi " << string_from_bool(features & KERNEL_FEATURE_NODE_VORONOI_EXTRA);
|
|
|
|
|
LOG_INFO << "Use Shader Raytrace " << string_from_bool(features & KERNEL_FEATURE_NODE_RAYTRACE);
|
|
|
|
|
LOG_INFO << "Use MNEE " << string_from_bool(features & KERNEL_FEATURE_MNEE);
|
|
|
|
|
LOG_INFO << "Use Transparent " << string_from_bool(features & KERNEL_FEATURE_TRANSPARENT);
|
|
|
|
|
LOG_INFO << "Use Denoising " << string_from_bool(features & KERNEL_FEATURE_DENOISING);
|
|
|
|
|
LOG_INFO << "Use Path Tracing " << string_from_bool(features & KERNEL_FEATURE_PATH_TRACING);
|
|
|
|
|
LOG_INFO << "Use Hair " << string_from_bool(features & KERNEL_FEATURE_HAIR);
|
|
|
|
|
LOG_INFO << "Use Pointclouds " << string_from_bool(features & KERNEL_FEATURE_POINTCLOUD);
|
|
|
|
|
LOG_INFO << "Use Object Motion " << string_from_bool(features & KERNEL_FEATURE_OBJECT_MOTION);
|
|
|
|
|
LOG_INFO << "Use Baking " << string_from_bool(features & KERNEL_FEATURE_BAKING);
|
|
|
|
|
LOG_INFO << "Use Subsurface " << string_from_bool(features & KERNEL_FEATURE_SUBSURFACE);
|
|
|
|
|
LOG_INFO << "Use Volume " << string_from_bool(features & KERNEL_FEATURE_VOLUME);
|
|
|
|
|
LOG_INFO << "Use Shadow Catcher " << string_from_bool(features & KERNEL_FEATURE_SHADOW_CATCHER);
|
2025-07-25 18:09:38 +02:00
|
|
|
LOG_INFO << "Use Portal Node " << string_from_bool(features & KERNEL_FEATURE_NODE_PORTAL);
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-22 18:59:32 +01:00
|
|
|
bool Scene::load_kernels(Progress &progress)
|
2020-08-18 10:46:12 +02:00
|
|
|
{
|
2025-08-29 13:23:56 +02:00
|
|
|
progress.set_status("Loading render kernels (may take a few minutes the first time)");
|
2020-08-18 10:46:12 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
const scoped_timer timer;
|
2020-08-18 10:46:12 +02:00
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
const uint kernel_features = dscene.data.kernel_features;
|
|
|
|
|
log_kernel_features(kernel_features);
|
|
|
|
|
if (!device->load_kernels(kernel_features)) {
|
|
|
|
|
string message = device->error_message();
|
|
|
|
|
if (message.empty()) {
|
|
|
|
|
message = "Failed loading render kernel, see console for errors";
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
|
|
|
|
|
2025-08-29 13:23:56 +02:00
|
|
|
progress.set_error(message);
|
|
|
|
|
progress.set_status(message);
|
|
|
|
|
progress.set_update();
|
|
|
|
|
return false;
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
2025-08-29 13:23:56 +02:00
|
|
|
|
|
|
|
|
kernels_loaded = true;
|
|
|
|
|
loaded_kernel_features = kernel_features;
|
|
|
|
|
return true;
|
2020-08-18 10:46:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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];
|
2021-05-02 02:34:56 +02:00
|
|
|
if (shader->reference_count()) {
|
2024-12-29 17:32:00 +01:00
|
|
|
const int num_closures = shader->graph->get_num_closures();
|
2020-08-18 10:46:12 +02:00
|
|
|
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. */
|
2025-07-10 19:44:14 +02:00
|
|
|
LOG_WARNING << "Maximum number of closures exceeded: " << max_closure_global << " > "
|
|
|
|
|
<< MAX_CLOSURE;
|
2020-08-18 10:46:12 +02:00
|
|
|
|
|
|
|
|
max_closure_global = MAX_CLOSURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return max_closure_global;
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-05 15:05:12 +02:00
|
|
|
int Scene::get_volume_stack_size() const
|
|
|
|
|
{
|
2021-10-08 16:38:40 +02:00
|
|
|
int volume_stack_size = 0;
|
|
|
|
|
|
|
|
|
|
/* Space for background volume and terminator.
|
2024-12-29 17:32:00 +01:00
|
|
|
* Don't do optional here because camera ray initialization expects that there
|
|
|
|
|
* is space for at least those elements (avoiding extra condition to check if
|
|
|
|
|
* there is actual volume or not).
|
2021-10-08 16:38:40 +02:00
|
|
|
*/
|
|
|
|
|
volume_stack_size += 2;
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
/* Quick non-expensive check. Can over-estimate maximum possible nested level,
|
|
|
|
|
* but does not require expensive calculation during pre-processing. */
|
2021-10-22 14:20:22 +02:00
|
|
|
bool has_volume_object = false;
|
2021-10-05 15:05:12 +02:00
|
|
|
for (const Object *object : objects) {
|
2021-10-22 14:20:22 +02:00
|
|
|
if (!object->get_geometry()->has_volume) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (object->intersects_volume) {
|
2024-12-29 17:32:00 +01:00
|
|
|
/* Object intersects another volume, assume it's possible to go deeper in
|
|
|
|
|
* the stack. */
|
|
|
|
|
/* TODO(sergey): This might count nesting twice (A intersects B and B
|
|
|
|
|
* intersects A), but can't think of a computationally cheap algorithm.
|
|
|
|
|
* Dividing my 2 doesn't work because of Venn diagram example with 3
|
|
|
|
|
* circles. */
|
2021-10-22 14:20:22 +02:00
|
|
|
++volume_stack_size;
|
|
|
|
|
}
|
|
|
|
|
else if (!has_volume_object) {
|
|
|
|
|
/* Allocate space for at least one volume object. */
|
2021-10-08 16:38:40 +02:00
|
|
|
++volume_stack_size;
|
2021-10-05 15:05:12 +02:00
|
|
|
}
|
|
|
|
|
|
2021-10-22 14:20:22 +02:00
|
|
|
has_volume_object = true;
|
|
|
|
|
|
2021-10-08 16:38:40 +02:00
|
|
|
if (volume_stack_size == MAX_VOLUME_STACK_SIZE) {
|
2021-10-05 15:05:12 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-08 16:38:40 +02:00
|
|
|
volume_stack_size = min(volume_stack_size, MAX_VOLUME_STACK_SIZE);
|
2021-10-05 15:05:12 +02:00
|
|
|
|
2025-08-18 20:22:44 +02:00
|
|
|
LOG_DEBUG << "Detected required volume stack size " << volume_stack_size;
|
2021-10-22 14:20:22 +02:00
|
|
|
|
2021-10-08 16:38:40 +02:00
|
|
|
return volume_stack_size;
|
2021-10-05 15:05:12 +02:00
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
bool Scene::has_shadow_catcher()
|
|
|
|
|
{
|
|
|
|
|
if (shadow_catcher_modified_) {
|
|
|
|
|
has_shadow_catcher_ = false;
|
|
|
|
|
for (Object *object : objects) {
|
2025-02-28 17:40:03 +01:00
|
|
|
/* Shadow catcher flags on lights only controls effect on other objects, it's
|
|
|
|
|
* not catching shadows itself. This is on by default, so ignore to avoid
|
|
|
|
|
* performance impact when there is no actual shadow catcher. */
|
|
|
|
|
if (object->get_is_shadow_catcher() && !object->get_geometry()->is_light()) {
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
has_shadow_catcher_ = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
shadow_catcher_modified_ = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return has_shadow_catcher_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Scene::tag_shadow_catcher_modified()
|
|
|
|
|
{
|
|
|
|
|
shadow_catcher_modified_ = true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-25 19:11:08 +01:00
|
|
|
bool Scene::has_volume()
|
|
|
|
|
{
|
|
|
|
|
has_volume_modified_ = false;
|
|
|
|
|
return dscene.data.integrator.use_volumes;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Scene::has_volume_modified() const
|
|
|
|
|
{
|
|
|
|
|
return has_volume_modified_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Scene::tag_has_volume_modified()
|
|
|
|
|
{
|
|
|
|
|
has_volume_modified_ = true;
|
|
|
|
|
}
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
template<> Light *Scene::create_node<Light>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Light> node = make_unique<Light>();
|
|
|
|
|
Light *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2025-02-24 23:44:14 +01:00
|
|
|
geometry.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
light_manager->tag_update(this, LightManager::LIGHT_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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<> Mesh *Scene::create_node<Mesh>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Mesh> node = make_unique<Mesh>();
|
|
|
|
|
Mesh *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::MESH_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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<> Hair *Scene::create_node<Hair>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Hair> node = make_unique<Hair>();
|
|
|
|
|
Hair *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::HAIR_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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<> Volume *Scene::create_node<Volume>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Volume> node = make_unique<Volume>();
|
|
|
|
|
Volume *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::MESH_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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
|
|
|
}
|
|
|
|
|
|
2021-12-01 17:30:46 +01:00
|
|
|
template<> PointCloud *Scene::create_node<PointCloud>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<PointCloud> node = make_unique<PointCloud>();
|
|
|
|
|
PointCloud *node_ptr = node.get();
|
2021-12-01 17:30:46 +01:00
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.push_back(std::move(node));
|
2021-12-01 17:30:46 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::POINT_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
2021-12-01 17:30:46 +01:00
|
|
|
}
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
template<> Object *Scene::create_node<Object>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Object> node = make_unique<Object>();
|
|
|
|
|
Object *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
objects.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
object_manager->tag_update(this, ObjectManager::OBJECT_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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<> ParticleSystem *Scene::create_node<ParticleSystem>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<ParticleSystem> node = make_unique<ParticleSystem>();
|
|
|
|
|
ParticleSystem *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
particle_systems.push_back(std::move(node));
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
particle_system_manager->tag_update(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
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<> Shader *Scene::create_node<Shader>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Shader> node = make_unique<Shader>();
|
|
|
|
|
Shader *node_ptr = node.get();
|
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
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
shaders.push_back(std::move(node));
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
shader_manager->tag_update(this, ShaderManager::SHADER_ADDED);
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
template<> Pass *Scene::create_node<Pass>()
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Pass> node = make_unique<Pass>();
|
|
|
|
|
Pass *node_ptr = node.get();
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
node->set_owner(this);
|
2024-12-30 02:20:36 +01:00
|
|
|
passes.push_back(std::move(node));
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
film->tag_modified();
|
2024-12-30 02:20:36 +01:00
|
|
|
return node_ptr;
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> Camera *Scene::create_node<Camera>()
|
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
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
unique_ptr<Camera> node = make_unique<Camera>();
|
|
|
|
|
Camera *node_ptr = node.get();
|
|
|
|
|
node->set_owner(this);
|
|
|
|
|
cameras.push_back(std::move(node));
|
|
|
|
|
return node_ptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<> Integrator *Scene::create_node<Integrator>()
|
|
|
|
|
{
|
|
|
|
|
unique_ptr<Integrator> node = make_unique<Integrator>();
|
|
|
|
|
Integrator *node_ptr = node.get();
|
|
|
|
|
node->set_owner(this);
|
|
|
|
|
integrators.push_back(std::move(node));
|
|
|
|
|
return node_ptr;
|
|
|
|
|
}
|
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
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> Background *Scene::create_node<Background>()
|
|
|
|
|
{
|
|
|
|
|
unique_ptr<Background> node = make_unique<Background>();
|
|
|
|
|
Background *node_ptr = node.get();
|
|
|
|
|
node->set_owner(this);
|
|
|
|
|
backgrounds.push_back(std::move(node));
|
|
|
|
|
return node_ptr;
|
|
|
|
|
}
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> Film *Scene::create_node<Film>()
|
|
|
|
|
{
|
|
|
|
|
unique_ptr<Film> node = make_unique<Film>();
|
|
|
|
|
Film *node_ptr = node.get();
|
|
|
|
|
node->set_owner(this);
|
|
|
|
|
films.push_back(std::move(node));
|
|
|
|
|
return node_ptr;
|
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
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Light *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
2025-02-24 23:44:14 +01:00
|
|
|
geometry.erase_by_swap(node);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
light_manager->tag_update(this, LightManager::LIGHT_REMOVED);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Mesh *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
geometry.erase_by_swap(node);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::MESH_REMOVED);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Hair *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
geometry.erase_by_swap(node);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::HAIR_REMOVED);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Volume *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
geometry.erase_by_swap(node);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::MESH_REMOVED);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(PointCloud *node)
|
2021-12-01 17:30:46 +01:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
geometry.erase_by_swap(node);
|
2021-12-01 17:30:46 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::POINT_REMOVED);
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Geometry *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
uint flag;
|
|
|
|
|
if (node->is_hair()) {
|
|
|
|
|
flag = GeometryManager::HAIR_REMOVED;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
flag = GeometryManager::MESH_REMOVED;
|
2024-11-29 12:20:56 +01:00
|
|
|
if (node->has_volume) {
|
|
|
|
|
volume_manager->tag_update(node);
|
|
|
|
|
}
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
geometry.erase_by_swap(node);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, flag);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Object *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
2024-11-29 12:20:56 +01:00
|
|
|
|
|
|
|
|
uint flag = ObjectManager::OBJECT_REMOVED;
|
|
|
|
|
if (node->get_geometry()->has_volume) {
|
|
|
|
|
volume_manager->tag_update(node, flag);
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
objects.erase_by_swap(node);
|
2024-11-29 12:20:56 +01:00
|
|
|
object_manager->tag_update(this, flag);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(ParticleSystem *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
particle_systems.erase_by_swap(node);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
particle_system_manager->tag_update(this);
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Shader *node)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
/* don't delete unused shaders, not supported */
|
2024-12-26 17:53:59 +01:00
|
|
|
node->clear_reference_count();
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Procedural *node)
|
2021-01-25 14:56:57 +01:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
procedurals.erase_by_swap(node);
|
2021-01-25 14:56:57 +01:00
|
|
|
procedural_manager->tag_update();
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<> void Scene::delete_node(Pass *node)
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
passes.erase_by_swap(node);
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
film->tag_modified();
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-30 02:20:36 +01:00
|
|
|
template<typename T> static void assert_same_owner(const set<T *> &nodes, const NodeOwner *owner)
|
2020-10-29 14:40:29 +01:00
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
#ifdef NDEBUG
|
|
|
|
|
(void)nodes;
|
2020-10-29 14:40:29 +01:00
|
|
|
(void)owner;
|
2024-12-30 02:20:36 +01:00
|
|
|
#else
|
|
|
|
|
for (const T *node : nodes) {
|
|
|
|
|
assert(node->get_owner() == owner);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2020-10-29 14:40:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<Geometry *> &nodes, const NodeOwner *owner)
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert_same_owner(nodes, owner);
|
|
|
|
|
geometry.erase_in_set(nodes);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
geometry_manager->tag_update(this, GeometryManager::GEOMETRY_REMOVED);
|
2025-02-24 23:44:14 +01:00
|
|
|
light_manager->tag_update(this, LightManager::LIGHT_REMOVED);
|
2020-10-29 14:40:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<Object *> &nodes, const NodeOwner *owner)
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert_same_owner(nodes, owner);
|
|
|
|
|
objects.erase_in_set(nodes);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
object_manager->tag_update(this, ObjectManager::OBJECT_REMOVED);
|
2020-10-29 14:40:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<ParticleSystem *> &nodes, const NodeOwner *owner)
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert_same_owner(nodes, owner);
|
|
|
|
|
particle_systems.erase_in_set(nodes);
|
2020-10-29 14:40:29 +01:00
|
|
|
particle_system_manager->tag_update(this);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-02 02:34:56 +02:00
|
|
|
template<> void Scene::delete_nodes(const set<Shader *> &nodes, const NodeOwner * /*owner*/)
|
2020-10-29 14:40:29 +01:00
|
|
|
{
|
|
|
|
|
/* don't delete unused shaders, not supported */
|
2021-05-02 02:34:56 +02:00
|
|
|
for (Shader *shader : nodes) {
|
|
|
|
|
shader->clear_reference_count();
|
|
|
|
|
}
|
2020-10-29 14:40:29 +01:00
|
|
|
}
|
|
|
|
|
|
2021-01-25 14:56:57 +01:00
|
|
|
template<> void Scene::delete_nodes(const set<Procedural *> &nodes, const NodeOwner *owner)
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert_same_owner(nodes, owner);
|
|
|
|
|
procedurals.erase_in_set(nodes);
|
2021-01-25 14:56:57 +01:00
|
|
|
procedural_manager->tag_update();
|
|
|
|
|
}
|
|
|
|
|
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
template<> void Scene::delete_nodes(const set<Pass *> &nodes, const NodeOwner *owner)
|
|
|
|
|
{
|
2024-12-30 02:20:36 +01:00
|
|
|
assert_same_owner(nodes, owner);
|
|
|
|
|
passes.erase_in_set(nodes);
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
film->tag_modified();
|
|
|
|
|
}
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
CCL_NAMESPACE_END
|