kannonier8/blender
1
0
Fork 0
forked from bartvdbraak/blender
Code Pull Requests Activity
3f29259676
blender/intern/cycles/bvh/bvh.cpp

1223 lines
35 KiB
C++
Raw Normal View History

Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/*
* Adapted from code copyright 2009-2010 NVIDIA Corporation
* Modifications Copyright 2011, Blender Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include "mesh.h"
#include "object.h"
#include "scene.h"
Cycles Hair: Introduction of Cardinal Spline Curve Segments and minor fixes. The curve segment primitive has been added. This includes an intersection function and changes to the BVH. A few small errors in the line segment intersection routine are also fixed.
2013-01-15 19:44:41 +00:00
#include "curves.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#include "bvh.h"
#include "bvh_build.h"
#include "bvh_node.h"
#include "bvh_params.h"
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
#include "bvh_unaligned.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#include "util_debug.h"
#include "util_foreach.h"
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
#include "util_logging.h"
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
#include "util_map.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#include "util_progress.h"
Fix cycles issue with BVH cache created with 64 bits and used for 32 bits binary, and vice versa.
2013-02-13 11:02:51 +00:00
#include "util_system.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#include "util_types.h"
Cycles : * Use is_zero(a) rather than dot(a, a) == 0, saves some calculations.
2013-05-14 18:31:55 +00:00
#include "util_math.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
CCL_NAMESPACE_BEGIN
/* Pack Utility */
struct BVHStackEntry
{
const BVHNode *node;
int idx;
BVHStackEntry(const BVHNode* n = 0, int i = 0)
: node(n), idx(i)
{
}
int encodeIdx() const
{
return (node->is_leaf())? ~idx: idx;
}
};
/* BVH */
BVH::BVH(const BVHParams& params_, const vector<Object*>& objects_)
: params(params_), objects(objects_)
{
}
BVH *BVH::create(const BVHParams& params, const vector<Object*>& objects)
{
if(params.use_qbvh)
return new QBVH(params, objects);
else
return new RegularBVH(params, objects);
}
/* Building */
void BVH::build(Progress& progress)
{
progress.set_substatus("Building BVH");
/* build nodes */
Cycles: Avoid having duplication of BVH arrays during build Previous idea behind having vector during building and array for actual storage was needed in order to minimize amount of re-allocations happening during the build, but it lead to double memory overhead used by those arrays at the vector to array conversion stage. Issue with such approach was that for BVH without spatial split size of arrays is known in advance and it never changes, which made vector to array conversion totally redundant. Also after testing with several rather complex from spatial split scenes (such as trees) it seems even conservative approach of reallocation (when we perform re-allocation when leaf does not fit into the memory) doesn't give measurable difference in time. This makes it so we can switch to array, which will avoid unneeded memory re-allocations when spatial split is disabled without harming other cases. it's a bit difficult to measure exact benefit of this change on our production files here, but depending on the scene it might give quite reasonable memory save.
2015-06-28 16:07:48 +00:00
BVHBuild bvh_build(objects,
pack.prim_type,
pack.prim_index,
pack.prim_object,
params,
progress);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
BVHNode *root = bvh_build.run();
if(progress.get_cancel()) {
if(root) root->deleteSubtree();
return;
}
/* pack triangles */
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
progress.set_substatus("Packing BVH triangles and strands");
pack_primitives();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
if(progress.get_cancel()) {
root->deleteSubtree();
return;
}
/* pack nodes */
progress.set_substatus("Packing BVH nodes");
Cycles / BVH: Remove unused temp copy of prim_object. This will save some memory during BVH Build.
2015-02-18 00:12:53 +00:00
pack_nodes(root);
Cycles: Free memory used by intermediate BVH vectors earlier Ideally we should get rid of those temporary vectors anyway, but it's not so trivial because of the alignment. For untl then we'll just have a bit worse solution. This part of code is not the root of the issue of memory spikes for now anyway. But since we're getting rid of temporary memory earlier actual spike is a bit smaller as now. For example in franck_sheep file it's now 5489.69MB vs. previously 5599.90MB.
2015-02-19 13:58:21 +00:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* free build nodes */
root->deleteSubtree();
}
/* Refitting */
void BVH::refit(Progress& progress)
{
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
progress.set_substatus("Packing BVH primitives");
pack_primitives();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
if(progress.get_cancel()) return;
progress.set_substatus("Refitting BVH nodes");
refit_nodes();
}
/* Triangles */
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 14:13:50 +00:00
void BVH::pack_triangle(int idx, float4 tri_verts[3])
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
int tob = pack.prim_object[idx];
Cycles: Add assert check to triangle packing Handy for troubleshooting.
2015-01-22 09:27:13 +00:00
assert(tob >= 0 && tob < objects.size());
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
const Mesh *mesh = objects[tob]->mesh;
Cycles: add support for mesh deformation motion blur.
2014-03-29 12:03:47 +00:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
int tidx = pack.prim_index[idx];
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
Mesh::Triangle t = mesh->get_triangle(tidx);
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 14:13:50 +00:00
const float3 *vpos = &mesh->verts[0];
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
float3 v0 = vpos[t.v[0]];
float3 v1 = vpos[t.v[1]];
float3 v2 = vpos[t.v[2]];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
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 14:13:50 +00:00
tri_verts[0] = float3_to_float4(v0);
tri_verts[1] = float3_to_float4(v1);
tri_verts[2] = float3_to_float4(v2);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
void BVH::pack_primitives()
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
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 14:13:50 +00:00
const size_t tidx_size = pack.prim_index.size();
size_t num_prim_triangles = 0;
/* Count number of triangles primitives in BVH. */
for(unsigned int i = 0; i < tidx_size; i++) {
if((pack.prim_index[i] != -1)) {
if ((pack.prim_type[i] & PRIMITIVE_ALL_TRIANGLE) != 0) {
++num_prim_triangles;
}
}
}
/* Reserve size for arrays. */
pack.prim_tri_index.clear();
pack.prim_tri_index.resize(tidx_size);
pack.prim_tri_verts.clear();
pack.prim_tri_verts.resize(num_prim_triangles * 3);
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
pack.prim_visibility.clear();
pack.prim_visibility.resize(tidx_size);
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 14:13:50 +00:00
/* Fill in all the arrays. */
size_t prim_triangle_index = 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
for(unsigned int i = 0; i < tidx_size; i++) {
if(pack.prim_index[i] != -1) {
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 14:13:50 +00:00
int tob = pack.prim_object[i];
Object *ob = objects[tob];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
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 14:13:50 +00:00
if((pack.prim_type[i] & PRIMITIVE_ALL_TRIANGLE) != 0) {
pack_triangle(i, (float4*)&pack.prim_tri_verts[3 * prim_triangle_index]);
pack.prim_tri_index[i] = 3 * prim_triangle_index;
++prim_triangle_index;
Fix T43484: Motion blur fails in certain circumstances The issue was caused by mismatch in how aligned triangles storage was filled in during BVH construction and how it was used during rendering. Basically, i was leaving uninitialized storage for triangles when there was deformation motion blur detected for the mesh. Was likely some sort of optimization, but in fact it's still possible that regular triangles would be needed for rendering. So now we're storing aligned storage for all triangle primitives and only skipping motion triangles (the deformation motion blur flag from mesh is now ignored).
2015-03-09 09:15:35 +00:00
}
else {
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 14:13:50 +00:00
pack.prim_tri_index[i] = -1;
Fix T43484: Motion blur fails in certain circumstances The issue was caused by mismatch in how aligned triangles storage was filled in during BVH construction and how it was used during rendering. Basically, i was leaving uninitialized storage for triangles when there was deformation motion blur detected for the mesh. Was likely some sort of optimization, but in fact it's still possible that regular triangles would be needed for rendering. So now we're storing aligned storage for all triangle primitives and only skipping motion triangles (the deformation motion blur flag from mesh is now ignored).
2015-03-09 09:15:35 +00:00
}
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
pack.prim_visibility[i] = ob->visibility;
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
if(pack.prim_type[i] & PRIMITIVE_ALL_CURVE)
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
pack.prim_visibility[i] |= PATH_RAY_CURVE;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Fix some (quite harmless) use of uninitialized memory reported by valgrind.
2013-02-12 13:48:04 +00:00
else {
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 14:13:50 +00:00
pack.prim_tri_index[i] = -1;
Fix some (quite harmless) use of uninitialized memory reported by valgrind.
2013-02-12 13:48:04 +00:00
pack.prim_visibility[i] = 0;
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
}
/* Pack Instances */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
void BVH::pack_instances(size_t nodes_size, size_t leaf_nodes_size)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
/* The BVH's for instances are built separately, but for traversal all
style cleanup: block comments
2012-06-09 17:22:52 +00:00
* BVH's are stored in global arrays. This function merges them into the
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
* top level BVH, adjusting indexes and offsets where appropriate.
*/
const bool use_qbvh = params.use_qbvh;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Adjust primitive index to point to the triangle in the global array, for
* meshes with transform applied and already in the top level BVH.
*/
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
for(size_t i = 0; i < pack.prim_index.size(); i++)
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
if(pack.prim_index[i] != -1) {
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
if(pack.prim_type[i] & PRIMITIVE_ALL_CURVE)
Cycles Hair: refactoring to store curves with the index of the first key and the number of keys in the curve, rather than curve segments with the indices of two keys. ShaderData.segment now stores the segment number in the curve.
2013-01-03 12:09:09 +00:00
pack.prim_index[i] += objects[pack.prim_object[i]]->mesh->curve_offset;
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
else
pack.prim_index[i] += objects[pack.prim_object[i]]->mesh->tri_offset;
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* track offsets of instanced BVH data in global array */
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
size_t prim_offset = pack.prim_index.size();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
size_t nodes_offset = nodes_size;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
size_t nodes_leaf_offset = leaf_nodes_size;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* clear array that gives the node indexes for instanced objects */
pack.object_node.clear();
/* reserve */
size_t prim_index_size = pack.prim_index.size();
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 14:13:50 +00:00
size_t prim_tri_verts_size = pack.prim_tri_verts.size();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
size_t pack_prim_index_offset = prim_index_size;
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 14:13:50 +00:00
size_t pack_prim_tri_verts_offset = prim_tri_verts_size;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
size_t pack_nodes_offset = nodes_size;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
size_t pack_leaf_nodes_offset = leaf_nodes_size;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
size_t object_offset = 0;
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
map<Mesh*, int> mesh_map;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
foreach(Object *ob, objects) {
Mesh *mesh = ob->mesh;
BVH *bvh = mesh->bvh;
Cycles: Use dedicated BVH for subsurface ray casting This commit makes it so casting subsurface rays will totally ignore all the BVH nodes and primitives which do not belong to a current object, making it much simpler traversal code and reduces number of intersection tests. Reviewers: brecht, juicyfruit, dingto, lukasstockner97 Differential Revision: https://developer.blender.org/D1823
2016-02-25 14:12:11 +00:00
if(mesh->need_build_bvh()) {
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
if(mesh_map.find(mesh) == mesh_map.end()) {
prim_index_size += bvh->pack.prim_index.size();
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 14:13:50 +00:00
prim_tri_verts_size += bvh->pack.prim_tri_verts.size();
Cycles: Avoid over-allocation in packing BVH instances This solves quite an over-allocation in BVH instances packing code, unfortunately, it's not a magic bullet to solve memory bump caused by the recent QBVH changes. For that we'll likely need to decouple storage for leaf and inner nodes. However, it's not really clear for now if it's something important since that'd still be just a fraction of memory comparing to all the hi-res textures.
2014-12-17 18:31:12 +00:00
nodes_size += bvh->pack.nodes.size();
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
leaf_nodes_size += bvh->pack.leaf_nodes.size();
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
mesh_map[mesh] = 1;
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
}
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
mesh_map.clear();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.prim_index.resize(prim_index_size);
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
pack.prim_type.resize(prim_index_size);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.prim_object.resize(prim_index_size);
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
pack.prim_visibility.resize(prim_index_size);
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 14:13:50 +00:00
pack.prim_tri_verts.resize(prim_tri_verts_size);
pack.prim_tri_index.resize(prim_index_size);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.nodes.resize(nodes_size);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
pack.leaf_nodes.resize(leaf_nodes_size);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.object_node.resize(objects.size());
Cycles: some tweaks to silence msvc assertions in debug mode.
2011-10-03 15:31:45 +00:00
int *pack_prim_index = (pack.prim_index.size())? &pack.prim_index[0]: NULL;
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
int *pack_prim_type = (pack.prim_type.size())? &pack.prim_type[0]: NULL;
Cycles: some tweaks to silence msvc assertions in debug mode.
2011-10-03 15:31:45 +00:00
int *pack_prim_object = (pack.prim_object.size())? &pack.prim_object[0]: NULL;
uint *pack_prim_visibility = (pack.prim_visibility.size())? &pack.prim_visibility[0]: NULL;
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 14:13:50 +00:00
float4 *pack_prim_tri_verts = (pack.prim_tri_verts.size())? &pack.prim_tri_verts[0]: NULL;
uint *pack_prim_tri_index = (pack.prim_tri_index.size())? &pack.prim_tri_index[0]: NULL;
Cycles: some tweaks to silence msvc assertions in debug mode.
2011-10-03 15:31:45 +00:00
int4 *pack_nodes = (pack.nodes.size())? &pack.nodes[0]: NULL;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int4 *pack_leaf_nodes = (pack.leaf_nodes.size())? &pack.leaf_nodes[0]: NULL;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* merge */
foreach(Object *ob, objects) {
Mesh *mesh = ob->mesh;
Cycles: Use dedicated BVH for subsurface ray casting This commit makes it so casting subsurface rays will totally ignore all the BVH nodes and primitives which do not belong to a current object, making it much simpler traversal code and reduces number of intersection tests. Reviewers: brecht, juicyfruit, dingto, lukasstockner97 Differential Revision: https://developer.blender.org/D1823
2016-02-25 14:12:11 +00:00
/* We assume that if mesh doesn't need own BVH it was already included
* into a top-level BVH and no packing here is needed.
*/
if(!mesh->need_build_bvh()) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.object_node[object_offset++] = 0;
continue;
}
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
/* if mesh already added once, don't add it again, but used set
style cleanup: block comments
2012-06-09 17:22:52 +00:00
* node offset for this object */
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
map<Mesh*, int>::iterator it = mesh_map.find(mesh);
if(mesh_map.find(mesh) != mesh_map.end()) {
int noffset = it->second;
pack.object_node[object_offset++] = noffset;
continue;
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
BVH *bvh = mesh->bvh;
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
int noffset = nodes_offset;
int noffset_leaf = nodes_leaf_offset;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
int mesh_tri_offset = mesh->tri_offset;
Cycles Hair: refactoring to store curves with the index of the first key and the number of keys in the curve, rather than curve segments with the indices of two keys. ShaderData.segment now stores the segment number in the curve.
2013-01-03 12:09:09 +00:00
int mesh_curve_offset = mesh->curve_offset;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* fill in node indexes for instances */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(bvh->pack.root_index == -1)
pack.object_node[object_offset++] = -noffset_leaf-1;
Code tweak removing comment, the fix here is indeed correct.
2012-07-31 15:05:11 +00:00
else
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.object_node[object_offset++] = noffset;
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
mesh_map[mesh] = pack.object_node[object_offset-1];
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 14:13:50 +00:00
/* merge primitive, object and triangle indexes */
Cycles: some tweaks to silence msvc assertions in debug mode.
2011-10-03 15:31:45 +00:00
if(bvh->pack.prim_index.size()) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
size_t bvh_prim_index_size = bvh->pack.prim_index.size();
int *bvh_prim_index = &bvh->pack.prim_index[0];
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
int *bvh_prim_type = &bvh->pack.prim_type[0];
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
uint *bvh_prim_visibility = &bvh->pack.prim_visibility[0];
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 14:13:50 +00:00
uint *bvh_prim_tri_index = &bvh->pack.prim_tri_index[0];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
for(size_t i = 0; i < bvh_prim_index_size; i++) {
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 14:13:50 +00:00
if(bvh->pack.prim_type[i] & PRIMITIVE_ALL_CURVE) {
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
pack_prim_index[pack_prim_index_offset] = bvh_prim_index[i] + mesh_curve_offset;
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 14:13:50 +00:00
pack_prim_tri_index[pack_prim_index_offset] = -1;
}
else {
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
pack_prim_index[pack_prim_index_offset] = bvh_prim_index[i] + mesh_tri_offset;
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 14:13:50 +00:00
pack_prim_tri_index[pack_prim_index_offset] =
bvh_prim_tri_index[i] + pack_prim_tri_verts_offset;
}
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
pack_prim_type[pack_prim_index_offset] = bvh_prim_type[i];
Cycles: * Fix crash in light path node * Fix struct alignment issue for cuda * Fix issue with instances taking up too much memory * Fix issue with ray visibility working incorrect on some objects * Enable OpenCL always and remove option, it has no dependencies so may as well * Refuse to load kernel if OpenCL version < 1.1, recent drivers are needed * Better error handling for OpenCL device * 3D views with rendered draw mode will now revert to wireframe on file load
2011-09-02 14:55:06 +00:00
pack_prim_visibility[pack_prim_index_offset] = bvh_prim_visibility[i];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_prim_object[pack_prim_index_offset] = 0; // unused for instances
pack_prim_index_offset++;
}
}
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 14:13:50 +00:00
/* Merge triangle vertices data. */
if(bvh->pack.prim_tri_verts.size()) {
const size_t prim_tri_size = bvh->pack.prim_tri_verts.size();
memcpy(pack_prim_tri_verts + pack_prim_tri_verts_offset,
&bvh->pack.prim_tri_verts[0],
prim_tri_size*sizeof(float4));
pack_prim_tri_verts_offset += prim_tri_size;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
/* merge nodes */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(bvh->pack.leaf_nodes.size()) {
int4 *leaf_nodes_offset = &bvh->pack.leaf_nodes[0];
size_t leaf_nodes_offset_size = bvh->pack.leaf_nodes.size();
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
for(size_t i = 0, j = 0;
i < leaf_nodes_offset_size;
Cycles: Cleanup, spaces
2016-10-24 09:10:35 +00:00
i += BVH_NODE_LEAF_SIZE, j++)
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
{
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int4 data = leaf_nodes_offset[i];
data.x += prim_offset;
data.y += prim_offset;
pack_leaf_nodes[pack_leaf_nodes_offset] = data;
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
for(int j = 1; j < BVH_NODE_LEAF_SIZE; ++j) {
Cycles: Proper pack of leaves which are bigger than single float4
2016-04-25 16:56:52 +00:00
pack_leaf_nodes[pack_leaf_nodes_offset + j] = leaf_nodes_offset[i + j];
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack_leaf_nodes_offset += BVH_NODE_LEAF_SIZE;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
}
Fix some (quite harmless) use of uninitialized memory reported by valgrind.
2013-02-12 13:48:04 +00:00
if(bvh->pack.nodes.size()) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
int4 *bvh_nodes = &bvh->pack.nodes[0];
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
size_t bvh_nodes_size = bvh->pack.nodes.size();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
for(size_t i = 0, j = 0; i < bvh_nodes_size; j++) {
size_t nsize, nsize_bbox;
if(bvh_nodes[i].x & PATH_RAY_NODE_UNALIGNED) {
nsize = use_qbvh
? BVH_UNALIGNED_QNODE_SIZE
: BVH_UNALIGNED_NODE_SIZE;
nsize_bbox = (use_qbvh)? 13: 0;
}
else {
nsize = (use_qbvh)? BVH_QNODE_SIZE: BVH_NODE_SIZE;
nsize_bbox = (use_qbvh)? 7: 0;
}
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
memcpy(pack_nodes + pack_nodes_offset,
bvh_nodes + i,
nsize_bbox*sizeof(int4));
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Modify offsets into arrays */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
int4 data = bvh_nodes[i + nsize_bbox];
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
data.z += (data.z < 0)? -noffset_leaf: noffset;
data.w += (data.w < 0)? -noffset_leaf: noffset;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(use_qbvh) {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
data.x += (data.x < 0)? -noffset_leaf: noffset;
data.y += (data.y < 0)? -noffset_leaf: noffset;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
pack_nodes[pack_nodes_offset + nsize_bbox] = data;
Cleanup: Typo fixes for comments.
2014-12-25 01:42:06 +00:00
/* Usually this copies nothing, but we better
* be prepared for possible node size extension.
Cycles: Correction for node tail copy on packing BVH This is harmless for now because tail of the node is zero in there, but better to fix it early so in the case of extending BVH nodes this code doesn't give issues.
2014-12-24 21:49:27 +00:00
*/
memcpy(&pack_nodes[pack_nodes_offset + nsize_bbox+1],
&bvh_nodes[i + nsize_bbox+1],
sizeof(int4) * (nsize - (nsize_bbox+1)));
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_nodes_offset += nsize;
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
i += nsize;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
}
nodes_offset += bvh->pack.nodes.size();
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
nodes_leaf_offset += bvh->pack.leaf_nodes.size();
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
prim_offset += bvh->pack.prim_index.size();
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
}
/* Regular BVH */
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
static bool node_bvh_is_unaligned(const BVHNode *node)
{
const BVHNode *node0 = node->get_child(0),
*node1 = node->get_child(1);
return node0->is_unaligned() || node1->is_unaligned();
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
RegularBVH::RegularBVH(const BVHParams& params_, const vector<Object*>& objects_)
: BVH(params_, objects_)
{
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_leaf(const BVHStackEntry& e,
const LeafNode *leaf)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Add asserts to BVH node packing
2016-09-08 12:32:05 +00:00
assert(e.idx + BVH_NODE_LEAF_SIZE <= pack.leaf_nodes.size());
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
float4 data[BVH_NODE_LEAF_SIZE];
memset(data, 0, sizeof(data));
Cycles: BVH params option to split leaf node by primitive types The idea of this change is make it possible to split leaf nodes by primitive type, making leaf containing primitives of the same type. This would become handy when working on a single ray to multiple triangles intersection code, plus with careful implementation it might give some extra benefits on BVH traversal code by avoiding primitive type fetch and check for each primitive in the node. But that's a bit tricky to have benefits on this change only because depth of BVH increases. This option is not exposed to the interface at all and not used even secretly, the commit is only needed to help working further in this direction without messing around with local patches and worrying of them running out of date.
2015-01-09 22:41:04 +00:00
if(leaf->num_triangles() == 1 && pack.prim_index[leaf->m_lo] == -1) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* object */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
data[0].x = __int_as_float(~(leaf->m_lo));
data[0].y = __int_as_float(0);
Cycles: BVH params option to split leaf node by primitive types The idea of this change is make it possible to split leaf nodes by primitive type, making leaf containing primitives of the same type. This would become handy when working on a single ray to multiple triangles intersection code, plus with careful implementation it might give some extra benefits on BVH traversal code by avoiding primitive type fetch and check for each primitive in the node. But that's a bit tricky to have benefits on this change only because depth of BVH increases. This option is not exposed to the interface at all and not used even secretly, the commit is only needed to help working further in this direction without messing around with local patches and worrying of them running out of date.
2015-01-09 22:41:04 +00:00
}
else {
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
/* triangle */
data[0].x = __int_as_float(leaf->m_lo);
data[0].y = __int_as_float(leaf->m_hi);
}
data[0].z = __uint_as_float(leaf->m_visibility);
if(leaf->num_triangles() != 0) {
data[0].w = __uint_as_float(pack.prim_type[leaf->m_lo]);
Cycles: BVH params option to split leaf node by primitive types The idea of this change is make it possible to split leaf nodes by primitive type, making leaf containing primitives of the same type. This would become handy when working on a single ray to multiple triangles intersection code, plus with careful implementation it might give some extra benefits on BVH traversal code by avoiding primitive type fetch and check for each primitive in the node. But that's a bit tricky to have benefits on this change only because depth of BVH increases. This option is not exposed to the interface at all and not used even secretly, the commit is only needed to help working further in this direction without messing around with local patches and worrying of them running out of date.
2015-01-09 22:41:04 +00:00
}
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
memcpy(&pack.leaf_nodes[e.idx], data, sizeof(float4)*BVH_NODE_LEAF_SIZE);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_inner(const BVHStackEntry& e,
const BVHStackEntry& e0,
const BVHStackEntry& e1)
{
if (e0.node->is_unaligned() || e1.node->is_unaligned()) {
pack_unaligned_inner(e, e0, e1);
} else {
pack_aligned_inner(e, e0, e1);
}
}
void RegularBVH::pack_aligned_inner(const BVHStackEntry& e,
const BVHStackEntry& e0,
const BVHStackEntry& e1)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack_aligned_node(e.idx,
e0.node->m_bounds, e1.node->m_bounds,
e0.encodeIdx(), e1.encodeIdx(),
Cycles: Fix refitting of regular BVH Was causing CUDA issues on viewport edits.
2016-07-15 16:12:05 +00:00
e0.node->m_visibility, e1.node->m_visibility);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_aligned_node(int idx,
const BoundBox& b0,
const BoundBox& b1,
int c0, int c1,
uint visibility0, uint visibility1)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Add asserts to BVH node packing
2016-09-08 12:32:05 +00:00
assert(idx + BVH_NODE_SIZE <= pack.nodes.size());
assert(c0 < 0 || c0 < pack.nodes.size());
assert(c1 < 0 || c1 < pack.nodes.size());
int4 data[BVH_NODE_SIZE] = {
Cycles: Fix refitting of regular BVH Was causing CUDA issues on viewport edits.
2016-07-15 16:12:05 +00:00
make_int4(visibility0 & ~PATH_RAY_NODE_UNALIGNED,
Cycles: Cleanup: line wrapping
2016-09-08 12:26:10 +00:00
visibility1 & ~PATH_RAY_NODE_UNALIGNED,
c0, c1),
make_int4(__float_as_int(b0.min.x),
__float_as_int(b1.min.x),
__float_as_int(b0.max.x),
__float_as_int(b1.max.x)),
make_int4(__float_as_int(b0.min.y),
__float_as_int(b1.min.y),
__float_as_int(b0.max.y),
__float_as_int(b1.max.y)),
make_int4(__float_as_int(b0.min.z),
__float_as_int(b1.min.z),
__float_as_int(b0.max.z),
__float_as_int(b1.max.z)),
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
};
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
memcpy(&pack.nodes[idx], data, sizeof(int4)*BVH_NODE_SIZE);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_unaligned_inner(const BVHStackEntry& e,
const BVHStackEntry& e0,
const BVHStackEntry& e1)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack_unaligned_node(e.idx,
e0.node->get_aligned_space(),
e1.node->get_aligned_space(),
e0.node->m_bounds,
e1.node->m_bounds,
e0.encodeIdx(), e1.encodeIdx(),
e0.node->m_visibility, e1.node->m_visibility);
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_unaligned_node(int idx,
const Transform& aligned_space0,
const Transform& aligned_space1,
const BoundBox& bounds0,
const BoundBox& bounds1,
int c0, int c1,
uint visibility0, uint visibility1)
{
Cycles: Add asserts to BVH node packing
2016-09-08 12:32:05 +00:00
assert(idx + BVH_UNALIGNED_NODE_SIZE <= pack.nodes.size());
assert(c0 < 0 || c0 < pack.nodes.size());
assert(c1 < 0 || c1 < pack.nodes.size());
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
float4 data[BVH_UNALIGNED_NODE_SIZE];
Transform space0 = BVHUnaligned::compute_node_transform(bounds0,
aligned_space0);
Transform space1 = BVHUnaligned::compute_node_transform(bounds1,
aligned_space1);
data[0] = make_float4(__int_as_float(visibility0 | PATH_RAY_NODE_UNALIGNED),
__int_as_float(visibility1 | PATH_RAY_NODE_UNALIGNED),
__int_as_float(c0),
__int_as_float(c1));
data[1] = space0.x;
data[2] = space0.y;
data[3] = space0.z;
data[4] = space1.x;
data[5] = space1.y;
data[6] = space1.z;
memcpy(&pack.nodes[idx], data, sizeof(float4)*BVH_UNALIGNED_NODE_SIZE);
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void RegularBVH::pack_nodes(const BVHNode *root)
{
const size_t num_nodes = root->getSubtreeSize(BVH_STAT_NODE_COUNT);
const size_t num_leaf_nodes = root->getSubtreeSize(BVH_STAT_LEAF_COUNT);
assert(num_leaf_nodes <= num_nodes);
const size_t num_inner_nodes = num_nodes - num_leaf_nodes;
size_t node_size;
if(params.use_unaligned_nodes) {
const size_t num_unaligned_nodes =
root->getSubtreeSize(BVH_STAT_UNALIGNED_INNER_COUNT);
node_size = (num_unaligned_nodes * BVH_UNALIGNED_NODE_SIZE) +
(num_inner_nodes - num_unaligned_nodes) * BVH_NODE_SIZE;
}
else {
node_size = num_inner_nodes * BVH_NODE_SIZE;
}
/* Resize arrays */
pack.nodes.clear();
pack.leaf_nodes.clear();
/* For top level BVH, first merge existing BVH's so we know the offsets. */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(params.top_level) {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack_instances(node_size, num_leaf_nodes*BVH_NODE_LEAF_SIZE);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
else {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack.nodes.resize(node_size);
pack.leaf_nodes.resize(num_leaf_nodes*BVH_NODE_LEAF_SIZE);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int nextNodeIdx = 0, nextLeafNodeIdx = 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
vector<BVHStackEntry> stack;
Cycles: attempt to fix internal compile error with some visual studio builds
2013-06-18 13:19:16 +00:00
stack.reserve(BVHParams::MAX_DEPTH*2);
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
if(root->is_leaf()) {
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
stack.push_back(BVHStackEntry(root, nextLeafNodeIdx++));
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
}
else {
stack.push_back(BVHStackEntry(root, nextNodeIdx));
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
nextNodeIdx += node_bvh_is_unaligned(root)
? BVH_UNALIGNED_NODE_SIZE
: BVH_NODE_SIZE;
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
while(stack.size()) {
BVHStackEntry e = stack.back();
stack.pop_back();
if(e.node->is_leaf()) {
/* leaf node */
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
const LeafNode *leaf = reinterpret_cast<const LeafNode*>(e.node);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_leaf(e, leaf);
}
else {
/* innner node */
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
int idx[2];
for (int i = 0; i < 2; ++i) {
if (e.node->get_child(i)->is_leaf()) {
idx[i] = nextLeafNodeIdx++;
}
else {
idx[i] = nextNodeIdx;
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
nextNodeIdx += node_bvh_is_unaligned(e.node->get_child(i))
? BVH_UNALIGNED_NODE_SIZE
: BVH_NODE_SIZE;
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
}
}
stack.push_back(BVHStackEntry(e.node->get_child(0), idx[0]));
stack.push_back(BVHStackEntry(e.node->get_child(1), idx[1]));
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_inner(e, stack[stack.size()-2], stack[stack.size()-1]);
}
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
assert(node_size == nextNodeIdx);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* root index to start traversal at, to handle case of single leaf node */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
pack.root_index = (root->is_leaf())? -1: 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
void RegularBVH::refit_nodes()
{
assert(!params.top_level);
Cycles: merging features from tomato branch. === BVH build time optimizations === * BVH building was multithreaded. Not all building is multithreaded, packing and the initial bounding/splitting is still single threaded, but recursive splitting is, which was the main bottleneck. * Object splitting now uses binning rather than sorting of all elements, using code from the Embree raytracer from Intel. http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/ * Other small changes to avoid allocations, pack memory more tightly, avoid some unnecessary operations, ... These optimizations do not work yet when Spatial Splits are enabled, for that more work is needed. There's also other optimizations still needed, in particular for the case of many low poly objects, the packing step and node memory allocation. BVH raytracing time should remain about the same, but BVH build time should be significantly reduced, test here show speedup of about 5x to 10x on a dual core and 5x to 25x on an 8-core machine, depending on the scene. === Threads === Centralized task scheduler for multithreading, which is basically the CPU device threading code wrapped into something reusable. Basic idea is that there is a single TaskScheduler that keeps a pool of threads, one for each core. Other places in the code can then create a TaskPool that they can drop Tasks in to be executed by the scheduler, and wait for them to complete or cancel them early. === Normal ==== Added a Normal output to the texture coordinate node. This currently gives the object space normal, which is the same under object animation. In the future this might become a "generated" normal so it's also stable for deforming objects, but for now it's already useful for non-deforming objects. === Render Layers === Per render layer Samples control, leaving it to 0 will use the common scene setting. Environment pass will now render environment even if film is set to transparent. Exclude Layers" added. Scene layers (all object that influence the render, directly or indirectly) are shared between all render layers. However sometimes it's useful to leave out some object influence for a particular render layer. That's what this option allows you to do. === Filter Glossy === When using a value higher than 0.0, this will blur glossy reflections after blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good starting value to tweak. Some light paths have a low probability of being found while contributing much light to the pixel. As a result these light paths will be found in some pixels and not in others, causing fireflies. An example of such a difficult path might be a small light that is causing a small specular highlight on a sharp glossy material, which we are seeing through a rough glossy material. With path tracing it is difficult to find the specular highlight, but if we increase the roughness on the material the highlight gets bigger and softer, and so easier to find. Often this blurring will be hardly noticeable, because we are seeing it through a blurry material anyway, but there are also cases where this will lead to a loss of detail in lighting.
2012-04-28 08:53:59 +00:00
BoundBox bbox = BoundBox::empty;
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
uint visibility = 0;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
refit_node(0, (pack.root_index == -1)? true: false, bbox, visibility);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
void RegularBVH::refit_node(int idx, bool leaf, BoundBox& bbox, uint& visibility)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
if(leaf) {
Cycles: Add asserts to BVH node packing
2016-09-08 12:32:05 +00:00
assert(idx + BVH_NODE_LEAF_SIZE <= pack.leaf_nodes.size());
Cycles: Fix regular BVH nodes refit For proper indexing to work we need to use unaligned node with identity transform instead of aligned nodes when doing refit. To be backported to 2.78 release.
2016-09-08 13:08:35 +00:00
const int4 *data = &pack.leaf_nodes[idx];
const int c0 = data[0].x;
const int c1 = data[0].y;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* refit leaf node */
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
for(int prim = c0; prim < c1; prim++) {
int pidx = pack.prim_index[prim];
int tob = pack.prim_object[prim];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Object *ob = objects[tob];
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
if(pidx == -1) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* object instance */
bbox.grow(ob->bounds);
}
else {
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
/* primitives */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
const Mesh *mesh = ob->mesh;
Cycles code refactor: changes to make adding new primitive types easier.
2014-03-29 12:03:46 +00:00
if(pack.prim_type[prim] & PRIMITIVE_ALL_CURVE) {
Cycles Hair: refactoring to store curves with the index of the first key and the number of keys in the curve, rather than curve segments with the indices of two keys. ShaderData.segment now stores the segment number in the curve.
2013-01-03 12:09:09 +00:00
/* curves */
int str_offset = (params.top_level)? mesh->curve_offset: 0;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
Mesh::Curve curve = mesh->get_curve(pidx - str_offset);
Cycles code refactor: change curve key to float4 for easier storage as attribute.
2014-03-29 12:03:46 +00:00
int k = PRIMITIVE_UNPACK_SEGMENT(pack.prim_type[prim]);
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
curve.bounds_grow(k, &mesh->curve_keys[0], &mesh->curve_radius[0], bbox);
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
visibility |= PATH_RAY_CURVE;
Cycles: add support for curve deformation motion blur.
2014-03-29 12:03:47 +00:00
/* motion curves */
if(mesh->use_motion_blur) {
Attribute *attr = mesh->curve_attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
if(attr) {
size_t mesh_size = mesh->curve_keys.size();
size_t steps = mesh->motion_steps - 1;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
float3 *key_steps = attr->data_float3();
Cycles: add support for curve deformation motion blur.
2014-03-29 12:03:47 +00:00
Cycles: Code cleanup, spaces around keywords This inconsistency drove me totally crazy, it's really confusing when it's inconsistent especially when you work on both Cycles and Blender sides. Shouldn;t cause merge PITA, it's whitespace changes only, Git should be able to merge it nicely.
2015-03-27 19:15:15 +00:00
for(size_t i = 0; i < steps; i++)
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
curve.bounds_grow(k, key_steps + i*mesh_size, &mesh->curve_radius[0], bbox);
Cycles: add support for curve deformation motion blur.
2014-03-29 12:03:47 +00:00
}
}
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
}
else {
/* triangles */
int tri_offset = (params.top_level)? mesh->tri_offset: 0;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
Mesh::Triangle triangle = mesh->get_triangle(pidx - tri_offset);
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
const float3 *vpos = &mesh->verts[0];
Cycles code refactor: change curve key to float4 for easier storage as attribute.
2014-03-29 12:03:46 +00:00
triangle.bounds_grow(vpos, bbox);
Cycles: add support for mesh deformation motion blur.
2014-03-29 12:03:47 +00:00
/* motion triangles */
if(mesh->use_motion_blur) {
Attribute *attr = mesh->attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
if(attr) {
size_t mesh_size = mesh->verts.size();
size_t steps = mesh->motion_steps - 1;
float3 *vert_steps = attr->data_float3();
Cycles: Code cleanup, spaces around keywords This inconsistency drove me totally crazy, it's really confusing when it's inconsistent especially when you work on both Cycles and Blender sides. Shouldn;t cause merge PITA, it's whitespace changes only, Git should be able to merge it nicely.
2015-03-27 19:15:15 +00:00
for(size_t i = 0; i < steps; i++)
Cycles: add support for mesh deformation motion blur.
2014-03-29 12:03:47 +00:00
triangle.bounds_grow(vert_steps + i*mesh_size, bbox);
}
}
New feature Patch [#33445] - Experimental Cycles Hair Rendering (CPU only) This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with. The UI appears under the particle tab and there is a new hair info node available. It is only available under the experimental feature set and for cpu rendering.
2012-12-28 14:21:30 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
visibility |= ob->visibility;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
/* TODO(sergey): De-duplicate with pack_leaf(). */
float4 leaf_data[BVH_NODE_LEAF_SIZE];
leaf_data[0].x = __int_as_float(c0);
leaf_data[0].y = __int_as_float(c1);
leaf_data[0].z = __uint_as_float(visibility);
leaf_data[0].w = __uint_as_float(data[0].w);
Cycles: Fix refitting of regular BVH Was causing CUDA issues on viewport edits.
2016-07-15 16:12:05 +00:00
memcpy(&pack.leaf_nodes[idx], leaf_data, sizeof(float4)*BVH_NODE_LEAF_SIZE);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
else {
Cycles: Add asserts to BVH node packing
2016-09-08 12:32:05 +00:00
assert(idx + BVH_NODE_SIZE <= pack.nodes.size());
Cycles: Fix regular BVH nodes refit For proper indexing to work we need to use unaligned node with identity transform instead of aligned nodes when doing refit. To be backported to 2.78 release.
2016-09-08 13:08:35 +00:00
const int4 *data = &pack.nodes[idx];
const bool is_unaligned = (data[0].x & PATH_RAY_NODE_UNALIGNED) != 0;
const int c0 = data[0].z;
const int c1 = data[0].w;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* refit inner node, set bbox from children */
Cycles: merging features from tomato branch. === BVH build time optimizations === * BVH building was multithreaded. Not all building is multithreaded, packing and the initial bounding/splitting is still single threaded, but recursive splitting is, which was the main bottleneck. * Object splitting now uses binning rather than sorting of all elements, using code from the Embree raytracer from Intel. http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/ * Other small changes to avoid allocations, pack memory more tightly, avoid some unnecessary operations, ... These optimizations do not work yet when Spatial Splits are enabled, for that more work is needed. There's also other optimizations still needed, in particular for the case of many low poly objects, the packing step and node memory allocation. BVH raytracing time should remain about the same, but BVH build time should be significantly reduced, test here show speedup of about 5x to 10x on a dual core and 5x to 25x on an 8-core machine, depending on the scene. === Threads === Centralized task scheduler for multithreading, which is basically the CPU device threading code wrapped into something reusable. Basic idea is that there is a single TaskScheduler that keeps a pool of threads, one for each core. Other places in the code can then create a TaskPool that they can drop Tasks in to be executed by the scheduler, and wait for them to complete or cancel them early. === Normal ==== Added a Normal output to the texture coordinate node. This currently gives the object space normal, which is the same under object animation. In the future this might become a "generated" normal so it's also stable for deforming objects, but for now it's already useful for non-deforming objects. === Render Layers === Per render layer Samples control, leaving it to 0 will use the common scene setting. Environment pass will now render environment even if film is set to transparent. Exclude Layers" added. Scene layers (all object that influence the render, directly or indirectly) are shared between all render layers. However sometimes it's useful to leave out some object influence for a particular render layer. That's what this option allows you to do. === Filter Glossy === When using a value higher than 0.0, this will blur glossy reflections after blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good starting value to tweak. Some light paths have a low probability of being found while contributing much light to the pixel. As a result these light paths will be found in some pixels and not in others, causing fireflies. An example of such a difficult path might be a small light that is causing a small specular highlight on a sharp glossy material, which we are seeing through a rough glossy material. With path tracing it is difficult to find the specular highlight, but if we increase the roughness on the material the highlight gets bigger and softer, and so easier to find. Often this blurring will be hardly noticeable, because we are seeing it through a blurry material anyway, but there are also cases where this will lead to a loss of detail in lighting.
2012-04-28 08:53:59 +00:00
BoundBox bbox0 = BoundBox::empty, bbox1 = BoundBox::empty;
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
uint visibility0 = 0, visibility1 = 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
refit_node((c0 < 0)? -c0-1: c0, (c0 < 0), bbox0, visibility0);
refit_node((c1 < 0)? -c1-1: c1, (c1 < 0), bbox1, visibility1);
Cycles: Fix regular BVH nodes refit For proper indexing to work we need to use unaligned node with identity transform instead of aligned nodes when doing refit. To be backported to 2.78 release.
2016-09-08 13:08:35 +00:00
if(is_unaligned) {
Transform aligned_space = transform_identity();
pack_unaligned_node(idx,
aligned_space, aligned_space,
bbox0, bbox1,
c0, c1,
visibility0,
visibility1);
}
else {
pack_aligned_node(idx,
bbox0, bbox1,
c0, c1,
visibility0,
visibility1);
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
bbox.grow(bbox0);
bbox.grow(bbox1);
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
visibility = visibility0|visibility1;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
}
/* QBVH */
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Can we avoid this somehow or make more generic?
*
* Perhaps we can merge nodes in actual tree and make our
* life easier all over the place.
*/
static bool node_qbvh_is_unaligned(const BVHNode *node)
{
const BVHNode *node0 = node->get_child(0),
*node1 = node->get_child(1);
bool has_unaligned = false;
if(node0->is_leaf()) {
has_unaligned |= node0->is_unaligned();
}
else {
has_unaligned |= node0->get_child(0)->is_unaligned();
has_unaligned |= node0->get_child(1)->is_unaligned();
}
if(node1->is_leaf()) {
has_unaligned |= node1->is_unaligned();
}
else {
has_unaligned |= node1->get_child(0)->is_unaligned();
has_unaligned |= node1->get_child(1)->is_unaligned();
}
return has_unaligned;
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
QBVH::QBVH(const BVHParams& params_, const vector<Object*>& objects_)
: BVH(params_, objects_)
{
params.use_qbvh = true;
}
void QBVH::pack_leaf(const BVHStackEntry& e, const LeafNode *leaf)
{
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
float4 data[BVH_QNODE_LEAF_SIZE];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
memset(data, 0, sizeof(data));
if(leaf->num_triangles() == 1 && pack.prim_index[leaf->m_lo] == -1) {
/* object */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
data[0].x = __int_as_float(~(leaf->m_lo));
data[0].y = __int_as_float(0);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
else {
/* triangle */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
data[0].x = __int_as_float(leaf->m_lo);
data[0].y = __int_as_float(leaf->m_hi);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
data[0].z = __uint_as_float(leaf->m_visibility);
Cycles: Fix crash after recent BVH changes on empty BVH trees It's apparently not nice to access 0th element of zero-size vector in C++.
2015-01-12 14:11:32 +00:00
if(leaf->num_triangles() != 0) {
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
data[0].w = __uint_as_float(pack.prim_type[leaf->m_lo]);
Cycles: Fix crash after recent BVH changes on empty BVH trees It's apparently not nice to access 0th element of zero-size vector in C++.
2015-01-12 14:11:32 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
memcpy(&pack.leaf_nodes[e.idx], data, sizeof(float4)*BVH_QNODE_LEAF_SIZE);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void QBVH::pack_inner(const BVHStackEntry& e,
const BVHStackEntry *en,
int num)
{
bool has_unaligned = false;
/* Check whether we have to create unaligned node or all nodes are aligned
* and we can cut some corner here.
*/
if(params.use_unaligned_nodes) {
for(int i = 0; i < num; i++) {
if(en[i].node->is_unaligned()) {
has_unaligned = true;
break;
}
}
}
if(has_unaligned) {
/* There's no unaligned children, pack into AABB node. */
pack_unaligned_inner(e, en, num);
}
else {
/* Create unaligned node with orientation transform for each of the
* children.
*/
pack_aligned_inner(e, en, num);
}
}
void QBVH::pack_aligned_inner(const BVHStackEntry& e,
const BVHStackEntry *en,
int num)
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
{
BoundBox bounds[4];
int child[4];
for(int i = 0; i < num; ++i) {
bounds[i] = en[i].node->m_bounds;
child[i] = en[i].encodeIdx();
}
pack_aligned_node(e.idx,
bounds,
child,
e.node->m_visibility,
num);
}
void QBVH::pack_aligned_node(int idx,
const BoundBox *bounds,
const int *child,
const uint visibility,
const int num)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
float4 data[BVH_QNODE_SIZE];
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
memset(data, 0, sizeof(data));
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
data[0].x = __uint_as_float(visibility & ~PATH_RAY_NODE_UNALIGNED);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
for(int i = 0; i < num; i++) {
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
float3 bb_min = bounds[i].min;
float3 bb_max = bounds[i].max;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
data[1][i] = bb_min.x;
data[2][i] = bb_max.x;
data[3][i] = bb_min.y;
data[4][i] = bb_max.y;
data[5][i] = bb_min.z;
data[6][i] = bb_max.z;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
data[7][i] = __int_as_float(child[i]);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
for(int i = num; i < 4; i++) {
Cycles: Store proper empty boundbox for missing child nodes in QBVH The idea is to make sure those childs would never be intersected with a ray in order to make it so kernel never worries about number of child nodes.
2014-12-24 19:14:12 +00:00
/* We store BB which would never be recorded as intersection
* so kernel might safely assume there are always 4 child nodes.
*/
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
data[1][i] = FLT_MAX;
data[2][i] = -FLT_MAX;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
data[3][i] = FLT_MAX;
data[4][i] = -FLT_MAX;
Cycles: Store proper empty boundbox for missing child nodes in QBVH The idea is to make sure those childs would never be intersected with a ray in order to make it so kernel never worries about number of child nodes.
2014-12-24 19:14:12 +00:00
Cycles: Support visibility check for inner nodes of QBVH It was initially unsupported because initial idea of checking visibility of all children was slowing scenes down a lot. Now the idea has changed and we only perform visibility check of current node. This avoids huge slowdown (from tests here it seems to be withing 1-2%, but more tests would never hurt) and gives nice speedup of ray traversal for complex scenes which utilized ray visibility. Here's timing of koro.blend: Without visibility check With visibility check Original file 4min 20sec 4min 23sec Camera rays only 1min 43 sec 55sec Unfortunately, this doesn't come for free and requires extra data in BVH node, which increases memory usage of BVH nodes by 15%. This we can solve with some future trickery of avoiding __tri_storage created for curve segments.
2016-06-10 08:14:05 +00:00
data[5][i] = FLT_MAX;
data[6][i] = -FLT_MAX;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Revert "Cycles: Tweak empty boundbox children" This reverts commit ecbfa31caaadb03c53c0fe1459718b99613c8804. Original commit broke logic in nodes re-fitting. That area can access non-existing children momentarely. Not sure what would be best solution here, for now simply reverting the change/
2016-09-15 07:39:33 +00:00
data[7][i] = __int_as_float(0);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
memcpy(&pack.nodes[idx], data, sizeof(float4)*BVH_QNODE_SIZE);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
void QBVH::pack_unaligned_inner(const BVHStackEntry& e,
const BVHStackEntry *en,
int num)
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
{
Transform aligned_space[4];
BoundBox bounds[4];
int child[4];
for(int i = 0; i < num; ++i) {
aligned_space[i] = en[i].node->get_aligned_space();
bounds[i] = en[i].node->m_bounds;
child[i] = en[i].encodeIdx();
}
pack_unaligned_node(e.idx,
aligned_space,
bounds,
child,
e.node->m_visibility,
num);
}
void QBVH::pack_unaligned_node(int idx,
const Transform *aligned_space,
const BoundBox *bounds,
const int *child,
const uint visibility,
const int num)
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
{
float4 data[BVH_UNALIGNED_QNODE_SIZE];
memset(data, 0, sizeof(data));
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
data[0].x = __uint_as_float(visibility | PATH_RAY_NODE_UNALIGNED);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
for(int i = 0; i < num; i++) {
Transform space = BVHUnaligned::compute_node_transform(
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
bounds[i],
aligned_space[i]);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
data[1][i] = space.x.x;
data[2][i] = space.x.y;
data[3][i] = space.x.z;
data[4][i] = space.y.x;
data[5][i] = space.y.y;
data[6][i] = space.y.z;
data[7][i] = space.z.x;
data[8][i] = space.z.y;
data[9][i] = space.z.z;
data[10][i] = space.x.w;
data[11][i] = space.y.w;
data[12][i] = space.z.w;
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
data[13][i] = __int_as_float(child[i]);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
}
for(int i = num; i < 4; i++) {
/* We store BB which would never be recorded as intersection
* so kernel might safely assume there are always 4 child nodes.
*/
Fix T49290: Specific .blend with hair crashes in MacOS 2.78 RC1 on render The issue was caused by some false-positive empty non-AABB intersection. Tried to tweak it a bit so it does not record intersection anymore. Hopefully will work for all platforms. Tested here on iMac and Debian.
2016-09-13 08:59:48 +00:00
data[1][i] = 1.0f;
data[2][i] = 0.0f;
data[3][i] = 0.0f;
data[4][i] = 0.0f;
data[5][i] = 0.0f;
data[6][i] = 0.0f;
data[7][i] = 0.0f;
data[8][i] = 0.0f;
data[9][i] = 0.0f;
data[10][i] = -FLT_MAX;
data[11][i] = -FLT_MAX;
data[12][i] = -FLT_MAX;
Revert "Cycles: Tweak empty boundbox children" This reverts commit ecbfa31caaadb03c53c0fe1459718b99613c8804. Original commit broke logic in nodes re-fitting. That area can access non-existing children momentarely. Not sure what would be best solution here, for now simply reverting the change/
2016-09-15 07:39:33 +00:00
data[13][i] = __int_as_float(0);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
}
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
memcpy(&pack.nodes[idx], data, sizeof(float4)*BVH_UNALIGNED_QNODE_SIZE);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* Quad SIMD Nodes */
Cycles / BVH: Remove unused temp copy of prim_object. This will save some memory during BVH Build.
2015-02-18 00:12:53 +00:00
void QBVH::pack_nodes(const BVHNode *root)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Calculate size of the arrays required. */
const size_t num_nodes = root->getSubtreeSize(BVH_STAT_QNODE_COUNT);
const size_t num_leaf_nodes = root->getSubtreeSize(BVH_STAT_LEAF_COUNT);
assert(num_leaf_nodes <= num_nodes);
const size_t num_inner_nodes = num_nodes - num_leaf_nodes;
size_t node_size;
if(params.use_unaligned_nodes) {
const size_t num_unaligned_nodes =
root->getSubtreeSize(BVH_STAT_UNALIGNED_INNER_QNODE_COUNT);
node_size = (num_unaligned_nodes * BVH_UNALIGNED_QNODE_SIZE) +
(num_inner_nodes - num_unaligned_nodes) * BVH_QNODE_SIZE;
}
else {
node_size = num_inner_nodes * BVH_QNODE_SIZE;
}
/* Resize arrays. */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack.nodes.clear();
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
pack.leaf_nodes.clear();
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* For top level BVH, first merge existing BVH's so we know the offsets. */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(params.top_level) {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack_instances(node_size, num_leaf_nodes*BVH_QNODE_LEAF_SIZE);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
else {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
pack.nodes.resize(node_size);
pack.leaf_nodes.resize(num_leaf_nodes*BVH_QNODE_LEAF_SIZE);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int nextNodeIdx = 0, nextLeafNodeIdx = 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
vector<BVHStackEntry> stack;
Cycles: attempt to fix internal compile error with some visual studio builds
2013-06-18 13:19:16 +00:00
stack.reserve(BVHParams::MAX_DEPTH*2);
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
if(root->is_leaf()) {
stack.push_back(BVHStackEntry(root, nextLeafNodeIdx++));
}
else {
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
stack.push_back(BVHStackEntry(root, nextNodeIdx));
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
nextNodeIdx += node_qbvh_is_unaligned(root)
? BVH_UNALIGNED_QNODE_SIZE
: BVH_QNODE_SIZE;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
while(stack.size()) {
BVHStackEntry e = stack.back();
stack.pop_back();
if(e.node->is_leaf()) {
/* leaf node */
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
const LeafNode *leaf = reinterpret_cast<const LeafNode*>(e.node);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_leaf(e, leaf);
}
else {
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Inner node. */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
const BVHNode *node = e.node;
const BVHNode *node0 = node->get_child(0);
const BVHNode *node1 = node->get_child(1);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Collect nodes. */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
const BVHNode *nodes[4];
int numnodes = 0;
if(node0->is_leaf()) {
nodes[numnodes++] = node0;
}
else {
nodes[numnodes++] = node0->get_child(0);
nodes[numnodes++] = node0->get_child(1);
}
if(node1->is_leaf()) {
nodes[numnodes++] = node1;
}
else {
nodes[numnodes++] = node1->get_child(0);
nodes[numnodes++] = node1->get_child(1);
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Push entries on the stack. */
for(int i = 0; i < numnodes; ++i) {
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int idx;
if(nodes[i]->is_leaf()) {
idx = nextLeafNodeIdx++;
}
else {
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
idx = nextNodeIdx;
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
nextNodeIdx += node_qbvh_is_unaligned(nodes[i])
? BVH_UNALIGNED_QNODE_SIZE
: BVH_QNODE_SIZE;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
}
stack.push_back(BVHStackEntry(nodes[i], idx));
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
/* Set node. */
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
pack_inner(e, &stack[stack.size()-numnodes], numnodes);
}
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
assert(node_size == nextNodeIdx);
/* Root index to start traversal at, to handle case of single leaf node. */
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
pack.root_index = (root->is_leaf())? -1: 0;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
void QBVH::refit_nodes()
{
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
assert(!params.top_level);
BoundBox bbox = BoundBox::empty;
uint visibility = 0;
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
refit_node(0, (pack.root_index == -1)? true: false, bbox, visibility);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
void QBVH::refit_node(int idx, bool leaf, BoundBox& bbox, uint& visibility)
{
if(leaf) {
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
int4 *data = &pack.leaf_nodes[idx];
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
int4 c = data[0];
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
/* Refit leaf node. */
for(int prim = c.x; prim < c.y; prim++) {
int pidx = pack.prim_index[prim];
int tob = pack.prim_object[prim];
Object *ob = objects[tob];
if(pidx == -1) {
/* Object instance. */
bbox.grow(ob->bounds);
}
else {
/* Primitives. */
const Mesh *mesh = ob->mesh;
if(pack.prim_type[prim] & PRIMITIVE_ALL_CURVE) {
/* Curves. */
int str_offset = (params.top_level)? mesh->curve_offset: 0;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
Mesh::Curve curve = mesh->get_curve(pidx - str_offset);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
int k = PRIMITIVE_UNPACK_SEGMENT(pack.prim_type[prim]);
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
curve.bounds_grow(k, &mesh->curve_keys[0], &mesh->curve_radius[0], bbox);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
visibility |= PATH_RAY_CURVE;
/* Motion curves. */
if(mesh->use_motion_blur) {
Attribute *attr = mesh->curve_attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
if(attr) {
size_t mesh_size = mesh->curve_keys.size();
size_t steps = mesh->motion_steps - 1;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
float3 *key_steps = attr->data_float3();
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
Cycles: Code cleanup, spaces around keywords This inconsistency drove me totally crazy, it's really confusing when it's inconsistent especially when you work on both Cycles and Blender sides. Shouldn;t cause merge PITA, it's whitespace changes only, Git should be able to merge it nicely.
2015-03-27 19:15:15 +00:00
for(size_t i = 0; i < steps; i++)
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
curve.bounds_grow(k, key_steps + i*mesh_size, &mesh->curve_radius[0], bbox);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
}
}
}
else {
/* Triangles. */
int tri_offset = (params.top_level)? mesh->tri_offset: 0;
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-07 22:09:08 +00:00
Mesh::Triangle triangle = mesh->get_triangle(pidx - tri_offset);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
const float3 *vpos = &mesh->verts[0];
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
triangle.bounds_grow(vpos, bbox);
/* Motion triangles. */
if(mesh->use_motion_blur) {
Attribute *attr = mesh->attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
if(attr) {
size_t mesh_size = mesh->verts.size();
size_t steps = mesh->motion_steps - 1;
float3 *vert_steps = attr->data_float3();
Cycles: Code cleanup, spaces around keywords This inconsistency drove me totally crazy, it's really confusing when it's inconsistent especially when you work on both Cycles and Blender sides. Shouldn;t cause merge PITA, it's whitespace changes only, Git should be able to merge it nicely.
2015-03-27 19:15:15 +00:00
for(size_t i = 0; i < steps; i++)
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
triangle.bounds_grow(vert_steps + i*mesh_size, bbox);
}
}
}
}
visibility |= ob->visibility;
}
/* TODO(sergey): This is actually a copy of pack_leaf(),
* but this chunk of code only knows actual data and has
* no idea about BVHNode.
*
* Would be nice to de-duplicate code, but trying to make
cleanup: style
2015-01-02 08:18:57 +00:00
* making code more general ends up in much nastier code
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
* in my opinion so far.
*
* Same applies to the inner nodes case below.
*/
Cycles: Split BVH nodes storage into inner and leaf nodes This way we can get rid of inefficient memory usage caused by BVH boundbox part being unused by leaf nodes but still being allocated for them. Doing such split allows to save 6 of float4 values for QBVH per leaf node and 3 of float4 values for regular BVH per leaf node. This translates into following memory save using 01.01.01.G rendered without hair: Device memory size Device memory peak Global memory peak Before the patch: 4957 5051 7668 With the patch: 4467 4562 7332 The measurements are done against current master. Still need to run speed tests and it's hard to predict if it's faster or not: on the one hand leaf nodes are now much more coherent in cache, on the other hand they're not so much coherent with regular nodes anymore. Reviewers: brecht, juicyfruit Subscribers: venomgfx, eyecandy Differential Revision: https://developer.blender.org/D1236
2015-04-13 18:05:09 +00:00
float4 leaf_data[BVH_QNODE_LEAF_SIZE];
leaf_data[0].x = __int_as_float(c.x);
leaf_data[0].y = __int_as_float(c.y);
leaf_data[0].z = __uint_as_float(visibility);
leaf_data[0].w = __uint_as_float(c.w);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
memcpy(&pack.leaf_nodes[idx], leaf_data, sizeof(float4)*BVH_QNODE_LEAF_SIZE);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
}
else {
Cycles: Switch node address to absolute values in BVH tree This seems to be straightforward way to support heterogeneous nodes in the same tree. There is some penalty related on 4gig limit of the address space now, but here's are the thing: Traversal code was already using ints to store final offset, so there can't be regressions really. This is a required commit to make it possible to encode both aligned and unaligned nodes in the same array. Also, in the future we can use this to get rid of __leaf_nodes array (which is a bit tricky to do since trickery in pack_instances().
2016-06-14 12:29:09 +00:00
int4 *data = &pack.nodes[idx];
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
bool is_unaligned = (data[0].x & PATH_RAY_NODE_UNALIGNED) != 0;
int4 c;
if(is_unaligned) {
c = data[13];
}
else {
c = data[7];
}
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
/* Refit inner node, set bbox from children. */
BoundBox child_bbox[4] = {BoundBox::empty,
BoundBox::empty,
BoundBox::empty,
BoundBox::empty};
uint child_visibility[4] = {0};
int num_nodes = 0;
for(int i = 0; i < 4; ++i) {
if(c[i] != 0) {
refit_node((c[i] < 0)? -c[i]-1: c[i], (c[i] < 0),
child_bbox[i], child_visibility[i]);
++num_nodes;
bbox.grow(child_bbox[i]);
visibility |= child_visibility[i];
}
}
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
if(is_unaligned) {
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
Transform aligned_space[4] = {transform_identity(),
transform_identity(),
transform_identity(),
transform_identity()};
pack_unaligned_node(idx,
aligned_space,
child_bbox,
&c[0],
visibility,
4);
Cycles: Implement unaligned nodes BVH builder This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.
2016-07-07 10:18:57 +00:00
}
else {
Cycles: Deduplicate QBVH node packing across BVH build and refit
2016-09-09 09:32:05 +00:00
pack_aligned_node(idx,
child_bbox,
&c[0],
visibility,
4);
Cycles: Implement refit_nodes for QBVH Title says it all, quite straightforward implementation. Would only mention that there's a bit of code duplication around packing node into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like functions with loads of arguments some of which could be NULL in certain circumstances etc..). Leaving solving this duplication for later.
2014-12-17 17:46:02 +00:00
}
}
}
CCL_NAMESPACE_END
Copy Permalink