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

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

774 lines
24 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
*
* SPDX-License-Identifier: Apache-2.0 */
#include "blender/light_linking.h"
#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/hash.h"
#include "util/log.h"
#include "util/task.h"
2024-02-14 10:51:40 -05:00
#include "BKE_duplilist.hh"
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;
}
if (ccl::BKE_object_is_modified(b_ob, b_scene, preview)) {
/* modifiers */
return true;
}
/* 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_CURVES ||
type == BL::Object::type_POINTCLOUD)
{
/* Will be exported attached to mesh. */
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_CURVES:
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));
}
Attribute Node: support accessing attributes of View Layer and Scene. The attribute node already allows accessing attributes associated with objects and meshes, which allows changing the behavior of the same material between different objects or instances. The same idea can be extended to an even more global level of layers and scenes. Currently view layers provide an option to replace all materials with a different one. However, since the same material will be applied to all objects in the layer, varying the behavior between layers while preserving distinct materials requires duplicating objects. Providing access to properties of layers and scenes via the attribute node enables making materials with built-in switches or settings that can be controlled globally at the view layer level. This is probably most useful for complex NPR shading and compositing. Like with objects, the node can also access built-in scene properties, like render resolution or FOV of the active camera. Lookup is also attempted in World, similar to how the Object mode checks the Mesh datablock. In Cycles this mode is implemented by replacing the attribute node with the attribute value during sync, allowing constant folding to take the values into account. This means however that materials that use this feature have to be re-synced upon any changes to scene, world or camera. The Eevee version uses a new uniform buffer containing a sorted array mapping name hashes to values, with binary search lookup. The array is limited to 512 entries, which is effectively limitless even considering it is shared by all materials in the scene; it is also just 16KB of memory so no point trying to optimize further. The buffer has to be rebuilt when new attributes are detected in a material, so the draw engine keeps a table of recently seen attribute names to minimize the chance of extra rebuilds mid-draw. Differential Revision: https://developer.blender.org/D15941
2022-09-12 00:30:58 +03:00
bool BlenderSync::object_is_camera(BL::Object &b_ob)
{
BL::ID b_ob_data = b_ob.data();
return (b_ob_data && b_ob_data.is_a(&RNA_Camera));
}
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);
if (!geom->has_motion_blur()) {
/* Only set motion steps if geometry doesn't already have
* motion blur from a velocity attribute. */
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 = nullptr;
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
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 nullptr;
}
/* 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 nullptr;
}
/* only interested in object that we can create geometry from */
if (!object_is_geometry(b_ob_info)) {
return nullptr;
}
/* Perform object culling. */
if (culling.test(scene, b_ob, tfm)) {
return nullptr;
}
/* 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 nullptr;
}
/* 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) ? nullptr : 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);
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 is_caustics_caster = get_boolean(cobject, "is_caustics_caster");
object->set_is_caustics_caster(is_caustics_caster);
bool is_caustics_receiver = get_boolean(cobject, "is_caustics_receiver");
object->set_is_caustics_receiver(is_caustics_receiver);
object->set_is_bake_target(b_ob_info.real_object == b_bake_target);
/* 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());
const BL::Array<float, 4> object_color = b_ob.color();
object->set_color(get_float3(object_color));
object->set_alpha(object_color[3]);
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));
}
/* Light group and linking. */
string lightgroup = b_ob.lightgroup();
if (lightgroup.empty()) {
lightgroup = b_parent.lightgroup();
}
object->set_lightgroup(ustring(lightgroup));
object->set_light_set_membership(BlenderLightLink::get_light_set_membership(b_parent, b_ob));
object->set_receiver_light_set(BlenderLightLink::get_receiver_light_set(b_parent, b_ob));
object->set_shadow_set_membership(BlenderLightLink::get_shadow_set_membership(b_parent, b_ob));
object->set_blocker_shadow_set(BlenderLightLink::get_blocker_shadow_set(b_parent, b_ob));
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;
}
extern "C" DupliObject *rna_hack_DepsgraphObjectInstance_dupli_object_get(PointerRNA *ptr);
static float4 lookup_instance_property(BL::DepsgraphObjectInstance &b_instance,
const string &name,
bool use_instancer)
{
::Object *ob = (::Object *)b_instance.object().ptr.data;
::DupliObject *dupli = nullptr;
::Object *dupli_parent = nullptr;
/* If requesting instance data, check the parent particle system and object. */
if (use_instancer && b_instance.is_instance()) {
dupli = rna_hack_DepsgraphObjectInstance_dupli_object_get(&b_instance.ptr);
dupli_parent = (::Object *)b_instance.parent().ptr.data;
}
float4 value;
BKE_object_dupli_find_rgba_attribute(ob, dupli, dupli_parent, name.c_str(), &value.x);
return value;
}
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. */
for (AttributeRequest &req : requests.requests) {
ustring name = req.name;
std::string real_name;
BlenderAttributeType type = blender_attribute_name_split_type(name, &real_name);
Attribute Node: support accessing attributes of View Layer and Scene. The attribute node already allows accessing attributes associated with objects and meshes, which allows changing the behavior of the same material between different objects or instances. The same idea can be extended to an even more global level of layers and scenes. Currently view layers provide an option to replace all materials with a different one. However, since the same material will be applied to all objects in the layer, varying the behavior between layers while preserving distinct materials requires duplicating objects. Providing access to properties of layers and scenes via the attribute node enables making materials with built-in switches or settings that can be controlled globally at the view layer level. This is probably most useful for complex NPR shading and compositing. Like with objects, the node can also access built-in scene properties, like render resolution or FOV of the active camera. Lookup is also attempted in World, similar to how the Object mode checks the Mesh datablock. In Cycles this mode is implemented by replacing the attribute node with the attribute value during sync, allowing constant folding to take the values into account. This means however that materials that use this feature have to be re-synced upon any changes to scene, world or camera. The Eevee version uses a new uniform buffer containing a sorted array mapping name hashes to values, with binary search lookup. The array is limited to 512 entries, which is effectively limitless even considering it is shared by all materials in the scene; it is also just 16KB of memory so no point trying to optimize further. The buffer has to be rebuilt when new attributes are detected in a material, so the draw engine keeps a table of recently seen attribute names to minimize the chance of extra rebuilds mid-draw. Differential Revision: https://developer.blender.org/D15941
2022-09-12 00:30:58 +03:00
if (type == BL::ShaderNodeAttribute::attribute_type_OBJECT ||
type == BL::ShaderNodeAttribute::attribute_type_INSTANCER)
{
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 = nullptr;
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, 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. */
if (experimental) {
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 ? nullptr : &geom_task_pool);
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
}
}
/* 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() != MOTION_POSITION_CENTER)
{
float shuttertime = scene->camera->get_shuttertime();
if (scene->camera->get_motion_position() == MOTION_POSITION_END) {
frame_center_delta = -shuttertime * 0.5f;
}
else {
assert(scene->camera->get_motion_position() == 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 */
for (float relative_time : motion_times) {
/* center time is already handled. */
if (relative_time == 0.0f) {
continue;
}
VLOG_WORK << "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