2011-04-27 11:58:34 +00:00
|
|
|
/*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Copyright 2011-2013 Blender Foundation
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
2014-12-25 02:50:24 +01:00
|
|
|
* limitations under the License.
|
2011-04-27 11:58:34 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __SCENE_H__
|
|
|
|
|
#define __SCENE_H__
|
|
|
|
|
|
2018-01-19 10:59:58 +01:00
|
|
|
#include "bvh/bvh_params.h"
|
|
|
|
|
|
2020-08-18 12:15:46 +02:00
|
|
|
#include "render/film.h"
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
|
|
|
#include "render/image.h"
|
|
|
|
|
#include "render/shader.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
2020-08-18 10:46:12 +02:00
|
|
|
#include "device/device.h"
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
|
|
|
#include "device/device_memory.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 20:39:14 +02:00
|
|
|
#include "util/util_param.h"
|
|
|
|
|
#include "util/util_string.h"
|
|
|
|
|
#include "util/util_system.h"
|
|
|
|
|
#include "util/util_texture.h"
|
|
|
|
|
#include "util/util_thread.h"
|
|
|
|
|
#include "util/util_types.h"
|
|
|
|
|
#include "util/util_vector.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
2021-01-25 15:12:00 +01:00
|
|
|
class AlembicProcedural;
|
2012-04-30 12:49:26 +00:00
|
|
|
class AttributeRequestSet;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Background;
|
2020-12-10 14:18:25 +01:00
|
|
|
class BVH;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Camera;
|
|
|
|
|
class Device;
|
2012-09-04 13:29:07 +00:00
|
|
|
class DeviceInfo;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Film;
|
|
|
|
|
class Integrator;
|
|
|
|
|
class Light;
|
|
|
|
|
class LightManager;
|
2013-04-01 20:26:43 +00:00
|
|
|
class LookupTables;
|
2020-02-02 12:04:19 +01:00
|
|
|
class Geometry;
|
|
|
|
|
class GeometryManager;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Object;
|
|
|
|
|
class ObjectManager;
|
2012-08-31 17:27:08 +00:00
|
|
|
class ParticleSystemManager;
|
|
|
|
|
class ParticleSystem;
|
2021-01-25 14:56:57 +01:00
|
|
|
class Procedural;
|
|
|
|
|
class ProceduralManager;
|
2012-12-28 14:21:30 +00:00
|
|
|
class CurveSystemManager;
|
2011-04-27 11:58:34 +00:00
|
|
|
class Shader;
|
|
|
|
|
class ShaderManager;
|
|
|
|
|
class Progress;
|
2014-01-02 19:05:07 -02:00
|
|
|
class BakeManager;
|
|
|
|
|
class BakeData;
|
2018-07-27 15:46:13 +02:00
|
|
|
class RenderStats;
|
2020-10-01 23:16:01 +02:00
|
|
|
class SceneUpdateStats;
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
class Volume;
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
|
/* Scene Device Data */
|
|
|
|
|
|
|
|
|
|
class DeviceScene {
|
|
|
|
|
public:
|
|
|
|
|
/* BVH */
|
2017-10-20 04:32:29 +02:00
|
|
|
device_vector<int4> bvh_nodes;
|
|
|
|
|
device_vector<int4> bvh_leaf_nodes;
|
|
|
|
|
device_vector<int> object_node;
|
Cycles: Reduce memory usage by de-duplicating triangle storage
There are several internal changes for this:
First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_normal().
In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.
Additionally, the order of vertices in that array is aligned with
primitives from BVH. This is needed to keep cache as much coherent as
possible for BVH traversal. This causes some extra tricks needed to
fill the array in and deal with True Displacement but those trickery
is fully required to prevent noticeable slowdown.
Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Mainly this loss is caused by extra lookup
happening to access vertex coordinate.
Fortunately, tricks here and there (i,e, some types changes to avoid
casts which are not really coming for free) reduces those losses to
an acceptable level. So now they are within couple of percent only,
On a positive site we've achieved:
- Few percent of memory save with triangle-only scenes. Actual save
in this case is close to size of all vertices.
On a more fine-subdivided scenes this benefit might become more
obvious.
- Huge memory save of hairy scenes. For example, on koro.blend
there is about 20% memory save. Similar figure for bunny.blend.
This memory save was the main goal of this commit to move forward
with Hair BVH which required more memory per BVH node. So while
this sounds exciting, this memory optimization will become invisible
by upcoming Hair BVH work.
But again on a positive side, we can add an option to NOT use Hair
BVH and then we'll have same-ish render times as we've got currently
but will have this 20% memory benefit on hairy scenes.
2016-06-10 16:13:50 +02:00
|
|
|
device_vector<uint> prim_tri_index;
|
|
|
|
|
device_vector<float4> prim_tri_verts;
|
2017-10-20 04:32:29 +02:00
|
|
|
device_vector<int> prim_type;
|
2011-09-01 15:53:36 +00:00
|
|
|
device_vector<uint> prim_visibility;
|
2017-10-20 04:32:29 +02:00
|
|
|
device_vector<int> prim_index;
|
|
|
|
|
device_vector<int> prim_object;
|
2017-02-15 10:56:54 +01:00
|
|
|
device_vector<float2> prim_time;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* mesh */
|
2014-09-24 13:34:28 +02:00
|
|
|
device_vector<uint> tri_shader;
|
2011-04-27 11:58:34 +00:00
|
|
|
device_vector<float4> tri_vnormal;
|
Cycles: Reduce memory usage by de-duplicating triangle storage
There are several internal changes for this:
First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_normal().
In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.
Additionally, the order of vertices in that array is aligned with
primitives from BVH. This is needed to keep cache as much coherent as
possible for BVH traversal. This causes some extra tricks needed to
fill the array in and deal with True Displacement but those trickery
is fully required to prevent noticeable slowdown.
Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Mainly this loss is caused by extra lookup
happening to access vertex coordinate.
Fortunately, tricks here and there (i,e, some types changes to avoid
casts which are not really coming for free) reduces those losses to
an acceptable level. So now they are within couple of percent only,
On a positive site we've achieved:
- Few percent of memory save with triangle-only scenes. Actual save
in this case is close to size of all vertices.
On a more fine-subdivided scenes this benefit might become more
obvious.
- Huge memory save of hairy scenes. For example, on koro.blend
there is about 20% memory save. Similar figure for bunny.blend.
This memory save was the main goal of this commit to move forward
with Hair BVH which required more memory per BVH node. So while
this sounds exciting, this memory optimization will become invisible
by upcoming Hair BVH work.
But again on a positive side, we can add an option to NOT use Hair
BVH and then we'll have same-ish render times as we've got currently
but will have this 20% memory benefit on hairy scenes.
2016-06-10 16:13:50 +02:00
|
|
|
device_vector<uint4> tri_vindex;
|
2016-07-16 19:42:28 -04:00
|
|
|
device_vector<uint> tri_patch;
|
|
|
|
|
device_vector<float2> tri_patch_uv;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-03 12:09:09 +00:00
|
|
|
device_vector<float4> curves;
|
2013-01-03 12:08:54 +00:00
|
|
|
device_vector<float4> curve_keys;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-16 19:42:28 -04:00
|
|
|
device_vector<uint> patches;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* objects */
|
2018-03-07 22:19:56 +01:00
|
|
|
device_vector<KernelObject> objects;
|
2018-03-10 00:37:07 +01:00
|
|
|
device_vector<Transform> object_motion_pass;
|
2018-03-08 04:04:52 +01:00
|
|
|
device_vector<DecomposedTransform> object_motion;
|
2018-03-10 00:37:07 +01:00
|
|
|
device_vector<uint> object_flag;
|
2020-03-07 14:38:52 +01:00
|
|
|
device_vector<float> object_volume_step;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-03-10 01:36:09 +01:00
|
|
|
/* cameras */
|
|
|
|
|
device_vector<DecomposedTransform> camera_motion;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* attributes */
|
|
|
|
|
device_vector<uint4> attributes_map;
|
|
|
|
|
device_vector<float> attributes_float;
|
2019-03-05 14:54:54 +01:00
|
|
|
device_vector<float2> attributes_float2;
|
2011-04-27 11:58:34 +00:00
|
|
|
device_vector<float4> attributes_float3;
|
2014-06-13 23:40:39 +02:00
|
|
|
device_vector<uchar4> attributes_uchar4;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* lights */
|
2018-03-08 00:15:41 +01:00
|
|
|
device_vector<KernelLightDistribution> light_distribution;
|
|
|
|
|
device_vector<KernelLight> lights;
|
2012-01-20 17:49:17 +00:00
|
|
|
device_vector<float2> light_background_marginal_cdf;
|
|
|
|
|
device_vector<float2> light_background_conditional_cdf;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-08 16:17:57 +00:00
|
|
|
/* particles */
|
2018-03-08 00:35:24 +01:00
|
|
|
device_vector<KernelParticle> particles;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* shaders */
|
2017-10-20 04:32:29 +02:00
|
|
|
device_vector<int4> svm_nodes;
|
2018-03-08 00:35:24 +01:00
|
|
|
device_vector<KernelShader> shaders;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-04-01 20:26:43 +00:00
|
|
|
/* lookup tables */
|
|
|
|
|
device_vector<float> lookup_table;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* integrator */
|
2020-03-02 15:12:44 +01:00
|
|
|
device_vector<uint> sample_pattern_lut;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Cycles: Add Support for IES files as textures for light strength
This patch adds support for IES files, a file format that is commonly used to store the directional intensity distribution of light sources.
The new IES node is supposed to be plugged into the Strength input of the Emission node of the lamp.
Since people generating IES files do not really seem to care about the standard, the parser is flexible enough to accept all test files I have tried.
Some common weirdnesses are distributing values over multiple lines that should go into one line, using commas instead of spaces as delimiters and adding various useless stuff at the end of the file.
The user interface of the node is similar to the script node, the user can either select an internal Text or load a file.
Internally, IES files are handled similar to Image textures: They are stored in slots by the LightManager and each unique IES is assigned to one slot.
The local coordinate system of the lamp is used, so that the direction of the light can be changed. For UI reasons, it's usually best to add an area light,
rotate it and then change its type, since especially the point light does not immediately show its local coordinate system in the viewport.
Reviewers: #cycles, dingto, sergey, brecht
Reviewed By: #cycles, dingto, brecht
Subscribers: OgDEV, crazyrobinhood, secundar, cardboard, pisuke, intrah, swerner, micah_denn, harvester, gottfried, disnel, campbellbarton, duarteframos, Lapineige, brecht, juicyfruit, dingto, marek, rickyblender, bliblubli, lockal, sergey
Differential Revision: https://developer.blender.org/D1543
2018-05-27 00:46:37 +02:00
|
|
|
/* ies lights */
|
|
|
|
|
device_vector<float> ies_lights;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
KernelData data;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 23:31:13 +02:00
|
|
|
DeviceScene(Device *device);
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Scene Parameters */
|
|
|
|
|
|
|
|
|
|
class SceneParams {
|
|
|
|
|
public:
|
2018-01-19 10:59:58 +01:00
|
|
|
/* Type of BVH, in terms whether it is supported dynamic updates of meshes
|
|
|
|
|
* or whether modifying geometry requires full BVH rebuild.
|
|
|
|
|
*/
|
2016-02-10 15:09:45 +01:00
|
|
|
enum BVHType {
|
2018-01-19 10:59:58 +01:00
|
|
|
/* BVH supports dynamic updates of geometry.
|
|
|
|
|
*
|
|
|
|
|
* Faster for updating BVH tree when doing modifications in viewport,
|
|
|
|
|
* but slower for rendering.
|
|
|
|
|
*/
|
2016-02-10 15:09:45 +01:00
|
|
|
BVH_DYNAMIC = 0,
|
2018-01-19 10:59:58 +01:00
|
|
|
/* BVH tree is calculated for specific scene, updates in geometry
|
|
|
|
|
* requires full tree rebuild.
|
|
|
|
|
*
|
|
|
|
|
* Slower to update BVH tree when modifying objects in viewport, also
|
|
|
|
|
* slower to build final BVH tree but gives best possible render speed.
|
|
|
|
|
*/
|
2016-02-10 15:09:45 +01:00
|
|
|
BVH_STATIC = 1,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-02-10 15:09:45 +01:00
|
|
|
BVH_NUM_TYPES,
|
2018-01-19 10:59:58 +01:00
|
|
|
};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-01-19 10:59:58 +01:00
|
|
|
ShadingSystem shadingsystem;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-01-19 10:59:58 +01:00
|
|
|
/* Requested BVH layout.
|
|
|
|
|
*
|
|
|
|
|
* If it's not supported by the device, the widest one from supported ones
|
|
|
|
|
* will be used, but BVH wider than this one will never be used.
|
|
|
|
|
*/
|
|
|
|
|
BVHLayout bvh_layout;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-01-19 10:59:58 +01:00
|
|
|
BVHType bvh_type;
|
2011-04-27 11:58:34 +00:00
|
|
|
bool use_bvh_spatial_split;
|
2016-07-07 18:04:16 +02:00
|
|
|
bool use_bvh_unaligned_nodes;
|
2017-01-17 15:13:01 +01:00
|
|
|
int num_bvh_time_steps;
|
2020-06-10 19:07:07 +02:00
|
|
|
int hair_subdivisions;
|
|
|
|
|
CurveShapeType hair_shape;
|
2016-11-17 12:13:22 +01:00
|
|
|
int texture_limit;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Add support for tiled images and the UDIM naming scheme
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
2019-12-12 16:06:08 +01:00
|
|
|
bool background;
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
SceneParams()
|
|
|
|
|
{
|
2014-05-19 13:49:36 +03:00
|
|
|
shadingsystem = SHADINGSYSTEM_SVM;
|
2018-01-19 10:59:58 +01:00
|
|
|
bvh_layout = BVH_LAYOUT_BVH2;
|
2011-04-27 11:58:34 +00:00
|
|
|
bvh_type = BVH_DYNAMIC;
|
|
|
|
|
use_bvh_spatial_split = false;
|
2016-07-07 18:04:16 +02:00
|
|
|
use_bvh_unaligned_nodes = true;
|
2017-01-17 15:13:01 +01:00
|
|
|
num_bvh_time_steps = 0;
|
2020-06-10 19:07:07 +02:00
|
|
|
hair_subdivisions = 3;
|
|
|
|
|
hair_shape = CURVE_RIBBON;
|
2016-11-17 12:13:22 +01:00
|
|
|
texture_limit = 0;
|
Add support for tiled images and the UDIM naming scheme
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
2019-12-12 16:06:08 +01:00
|
|
|
background = true;
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
bool modified(const SceneParams ¶ms)
|
|
|
|
|
{
|
|
|
|
|
return !(shadingsystem == params.shadingsystem && bvh_layout == params.bvh_layout &&
|
|
|
|
|
bvh_type == params.bvh_type &&
|
|
|
|
|
use_bvh_spatial_split == params.use_bvh_spatial_split &&
|
2016-07-07 18:04:16 +02:00
|
|
|
use_bvh_unaligned_nodes == params.use_bvh_unaligned_nodes &&
|
2017-01-17 15:13:01 +01:00
|
|
|
num_bvh_time_steps == params.num_bvh_time_steps &&
|
2020-06-10 19:07:07 +02:00
|
|
|
hair_subdivisions == params.hair_subdivisions && hair_shape == params.hair_shape &&
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
texture_limit == params.texture_limit);
|
2016-11-17 12:13:22 +01:00
|
|
|
}
|
2020-06-10 19:07:07 +02:00
|
|
|
|
|
|
|
|
int curve_subdivisions()
|
|
|
|
|
{
|
|
|
|
|
/* Matching the tesselation rate limit in Embree. */
|
|
|
|
|
return clamp(1 << hair_subdivisions, 1, 16);
|
|
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Scene */
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
class Scene : public NodeOwner {
|
2011-04-27 11:58:34 +00:00
|
|
|
public:
|
2018-11-09 16:04:53 +01:00
|
|
|
/* Optional name. Is used for logging and reporting. */
|
|
|
|
|
string name;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* data */
|
2020-12-10 14:18:25 +01:00
|
|
|
BVH *bvh;
|
2011-04-27 11:58:34 +00:00
|
|
|
Camera *camera;
|
2018-01-12 00:50:34 +01:00
|
|
|
Camera *dicing_camera;
|
2013-04-01 20:26:43 +00:00
|
|
|
LookupTables *lookup_tables;
|
2011-04-27 11:58:34 +00:00
|
|
|
Film *film;
|
|
|
|
|
Background *background;
|
|
|
|
|
Integrator *integrator;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* data lists */
|
|
|
|
|
vector<Object *> objects;
|
2020-02-02 12:04:19 +01:00
|
|
|
vector<Geometry *> geometry;
|
2011-04-27 11:58:34 +00:00
|
|
|
vector<Shader *> shaders;
|
|
|
|
|
vector<Light *> lights;
|
2012-08-31 17:27:08 +00:00
|
|
|
vector<ParticleSystem *> particle_systems;
|
2020-08-18 12:15:46 +02:00
|
|
|
vector<Pass> passes;
|
2021-01-25 14:56:57 +01:00
|
|
|
vector<Procedural *> procedurals;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* data managers */
|
|
|
|
|
ImageManager *image_manager;
|
|
|
|
|
LightManager *light_manager;
|
|
|
|
|
ShaderManager *shader_manager;
|
2020-02-02 12:04:19 +01:00
|
|
|
GeometryManager *geometry_manager;
|
2011-04-27 11:58:34 +00:00
|
|
|
ObjectManager *object_manager;
|
2012-08-31 17:27:08 +00:00
|
|
|
ParticleSystemManager *particle_system_manager;
|
2014-01-02 19:05:07 -02:00
|
|
|
BakeManager *bake_manager;
|
2021-01-25 14:56:57 +01:00
|
|
|
ProceduralManager *procedural_manager;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* default shaders */
|
2016-05-14 14:50:03 +02:00
|
|
|
Shader *default_surface;
|
2020-03-11 17:49:00 +01:00
|
|
|
Shader *default_volume;
|
2016-05-14 14:50:03 +02:00
|
|
|
Shader *default_light;
|
|
|
|
|
Shader *default_background;
|
|
|
|
|
Shader *default_empty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* device */
|
|
|
|
|
Device *device;
|
|
|
|
|
DeviceScene dscene;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* parameters */
|
|
|
|
|
SceneParams params;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
/* mutex must be locked manually by callers */
|
|
|
|
|
thread_mutex mutex;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-10-01 23:16:01 +02:00
|
|
|
/* scene update statistics */
|
|
|
|
|
SceneUpdateStats *update_stats;
|
|
|
|
|
|
2017-10-20 05:08:26 +02:00
|
|
|
Scene(const SceneParams ¶ms, Device *device);
|
2011-04-27 11:58:34 +00:00
|
|
|
~Scene();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
void device_update(Device *device, Progress &progress);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-30 12:49:26 +00:00
|
|
|
bool need_global_attribute(AttributeStandard std);
|
|
|
|
|
void need_global_attributes(AttributeRequestSet &attributes);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-30 12:49:26 +00:00
|
|
|
enum MotionType { MOTION_NONE = 0, MOTION_PASS, MOTION_BLUR };
|
2018-01-12 19:56:52 +01:00
|
|
|
MotionType need_motion();
|
2016-07-16 18:56:59 +02:00
|
|
|
float motion_shutter_time();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
bool need_update();
|
|
|
|
|
bool need_reset();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
void reset();
|
|
|
|
|
void device_free();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-07-27 15:46:13 +02:00
|
|
|
void collect_statistics(RenderStats *stats);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-10-01 23:16:01 +02:00
|
|
|
void enable_update_stats();
|
|
|
|
|
|
2020-08-18 10:46:12 +02:00
|
|
|
bool update(Progress &progress, bool &kernel_switch_needed);
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
/* This function is used to create a node of a specified type instead of
|
|
|
|
|
* calling 'new', and sets the scene as the owner of the node.
|
|
|
|
|
* The function has overloads that will also add the created node to the right
|
|
|
|
|
* node array (e.g. Scene::geometry for Geometry nodes) and tag the appropriate
|
|
|
|
|
* manager for an update.
|
|
|
|
|
*/
|
2021-04-11 14:37:37 +10:00
|
|
|
template<typename T, typename... Args> T *create_node(Args &&... args)
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
{
|
|
|
|
|
T *node = new T(args...);
|
|
|
|
|
node->set_owner(this);
|
|
|
|
|
return node;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This function is used to delete a node from the scene instead of calling 'delete'
|
|
|
|
|
* and manually removing the node from the data array. It also tags the
|
|
|
|
|
* appropriate manager for an update, if any, and checks that the scene is indeed
|
|
|
|
|
* the owner of the node. Calling this function on a node not owned by the scene
|
|
|
|
|
* will likely cause a crash which we want in order to detect such cases.
|
|
|
|
|
*/
|
|
|
|
|
template<typename T> void delete_node(T *node)
|
|
|
|
|
{
|
|
|
|
|
assert(node->get_owner() == this);
|
|
|
|
|
delete_node_impl(node);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same as above, but specify the actual owner.
|
|
|
|
|
*/
|
|
|
|
|
template<typename T> void delete_node(T *node, const NodeOwner *owner)
|
|
|
|
|
{
|
|
|
|
|
assert(node->get_owner() == owner);
|
|
|
|
|
delete_node_impl(node);
|
|
|
|
|
(void)owner;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-29 14:40:29 +01:00
|
|
|
/* Remove all nodes in the set from the appropriate data arrays, and tag the
|
|
|
|
|
* specific managers for an update. This assumes that the scene owns the nodes.
|
|
|
|
|
*/
|
|
|
|
|
template<typename T> void delete_nodes(const set<T *> &nodes)
|
|
|
|
|
{
|
|
|
|
|
delete_nodes(nodes, this);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same as above, but specify the actual owner of all the nodes in the set.
|
|
|
|
|
*/
|
|
|
|
|
template<typename T> void delete_nodes(const set<T *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
protected:
|
2016-04-22 10:55:26 +02:00
|
|
|
/* Check if some heavy data worth logging was updated.
|
|
|
|
|
* Mainly used to suppress extra annoying logging.
|
|
|
|
|
*/
|
|
|
|
|
bool need_data_update();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
void free_memory(bool final);
|
2020-08-18 10:46:12 +02:00
|
|
|
|
|
|
|
|
bool kernels_loaded;
|
|
|
|
|
DeviceRequestedFeatures loaded_kernel_features;
|
|
|
|
|
|
|
|
|
|
bool load_kernels(Progress &progress, bool lock_scene = true);
|
|
|
|
|
|
|
|
|
|
/* ** Split kernel routines ** */
|
|
|
|
|
|
|
|
|
|
DeviceRequestedFeatures get_requested_device_features();
|
|
|
|
|
|
2021-02-05 16:23:34 +11:00
|
|
|
/* Maximum number of closure during session lifetime. */
|
2020-08-18 10:46:12 +02:00
|
|
|
int max_closure_global;
|
|
|
|
|
|
|
|
|
|
/* Get maximum number of closures to be used in kernel. */
|
|
|
|
|
int get_max_closure_count();
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
|
|
|
|
|
template<typename T> void delete_node_impl(T *node)
|
|
|
|
|
{
|
|
|
|
|
delete node;
|
|
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
template<> Light *Scene::create_node<Light>();
|
|
|
|
|
|
|
|
|
|
template<> Mesh *Scene::create_node<Mesh>();
|
|
|
|
|
|
|
|
|
|
template<> Object *Scene::create_node<Object>();
|
|
|
|
|
|
|
|
|
|
template<> Hair *Scene::create_node<Hair>();
|
|
|
|
|
|
|
|
|
|
template<> Volume *Scene::create_node<Volume>();
|
|
|
|
|
|
|
|
|
|
template<> ParticleSystem *Scene::create_node<ParticleSystem>();
|
|
|
|
|
|
|
|
|
|
template<> Shader *Scene::create_node<Shader>();
|
|
|
|
|
|
2021-01-25 15:12:00 +01:00
|
|
|
template<> AlembicProcedural *Scene::create_node<AlembicProcedural>();
|
|
|
|
|
|
Cycles: introduce an ownership system to protect nodes from unwanted deletions.
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
2020-08-30 23:20:51 +02:00
|
|
|
template<> void Scene::delete_node_impl(Light *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Mesh *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Volume *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Hair *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Geometry *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Object *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(ParticleSystem *node);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_node_impl(Shader *node);
|
|
|
|
|
|
2021-01-25 14:56:57 +01:00
|
|
|
template<> void Scene::delete_node_impl(Procedural *node);
|
|
|
|
|
|
2021-01-25 15:12:00 +01:00
|
|
|
template<> void Scene::delete_node_impl(AlembicProcedural *node);
|
|
|
|
|
|
2020-10-29 14:40:29 +01:00
|
|
|
template<> void Scene::delete_nodes(const set<Light *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<Geometry *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<Object *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<ParticleSystem *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
|
|
|
|
template<> void Scene::delete_nodes(const set<Shader *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
2021-01-25 14:56:57 +01:00
|
|
|
template<> void Scene::delete_nodes(const set<Procedural *> &nodes, const NodeOwner *owner);
|
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
CCL_NAMESPACE_END
|
|
|
|
|
|
|
|
|
|
#endif /* __SCENE_H__ */
|