2023-06-14 16:52:36 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0 */
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2024-12-26 17:53:56 +01:00
|
|
|
#pragma once
|
2011-04-27 11:58:34 +00:00
|
|
|
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
|
|
|
#include "graph/node.h"
|
2020-11-04 11:17:38 +01:00
|
|
|
|
|
|
|
|
/* included as Object::set_particle_system defined through NODE_SOCKET_API does
|
|
|
|
|
* not select the right Node::set overload as it does not know that ParticleSystem
|
|
|
|
|
* is a Node */
|
2022-12-13 16:29:23 +01:00
|
|
|
#include "scene/geometry.h"
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/particles.h"
|
|
|
|
|
#include "scene/scene.h"
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "util/array.h"
|
|
|
|
|
#include "util/boundbox.h"
|
|
|
|
|
#include "util/param.h"
|
|
|
|
|
#include "util/transform.h"
|
|
|
|
|
#include "util/types.h"
|
|
|
|
|
#include "util/vector.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
|
|
|
|
class Device;
|
|
|
|
|
class DeviceScene;
|
2020-02-02 12:04:19 +01:00
|
|
|
class Geometry;
|
2014-02-25 18:29:11 +01:00
|
|
|
class ParticleSystem;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Progress;
|
|
|
|
|
class Scene;
|
2011-05-03 18:29:11 +00:00
|
|
|
struct Transform;
|
2018-03-10 01:15:02 +01:00
|
|
|
struct UpdateObjectTransformState;
|
2018-11-29 02:06:30 +01:00
|
|
|
class ObjectManager;
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
|
/* Object */
|
|
|
|
|
|
2016-05-07 21:44:17 +02:00
|
|
|
class Object : public Node {
|
2011-04-27 11:58:34 +00:00
|
|
|
public:
|
2017-03-06 14:16:45 +01:00
|
|
|
NODE_DECLARE
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-04 11:17:38 +01:00
|
|
|
NODE_SOCKET_API(Geometry *, geometry)
|
|
|
|
|
NODE_SOCKET_API(Transform, tfm)
|
2011-04-27 11:58:34 +00:00
|
|
|
BoundBox bounds;
|
2020-11-04 11:17:38 +01:00
|
|
|
NODE_SOCKET_API(uint, random_id)
|
|
|
|
|
NODE_SOCKET_API(int, pass_id)
|
|
|
|
|
NODE_SOCKET_API(float3, color)
|
2022-03-07 17:34:52 +01:00
|
|
|
NODE_SOCKET_API(float, alpha)
|
2020-11-04 11:17:38 +01:00
|
|
|
NODE_SOCKET_API(ustring, asset_name)
|
2011-04-27 11:58:34 +00:00
|
|
|
vector<ParamValue> attributes;
|
2020-11-04 11:17:38 +01:00
|
|
|
NODE_SOCKET_API(uint, visibility)
|
|
|
|
|
NODE_SOCKET_API_ARRAY(array<Transform>, motion)
|
|
|
|
|
NODE_SOCKET_API(bool, hide_on_missing_motion)
|
|
|
|
|
NODE_SOCKET_API(bool, use_holdout)
|
|
|
|
|
NODE_SOCKET_API(bool, is_shadow_catcher)
|
2021-06-28 13:54:18 +02:00
|
|
|
NODE_SOCKET_API(float, shadow_terminator_shading_offset)
|
|
|
|
|
NODE_SOCKET_API(float, shadow_terminator_geometry_offset)
|
2020-11-04 11:17:38 +01:00
|
|
|
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
NODE_SOCKET_API(bool, is_caustics_caster)
|
|
|
|
|
NODE_SOCKET_API(bool, is_caustics_receiver)
|
|
|
|
|
|
2025-01-02 12:48:21 +01:00
|
|
|
NODE_SOCKET_API(bool, is_bake_target)
|
|
|
|
|
|
2020-11-04 11:17:38 +01:00
|
|
|
NODE_SOCKET_API(float3, dupli_generated)
|
|
|
|
|
NODE_SOCKET_API(float2, dupli_uv)
|
|
|
|
|
|
|
|
|
|
NODE_SOCKET_API(ParticleSystem *, particle_system);
|
|
|
|
|
NODE_SOCKET_API(int, particle_index);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-08-03 12:20:28 +02:00
|
|
|
NODE_SOCKET_API(float, ao_distance)
|
|
|
|
|
|
2022-04-02 00:11:11 +02:00
|
|
|
NODE_SOCKET_API(ustring, lightgroup)
|
2023-05-24 13:36:13 +02:00
|
|
|
NODE_SOCKET_API(uint, receiver_light_set)
|
|
|
|
|
NODE_SOCKET_API(uint64_t, light_set_membership)
|
|
|
|
|
NODE_SOCKET_API(uint, blocker_shadow_set)
|
|
|
|
|
NODE_SOCKET_API(uint64_t, shadow_set_membership)
|
2022-04-02 00:11:11 +02:00
|
|
|
|
2021-10-22 14:20:22 +02:00
|
|
|
/* Set during device update. */
|
|
|
|
|
bool intersects_volume;
|
|
|
|
|
|
2025-02-24 23:44:14 +01:00
|
|
|
/* Specifies the position of the object in scene->objects and
|
|
|
|
|
* in the device vectors. Gets set in device_update. */
|
|
|
|
|
int index;
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
Object();
|
2024-12-26 17:53:59 +01:00
|
|
|
~Object() override;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
void tag_update(Scene *scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-03-29 13:03:46 +01:00
|
|
|
void compute_bounds(bool motion_blur);
|
2014-05-09 17:02:08 +02:00
|
|
|
void apply_transform(bool apply_to_motion);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-03-08 04:04:52 +01:00
|
|
|
/* Convert between normalized -1..1 motion time and index
|
|
|
|
|
* in the motion array. */
|
|
|
|
|
bool use_motion() const;
|
2025-01-01 18:15:54 +01:00
|
|
|
float motion_time(const int step) const;
|
|
|
|
|
int motion_step(const float time) const;
|
2018-03-08 04:04:52 +01:00
|
|
|
void update_motion();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-02-18 14:02:40 +01:00
|
|
|
/* Maximum number of motion steps supported (due to Embree). */
|
|
|
|
|
static const uint MAX_MOTION_STEPS = 129;
|
|
|
|
|
|
2016-06-06 09:15:34 +02:00
|
|
|
/* Check whether object is traceable and it worth adding it to
|
|
|
|
|
* kernel scene.
|
|
|
|
|
*/
|
2018-03-10 00:37:07 +01:00
|
|
|
bool is_traceable() const;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-08-10 09:19:40 +02:00
|
|
|
/* Combine object's visibility with all possible internal run-time
|
|
|
|
|
* determined flags which denotes trace-time visibility.
|
|
|
|
|
*/
|
|
|
|
|
uint visibility_for_tracing() const;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-29 02:06:30 +01:00
|
|
|
/* Returns the index that is used in the kernel for this object. */
|
|
|
|
|
int get_device_index() const;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-03-07 14:38:52 +01:00
|
|
|
/* Compute step size from attributes, shaders, transforms. */
|
|
|
|
|
float compute_volume_step_size() const;
|
|
|
|
|
|
2023-04-03 10:54:17 +02:00
|
|
|
/* Check whether this object can be used as light-emissive. */
|
|
|
|
|
bool usable_as_light() const;
|
|
|
|
|
|
2023-05-26 12:21:44 +02:00
|
|
|
/* Check whether the object participates in light or shadow linking, either as a receiver/blocker
|
|
|
|
|
* or emitter. */
|
|
|
|
|
bool has_light_linking() const;
|
|
|
|
|
bool has_shadow_linking() const;
|
|
|
|
|
|
2018-11-29 02:06:30 +01:00
|
|
|
protected:
|
2020-10-26 15:37:07 +01:00
|
|
|
/* Reference to the attribute map with object attributes,
|
|
|
|
|
* or 0 if none. Set in update_svm_attributes. */
|
|
|
|
|
size_t attr_map_offset;
|
|
|
|
|
|
2018-11-29 02:06:30 +01:00
|
|
|
friend class ObjectManager;
|
2020-10-26 15:37:07 +01:00
|
|
|
friend class GeometryManager;
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Object Manager */
|
|
|
|
|
|
|
|
|
|
class ObjectManager {
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
uint32_t update_flags;
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
public:
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
enum : uint32_t {
|
|
|
|
|
PARTICLE_MODIFIED = (1 << 0),
|
|
|
|
|
GEOMETRY_MANAGER = (1 << 1),
|
|
|
|
|
MOTION_BLUR_MODIFIED = (1 << 2),
|
|
|
|
|
OBJECT_ADDED = (1 << 3),
|
|
|
|
|
OBJECT_REMOVED = (1 << 4),
|
|
|
|
|
OBJECT_MODIFIED = (1 << 5),
|
|
|
|
|
HOLDOUT_MODIFIED = (1 << 6),
|
2021-03-24 10:36:31 +01:00
|
|
|
TRANSFORM_MODIFIED = (1 << 7),
|
2021-05-10 18:23:32 +02:00
|
|
|
VISIBILITY_MODIFIED = (1 << 8),
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
|
|
|
|
|
/* tag everything in the manager for an update */
|
|
|
|
|
UPDATE_ALL = ~0u,
|
|
|
|
|
|
|
|
|
|
UPDATE_NONE = 0u,
|
|
|
|
|
};
|
|
|
|
|
|
2015-01-19 19:08:58 +05:00
|
|
|
bool need_flags_update;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
ObjectManager();
|
|
|
|
|
~ObjectManager();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
void device_update(Device *device, DeviceScene *dscene, Scene *scene, Progress &progress);
|
2018-01-15 11:45:16 +01:00
|
|
|
void device_update_transforms(DeviceScene *dscene, Scene *scene, Progress &progress);
|
2021-11-29 15:06:22 +00:00
|
|
|
void device_update_prim_offsets(Device *device, DeviceScene *dscene, Scene *scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-06-01 23:59:23 +05:00
|
|
|
void device_update_flags(Device *device,
|
|
|
|
|
DeviceScene *dscene,
|
|
|
|
|
Scene *scene,
|
|
|
|
|
Progress &progress,
|
|
|
|
|
bool bounds_valid = true);
|
2022-01-05 16:01:59 +01:00
|
|
|
void device_update_geom_offsets(Device *device, DeviceScene *dscene, Scene *scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
void device_free(Device *device, DeviceScene *dscene, bool force_free);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-01-01 18:15:54 +01:00
|
|
|
void tag_update(Scene *scene, const uint32_t flag);
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
|
|
|
|
|
bool need_update() const;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-03-10 01:15:02 +01:00
|
|
|
void apply_static_transforms(DeviceScene *dscene, Scene *scene, Progress &progress);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-07 04:05:47 +01:00
|
|
|
string get_cryptomatte_objects(Scene *scene);
|
|
|
|
|
string get_cryptomatte_assets(Scene *scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-04-20 18:12:26 +02:00
|
|
|
protected:
|
Cycles: optimize device updates
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
|
|
|
void device_update_object_transform(UpdateObjectTransformState *state,
|
|
|
|
|
Object *ob,
|
2022-04-02 00:11:11 +02:00
|
|
|
bool update_all,
|
|
|
|
|
const Scene *scene);
|
2018-02-05 11:01:00 +02:00
|
|
|
void device_update_object_transform_task(UpdateObjectTransformState *state);
|
2016-04-20 18:12:26 +02:00
|
|
|
bool device_update_object_transform_pop_work(UpdateObjectTransformState *state,
|
|
|
|
|
int *start_index,
|
|
|
|
|
int *num_objects);
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
CCL_NAMESPACE_END
|