Files
test/intern/cycles/blender/object.cpp

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

803 lines
25 KiB
C++
Raw Normal View History

/*
* Copyright 2011-2013 Blender Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include "blender/object_cull.h"
#include "blender/sync.h"
#include "blender/util.h"
#include "scene/alembic.h"
#include "scene/camera.h"
#include "scene/integrator.h"
#include "scene/light.h"
#include "scene/mesh.h"
#include "scene/object.h"
#include "scene/particles.h"
#include "scene/scene.h"
#include "scene/shader.h"
#include "scene/shader_graph.h"
#include "scene/shader_nodes.h"
#include "util/foreach.h"
#include "util/hash.h"
#include "util/log.h"
#include "util/task.h"
CCL_NAMESPACE_BEGIN
/* Utilities */
bool BlenderSync::BKE_object_is_modified(BL::Object &b_ob)
{
/* test if we can instance or if the object is modified */
if (b_ob.type() == BL::Object::type_META) {
/* multi-user and dupli metaballs are fused, can't instance */
return true;
}
else if (ccl::BKE_object_is_modified(b_ob, b_scene, preview)) {
/* modifiers */
return true;
}
else {
/* object level material links */
for (BL::MaterialSlot &b_slot : b_ob.material_slots) {
if (b_slot.link() == BL::MaterialSlot::link_OBJECT) {
return true;
}
}
}
return false;
}
bool BlenderSync::object_is_geometry(BObjectInfo &b_ob_info)
{
BL::ID b_ob_data = b_ob_info.object_data;
if (!b_ob_data) {
return false;
}
BL::Object::type_enum type = b_ob_info.iter_object.type();
if (type == BL::Object::type_VOLUME || type == BL::Object::type_HAIR ||
type == BL::Object::type_POINTCLOUD) {
/* Will be exported attached to mesh. */
return true;
}
/* Other object types that are not meshes but evaluate to meshes are presented to render engines
* as separate instance objects. Metaballs and surface objects have not been affected by that
* change yet. */
if (type == BL::Object::type_SURFACE || type == BL::Object::type_META) {
return true;
}
return b_ob_data.is_a(&RNA_Mesh);
}
bool BlenderSync::object_can_have_geometry(BL::Object &b_ob)
{
BL::Object::type_enum type = b_ob.type();
switch (type) {
case BL::Object::type_MESH:
case BL::Object::type_CURVE:
case BL::Object::type_SURFACE:
case BL::Object::type_META:
case BL::Object::type_FONT:
case BL::Object::type_HAIR:
case BL::Object::type_POINTCLOUD:
case BL::Object::type_VOLUME:
return true;
default:
return false;
}
}
bool BlenderSync::object_is_light(BL::Object &b_ob)
{
BL::ID b_ob_data = b_ob.data();
return (b_ob_data && b_ob_data.is_a(&RNA_Light));
}
void BlenderSync::sync_object_motion_init(BL::Object &b_parent, BL::Object &b_ob, Object *object)
{
/* Initialize motion blur for object, detecting if it's enabled and creating motion
* steps array if so. */
array<Transform> motion;
object->set_motion(motion);
Geometry *geom = object->get_geometry();
if (!geom) {
return;
}
int motion_steps = 0;
bool use_motion_blur = false;
Scene::MotionType need_motion = scene->need_motion();
if (need_motion == Scene::MOTION_BLUR) {
motion_steps = object_motion_steps(b_parent, b_ob, Object::MAX_MOTION_STEPS);
if (motion_steps && object_use_deform_motion(b_parent, b_ob)) {
use_motion_blur = true;
}
}
else if (need_motion != Scene::MOTION_NONE) {
motion_steps = 3;
}
geom->set_use_motion_blur(use_motion_blur);
geom->set_motion_steps(motion_steps);
motion.resize(motion_steps, transform_empty());
if (motion_steps) {
motion[motion_steps / 2] = object->get_tfm();
/* update motion socket before trying to access object->motion_time */
object->set_motion(motion);
for (size_t step = 0; step < motion_steps; step++) {
motion_times.insert(object->motion_time(step));
}
}
}
Object *BlenderSync::sync_object(BL::Depsgraph &b_depsgraph,
BL::ViewLayer &b_view_layer,
BL::DepsgraphObjectInstance &b_instance,
float motion_time,
bool use_particle_hair,
bool show_lights,
BlenderObjectCulling &culling,
bool *use_portal,
TaskPool *geom_task_pool)
{
const bool is_instance = b_instance.is_instance();
BL::Object b_ob = b_instance.object();
BL::Object b_parent = is_instance ? b_instance.parent() : b_instance.object();
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
BObjectInfo b_ob_info{b_ob, is_instance ? b_instance.instance_object() : b_ob, b_ob.data()};
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
const bool motion = motion_time != 0.0f;
/*const*/ Transform tfm = get_transform(b_ob.matrix_world());
int *persistent_id = NULL;
BL::Array<int, OBJECT_PERSISTENT_ID_SIZE> persistent_id_array;
if (is_instance) {
persistent_id_array = b_instance.persistent_id();
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
persistent_id = persistent_id_array.data;
if (!b_ob_info.is_real_object_data()) {
/* Remember which object data the geometry is coming from, so that we can sync it when the
* object has changed. */
instance_geometries_by_object[b_ob_info.real_object.ptr.data].insert(b_ob_info.object_data);
}
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
}
/* light is handled separately */
if (!motion && object_is_light(b_ob)) {
if (!show_lights) {
return NULL;
}
/* TODO: don't use lights for excluded layers used as mask layer,
* when dynamic overrides are back. */
#if 0
if (!((layer_flag & view_layer.holdout_layer) && (layer_flag & view_layer.exclude_layer)))
#endif
{
sync_light(b_parent,
persistent_id,
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
b_ob_info,
is_instance ? b_instance.random_id() : 0,
tfm,
use_portal);
}
return NULL;
}
/* only interested in object that we can create geometry from */
if (!object_is_geometry(b_ob_info)) {
return NULL;
}
/* Perform object culling. */
if (culling.test(scene, b_ob, tfm)) {
return NULL;
}
/* Visibility flags for both parent and child. */
PointerRNA cobject = RNA_pointer_get(&b_ob.ptr, "cycles");
bool use_holdout = b_parent.holdout_get(PointerRNA_NULL, b_view_layer);
uint visibility = object_ray_visibility(b_ob) & PATH_RAY_ALL_VISIBILITY;
if (b_parent.ptr.data != b_ob.ptr.data) {
visibility &= object_ray_visibility(b_parent);
}
/* TODO: make holdout objects on excluded layer invisible for non-camera rays. */
#if 0
if (use_holdout && (layer_flag & view_layer.exclude_layer)) {
visibility &= ~(PATH_RAY_ALL_VISIBILITY - PATH_RAY_CAMERA);
}
#endif
/* Clear camera visibility for indirect only objects. */
bool use_indirect_only = !use_holdout &&
b_parent.indirect_only_get(PointerRNA_NULL, b_view_layer);
if (use_indirect_only) {
visibility &= ~PATH_RAY_CAMERA;
}
/* Don't export completely invisible objects. */
if (visibility == 0) {
return NULL;
}
/* Use task pool only for non-instances, since sync_dupli_particle accesses
* geometry. This restriction should be removed for better performance. */
TaskPool *object_geom_task_pool = (is_instance) ? NULL : geom_task_pool;
/* key to lookup object */
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
ObjectKey key(b_parent, persistent_id, b_ob_info.real_object, use_particle_hair);
Object *object;
/* motion vector case */
if (motion) {
object = object_map.find(key);
if (object && object->use_motion()) {
/* Set transform at matching motion time step. */
int time_index = object->motion_step(motion_time);
if (time_index >= 0) {
array<Transform> motion = object->get_motion();
motion[time_index] = tfm;
object->set_motion(motion);
}
/* mesh deformation */
if (object->get_geometry())
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
sync_geometry_motion(
b_depsgraph, b_ob_info, object, motion_time, use_particle_hair, object_geom_task_pool);
}
return object;
}
/* test if we need to sync */
bool object_updated = object_map.add_or_update(&object, b_ob, b_parent, key) ||
(tfm != object->get_tfm());
/* mesh sync */
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
Geometry *geometry = sync_geometry(
b_depsgraph, b_ob_info, object_updated, use_particle_hair, object_geom_task_pool);
object->set_geometry(geometry);
/* special case not tracked by object update flags */
if (sync_object_attributes(b_instance, object)) {
object_updated = true;
}
/* holdout */
object->set_use_holdout(use_holdout);
object->set_visibility(visibility);
object->set_is_shadow_catcher(b_ob.is_shadow_catcher() || b_parent.is_shadow_catcher());
float shadow_terminator_shading_offset = get_float(cobject, "shadow_terminator_offset");
object->set_shadow_terminator_shading_offset(shadow_terminator_shading_offset);
float shadow_terminator_geometry_offset = get_float(cobject,
"shadow_terminator_geometry_offset");
object->set_shadow_terminator_geometry_offset(shadow_terminator_geometry_offset);
float ao_distance = get_float(cobject, "ao_distance");
if (ao_distance == 0.0f && b_parent.ptr.data != b_ob.ptr.data) {
PointerRNA cparent = RNA_pointer_get(&b_parent.ptr, "cycles");
ao_distance = get_float(cparent, "ao_distance");
}
object->set_ao_distance(ao_distance);
/* sync the asset name for Cryptomatte */
BL::Object parent = b_ob.parent();
ustring parent_name;
if (parent) {
while (parent.parent()) {
parent = parent.parent();
}
parent_name = parent.name();
}
else {
parent_name = b_ob.name();
}
object->set_asset_name(parent_name);
/* object sync
* transform comparison should not be needed, but duplis don't work perfect
* in the depsgraph and may not signal changes, so this is a workaround */
if (object->is_modified() || object_updated ||
(object->get_geometry() && object->get_geometry()->is_modified())) {
object->name = b_ob.name().c_str();
object->set_pass_id(b_ob.pass_index());
object->set_color(get_float3(b_ob.color()));
object->set_tfm(tfm);
/* dupli texture coordinates and random_id */
if (is_instance) {
object->set_dupli_generated(0.5f * get_float3(b_instance.orco()) -
make_float3(0.5f, 0.5f, 0.5f));
object->set_dupli_uv(get_float2(b_instance.uv()));
object->set_random_id(b_instance.random_id());
}
else {
object->set_dupli_generated(zero_float3());
object->set_dupli_uv(zero_float2());
object->set_random_id(hash_uint2(hash_string(object->name.c_str()), 0));
}
object->tag_update(scene);
}
sync_object_motion_init(b_parent, b_ob, object);
if (is_instance) {
/* Sync possible particle data. */
sync_dupli_particle(b_parent, b_instance, object);
}
return object;
}
/* This function mirrors drw_uniform_property_lookup in draw_instance_data.cpp */
static bool lookup_property(BL::ID b_id, const string &name, float4 *r_value)
{
PointerRNA ptr;
PropertyRNA *prop;
if (!RNA_path_resolve(&b_id.ptr, name.c_str(), &ptr, &prop)) {
return false;
}
if (prop == NULL) {
return false;
}
PropertyType type = RNA_property_type(prop);
int arraylen = RNA_property_array_length(&ptr, prop);
if (arraylen == 0) {
float value;
if (type == PROP_FLOAT)
value = RNA_property_float_get(&ptr, prop);
else if (type == PROP_INT)
2021-08-26 10:36:04 +02:00
value = static_cast<float>(RNA_property_int_get(&ptr, prop));
else
return false;
*r_value = make_float4(value, value, value, 1.0f);
return true;
}
else if (type == PROP_FLOAT && arraylen <= 4) {
*r_value = make_float4(0.0f, 0.0f, 0.0f, 1.0f);
RNA_property_float_get_array(&ptr, prop, &r_value->x);
return true;
}
return false;
}
/* This function mirrors drw_uniform_attribute_lookup in draw_instance_data.cpp */
static float4 lookup_instance_property(BL::DepsgraphObjectInstance &b_instance,
const string &name,
bool use_instancer)
{
string idprop_name = string_printf("[\"%s\"]", name.c_str());
float4 value;
/* If requesting instance data, check the parent particle system and object. */
if (use_instancer && b_instance.is_instance()) {
BL::ParticleSystem b_psys = b_instance.particle_system();
if (b_psys) {
if (lookup_property(b_psys.settings(), idprop_name, &value) ||
lookup_property(b_psys.settings(), name, &value)) {
return value;
}
}
if (lookup_property(b_instance.parent(), idprop_name, &value) ||
lookup_property(b_instance.parent(), name, &value)) {
return value;
}
}
/* Check the object and mesh. */
BL::Object b_ob = b_instance.object();
BL::ID b_data = b_ob.data();
if (lookup_property(b_ob, idprop_name, &value) || lookup_property(b_ob, name, &value) ||
lookup_property(b_data, idprop_name, &value) || lookup_property(b_data, name, &value)) {
return value;
}
return make_float4(0.0f);
}
bool BlenderSync::sync_object_attributes(BL::DepsgraphObjectInstance &b_instance, Object *object)
{
/* Find which attributes are needed. */
AttributeRequestSet requests = object->get_geometry()->needed_attributes();
/* Delete attributes that became unnecessary. */
vector<ParamValue> &attributes = object->attributes;
bool changed = false;
for (int i = attributes.size() - 1; i >= 0; i--) {
if (!requests.find(attributes[i].name())) {
attributes.erase(attributes.begin() + i);
changed = true;
}
}
/* Update attribute values. */
foreach (AttributeRequest &req, requests.requests) {
ustring name = req.name;
std::string real_name;
BlenderAttributeType type = blender_attribute_name_split_type(name, &real_name);
if (type != BL::ShaderNodeAttribute::attribute_type_GEOMETRY) {
bool use_instancer = (type == BL::ShaderNodeAttribute::attribute_type_INSTANCER);
float4 value = lookup_instance_property(b_instance, real_name, use_instancer);
/* Try finding the existing attribute value. */
ParamValue *param = NULL;
for (size_t i = 0; i < attributes.size(); i++) {
if (attributes[i].name() == name) {
param = &attributes[i];
break;
}
}
/* Replace or add the value. */
ParamValue new_param(name, TypeDesc::TypeFloat4, 1, &value);
assert(new_param.datasize() == sizeof(value));
if (!param) {
changed = true;
attributes.push_back(new_param);
}
else if (memcmp(param->data(), &value, sizeof(value)) != 0) {
changed = true;
*param = new_param;
}
}
}
return changed;
}
/* Object Loop */
void BlenderSync::sync_procedural(BL::Object &b_ob,
BL::MeshSequenceCacheModifier &b_mesh_cache,
bool has_subdivision_modifier)
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
{
#ifdef WITH_ALEMBIC
BL::CacheFile cache_file = b_mesh_cache.cache_file();
void *cache_file_key = cache_file.ptr.data;
AlembicProcedural *procedural = static_cast<AlembicProcedural *>(
procedural_map.find(cache_file_key));
if (procedural == nullptr) {
procedural = scene->create_node<AlembicProcedural>();
procedural_map.add(cache_file_key, procedural);
}
else {
procedural_map.used(procedural);
}
2021-08-26 10:36:04 +02:00
float current_frame = static_cast<float>(b_scene.frame_current());
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
if (cache_file.override_frame()) {
current_frame = cache_file.frame();
}
if (!cache_file.override_frame()) {
2021-08-26 10:36:04 +02:00
procedural->set_start_frame(static_cast<float>(b_scene.frame_start()));
procedural->set_end_frame(static_cast<float>(b_scene.frame_end()));
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
}
procedural->set_frame(current_frame);
procedural->set_frame_rate(b_scene.render().fps() / b_scene.render().fps_base());
procedural->set_frame_offset(cache_file.frame_offset());
string absolute_path = blender_absolute_path(b_data, b_ob, b_mesh_cache.cache_file().filepath());
procedural->set_filepath(ustring(absolute_path));
array<ustring> layers;
for (BL::CacheFileLayer &layer : cache_file.layers) {
if (layer.hide_layer()) {
continue;
}
absolute_path = blender_absolute_path(b_data, b_ob, layer.filepath());
layers.push_back_slow(ustring(absolute_path));
}
procedural->set_layers(layers);
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
procedural->set_scale(cache_file.scale());
procedural->set_use_prefetch(cache_file.use_prefetch());
procedural->set_prefetch_cache_size(cache_file.prefetch_cache_size());
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
/* create or update existing AlembicObjects */
ustring object_path = ustring(b_mesh_cache.object_path());
AlembicObject *abc_object = procedural->get_or_create_object(object_path);
array<Node *> used_shaders = find_used_shaders(b_ob);
abc_object->set_used_shaders(used_shaders);
PointerRNA cobj = RNA_pointer_get(&b_ob.ptr, "cycles");
const float subd_dicing_rate = max(0.1f, RNA_float_get(&cobj, "dicing_rate") * dicing_rate);
abc_object->set_subd_dicing_rate(subd_dicing_rate);
abc_object->set_subd_max_level(max_subdivisions);
abc_object->set_ignore_subdivision(!has_subdivision_modifier);
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
if (abc_object->is_modified() || procedural->is_modified()) {
procedural->tag_update(scene);
}
#else
(void)b_ob;
(void)b_mesh_cache;
2021-08-26 12:36:13 +10:00
(void)has_subdivision_modifier;
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
#endif
}
void BlenderSync::sync_objects(BL::Depsgraph &b_depsgraph,
BL::SpaceView3D &b_v3d,
float motion_time)
{
/* Task pool for multithreaded geometry sync. */
TaskPool geom_task_pool;
/* layer data */
bool motion = motion_time != 0.0f;
if (!motion) {
/* prepare for sync */
light_map.pre_sync();
geometry_map.pre_sync();
object_map.pre_sync();
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
procedural_map.pre_sync();
particle_system_map.pre_sync();
motion_times.clear();
}
else {
geometry_motion_synced.clear();
}
instance_geometries_by_object.clear();
/* initialize culling */
BlenderObjectCulling culling(scene, b_scene);
/* object loop */
bool cancel = false;
bool use_portal = false;
const bool show_lights = BlenderViewportParameters(b_v3d, use_developer_ui).use_scene_lights;
BL::ViewLayer b_view_layer = b_depsgraph.view_layer_eval();
BL::Depsgraph::object_instances_iterator b_instance_iter;
for (b_depsgraph.object_instances.begin(b_instance_iter);
b_instance_iter != b_depsgraph.object_instances.end() && !cancel;
++b_instance_iter) {
BL::DepsgraphObjectInstance b_instance = *b_instance_iter;
BL::Object b_ob = b_instance.object();
/* Viewport visibility. */
const bool show_in_viewport = !b_v3d || b_ob.visible_in_viewport_get(b_v3d);
if (show_in_viewport == false) {
continue;
}
/* Load per-object culling data. */
culling.init_object(scene, b_ob);
/* Ensure the object geom supporting the hair is processed before adding
* the hair processing task to the task pool, calling .to_mesh() on the
* same object in parallel does not work. */
const bool sync_hair = b_instance.show_particles() && object_has_particle_hair(b_ob);
/* Object itself. */
if (b_instance.show_self()) {
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
#ifdef WITH_ALEMBIC
bool use_procedural = false;
bool has_subdivision_modifier = false;
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
BL::MeshSequenceCacheModifier b_mesh_cache(PointerRNA_NULL);
/* Experimental as Blender does not have good support for procedurals at the moment, also
* only available in preview renders since currently do not have a good cache policy, the
* data being loaded at once for all the frames. */
if (experimental && b_v3d) {
b_mesh_cache = object_mesh_cache_find(b_ob, &has_subdivision_modifier);
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
use_procedural = b_mesh_cache && b_mesh_cache.cache_file().use_render_procedural();
}
if (use_procedural) {
/* Skip in the motion case, as generating motion blur data will be handled in the
* procedural. */
if (!motion) {
sync_procedural(b_ob, b_mesh_cache, has_subdivision_modifier);
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
}
}
else
#endif
{
sync_object(b_depsgraph,
b_view_layer,
b_instance,
motion_time,
false,
show_lights,
culling,
&use_portal,
sync_hair ? NULL : &geom_task_pool);
}
}
/* Particle hair as separate object. */
if (sync_hair) {
sync_object(b_depsgraph,
b_view_layer,
b_instance,
motion_time,
true,
show_lights,
culling,
&use_portal,
&geom_task_pool);
}
cancel = progress.get_cancel();
}
geom_task_pool.wait_work();
progress.set_sync_status("");
if (!cancel && !motion) {
sync_background_light(b_v3d, use_portal);
/* Handle removed data and modified pointers, as this may free memory, delete Nodes in the
2021-05-04 00:42:34 +10:00
* right order to ensure that dependent data is freed after their users. Objects should be
* freed before particle systems and geometries. */
light_map.post_sync();
object_map.post_sync();
geometry_map.post_sync();
particle_system_map.post_sync();
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
procedural_map.post_sync();
}
if (motion)
geometry_motion_synced.clear();
}
void BlenderSync::sync_motion(BL::RenderSettings &b_render,
BL::Depsgraph &b_depsgraph,
BL::SpaceView3D &b_v3d,
BL::Object &b_override,
int width,
int height,
void **python_thread_state)
{
if (scene->need_motion() == Scene::MOTION_NONE)
return;
/* get camera object here to deal with camera switch */
BL::Object b_cam = b_scene.camera();
if (b_override)
b_cam = b_override;
int frame_center = b_scene.frame_current();
float subframe_center = b_scene.frame_subframe();
float frame_center_delta = 0.0f;
if (scene->need_motion() != Scene::MOTION_PASS &&
scene->camera->get_motion_position() != Camera::MOTION_POSITION_CENTER) {
float shuttertime = scene->camera->get_shuttertime();
if (scene->camera->get_motion_position() == Camera::MOTION_POSITION_END) {
frame_center_delta = -shuttertime * 0.5f;
}
else {
assert(scene->camera->get_motion_position() == Camera::MOTION_POSITION_START);
frame_center_delta = shuttertime * 0.5f;
}
float time = frame_center + subframe_center + frame_center_delta;
int frame = (int)floorf(time);
float subframe = time - frame;
python_thread_state_restore(python_thread_state);
b_engine.frame_set(frame, subframe);
python_thread_state_save(python_thread_state);
if (b_cam) {
sync_camera_motion(b_render, b_cam, width, height, 0.0f);
}
sync_objects(b_depsgraph, b_v3d);
}
/* Insert motion times from camera. Motion times from other objects
* have already been added in a sync_objects call. */
if (b_cam) {
uint camera_motion_steps = object_motion_steps(b_cam, b_cam);
for (size_t step = 0; step < camera_motion_steps; step++) {
motion_times.insert(scene->camera->motion_time(step));
}
}
/* Check which geometry already has motion blur so it can be skipped. */
geometry_motion_attribute_synced.clear();
for (Geometry *geom : scene->geometry) {
if (geom->attributes.find(ATTR_STD_MOTION_VERTEX_POSITION)) {
geometry_motion_attribute_synced.insert(geom);
}
}
/* note iteration over motion_times set happens in sorted order */
foreach (float relative_time, motion_times) {
/* center time is already handled. */
if (relative_time == 0.0f) {
continue;
}
VLOG(1) << "Synchronizing motion for the relative time " << relative_time << ".";
/* fixed shutter time to get previous and next frame for motion pass */
float shuttertime = scene->motion_shutter_time();
/* compute frame and subframe time */
float time = frame_center + subframe_center + frame_center_delta +
relative_time * shuttertime * 0.5f;
int frame = (int)floorf(time);
float subframe = time - frame;
/* change frame */
python_thread_state_restore(python_thread_state);
b_engine.frame_set(frame, subframe);
python_thread_state_save(python_thread_state);
/* Syncs camera motion if relative_time is one of the camera's motion times. */
sync_camera_motion(b_render, b_cam, width, height, relative_time);
/* sync object */
sync_objects(b_depsgraph, b_v3d, relative_time);
}
geometry_motion_attribute_synced.clear();
/* we need to set the python thread state again because this
* function assumes it is being executed from python and will
* try to save the thread state */
python_thread_state_restore(python_thread_state);
b_engine.frame_set(frame_center, subframe_center);
python_thread_state_save(python_thread_state);
}
CCL_NAMESPACE_END