griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
60bec183cbfa7ef9c713077347c518d697b65811
test/intern/cycles/blender/mesh.cpp

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

1298 lines
46 KiB
C++
Raw Normal View History

License headers: use SPDX-FileCopyrightText in intern/cycles
2023-06-14 16:52:36 +10:00
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
*
* SPDX-License-Identifier: Apache-2.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
Mesh: Move material indices to a generic attribute This patch moves material indices from the mesh `MPoly` struct to a generic integer attribute. The builtin material index was already exposed in geometry nodes, but this makes it a "proper" attribute accessible with Python and visible in the "Attributes" panel. The goals of the refactor are code simplification and memory and performance improvements, mainly because the attribute doesn't have to be stored and processed if there are no materials. However, until 4.0, material indices will still be read and written in the old format, meaning there may be a temporary increase in memory usage. Further notes: * Completely removing the `MPoly.mat_nr` after 4.0 may require changes to DNA or introducing a new `MPoly` type. * Geometry nodes regression tests didn't look at material indices, so the change reveals a bug in the realize instances node that I fixed. * Access to material indices from the RNA `MeshPolygon` type is slower with this patch. The `material_index` attribute can be used instead. * Cycles is changed to read from the attribute instead. * BMesh isn't changed in this patch. Theoretically it could be though, to save 2 bytes per face when less than two materials are used. * Eventually we could use a 16 bit integer attribute type instead. Ref T95967 Differential Revision: https://developer.blender.org/D15675
2022-08-31 09:09:01 -05:00
#include <optional>
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
#include "blender/attribute_convert.h"
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "blender/session.h"
#include "blender/sync.h"
#include "blender/util.h"
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
#include "scene/bake.h"
Cycles: changes to source code folders structure * Split render/ into scene/ and session/. The scene/ folder now contains the scene and its nodes. The session/ folder contains the render session and associated data structures like drivers and render buffers. * Move top level kernel headers into new folders kernel/camera/, kernel/film/, kernel/light/, kernel/sample/, kernel/util/ * Move integrator related kernel headers into kernel/integrator/ * Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/ For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "scene/camera.h"
#include "scene/mesh.h"
#include "scene/object.h"
#include "scene/scene.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
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "subd/split.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
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "util/algorithm.h"
#include "util/disjoint_set.h"
Refactor: Cycles: Replace foreach() by range based for loops Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 19:41:25 +01:00
Cycles: remove prefix from source code file names Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-24 14:19:19 +02:00
#include "util/hash.h"
#include "util/log.h"
#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
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
#include "mikktspace.hh"
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
#include "BKE_attribute.hh"
#include "BKE_attribute_math.hh"
Cleanup: Remove most indirect includes of BKE_customdata.hh Some common headers were including this. Separating the includes will ideally lead to better conceptual separation between CustomData and the attribute API too. Mostly the change is adding the file to places where it was included indirectly before. But some code is shuffled around to hopefully better places as well.
2023-12-26 23:21:19 -05:00
#include "BKE_customdata.hh"
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
#include "BKE_mesh.hh"
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05: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
CCL_NAMESPACE_BEGIN
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
/* Tangent Space */
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
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
template<bool is_subd> struct MikkMeshWrapper {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
MikkMeshWrapper(const ::Mesh &b_mesh,
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const char *layer_name,
const Mesh *mesh,
float3 *tangent,
float *tangent_sign)
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
: mesh(mesh), tangent(tangent), tangent_sign(tangent_sign)
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
{
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const AttributeSet &attributes = is_subd ? mesh->subd_attributes : mesh->attributes;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
Attribute *attr_vN = attributes.find(ATTR_STD_VERTEX_NORMAL);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
vertex_normal = attr_vN->data_float3();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (layer_name == nullptr) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
Attribute *attr_orco = attributes.find(ATTR_STD_GENERATED);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: add Vector Displacement node and extend Displacement node. This adds midlevel and object/world space for displacement, and a vector displacement node with tangent/object/world space, midlevel and scale. Note that tangent space vector displacement still is not exactly compatible with maps created by other software, this will require changes to the tangent computation. Differential Revision: https://developer.blender.org/D1734
2018-01-21 00:40:42 +01:00
if (attr_orco) {
orco = attr_orco->data_float3();
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
float3 orco_size;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mesh_texture_space(b_mesh, orco_loc, orco_size);
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
inv_orco_size = 1.0f / orco_size;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: add Vector Displacement node and extend Displacement node. This adds midlevel and object/world space for displacement, and a vector displacement node with tangent/object/world space, midlevel and scale. Note that tangent space vector displacement still is not exactly compatible with maps created by other software, this will require changes to the tangent computation. Differential Revision: https://developer.blender.org/D1734
2018-01-21 00:40:42 +01:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
else {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
Attribute *attr_uv = attributes.find(ustring(layer_name));
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (attr_uv != nullptr) {
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
uv = attr_uv->data_float2();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
int GetNumFaces()
{
if constexpr (is_subd) {
return mesh->get_num_subd_faces();
}
else {
return mesh->num_triangles();
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
int GetNumVerticesOfFace(const int face_num)
{
if constexpr (is_subd) {
return mesh->get_subd_num_corners()[face_num];
}
else {
return 3;
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
int CornerIndex(const int face_num, const int vert_num)
{
if constexpr (is_subd) {
const Mesh::SubdFace &face = mesh->get_subd_face(face_num);
return face.start_corner + vert_num;
}
else {
return face_num * 3 + vert_num;
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map. It's using the Ward BSDF currently, which has some energy loss so might be a bit dark. More/better BSDF options can be implemented later. Patch by Mike Farnsworth, some modifications by me. Currently it's not possible yet to set a custom tangent, that will follow as part of per-bsdf normals patch.
2012-10-10 13:02:20 +00:00
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
int VertexIndex(const int face_num, const int vert_num)
{
int corner = CornerIndex(face_num, vert_num);
if constexpr (is_subd) {
return mesh->get_subd_face_corners()[corner];
}
else {
return mesh->get_triangles()[corner];
}
Fix T41174: Tangent space required UV map in Cycles Now Cycles behaves in the same way as BI in terms of using sphere projection of orco coordinates if there's no UV map when calculating tangent space.
2014-07-29 16:07:05 +06:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
mikk::float3 GetPosition(const int face_num, const int vert_num)
{
const float3 vP = mesh->get_verts()[VertexIndex(face_num, vert_num)];
return mikk::float3(vP.x, vP.y, vP.z);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
mikk::float3 GetTexCoord(const int face_num, const int vert_num)
{
/* TODO: Check whether introducing a template boolean in order to
* turn this into a constexpr is worth it. */
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (uv != nullptr) {
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const int corner_index = CornerIndex(face_num, vert_num);
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
float2 tfuv = uv[corner_index];
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
return mikk::float3(tfuv.x, tfuv.y, 1.0f);
}
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
if (orco != nullptr) {
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const int vertex_index = VertexIndex(face_num, vert_num);
const float2 uv = map_to_sphere((orco[vertex_index] + orco_loc) * inv_orco_size);
return mikk::float3(uv.x, uv.y, 1.0f);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
return mikk::float3(0.0f, 0.0f, 1.0f);
Fix #35306: cycles normal mapping not working with flat shading.
2013-05-11 09:31:58 +00:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
mikk::float3 GetNormal(const int face_num, const int vert_num)
{
float3 vN;
if (is_subd) {
const Mesh::SubdFace &face = mesh->get_subd_face(face_num);
if (face.smooth) {
const int vertex_index = VertexIndex(face_num, vert_num);
vN = vertex_normal[vertex_index];
}
else {
vN = face.normal(mesh);
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
else {
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
if (mesh->get_smooth()[face_num]) {
const int vertex_index = VertexIndex(face_num, vert_num);
vN = vertex_normal[vertex_index];
}
else {
const Mesh::Triangle tri = mesh->get_triangle(face_num);
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
vN = tri.compute_normal(mesh->get_verts().data());
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
return mikk::float3(vN.x, vN.y, vN.z);
Fix #35306: cycles normal mapping not working with flat shading.
2013-05-11 09:31:58 +00:00
}
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
void SetTangentSpace(const int face_num, const int vert_num, mikk::float3 T, bool orientation)
{
const int corner_index = CornerIndex(face_num, vert_num);
tangent[corner_index] = make_float3(T.x, T.y, T.z);
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (tangent_sign != nullptr) {
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
tangent_sign[corner_index] = orientation ? 1.0f : -1.0f;
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const Mesh *mesh;
int num_faces;
float3 *vertex_normal;
float2 *texface;
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
float2 *uv = nullptr;
float3 *orco = nullptr;
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
float3 orco_loc, inv_orco_size;
float3 *tangent;
float *tangent_sign;
};
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
static void mikk_compute_tangents(
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ::Mesh &b_mesh, const char *layer_name, Mesh *mesh, bool need_sign, bool active_render)
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
{
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* Create tangent attributes. */
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
const bool is_subd = mesh->get_num_subd_faces();
AttributeSet &attributes = is_subd ? mesh->subd_attributes : mesh->attributes;
Cycles: 4 new nodes. * Tangent: generate a tangent direction for anisotropic shading. Can be either radial around X/Y/Z axis, or from a UV map. The default tangent for the anisotropic BSDF and geometry node is now always radial Z, for UV tangent use this node now. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Tangent * Normal Map: generate a perturbed normal from an RGB normal map image. This is usually chained with an Image Texture node in the color input, to specify the normal map image. For tangent space normal maps, the UV coordinates for the image must match, and the image texture should be set to Non-Color mode to give correct results. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Normal_Map * Refraction BSDF: for best results this node should be considered as a building block and not be used on its own, but rather mixed with a glossy node using a fresnel type factor. Otherwise it will give quite dark results at the edges for glossy refraction. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Refraction * Ambient Occlusion: controls the amount of AO a surface receives, rather than having just a global factor in the world. Note that this outputs a shader and not a color, that's for another time. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Ambient_Occlusion
2012-11-06 19:59:02 +00:00
Attribute *attr;
Fix T41174: Tangent space required UV map in Cycles Now Cycles behaves in the same way as BI in terms of using sphere projection of orco coordinates if there's no UV map when calculating tangent space.
2014-07-29 16:07:05 +06:00
ustring name;
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (layer_name != nullptr) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
name = ustring((string(layer_name) + ".tangent").c_str());
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
else {
Fix T41174: Tangent space required UV map in Cycles Now Cycles behaves in the same way as BI in terms of using sphere projection of orco coordinates if there's no UV map when calculating tangent space.
2014-07-29 16:07:05 +06:00
name = ustring("orco.tangent");
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
if (active_render) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
attr = attributes.add(ATTR_STD_UV_TANGENT, name);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
else {
Cleanup: Replace deprecated OIIO APIs with modern ones Noticed while helping validate the soon to be released OpenImageIO 3.x. This cleanup makes 2 sets of changes to accommodate removed APIs [1]: - Remove `ustringHash` since it's been defined as `std::hash<ustring>` for quite some time and is fully removed in 3.0. - Replace `TypeDesc::Type*` types with just `Type*` as the former has been removed in 3.0. Cycles was using a mix of the deprecated and modern forms anyhow. [1] https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/Deprecations-3.0.md Pull Request: https://projects.blender.org/blender/blender/pulls/129136
2024-10-17 19:48:38 +02:00
attr = attributes.add(name, TypeVector, ATTR_ELEMENT_CORNER);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
float3 *tangent = attr->data_float3();
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* Create bitangent sign attribute. */
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
float *tangent_sign = nullptr;
Cycles: 4 new nodes. * Tangent: generate a tangent direction for anisotropic shading. Can be either radial around X/Y/Z axis, or from a UV map. The default tangent for the anisotropic BSDF and geometry node is now always radial Z, for UV tangent use this node now. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Tangent * Normal Map: generate a perturbed normal from an RGB normal map image. This is usually chained with an Image Texture node in the color input, to specify the normal map image. For tangent space normal maps, the UV coordinates for the image must match, and the image texture should be set to Non-Color mode to give correct results. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Normal_Map * Refraction BSDF: for best results this node should be considered as a building block and not be used on its own, but rather mixed with a glossy node using a fresnel type factor. Otherwise it will give quite dark results at the edges for glossy refraction. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Refraction * Ambient Occlusion: controls the amount of AO a surface receives, rather than having just a global factor in the world. Note that this outputs a shader and not a color, that's for another time. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Ambient_Occlusion
2012-11-06 19:59:02 +00:00
if (need_sign) {
Attribute *attr_sign;
Fix T41174: Tangent space required UV map in Cycles Now Cycles behaves in the same way as BI in terms of using sphere projection of orco coordinates if there's no UV map when calculating tangent space.
2014-07-29 16:07:05 +06:00
ustring name_sign;
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (layer_name != nullptr) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
name_sign = ustring((string(layer_name) + ".tangent_sign").c_str());
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
else {
Fix T41174: Tangent space required UV map in Cycles Now Cycles behaves in the same way as BI in terms of using sphere projection of orco coordinates if there's no UV map when calculating tangent space.
2014-07-29 16:07:05 +06:00
name_sign = ustring("orco.tangent_sign");
Cycles: 4 new nodes. * Tangent: generate a tangent direction for anisotropic shading. Can be either radial around X/Y/Z axis, or from a UV map. The default tangent for the anisotropic BSDF and geometry node is now always radial Z, for UV tangent use this node now. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Tangent * Normal Map: generate a perturbed normal from an RGB normal map image. This is usually chained with an Image Texture node in the color input, to specify the normal map image. For tangent space normal maps, the UV coordinates for the image must match, and the image texture should be set to Non-Color mode to give correct results. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Normal_Map * Refraction BSDF: for best results this node should be considered as a building block and not be used on its own, but rather mixed with a glossy node using a fresnel type factor. Otherwise it will give quite dark results at the edges for glossy refraction. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Refraction * Ambient Occlusion: controls the amount of AO a surface receives, rather than having just a global factor in the world. Note that this outputs a shader and not a color, that's for another time. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Ambient_Occlusion
2012-11-06 19:59:02 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
if (active_render) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
attr_sign = attributes.add(ATTR_STD_UV_TANGENT_SIGN, name_sign);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
else {
Cleanup: Replace deprecated OIIO APIs with modern ones Noticed while helping validate the soon to be released OpenImageIO 3.x. This cleanup makes 2 sets of changes to accommodate removed APIs [1]: - Remove `ustringHash` since it's been defined as `std::hash<ustring>` for quite some time and is fully removed in 3.0. - Replace `TypeDesc::Type*` types with just `Type*` as the former has been removed in 3.0. Cycles was using a mix of the deprecated and modern forms anyhow. [1] https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/Deprecations-3.0.md Pull Request: https://projects.blender.org/blender/blender/pulls/129136
2024-10-17 19:48:38 +02:00
attr_sign = attributes.add(name_sign, TypeFloat, ATTR_ELEMENT_CORNER);
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
tangent_sign = attr_sign->data_float();
Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map. It's using the Ward BSDF currently, which has some energy loss so might be a bit dark. More/better BSDF options can be implemented later. Patch by Mike Farnsworth, some modifications by me. Currently it's not possible yet to set a custom tangent, that will follow as part of per-bsdf normals patch.
2012-10-10 13:02:20 +00:00
}
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* Setup userdata. */
Mikktspace: Optimized port to C++ This commit is a big overhaul to the Mikktspace module, which is used to compute tangents. I'm not calling it a rewrite since it's the result of a lot of iterations on the original code, but pretty much everything is reworked somehow. Overall goal was to a) make it faster and b) make it maintainable. Notable changes: - Since the callbacks for requesting geometry data were a big bottleneck before, I've ported it to C++ and made it header-only, templating on the data source. That way, the compiler generates code specific to the caller, which allows it to inline the data source and specialize for some cases (e.g. subd vs. non-subd in Cycles). - The one input parameter, an optional angle threshold, was not used anywhere. Turns out that removing it allows for considerable algorithmic simplification, removing a lot of the complexity in the later stages. Therefore, I've just removed the option in the new code. - The code computes several outputs, but only one (the tangent itself) is ever used in Blender. Therefore, I've removed the others to simplify the code. They could easily be brought back if needed, none of the algorithmic simplifications are conflicting with them. - The original code had fallback paths for many steps in case temporary memory allocation fails, but that never actually gets used anyways since malloc() doesn't really ever return NULL in practise, so I removed them. - In general, I've restructured A LOT of the code to make the algorithms clearer and make use of some C++ features (vectors, std::array, booleans, classes), though there's still some of cleanup that could be done. - Parallelized duplicate detection, neighbor detection, triangle tangent computation, degenerate triangle handling and tangent space accumulation. - Replaced several algorithms with faster equivalents: Duplicate detection uses a (concurrent) hash set now, neighbor detection uses Radixsort and splits vertices by index pairs etc. As for results, the exact speedup depends on the scene of course, but let's consider the file from T97378: - Blender 3.1 (before D14675): 6.07sec - Blender 3.2 (with D14675): 4.62sec - rBf0a36599007d (last nightly build): 4.42sec - With this commit: 0.90sec This speedup will mostly be noticed at the start of Cycles renders and, even more importantly, in Eevee when doing something that changes the geometry (e.g. animating) on a model using normal maps. Differential Revision: https://developer.blender.org/D15589
2022-09-03 17:21:44 +02:00
if (is_subd) {
MikkMeshWrapper<true> userdata(b_mesh, layer_name, mesh, tangent, tangent_sign);
/* Compute tangents. */
mikk::Mikktspace(userdata).genTangSpace();
}
else {
MikkMeshWrapper<false> userdata(b_mesh, layer_name, mesh, tangent, tangent_sign);
/* Compute tangents. */
mikk::Mikktspace(userdata).genTangSpace();
}
Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map. It's using the Ward BSDF currently, which has some energy loss so might be a bit dark. More/better BSDF options can be implemented later. Patch by Mike Farnsworth, some modifications by me. Currently it's not possible yet to set a custom tangent, that will follow as part of per-bsdf normals patch.
2012-10-10 13:02:20 +00:00
}
Fix #116792: Cycles render issue velocity attribute and motion steps > 1 In this case the object transform can use more motion steps, but the geometry needs to have its motion steps fixed since the velocity attribute completely overrides them.
2024-01-10 18:45:15 +01:00
static void attr_create_motion_from_velocity(Mesh *mesh,
const blender::Span<blender::float3> b_attr,
const float motion_scale)
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
{
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
const int numverts = mesh->get_verts().size();
Fix #116792: Cycles render issue velocity attribute and motion steps > 1 In this case the object transform can use more motion steps, but the geometry needs to have its motion steps fixed since the velocity attribute completely overrides them.
2024-01-10 18:45:15 +01:00
/* Override motion steps to fixed number. */
mesh->set_motion_steps(3);
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
/* Find or add attribute */
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
float3 *P = mesh->get_verts().data();
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
Attribute *attr_mP = mesh->attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
if (!attr_mP) {
attr_mP = mesh->attributes.add(ATTR_STD_MOTION_VERTEX_POSITION);
}
/* Only export previous and next frame, we don't have any in between data. */
float motion_times[2] = {-1.0f, 1.0f};
for (int step = 0; step < 2; step++) {
const float relative_time = motion_times[step] * 0.5f * motion_scale;
float3 *mP = attr_mP->data_float3() + step * numverts;
for (int i = 0; i < numverts; i++) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mP[i] = P[i] + make_float3(b_attr[i][0], b_attr[i][1], b_attr[i][2]) * relative_time;
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
}
}
}
static void attr_create_generic(Scene *scene,
Mesh *mesh,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ::Mesh &b_mesh,
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
const bool subdivision,
const bool need_motion,
const float motion_scale)
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
{
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
blender::Span<blender::int3> corner_tris;
blender::Span<int> tri_faces;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!subdivision) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
corner_tris = b_mesh.corner_tris();
tri_faces = b_mesh.corner_tri_faces();
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
const blender::bke::AttributeAccessor b_attributes = b_mesh.attributes();
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
AttributeSet &attributes = (subdivision) ? mesh->subd_attributes : mesh->attributes;
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
static const ustring u_velocity("velocity");
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ustring default_color_name{BKE_id_attributes_default_color_name(&b_mesh.id)};
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
b_attributes.foreach_attribute([&](const blender::bke::AttributeIter &iter) {
const ustring name{std::string_view(iter.name)};
Fix T103143: Cycles can lose default color attribute The `render_color_index` skips attributes with different types and domains in order to give the proper order for the UI list. That is a different than an index in the group of all attributes. The most solid solution I could think of is exposing the name of the default color attribute. It's "solid" because we always address attributes by name internally. Doing something different is bound to create problems. It's also aligned with the design in T98366 and D15169. Another option would be to change the way the "attribute index" is incremented in Cycles. That would be a valid solution, but would be more complex and annoying. For consistency, I also exposed the name of the active color attribute the same way, though it isn't necessary to fix this particular bug. The properties aren't editable, that can come in 3.5 as part of D15169. Differential Revision: https://developer.blender.org/D16769
2022-12-14 11:11:37 -06:00
const bool is_render_color = name == default_color_name;
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
if (need_motion && name == u_velocity) {
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
const blender::VArraySpan b_attribute = *iter.get<blender::float3>(
blender::bke::AttrDomain::Point);
Fix #116792: Cycles render issue velocity attribute and motion steps > 1 In this case the object transform can use more motion steps, but the geometry needs to have its motion steps fixed since the velocity attribute completely overrides them.
2024-01-10 18:45:15 +01:00
attr_create_motion_from_velocity(mesh, b_attribute, motion_scale);
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
}
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
if (!(mesh->need_attribute(scene, name) ||
(is_render_color && mesh->need_attribute(scene, ATTR_STD_VERTEX_COLOR))))
{
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
return;
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
}
if (attributes.find(name)) {
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
return;
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
}
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
blender::bke::AttrDomain b_domain = iter.domain;
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
if (b_domain == blender::bke::AttrDomain::Edge) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
/* Blender's attribute API handles edge to vertex attribute domain interpolation. */
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
b_domain = blender::bke::AttrDomain::Point;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
const blender::bke::GAttributeReader b_attr = iter.get(b_domain);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (b_attr.varray.is_empty()) {
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
return;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
if (b_attr.domain == blender::bke::AttrDomain::Corner && iter.data_type == CD_PROP_BYTE_COLOR)
Clang Format: bump to version 17 Along with the 4.1 libraries upgrade, we are bumping the clang-format version from 8-12 to 17. This affects quite a few files. If not already the case, you may consider pointing your IDE to the clang-format binary bundled with the Blender precompiled libraries.
2024-01-02 18:12:54 +01:00
{
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
Attribute *attr = attributes.add(name, TypeRGBA, ATTR_ELEMENT_CORNER_BYTE);
if (is_render_color) {
attr->std = ATTR_STD_VERTEX_COLOR;
}
uchar4 *data = attr->data_uchar4();
const blender::VArraySpan src = b_attr.varray.typed<blender::ColorGeometry4b>();
if (subdivision) {
for (const int i : src.index_range()) {
data[i] = make_uchar4(src[i][0], src[i][1], src[i][2], src[i][3]);
}
}
else {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
for (const int i : corner_tris.index_range()) {
const blender::int3 &tri = corner_tris[i];
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
data[i * 3 + 0] = make_uchar4(
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
src[tri[0]][0], src[tri[0]][1], src[tri[0]][2], src[tri[0]][3]);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
data[i * 3 + 1] = make_uchar4(
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
src[tri[1]][0], src[tri[1]][1], src[tri[1]][2], src[tri[1]][3]);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
data[i * 3 + 2] = make_uchar4(
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
src[tri[2]][0], src[tri[2]][1], src[tri[2]][2], src[tri[2]][3]);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
}
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
return;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
AttributeElement element = ATTR_ELEMENT_NONE;
switch (b_domain) {
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Corner:
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
element = ATTR_ELEMENT_CORNER;
break;
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Point:
Fix part of T97895: Cycles not rendering edge domain attributes These aren't really ideal for rendering, but better to show something. Edge values are averaged at vertices.
2022-05-10 18:12:17 +02:00
element = ATTR_ELEMENT_VERTEX;
break;
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Face:
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
element = ATTR_ELEMENT_FACE;
break;
default:
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
assert(false);
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
return;
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
}
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
blender::bke::attribute_math::convert_to_static_type(b_attr.varray.type(), [&](auto dummy) {
using BlenderT = decltype(dummy);
using Converter = typename ccl::AttributeConverter<BlenderT>;
using CyclesT = typename Converter::CyclesT;
if constexpr (!std::is_void_v<CyclesT>) {
Attribute *attr = attributes.add(name, Converter::type_desc, element);
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
if (is_render_color) {
attr->std = ATTR_STD_VERTEX_COLOR;
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
CyclesT *data = reinterpret_cast<CyclesT *>(attr->data());
const blender::VArraySpan src = b_attr.varray.typed<BlenderT>();
switch (b_attr.domain) {
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Corner: {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (subdivision) {
for (const int i : src.index_range()) {
data[i] = Converter::convert(src[i]);
}
}
else {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
for (const int i : corner_tris.index_range()) {
const blender::int3 &tri = corner_tris[i];
data[i * 3 + 0] = Converter::convert(src[tri[0]]);
data[i * 3 + 1] = Converter::convert(src[tri[1]]);
data[i * 3 + 2] = Converter::convert(src[tri[2]]);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
}
break;
}
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Point: {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : src.index_range()) {
data[i] = Converter::convert(src[i]);
}
break;
}
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
case blender::bke::AttrDomain::Face: {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (subdivision) {
for (const int i : src.index_range()) {
data[i] = Converter::convert(src[i]);
}
}
else {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
for (const int i : corner_tris.index_range()) {
data[i] = Converter::convert(src[tri_faces[i]]);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
}
}
break;
}
default: {
assert(false);
break;
}
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
}
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
});
});
}
Fix Cycles not rendering byte precision vertex domain colors Code was not yet updated to use generic attributes for vertex colors. This also makes generic attributes work for adaptive subdivision.
2022-05-27 15:45:29 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
static set<ustring> get_blender_uv_names(const ::Mesh &b_mesh)
{
set<ustring> uv_names;
Attributes: improve API to iterate over attributes This improve the API in multiple aspects: * No need for an additional `lookup` call to get the current attribute. This would internally iterate over all attributes again. This leads to O(n^2) behavior. Note that there are still other reasons for O(n^2) behavior when processing attributes (where n is the number of attributes). * Remove the need to return a value from the iteration code to indicate that the iteration should continue. This is now the default behavior. The iteration can still be stopped by calling `iter.stop()`. * Easier access to `is_builtin` property. * Iterator callback only has a single parameter instead of two (of which one is sometimes unused). Pull Request: https://projects.blender.org/blender/blender/pulls/128128
2024-09-26 12:59:00 +02:00
b_mesh.attributes().foreach_attribute([&](const blender::bke::AttributeIter &iter) {
if (iter.domain == blender::bke::AttrDomain::Corner && iter.data_type == CD_PROP_FLOAT2) {
if (!blender::bke::attribute_name_is_anonymous(iter.name)) {
uv_names.emplace(std::string_view(iter.name));
}
}
});
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
return uv_names;
Cycles: support accessing custom mesh attributes This makes custom mesh attributes available in Cycles. Typically, these attributes are generated by Geometry Nodes, but they can also be created with a Python script. * The `subdivision` code path is not yet supported. * This does not make vertex weights and some other builtin attributes available in Cycles, even though they are accesible in Geometry Nodes. All attributes generated in Geometry Nodes should be accessible though. * In some cases memory consumption could be removed by not storing all attributes in floats. E.g. booleans and integer attributes for which all values are within a certain range, could be stored in less than 4 bytes per element. Differential Revision: https://developer.blender.org/D10210
2021-02-17 12:07:59 +01:00
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
/* Create uv map attributes. */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
static void attr_create_uv_map(Scene *scene,
Mesh *mesh,
const ::Mesh &b_mesh,
const set<ustring> &blender_uv_names)
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
{
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const blender::Span<blender::int3> corner_tris = b_mesh.corner_tris();
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::bke::AttributeAccessor b_attributes = b_mesh.attributes();
Cleanup: Rename Mesh loop_data to corner_data Related to #110434, efbee2d606ac4bccca13, 7c69c8827b6552950717
2023-12-19 20:38:59 -05:00
const ustring render_name(CustomData_get_render_layer_name(&b_mesh.corner_data, CD_PROP_FLOAT2));
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!blender_uv_names.empty()) {
for (const ustring &uv_name : blender_uv_names) {
const bool active_render = uv_name == render_name;
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
AttributeStandard uv_std = (active_render) ? ATTR_STD_UV : ATTR_STD_NONE;
AttributeStandard tangent_std = (active_render) ? ATTR_STD_UV_TANGENT : ATTR_STD_NONE;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
ustring tangent_name = ustring((string(uv_name) + ".tangent").c_str());
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* Denotes whether UV map was requested directly. */
const bool need_uv = mesh->need_attribute(scene, uv_name) ||
mesh->need_attribute(scene, uv_std);
/* Denotes whether tangent was requested directly. */
const bool need_tangent = mesh->need_attribute(scene, tangent_name) ||
(active_render && mesh->need_attribute(scene, tangent_std));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
/* UV map */
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* NOTE: We create temporary UV layer if its needed for tangent but
* wasn't requested by other nodes in shaders.
*/
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
Attribute *uv_attr = nullptr;
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
if (need_uv || need_tangent) {
if (active_render) {
uv_attr = mesh->attributes.add(uv_std, uv_name);
}
else {
uv_attr = mesh->attributes.add(uv_name, TypeFloat2, ATTR_ELEMENT_CORNER);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::VArraySpan b_uv_map = *b_attributes.lookup<blender::float2>(
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
uv_name.c_str(), blender::bke::AttrDomain::Corner);
Cycles: Added Float2 attribute type. Float2 are now a new type for attributes in Cycles. Before, the choices for attribute storage were float and float3, the latter padded to float4. This meant that UV maps were inflated to twice the size necessary. Reviewers: brecht, sergey Reviewed By: brecht Subscribers: #cycles Tags: #cycles Differential Revision: https://developer.blender.org/D4409
2019-03-05 14:54:54 +01:00
float2 *fdata = uv_attr->data_float2();
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
for (const int i : corner_tris.index_range()) {
const blender::int3 &tri = corner_tris[i];
fdata[i * 3 + 0] = make_float2(b_uv_map[tri[0]][0], b_uv_map[tri[0]][1]);
fdata[i * 3 + 1] = make_float2(b_uv_map[tri[1]][0], b_uv_map[tri[1]][1]);
fdata[i * 3 + 2] = make_float2(b_uv_map[tri[2]][0], b_uv_map[tri[2]][1]);
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
/* UV tangent */
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
if (need_tangent) {
AttributeStandard sign_std = (active_render) ? ATTR_STD_UV_TANGENT_SIGN : ATTR_STD_NONE;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
ustring sign_name = ustring((string(uv_name) + ".tangent_sign").c_str());
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
bool need_sign = (mesh->need_attribute(scene, sign_name) ||
mesh->need_attribute(scene, sign_std));
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mikk_compute_tangents(b_mesh, uv_name.c_str(), mesh, need_sign, active_render);
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
/* Remove temporarily created UV attribute. */
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (!need_uv && uv_attr != nullptr) {
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
mesh->attributes.remove(uv_attr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
else if (mesh->need_attribute(scene, ATTR_STD_UV_TANGENT)) {
bool need_sign = mesh->need_attribute(scene, ATTR_STD_UV_TANGENT_SIGN);
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
mikk_compute_tangents(b_mesh, nullptr, mesh, need_sign, true);
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
if (!mesh->need_attribute(scene, ATTR_STD_GENERATED)) {
mesh->attributes.remove(ATTR_STD_GENERATED);
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
static void attr_create_subd_uv_map(Scene *scene,
Mesh *mesh,
const ::Mesh &b_mesh,
bool subdivide_uvs,
const set<ustring> &blender_uv_names)
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
{
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::OffsetIndices faces = b_mesh.faces();
if (faces.is_empty()) {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
return;
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!blender_uv_names.empty()) {
const blender::bke::AttributeAccessor b_attributes = b_mesh.attributes();
Cleanup: Rename Mesh loop_data to corner_data Related to #110434, efbee2d606ac4bccca13, 7c69c8827b6552950717
2023-12-19 20:38:59 -05:00
const ustring render_name(
CustomData_get_render_layer_name(&b_mesh.corner_data, CD_PROP_FLOAT2));
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const ustring &uv_name : blender_uv_names) {
const bool active_render = uv_name == render_name;
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
AttributeStandard uv_std = (active_render) ? ATTR_STD_UV : ATTR_STD_NONE;
AttributeStandard tangent_std = (active_render) ? ATTR_STD_UV_TANGENT : ATTR_STD_NONE;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
ustring tangent_name = ustring((string(uv_name) + ".tangent").c_str());
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
/* Denotes whether UV map was requested directly. */
const bool need_uv = mesh->need_attribute(scene, uv_name) ||
mesh->need_attribute(scene, uv_std);
/* Denotes whether tangent was requested directly. */
const bool need_tangent = mesh->need_attribute(scene, tangent_name) ||
(active_render && mesh->need_attribute(scene, tangent_std));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
Attribute *uv_attr = nullptr;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
/* UV map */
if (need_uv || need_tangent) {
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
if (active_render) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
uv_attr = mesh->subd_attributes.add(uv_std, uv_name);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
else {
Fix Cycles bug rendering with multiple UV maps after recent changes.
2019-03-05 18:39:55 +01:00
uv_attr = mesh->subd_attributes.add(uv_name, TypeFloat2, ATTR_ELEMENT_CORNER);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
if (subdivide_uvs) {
uv_attr->flags |= ATTR_SUBDIVIDED;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::VArraySpan b_uv_map = *b_attributes.lookup<blender::float2>(
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
uv_name.c_str(), blender::bke::AttrDomain::Corner);
Cycles: Added Float2 attribute type. Float2 are now a new type for attributes in Cycles. Before, the choices for attribute storage were float and float3, the latter padded to float4. This meant that UV maps were inflated to twice the size necessary. Reviewers: brecht, sergey Reviewed By: brecht Subscribers: #cycles Tags: #cycles Differential Revision: https://developer.blender.org/D4409
2019-03-05 14:54:54 +01:00
float2 *fdata = uv_attr->data_float2();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : faces.index_range()) {
const blender::IndexRange face = faces[i];
for (const int corner : face) {
*(fdata++) = make_float2(b_uv_map[corner][0], b_uv_map[corner][1]);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
/* UV tangent */
if (need_tangent) {
AttributeStandard sign_std = (active_render) ? ATTR_STD_UV_TANGENT_SIGN : ATTR_STD_NONE;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
ustring sign_name = ustring((string(uv_name) + ".tangent_sign").c_str());
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
bool need_sign = (mesh->need_attribute(scene, sign_name) ||
mesh->need_attribute(scene, sign_std));
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mikk_compute_tangents(b_mesh, uv_name.c_str(), mesh, need_sign, active_render);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
/* Remove temporarily created UV attribute. */
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (!need_uv && uv_attr != nullptr) {
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
mesh->subd_attributes.remove(uv_attr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
}
else if (mesh->need_attribute(scene, ATTR_STD_UV_TANGENT)) {
bool need_sign = mesh->need_attribute(scene, ATTR_STD_UV_TANGENT_SIGN);
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
mikk_compute_tangents(b_mesh, nullptr, mesh, need_sign, true);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
if (!mesh->need_attribute(scene, ATTR_STD_GENERATED)) {
mesh->subd_attributes.remove(ATTR_STD_GENERATED);
}
}
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
/* Create vertex pointiness attributes. */
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
/* Compare vertices by sum of their coordinates. */
class VertexAverageComparator {
public:
Clang-Format: Allow empty functions to be single-line For example ``` OIIOOutputDriver::~OIIOOutputDriver() { } ``` becomes ``` OIIOOutputDriver::~OIIOOutputDriver() {} ``` Saves quite some vertical space, which is especially handy for constructors. Pull Request: https://projects.blender.org/blender/blender/pulls/105594
2023-03-29 16:50:54 +02:00
VertexAverageComparator(const array<float3> &verts) : verts_(verts) {}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
bool operator()(const int &vert_idx_a, const int &vert_idx_b)
{
const float3 &vert_a = verts_[vert_idx_a];
const float3 &vert_b = verts_[vert_idx_b];
if (vert_a == vert_b) {
/* Special case for doubles, so we ensure ordering. */
return vert_idx_a > vert_idx_b;
}
const float x1 = vert_a.x + vert_a.y + vert_a.z;
const float x2 = vert_b.x + vert_b.y + vert_b.z;
return x1 < x2;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
protected:
const array<float3> &verts_;
};
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
static void attr_create_pointiness(Mesh *mesh,
const blender::Span<blender::float3> positions,
const blender::Span<blender::float3> b_vert_normals,
const blender::Span<blender::int2> edges,
bool subdivision)
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
{
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const int num_verts = positions.size();
if (positions.is_empty()) {
Cycles: Fix access of NULL pointer as array Was confusing guarded allocator for some reason.
2017-04-07 15:07:25 +02:00
return;
}
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
/* STEP 1: Find out duplicated vertices and point duplicates to a single
* original vertex.
*/
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
vector<int> sorted_vert_indeices(num_verts);
Cycles: Cleanup, style
2017-02-15 20:33:49 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
sorted_vert_indeices[vert_index] = vert_index;
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
VertexAverageComparator compare(mesh->get_verts());
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
sort(sorted_vert_indeices.begin(), sorted_vert_indeices.end(), compare);
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
/* This array stores index of the original vertex for the given vertex
* index.
*/
vector<int> vert_orig_index(num_verts);
Cycles: Cleanup, style
2017-02-15 20:33:49 +01:00
for (int sorted_vert_index = 0; sorted_vert_index < num_verts; ++sorted_vert_index) {
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
const int vert_index = sorted_vert_indeices[sorted_vert_index];
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
const float3 &vert_co = mesh->get_verts()[vert_index];
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
bool found = false;
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
for (int other_sorted_vert_index = sorted_vert_index + 1; other_sorted_vert_index < num_verts;
++other_sorted_vert_index)
{
const int other_vert_index = sorted_vert_indeices[other_sorted_vert_index];
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
const float3 &other_vert_co = mesh->get_verts()[other_vert_index];
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
/* We are too far away now, we wouldn't have duplicate. */
Cycles: Cleanup, extra semicolon and space
2017-03-10 15:34:54 +01:00
if ((other_vert_co.x + other_vert_co.y + other_vert_co.z) -
(vert_co.x + vert_co.y + vert_co.z) >
3 * FLT_EPSILON)
{
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
break;
}
/* Found duplicate. */
Cycles: Fix wrong pointiness caused by precision issues
2017-02-15 12:39:06 +01:00
if (len_squared(other_vert_co - vert_co) < FLT_EPSILON) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
found = true;
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
vert_orig_index[vert_index] = other_vert_index;
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
}
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
if (!found) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
vert_orig_index[vert_index] = vert_index;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
}
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
/* Make sure we always points to the very first orig vertex. */
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
int orig_index = vert_orig_index[vert_index];
while (orig_index != vert_orig_index[orig_index]) {
orig_index = vert_orig_index[orig_index];
}
vert_orig_index[vert_index] = orig_index;
}
sorted_vert_indeices.free_memory();
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
/* STEP 2: Calculate vertex normals taking into account their possible
* duplicates which gets "welded" together.
*/
Cycles: add utility functions for zero float2/float3/float4/transform Ref D8237, T78710
2021-02-17 01:47:18 +01:00
vector<float3> vert_normal(num_verts, zero_float3());
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
/* First we accumulate all vertex normals in the original index. */
Cycles: Use Cycles-side mesh instead of C++ RNA Those are now matching and it's faster to skip C++ RNA to calculate pointiness.
2017-02-13 10:40:05 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
const float *b_vert_normal = b_vert_normals[vert_index];
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
const int orig_index = vert_orig_index[vert_index];
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
vert_normal[orig_index] += make_float3(b_vert_normal[0], b_vert_normal[1], b_vert_normal[2]);
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
}
/* Then we normalize the accumulated result and flush it to all duplicates
* as well.
*/
Cycles: Use Cycles-side mesh instead of C++ RNA Those are now matching and it's faster to skip C++ RNA to calculate pointiness.
2017-02-13 10:40:05 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
const int orig_index = vert_orig_index[vert_index];
vert_normal[vert_index] = normalize(vert_normal[orig_index]);
}
/* STEP 3: Calculate pointiness using single ring neighborhood. */
vector<int> counter(num_verts, 0);
vector<float> raw_data(num_verts, 0.0f);
Cycles: add utility functions for zero float2/float3/float4/transform Ref D8237, T78710
2021-02-17 01:47:18 +01:00
vector<float3> edge_accum(num_verts, zero_float3());
Cycles: Make an utility class for edge map Simplifies some logic.
2017-02-10 13:31:59 +01:00
EdgeMap visited_edges;
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
memset(counter.data(), 0, sizeof(int) * counter.size());
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : edges.index_range()) {
const blender::int2 b_edge = edges[i];
Mesh: Move edges to a generic attribute Implements #95966, as the final step of #95965. This commit changes the storage of mesh edge vertex indices from the `MEdge` type to the generic `int2` attribute type. This follows the general design for geometry and the attribute system, where the data storage type and the usage semantics are separated. The main benefit of the change is reduced memory usage-- the requirements of storing mesh edges is reduced by 1/3. For example, this saves 8MB on a 1 million vertex grid. This also gives performance benefits to any memory-bound mesh processing algorithm that uses edges. Another benefit is that all of the edge's vertex indices are contiguous. In a few cases, it's helpful to process all of them as `Span<int>` rather than `Span<int2>`. Similarly, the type is more likely to match a generic format used by a library, or code that shouldn't know about specific Blender `Mesh` types. Various Notes: - The `.edge_verts` name is used to reflect a mapping between domains, similar to `.corner_verts`, etc. The period means that it the data shouldn't change arbitrarily by the user or procedural operations. - `edge[0]` is now used instead of `edge.v1` - Signed integers are used instead of unsigned to reduce the mixing of signed-ness, which can be error prone. - All of the previously used core mesh data types (`MVert`, `MEdge`, `MLoop`, `MPoly` are now deprecated. Only generic types are used). - The `vec2i` DNA type is used in the few C files where necessary. Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
const int v0 = vert_orig_index[b_edge[0]];
const int v1 = vert_orig_index[b_edge[1]];
Cycles: Make an utility class for edge map Simplifies some logic.
2017-02-10 13:31:59 +01:00
if (visited_edges.exists(v0, v1)) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
continue;
}
Cycles: Make an utility class for edge map Simplifies some logic.
2017-02-10 13:31:59 +01:00
visited_edges.insert(v0, v1);
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
float3 co0 = make_float3(positions[v0][0], positions[v0][1], positions[v0][2]);
float3 co1 = make_float3(positions[v1][0], positions[v1][1], positions[v1][2]);
Cycles: Cleanup: Use less indentation by inverting condition
2017-02-10 10:10:06 +01:00
float3 edge = normalize(co1 - co0);
edge_accum[v0] += edge;
edge_accum[v1] += -edge;
++counter[v0];
++counter[v1];
}
Cycles: Use Cycles-side mesh instead of C++ RNA Those are now matching and it's faster to skip C++ RNA to calculate pointiness.
2017-02-13 10:40:05 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
const int orig_index = vert_orig_index[vert_index];
if (orig_index != vert_index) {
/* Skip duplicates, they'll be overwritten later on. */
continue;
}
if (counter[vert_index] > 0) {
const float3 normal = vert_normal[vert_index];
const float angle = safe_acosf(dot(normal, edge_accum[vert_index] / counter[vert_index]));
raw_data[vert_index] = angle * M_1_PI_F;
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
Cycles: Cleanup: Use less indentation by inverting condition
2017-02-10 10:10:06 +01:00
else {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
raw_data[vert_index] = 0.0f;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
/* STEP 3: Blur vertices to approximate 2 ring neighborhood. */
Fix T50655: Pointiness is too slow to calculate Optimize vertex de-duplication the same way as we do doe Remove Doubles.
2017-02-13 12:00:10 +01:00
AttributeSet &attributes = (subdivision) ? mesh->subd_attributes : mesh->attributes;
Attribute *attr = attributes.add(ATTR_STD_POINTINESS);
float *data = attr->data_float();
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
memcpy(data, raw_data.data(), sizeof(float) * raw_data.size());
memset(counter.data(), 0, sizeof(int) * counter.size());
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
visited_edges.clear();
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : edges.index_range()) {
const blender::int2 b_edge = edges[i];
Mesh: Move edges to a generic attribute Implements #95966, as the final step of #95965. This commit changes the storage of mesh edge vertex indices from the `MEdge` type to the generic `int2` attribute type. This follows the general design for geometry and the attribute system, where the data storage type and the usage semantics are separated. The main benefit of the change is reduced memory usage-- the requirements of storing mesh edges is reduced by 1/3. For example, this saves 8MB on a 1 million vertex grid. This also gives performance benefits to any memory-bound mesh processing algorithm that uses edges. Another benefit is that all of the edge's vertex indices are contiguous. In a few cases, it's helpful to process all of them as `Span<int>` rather than `Span<int2>`. Similarly, the type is more likely to match a generic format used by a library, or code that shouldn't know about specific Blender `Mesh` types. Various Notes: - The `.edge_verts` name is used to reflect a mapping between domains, similar to `.corner_verts`, etc. The period means that it the data shouldn't change arbitrarily by the user or procedural operations. - `edge[0]` is now used instead of `edge.v1` - Signed integers are used instead of unsigned to reduce the mixing of signed-ness, which can be error prone. - All of the previously used core mesh data types (`MVert`, `MEdge`, `MLoop`, `MPoly` are now deprecated. Only generic types are used). - The `vec2i` DNA type is used in the few C files where necessary. Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
const int v0 = vert_orig_index[b_edge[0]];
const int v1 = vert_orig_index[b_edge[1]];
Cycles: Make an utility class for edge map Simplifies some logic.
2017-02-10 13:31:59 +01:00
if (visited_edges.exists(v0, v1)) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
continue;
}
Cycles: Make an utility class for edge map Simplifies some logic.
2017-02-10 13:31:59 +01:00
visited_edges.insert(v0, v1);
Cycles: Cleanup: Use less indentation by inverting condition
2017-02-10 10:10:06 +01:00
data[v0] += raw_data[v1];
data[v1] += raw_data[v0];
++counter[v0];
++counter[v1];
}
Cycles: Use Cycles-side mesh instead of C++ RNA Those are now matching and it's faster to skip C++ RNA to calculate pointiness.
2017-02-13 10:40:05 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
data[vert_index] /= counter[vert_index] + 1;
}
/* STEP 4: Copy attribute to the duplicated vertices. */
Cycles: Use Cycles-side mesh instead of C++ RNA Those are now matching and it's faster to skip C++ RNA to calculate pointiness.
2017-02-13 10:40:05 +01:00
for (int vert_index = 0; vert_index < num_verts; ++vert_index) {
Cycles: Fix pointiness attribute giving wrong results with autosplit Basically made the algorithm to handle vertices with the same coordinate as a single vertex.
2017-02-10 13:23:40 +01:00
const int orig_index = vert_orig_index[vert_index];
data[vert_index] = data[orig_index];
Cycles: Cleanup: Use less indentation by inverting condition
2017-02-10 10:10:06 +01:00
}
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
}
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
/* The Random Per Island attribute is a random float associated with each
* connected component (island) of the mesh. The attribute is computed by
* first classifying the vertices into different sets using a Disjoint Set
* data structure. Then the index of the root of each vertex (Which is the
* representative of the set the vertex belongs to) is hashed and stored.
*
* We are using a face attribute to avoid interpolation during rendering,
* allowing the user to safely hash the output further. Had we used vertex
* attribute, the interpolation will introduce very slight variations,
* making the output unsafe to hash. */
static void attr_create_random_per_island(Scene *scene,
Mesh *mesh,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ::Mesh &b_mesh,
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
bool subdivision)
{
if (!mesh->need_attribute(scene, ATTR_STD_RANDOM_PER_ISLAND)) {
return;
}
Mesh: Rename totvert, totedge, and totloop fields Use the standard "elements_num" naming, and use the "corner" name rather than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`. This matches the existing `faces_num` field which was already renamed. Pull Request: https://projects.blender.org/blender/blender/pulls/116350
2023-12-20 02:21:48 +01:00
if (b_mesh.verts_num == 0) {
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
return;
}
Mesh: Rename totvert, totedge, and totloop fields Use the standard "elements_num" naming, and use the "corner" name rather than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`. This matches the existing `faces_num` field which was already renamed. Pull Request: https://projects.blender.org/blender/blender/pulls/116350
2023-12-20 02:21:48 +01:00
DisjointSet vertices_sets(b_mesh.verts_num);
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::int2> edges = b_mesh.edges();
const blender::Span<int> corner_verts = b_mesh.corner_verts();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : edges.index_range()) {
Mesh: Move edges to a generic attribute Implements #95966, as the final step of #95965. This commit changes the storage of mesh edge vertex indices from the `MEdge` type to the generic `int2` attribute type. This follows the general design for geometry and the attribute system, where the data storage type and the usage semantics are separated. The main benefit of the change is reduced memory usage-- the requirements of storing mesh edges is reduced by 1/3. For example, this saves 8MB on a 1 million vertex grid. This also gives performance benefits to any memory-bound mesh processing algorithm that uses edges. Another benefit is that all of the edge's vertex indices are contiguous. In a few cases, it's helpful to process all of them as `Span<int>` rather than `Span<int2>`. Similarly, the type is more likely to match a generic format used by a library, or code that shouldn't know about specific Blender `Mesh` types. Various Notes: - The `.edge_verts` name is used to reflect a mapping between domains, similar to `.corner_verts`, etc. The period means that it the data shouldn't change arbitrarily by the user or procedural operations. - `edge[0]` is now used instead of `edge.v1` - Signed integers are used instead of unsigned to reduce the mixing of signed-ness, which can be error prone. - All of the previously used core mesh data types (`MVert`, `MEdge`, `MLoop`, `MPoly` are now deprecated. Only generic types are used). - The `vec2i` DNA type is used in the few C files where necessary. Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
vertices_sets.join(edges[i][0], edges[i][1]);
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
}
AttributeSet &attributes = (subdivision) ? mesh->subd_attributes : mesh->attributes;
Attribute *attribute = attributes.add(ATTR_STD_RANDOM_PER_ISLAND);
float *data = attribute->data_float();
if (!subdivision) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const blender::Span<blender::int3> corner_tris = b_mesh.corner_tris();
if (!corner_tris.is_empty()) {
for (const int i : corner_tris.index_range()) {
const int vert = corner_verts[corner_tris[i][0]];
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
data[i] = hash_uint_to_float(vertices_sets.find(vert));
}
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
}
}
else {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::OffsetIndices<int> faces = b_mesh.faces();
if (!faces.is_empty()) {
for (const int i : faces.index_range()) {
const int vert = corner_verts[faces[i].start()];
Mesh: Replace MLoop struct with generic attributes Implements #102359. Split the `MLoop` struct into two separate integer arrays called `corner_verts` and `corner_edges`, referring to the vertex each corner is attached to and the next edge around the face at each corner. These arrays can be sliced to give access to the edges or vertices in a face. Then they are often referred to as "poly_verts" or "poly_edges". The main benefits are halving the necessary memory bandwidth when only one array is used and simplifications from using regular integer indices instead of a special-purpose struct. The commit also starts a renaming from "loop" to "corner" in mesh code. Like the other mesh struct of array refactors, forward compatibility is kept by writing files with the older format. This will be done until 4.0 to ease the transition process. Looking at a small portion of the patch should give a good impression for the rest of the changes. I tried to make the changes as small as possible so it's easy to tell the correctness from the diff. Though I found Blender developers have been very inventive over the last decade when finding different ways to loop over the corners in a face. For performance, nearly every piece of code that deals with `Mesh` is slightly impacted. Any algorithm that is memory bottle-necked should see an improvement. For example, here is a comparison of interpolating a vertex float attribute to face corners (Ryzen 3700x): **Before** (Average: 3.7 ms, Min: 3.4 ms) ``` threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) { for (const int64_t i : range) { dst[i] = src[loops[i].v]; } }); ``` **After** (Average: 2.9 ms, Min: 2.6 ms) ``` array_utils::gather(src, corner_verts, dst); ``` That's an improvement of 28% to the average timings, and it's also a simplification, since an index-based routine can be used instead. For more examples using the new arrays, see the design task. Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
data[i] = hash_uint_to_float(vertices_sets.find(vert));
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
}
}
}
Cycles: use mikktspace now for computing tangents from UV maps. This avoids ugly averaged tangents at UV seams but instead now the seams will show as discontinuities in the tangent.
2012-11-03 15:36:02 +00:00
/* Create Mesh */
Cycles: Pass Blender's C++ RNA structures by reference This way we avoid passing structures which could be up to few hundred bytes by value to the utility functions. Ideally we'll also have to add `const` qualifier in majority of the calls, but C++ RNA does not allow us to do that because it does not know if some function modifies contents or not.
2016-01-30 14:18:29 +01:00
static void create_mesh(Scene *scene,
Mesh *mesh,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ::Mesh &b_mesh,
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
const array<Node *> &used_shaders,
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
const bool need_motion,
const float motion_scale,
const bool subdivision = false,
const bool subdivide_uvs = true)
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: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::float3> positions = b_mesh.vert_positions();
const blender::OffsetIndices faces = b_mesh.faces();
const blender::Span<int> corner_verts = b_mesh.corner_verts();
const blender::bke::AttributeAccessor b_attributes = b_mesh.attributes();
Fix #114028: Cycles displace splits faces with smooth and flat faces Cycles can use a per face flag to determine if a face is smooth or flat, and there is no need to use corner normals in such cases. So revert to not doing that as before, which also saves a bit of memory. There is a pre-existing issue where faces are split by sharp edges and autosmooth, which is not solved by this. It's only fixing the regression.
2024-01-24 19:27:50 +01:00
const blender::bke::MeshNormalDomain normals_domain = b_mesh.normals_domain(true);
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
int numfaces = (!subdivision) ? b_mesh.corner_tris().size() : faces.size();
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
bool use_corner_normals = normals_domain == blender::bke::MeshNormalDomain::Corner &&
(mesh->get_subdivision_type() != Mesh::SUBDIVISION_CATMULL_CLARK);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T52943: don't export curves objects with no faces to Cycles. Also skip any objects with zero ray visibility and meshes with zero faces.
2017-09-29 03:56:14 +02:00
/* If no faces, create empty mesh. */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (faces.is_empty()) {
Fix T52943: don't export curves objects with no faces to Cycles. Also skip any objects with zero ray visibility and meshes with zero faces.
2017-09-29 03:56:14 +02:00
return;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
const blender::VArraySpan material_indices = *b_attributes.lookup<int>(
"material_index", blender::bke::AttrDomain::Face);
const blender::VArraySpan sharp_faces = *b_attributes.lookup<bool>(
"sharp_face", blender::bke::AttrDomain::Face);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
blender::Span<blender::float3> corner_normals;
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
if (use_corner_normals) {
Mesh: Replace auto smooth with node group Design task: #93551 This PR replaces the auto smooth option with a geometry nodes modifier that sets the sharp edge attribute. This solves a fair number of long- standing problems related to auto smooth, simplifies the process of normal computation, and allows Blender to automatically choose between face, vertex, and face corner normals based on the sharp edge and face attributes. Versioning adds a geometry node group to objects with meshes that had auto-smooth enabled. The modifier can be applied, which also improves performance. Auto smooth is now unnecessary to get a combination of sharp and smooth edges. In general workflows are changed a bit. Separate procedural and destructive workflows are available. Custom normals can be used immediately without turning on the removed auto smooth option. **Procedural** The node group asset "Smooth by Angle" is the main way to set sharp normals based on the edge angle. It can be accessed directly in the add modifier menu. Of course the modifier can be reordered, muted, or applied like any other, or changed internally like any geometry nodes modifier. **Destructive** Often the sharp edges don't need to be dynamic. This can give better performance since edge angles don't need to be recalculated. In edit mode the two operators "Select Sharp Edges" and "Mark Sharp" can be used. In other modes, the "Shade Smooth by Angle" controls the edge sharpness directly. ### Breaking API Changes - `use_auto_smooth` is removed. Face corner normals are now used automatically if there are mixed smooth vs. not smooth tags. Meshes now always use custom normals if they exist. - In Cycles, the lack of the separate auto smooth state makes normals look triangulated when all faces are shaded smooth. - `auto_smooth_angle` is removed. Replaced by a modifier (or operator) controlling the sharp edge attribute. This means the mesh itself (without an object) doesn't know anything about automatically smoothing by angle anymore. - `create_normals_split`, `calc_normals_split`, and `free_normals_split` are removed, and are replaced by the simpler `Mesh.corner_normals` collection property. Since it gives access to the normals cache, it is automatically updated when relevant data changes. Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609 ### Tests - `geo_node_curves_test_deform_curves_on_surface` has slightly different results because face corner normals are used instead of interpolated vertex normals. - `bf_wavefront_obj_tests` has different export results for one file which mixed sharp and smooth faces without turning on auto smooth. - `cycles_mesh_cpu` has one object which is completely flat shaded. Previously every edge was split before rendering, now it looks triangulated. Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
corner_normals = b_mesh.corner_normals();
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
}
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
int numngons = 0;
int numtris = 0;
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
if (!subdivision) {
Python API: add loop triangles access, remove tessfaces. Loop triangles are tessellated triangles create from polygons, for renderers or exporters that need to match Blender's polygon tesselation exactly. These are a read-only runtime cache. Tessfaces are a legacy data structure from before Blender supported n-gons, and were already mostly removed from the C code. Details on porting code to loop triangles is in the release notes. Differential Revision: https://developer.blender.org/D3539
2018-09-06 14:28:14 +02:00
numtris = numfaces;
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
}
else {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::OffsetIndices faces = b_mesh.faces();
for (const int i : faces.index_range()) {
numngons += (faces[i].size() == 4) ? 0 : 1;
Fix some unnecessary memory allocation slowness in cycles mesh export.
2013-07-14 12:51:41 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Code refactor: modify mesh storage to use arrays rather than vectors, separate some arrays. Differential Revision: https://developer.blender.org/D2016
2016-05-08 00:09:08 +02:00
/* allocate memory */
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
if (subdivision) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mesh->resize_subd_faces(numfaces, numngons, corner_verts.size());
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mesh->resize_mesh(positions.size(), numtris);
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
float3 *verts = mesh->get_verts().data();
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : positions.index_range()) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
verts[i] = make_float3(positions[i][0], positions[i][1], positions[i][2]);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
AttributeSet &attributes = (subdivision) ? mesh->subd_attributes : mesh->attributes;
Attribute *attr_N = attributes.add(ATTR_STD_VERTEX_NORMAL);
Cycles: use mesh normals computed by Blender instead of computing our own, solves an issue with poor mesh geometry.
2011-10-16 17:00:48 +00:00
float3 *N = attr_N->data_float3();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
if (subdivision || !(use_corner_normals && !corner_normals.is_empty())) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::float3> vert_normals = b_mesh.vert_normals();
for (const int i : vert_normals.index_range()) {
N[i] = make_float3(vert_normals[i][0], vert_normals[i][1], vert_normals[i][2]);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const set<ustring> blender_uv_names = get_blender_uv_names(b_mesh);
Split Normals I (5/5): Add support of split normals to Cycles. Idea and code by Brecht, many thanks! Reviewers: brecht Reviewed By: brecht CC: campbellbarton, dingto Differential Revision: https://developer.blender.org/D369
2014-04-13 12:51:06 +02:00
/* create generated coordinates from undeformed coordinates */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const bool need_default_tangent = (subdivision == false) && (blender_uv_names.empty()) &&
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
(mesh->need_attribute(scene, ATTR_STD_UV_TANGENT));
if (mesh->need_attribute(scene, ATTR_STD_GENERATED) || need_default_tangent) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const float(*orco)[3] = static_cast<const float(*)[3]>(
CustomData_get_layer(&b_mesh.vert_data, CD_ORCO));
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
Attribute *attr = attributes.add(ATTR_STD_GENERATED);
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
attr->flags |= ATTR_SUBDIVIDED;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Split Normals I (5/5): Add support of split normals to Cycles. Idea and code by Brecht, many thanks! Reviewers: brecht Reviewed By: brecht CC: campbellbarton, dingto Differential Revision: https://developer.blender.org/D369
2014-04-13 12:51:06 +02:00
float3 loc, size;
mesh_texture_space(b_mesh, loc, size);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
float texspace_location[3], texspace_size[3];
BKE_mesh_texspace_get(const_cast<::Mesh *>(b_mesh.texcomesh ? b_mesh.texcomesh : &b_mesh),
texspace_location,
texspace_size);
Split Normals I (5/5): Add support of split normals to Cycles. Idea and code by Brecht, many thanks! Reviewers: brecht Reviewed By: brecht CC: campbellbarton, dingto Differential Revision: https://developer.blender.org/D369
2014-04-13 12:51:06 +02:00
float3 *generated = attr->data_float3();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : positions.index_range()) {
blender::float3 value;
if (orco) {
madd_v3_v3v3v3(value, texspace_location, orco[i], texspace_size);
}
else {
value = positions[i];
}
generated[i] = make_float3(value[0], value[1], value[2]) * size - loc;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Speedup up tangent space calculation This patch goes away form using C++ RNA during tangent space calculation which avoids quite a bit of overhead. Now all calculation is done using data which already exists in ccl::Mesh. This means, tangent space is now calculated from triangles, which doesn't seem to be any different (at least as far as regression tests are concerned). One of the positive sides is that this change makes it possible to move tangent space calculation from blender/ to render/ so we will have Cycles standalone supporting tangent space. Reviewers: brecht, lukasstockner97, campbellbarton Differential Revision: https://developer.blender.org/D2810
2017-08-25 22:26:04 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
auto clamp_material_index = [&](const int material_index) -> int {
return clamp(material_index, 0, used_shaders.size() - 1);
Mesh: Move face shade smooth flag to a generic attribute Currently the shade smooth status for mesh faces is stored as part of `MPoly::flag`. As described in #95967, this moves that information to a separate boolean attribute. It also flips its status, so the attribute is now called `sharp_face`, which mirrors the existing `sharp_edge` attribute. The attribute doesn't need to be allocated when all faces are smooth. Forward compatibility is kept until 4.0 like the other mesh refactors. This will reduce memory bandwidth requirements for some operations, since the array of booleans uses 12 times less memory than `MPoly`. It also allows faces to be stored more efficiently in the future, since the flag is now unused. It's also possible to use generic functions to process the values. For example, finding whether there is a sharp face is just `sharp_faces.contains(true)`. The `shade_smooth` attribute is no longer accessible with geometry nodes. Since there were dedicated accessor nodes for that data, that shouldn't be a problem. That's difficult to version automatically since the named attribute nodes could be used in arbitrary combinations. **Implementation notes:** - The attribute and array variables in the code use the `sharp_faces` term, to be consistent with the user-facing "sharp faces" wording, and to avoid requiring many renames when #101689 is implemented. - Cycles now accesses smooth face status with the generic attribute, to avoid overhead. - Changing the zero-value from "smooth" to "flat" takes some care to make sure defaults are the same. - Versioning for the edge mode extrude node is particularly complex. New nodes are added by versioning to propagate the attribute in its old inverted state. - A lot of access is still done through the `CustomData` API rather than the attribute API because of a few functions. That can be cleaned up easily in the future. - In the future we would benefit from a way to store attributes as a single value for when all faces are sharp. Pull Request: https://projects.blender.org/blender/blender/pulls/104422
2023-03-08 15:36:18 +01: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
/* create faces */
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
if (!subdivision) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
int *triangles = mesh->get_triangles().data();
bool *smooth = mesh->get_smooth().data();
int *shader = mesh->get_shader().data();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const blender::Span<blender::int3> corner_tris = b_mesh.corner_tris();
for (const int i : corner_tris.index_range()) {
const blender::int3 &tri = corner_tris[i];
triangles[i * 3 + 0] = corner_verts[tri[0]];
triangles[i * 3 + 1] = corner_verts[tri[1]];
triangles[i * 3 + 2] = corner_verts[tri[2]];
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
}
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!material_indices.is_empty()) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const blender::Span<int> tri_faces = b_mesh.corner_tri_faces();
for (const int i : corner_tris.index_range()) {
shader[i] = clamp_material_index(material_indices[tri_faces[i]]);
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
}
}
else {
std::fill(shader, shader + numtris, 0);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
if (!sharp_faces.is_empty() && !(use_corner_normals && !corner_normals.is_empty())) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const blender::Span<int> tri_faces = b_mesh.corner_tri_faces();
for (const int i : corner_tris.index_range()) {
smooth[i] = !sharp_faces[tri_faces[i]];
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
}
}
else {
Mesh: Replace auto smooth with node group Design task: #93551 This PR replaces the auto smooth option with a geometry nodes modifier that sets the sharp edge attribute. This solves a fair number of long- standing problems related to auto smooth, simplifies the process of normal computation, and allows Blender to automatically choose between face, vertex, and face corner normals based on the sharp edge and face attributes. Versioning adds a geometry node group to objects with meshes that had auto-smooth enabled. The modifier can be applied, which also improves performance. Auto smooth is now unnecessary to get a combination of sharp and smooth edges. In general workflows are changed a bit. Separate procedural and destructive workflows are available. Custom normals can be used immediately without turning on the removed auto smooth option. **Procedural** The node group asset "Smooth by Angle" is the main way to set sharp normals based on the edge angle. It can be accessed directly in the add modifier menu. Of course the modifier can be reordered, muted, or applied like any other, or changed internally like any geometry nodes modifier. **Destructive** Often the sharp edges don't need to be dynamic. This can give better performance since edge angles don't need to be recalculated. In edit mode the two operators "Select Sharp Edges" and "Mark Sharp" can be used. In other modes, the "Shade Smooth by Angle" controls the edge sharpness directly. ### Breaking API Changes - `use_auto_smooth` is removed. Face corner normals are now used automatically if there are mixed smooth vs. not smooth tags. Meshes now always use custom normals if they exist. - In Cycles, the lack of the separate auto smooth state makes normals look triangulated when all faces are shaded smooth. - `auto_smooth_angle` is removed. Replaced by a modifier (or operator) controlling the sharp edge attribute. This means the mesh itself (without an object) doesn't know anything about automatically smoothing by angle anymore. - `create_normals_split`, `calc_normals_split`, and `free_normals_split` are removed, and are replaced by the simpler `Mesh.corner_normals` collection property. Since it gives access to the normals cache, it is automatically updated when relevant data changes. Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609 ### Tests - `geo_node_curves_test_deform_curves_on_surface` has slightly different results because face corner normals are used instead of interpolated vertex normals. - `bf_wavefront_obj_tests` has different export results for one file which mixed sharp and smooth faces without turning on auto smooth. - `cycles_mesh_cpu` has one object which is completely flat shaded. Previously every edge was split before rendering, now it looks triangulated. Pull Request: https://projects.blender.org/blender/blender/pulls/108014
2023-10-20 16:54:08 +02:00
/* If only face normals are needed, all faces are sharp. */
std::fill(smooth, smooth + numtris, normals_domain != blender::bke::MeshNormalDomain::Face);
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
}
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
if (use_corner_normals && !corner_normals.is_empty()) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
for (const int i : corner_tris.index_range()) {
const blender::int3 &tri = corner_tris[i];
Python API: add loop triangles access, remove tessfaces. Loop triangles are tessellated triangles create from polygons, for renderers or exporters that need to match Blender's polygon tesselation exactly. These are a read-only runtime cache. Tessfaces are a legacy data structure from before Blender supported n-gons, and were already mostly removed from the C code. Details on porting code to loop triangles is in the release notes. Differential Revision: https://developer.blender.org/D3539
2018-09-06 14:28:14 +02:00
for (int i = 0; i < 3; i++) {
Mesh: Rename MLoopTri variable names, and functions Make the naming consistent with the recent change from "loop" to "corner". Avoid the need for a special type for these triangles by conveying the semantics in the naming instead. - `looptris` -> `corner_tris` - `lt` -> `tri` (or `corner_tri` when there is less context) - `looptri_index` -> `tri_index` (or `corner_tri_index`) - `lt->tri[0]` -> `tri[0]` - `Span<MLoopTri>` -> `Span<int3>` - `looptri_faces` -> `tri_faces` (or `corner_tri_faces`) If we followed the naming pattern of "corner_verts" and "edge_verts" exactly, we'd probably use "tri_corners" instead. But that sounds much worse and less intuitive to me. I've found that by using standard vector types for this sort of data, the commonalities with other areas become much clearer, and code ends up being naturally more data oriented. Besides that, the consistency is nice, and we get to mostly remove use of `DNA_meshdata_types.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
const int corner = tri[i];
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
const int vert = corner_verts[corner];
const float *normal = corner_normals[corner];
N[vert] = make_float3(normal[0], normal[1], normal[2]);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Fix shading with autosmooth and custom normals New logic of split_faces was leaving mesh in a proper state from Blender's point of view, but Cycles wanted loop normals to be "flushed" to vertex normals. Now we do such a flush from Cycles side again, so we don't leave bad meshes behind. Thanks Bastien for assistance here!
2017-02-22 10:53:28 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
mesh->tag_triangles_modified();
mesh->tag_shader_modified();
mesh->tag_smooth_modified();
Fix to prevent undefined normals being generated with `add_face_normals()', from triangles with zero area.
2013-01-01 19:44:09 +00:00
}
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
else {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
int *subd_start_corner = mesh->get_subd_start_corner().data();
int *subd_num_corners = mesh->get_subd_num_corners().data();
int *subd_shader = mesh->get_subd_shader().data();
bool *subd_smooth = mesh->get_subd_smooth().data();
int *subd_ptex_offset = mesh->get_subd_ptex_offset().data();
int *subd_face_corners = mesh->get_subd_face_corners().data();
Cleanup: Cycles: rename some legacy names to new ones
2024-01-19 17:22:14 +01:00
if (!sharp_faces.is_empty() && !use_corner_normals) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
for (int i = 0; i < numfaces; i++) {
subd_smooth[i] = !sharp_faces[i];
}
}
else {
std::fill(subd_smooth, subd_smooth + numfaces, true);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!material_indices.is_empty()) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
for (int i = 0; i < numfaces; i++) {
subd_shader[i] = clamp_material_index(material_indices[i]);
}
}
else {
std::fill(subd_shader, subd_shader + numfaces, 0);
}
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
std::copy(corner_verts.data(), corner_verts.data() + corner_verts.size(), subd_face_corners);
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::OffsetIndices faces = b_mesh.faces();
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
int ptex_offset = 0;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : faces.index_range()) {
const blender::IndexRange face = faces[i];
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
subd_start_corner[i] = face.start();
subd_num_corners[i] = face.size();
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
subd_ptex_offset[i] = ptex_offset;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const int num_ptex = (face.size() == 4) ? 1 : face.size();
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
ptex_offset += num_ptex;
}
mesh->tag_subd_face_corners_modified();
mesh->tag_subd_start_corner_modified();
mesh->tag_subd_num_corners_modified();
mesh->tag_subd_shader_modified();
mesh->tag_subd_smooth_modified();
mesh->tag_subd_ptex_offset_modified();
Cycles microdisplacement: ngons and attributes for subdivision meshes This adds support for ngons and attributes on subdivision meshes. Ngons are needed for proper attribute interpolation as well as correct Catmull-Clark subdivision. Several changes are made to achieve this: - new primitive `SubdFace` added to `Mesh` - 3 more textures are used to store info on patches from subd meshes - Blender export uses loop interface instead of tessface for subd meshes - `Attribute` class is updated with a simplified way to pass primitive counts around and to support ngons. - extra points for ngons are generated for O(1) attribute interpolation - curves are temporally disabled on subd meshes to avoid various bugs with implementation - old unneeded code is removed from `subd/` - various fixes and improvements Reviewed By: brecht Differential Revision: https://developer.blender.org/D2108
2016-07-16 19:42:28 -04:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: Move mesh attribute creation into separate functions This makes overall code of create_mesh() much cleaner and easier to follow.
2015-02-10 23:40:26 +05:00
/* Create all needed attributes.
* The calculate functions will check whether they're needed or not.
Cycles: implement pointiness geometry attribute This attribute means how "pointy" the geometry surface is, which allows to do effects like dirt maps and wear-off effects on render geometry. This means the attribute is calculated for the final mesh which means no baking (which implies UV unwrap) is needed. Apart from this the behavior is quite close to how vertex dirty colors works. The new attribute is available as an output socket of Geometry node. There's no penalty for the render time, only some delay on scene preparation (the delay is linear of the mesh complexity). Reviewers: brecht, juicyfruit Subscribers: eyecandy, venomgfx Differential Revision: https://developer.blender.org/D1086
2015-02-06 12:35:46 +05:00
*/
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (mesh->need_attribute(scene, ATTR_STD_POINTINESS)) {
attr_create_pointiness(mesh, positions, b_mesh.vert_normals(), b_mesh.edges(), subdivision);
}
Cycles: Add Random Per Island attribute. The Random Per Island attribute is a random float associated with each connected component (island) of the mesh. It is particularly useful when artists want to add variations to meshes composed of separate units. Like tree leaves created using particle systems, wood planks created using array modifiers, or abstract splines created using AN. Reviewed By: Sergey Sharybin, Jacques Lucke Differential Revision: https://developer.blender.org/D6154
2019-11-27 12:07:20 +02:00
attr_create_random_per_island(scene, mesh, b_mesh, subdivision);
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
attr_create_generic(scene, mesh, b_mesh, subdivision, need_motion, motion_scale);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
if (subdivision) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
attr_create_subd_uv_map(scene, mesh, b_mesh, subdivide_uvs, blender_uv_names);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
else {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
attr_create_uv_map(scene, mesh, b_mesh, blender_uv_names);
Fix broken merge in fb45821, was missing changes from cc64872.
2018-01-22 14:28:43 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
/* For volume objects, create a matrix to transform from object space to
Cycles Volume Render: generated texture coordinates for volume render. This does not support staying fixed while the surface deforms, but for static meshes it should match up with the surface texture coordinates. Implemented as a matrix transform from objects space to mesh texture space. Making this work for deforming surfaces would be quite complicated, you might need something like harmonic coordinates as used in the mesh deform modifier, probably will not be possible anytime soon.
2013-12-31 17:33:55 +01:00
* mesh texture space. this does not work with deformations but that can
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
* probably only be done well with a volume grid mapping of coordinates. */
Cycles Volume Render: generated texture coordinates for volume render. This does not support staying fixed while the surface deforms, but for static meshes it should match up with the surface texture coordinates. Implemented as a matrix transform from objects space to mesh texture space. Making this work for deforming surfaces would be quite complicated, you might need something like harmonic coordinates as used in the mesh deform modifier, probably will not be possible anytime soon.
2013-12-31 17:33:55 +01:00
if (mesh->need_attribute(scene, ATTR_STD_GENERATED_TRANSFORM)) {
Attribute *attr = mesh->attributes.add(ATTR_STD_GENERATED_TRANSFORM);
Transform *tfm = attr->data_transform();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles Volume Render: generated texture coordinates for volume render. This does not support staying fixed while the surface deforms, but for static meshes it should match up with the surface texture coordinates. Implemented as a matrix transform from objects space to mesh texture space. Making this work for deforming surfaces would be quite complicated, you might need something like harmonic coordinates as used in the mesh deform modifier, probably will not be possible anytime soon.
2013-12-31 17:33:55 +01:00
float3 loc, size;
mesh_texture_space(b_mesh, loc, size);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles Volume Render: generated texture coordinates for volume render. This does not support staying fixed while the surface deforms, but for static meshes it should match up with the surface texture coordinates. Implemented as a matrix transform from objects space to mesh texture space. Making this work for deforming surfaces would be quite complicated, you might need something like harmonic coordinates as used in the mesh deform modifier, probably will not be possible anytime soon.
2013-12-31 17:33:55 +01:00
*tfm = transform_translate(-loc) * transform_scale(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: Pass Blender's C++ RNA structures by reference This way we avoid passing structures which could be up to few hundred bytes by value to the utility functions. Ideally we'll also have to add `const` qualifier in majority of the calls, but C++ RNA does not allow us to do that because it does not know if some function modifies contents or not.
2016-01-30 14:18:29 +01:00
static void create_subd_mesh(Scene *scene,
Mesh *mesh,
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
BObjectInfo &b_ob_info,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const ::Mesh &b_mesh,
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
const array<Node *> &used_shaders,
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
const bool need_motion,
const float motion_scale,
Cycles microdisplacement: add max subdivision setting This is to prevent situations such as when the camera gets very close to a mesh and causes it to be tessellated into an excessive amount of micropolygons. In REYES this is known as the eye-splits problem. Reviewed By: brecht Differential Revision: https://developer.blender.org/D1922
2016-04-18 22:35:49 +02:00
float dicing_rate,
int max_subdivisions)
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
{
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
BL::Object b_ob = b_ob_info.real_object;
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
BL::SubsurfModifier subsurf_mod(b_ob.modifiers[b_ob.modifiers.length() - 1]);
Subsurf: Make uv boundaries easily extendible This replaces old single toggle option to subdivide UVs with an enum which can have more options. The usecase for this is to be compatible with other software. But we also might choose different subdivision type as default in the future. DNA and underlying code supports all possible options, but only the ones which are compatible with old subdivision code are currently exposes. Reviewers: brecht Reviewed By: brecht Differential Revision: https://developer.blender.org/D3575
2018-08-02 13:36:22 +02:00
bool subdivide_uvs = subsurf_mod.uv_smooth() != BL::SubsurfModifier::uv_smooth_NONE;
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
create_mesh(scene, mesh, b_mesh, used_shaders, need_motion, motion_scale, true, subdivide_uvs);
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
const blender::VArraySpan creases = *b_mesh.attributes().lookup<float>(
"crease_edge", blender::bke::AttrDomain::Edge);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!creases.is_empty()) {
Fix: Mishandled creases in Cycles adaptive subdivision Caused by a8a454287a27 which assumed it was possible to access the raw data of the edge creases layer. Also allow processing vertex creases even if there aren't any edge creases.
2022-11-28 13:49:55 -06:00
size_t num_creases = 0;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
for (const int i : creases.index_range()) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
if (creases[i] != 0.0f) {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
num_creases++;
}
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
}
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
mesh->reserve_subd_creases(num_creases);
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::int2> edges = b_mesh.edges();
for (const int i : edges.index_range()) {
Cycles: Avoid overhead from RNA when extracting mesh data Use raw Blender structs and mesh data rather than using the RNA API. There isn't any benefit from using the RNA when Cycles is compiled with Blender anyway, and a profile showed that the majority of time was spent in Blender RNA API functions. This gives a significant improvement in performance when ingesting meshes. Here are some tests of the runtime of the `create_mesh` function (in seconds): | | Before | After | | ------------------------- | ------ | ----- | | Grid | 0.66 | 0.11 | | Many realized cubes | 2.60 | 0.48 | | Large curve to mesh setup | 4.18 | 1.14 | Also change to resizing the arrays and filling them by index rather than appending. This makes the parallel aspect of the logic clearer, and makes the loops easier to parallelize in the future, and makes it easier to have a performance benefit when an attribute like `sharp_face` doesn't exist. Pull Request: https://projects.blender.org/blender/blender/pulls/106275
2023-04-03 17:04:58 +02:00
const float crease = creases[i];
Fix: Mishandled creases in Cycles adaptive subdivision Caused by a8a454287a27 which assumed it was possible to access the raw data of the edge creases layer. Also allow processing vertex creases even if there aren't any edge creases.
2022-11-28 13:49:55 -06:00
if (crease != 0.0f) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::int2 &b_edge = edges[i];
Mesh: Move edges to a generic attribute Implements #95966, as the final step of #95965. This commit changes the storage of mesh edge vertex indices from the `MEdge` type to the generic `int2` attribute type. This follows the general design for geometry and the attribute system, where the data storage type and the usage semantics are separated. The main benefit of the change is reduced memory usage-- the requirements of storing mesh edges is reduced by 1/3. For example, this saves 8MB on a 1 million vertex grid. This also gives performance benefits to any memory-bound mesh processing algorithm that uses edges. Another benefit is that all of the edge's vertex indices are contiguous. In a few cases, it's helpful to process all of them as `Span<int>` rather than `Span<int2>`. Similarly, the type is more likely to match a generic format used by a library, or code that shouldn't know about specific Blender `Mesh` types. Various Notes: - The `.edge_verts` name is used to reflect a mapping between domains, similar to `.corner_verts`, etc. The period means that it the data shouldn't change arbitrarily by the user or procedural operations. - `edge[0]` is now used instead of `edge.v1` - Signed integers are used instead of unsigned to reduce the mixing of signed-ness, which can be error prone. - All of the previously used core mesh data types (`MVert`, `MEdge`, `MLoop`, `MPoly` are now deprecated. Only generic types are used). - The `vec2i` DNA type is used in the few C files where necessary. Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
mesh->add_edge_crease(b_edge[0], b_edge[1], crease);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
Subdivision: add support for vertex creasing This adds vertex creasing support for OpenSubDiv for modeling, rendering, Alembic and USD I/O. For modeling, vertex creasing follows the edge creasing implementation with an operator accessible through the Vertex menu in Edit Mode, and some parameter in the properties panel. The option in the Subsurf and Multires to use edge creasing also affects vertex creasing. The vertex crease data is stored as a CustomData layer, unlike edge creases which for now are stored in `MEdge`, but will in the future also be moved to a `CustomData` layer. See comments for details on the difference in behavior for the `CD_CREASE` layer between egdes and vertices. For Cycles this adds sockets on the Mesh node to hold data about which vertices are creased (one socket for the indices, one for the weigths). Viewport rendering of vertex creasing reuses the same color scheme as for edges and creased vertices are drawn bigger than uncreased vertices. For Alembic and USD, vertex crease support follows the edge crease implementation, they are always read, but only exported if a `Subsurf` modifier is present on the Mesh. Reviewed By: brecht, fclem, sergey, sybren, campbellbarton Differential Revision: https://developer.blender.org/D10145
2022-01-20 12:20:30 +01:00
}
Fix: Mishandled creases in Cycles adaptive subdivision Caused by a8a454287a27 which assumed it was possible to access the raw data of the edge creases layer. Also allow processing vertex creases even if there aren't any edge creases.
2022-11-28 13:49:55 -06:00
}
Subdivision: add support for vertex creasing This adds vertex creasing support for OpenSubDiv for modeling, rendering, Alembic and USD I/O. For modeling, vertex creasing follows the edge creasing implementation with an operator accessible through the Vertex menu in Edit Mode, and some parameter in the properties panel. The option in the Subsurf and Multires to use edge creasing also affects vertex creasing. The vertex crease data is stored as a CustomData layer, unlike edge creases which for now are stored in `MEdge`, but will in the future also be moved to a `CustomData` layer. See comments for details on the difference in behavior for the `CD_CREASE` layer between egdes and vertices. For Cycles this adds sockets on the Mesh node to hold data about which vertices are creased (one socket for the indices, one for the weigths). Viewport rendering of vertex creasing reuses the same color scheme as for edges and creased vertices are drawn bigger than uncreased vertices. For Alembic and USD, vertex crease support follows the edge crease implementation, they are always read, but only exported if a `Subsurf` modifier is present on the Mesh. Reviewed By: brecht, fclem, sergey, sybren, campbellbarton Differential Revision: https://developer.blender.org/D10145
2022-01-20 12:20:30 +01:00
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 13:13:16 -05:00
const blender::VArraySpan vert_creases = *b_mesh.attributes().lookup<float>(
"crease_vert", blender::bke::AttrDomain::Point);
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (!vert_creases.is_empty()) {
for (const int i : vert_creases.index_range()) {
Mesh: Move vertex/edge crease to generic attributes Store subdivision surface creases in two new named float attributes: - `crease_vert` - `crease_edge` This is similar to 2a56403cb0dbcbc1dfb19a9bf7e6434517cbdca9. The attributes are naming conventions, so their data type and domain aren't enforced, and may be interpolated when necessary. Editing tools and the subdivision surface modifier use the hard-coded name. It might be best if these were edited as generic attributes in the future, but in the meantime using generic attributes helps. The attributes are visible in the list, which is how they're now meant to be removed. They are now interchangeable with any tool that works with the generic attribute system-- even tools like vertex paint can affect creases now. This is a breaking change. Forward compatibility isn't preserved for versions before 3.6, and the `crease` property in RNA is removed in favor of making a smaller API surface area with just the attribute API. `Mesh.vertex_creases` and `Mesh.edge_creases` now just return the matching attribute if possible, and are now implemented in Python. New functions `*ensure` and `*remove` also replace the operators to add and remove the layers for Python. A few extrude node test files have to be updated because of different (now generic) attribute interpolation behavior. Pull Request: https://projects.blender.org/blender/blender/pulls/108089
2023-06-13 20:23:39 +02:00
if (vert_creases[i] != 0.0f) {
mesh->add_vertex_crease(i, vert_creases[i]);
Subdivision: add support for vertex creasing This adds vertex creasing support for OpenSubDiv for modeling, rendering, Alembic and USD I/O. For modeling, vertex creasing follows the edge creasing implementation with an operator accessible through the Vertex menu in Edit Mode, and some parameter in the properties panel. The option in the Subsurf and Multires to use edge creasing also affects vertex creasing. The vertex crease data is stored as a CustomData layer, unlike edge creases which for now are stored in `MEdge`, but will in the future also be moved to a `CustomData` layer. See comments for details on the difference in behavior for the `CD_CREASE` layer between egdes and vertices. For Cycles this adds sockets on the Mesh node to hold data about which vertices are creased (one socket for the indices, one for the weigths). Viewport rendering of vertex creasing reuses the same color scheme as for edges and creased vertices are drawn bigger than uncreased vertices. For Alembic and USD, vertex crease support follows the edge crease implementation, they are always read, but only exported if a `Subsurf` modifier is present on the Mesh. Reviewed By: brecht, fclem, sergey, sybren, campbellbarton Differential Revision: https://developer.blender.org/D10145
2022-01-20 12:20:30 +01:00
}
Cycles microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04: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 microdisplacement: Support for Catmull-Clark subdivision via OpenSubdiv Enables Catmull-Clark subdivision meshes with support for creases and attribute subdivision. Still waiting on OpenSubdiv to fully support face varying interpolation for subdividing uv coordinates tho. Also there may be some inconsistencies with Blender's subdivision which will be resolved at a later time. Code for reading patch tables and creating patch maps is borrowed from OpenSubdiv. Reviewed By: brecht Differential Revision: https://developer.blender.org/D2111
2016-07-16 22:57:06 -04:00
/* set subd params */
Cycles microdisplacement: move subdivision options to subsurf modifier Subdivision options can now be found in the subsurf modifier. The modifier must be the last in the stack or the options will be unavailable. Catmull-Clark subdivision is still unavailable and will fallback to linear subdivision instead Reviewed By: brecht Differential Revision: https://developer.blender.org/D2109
2016-07-16 19:56:45 -04:00
PointerRNA cobj = RNA_pointer_get(&b_ob.ptr, "cycles");
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
float subd_dicing_rate = max(0.1f, RNA_float_get(&cobj, "dicing_rate") * dicing_rate);
Cycles microdisplacement: move subdivision options to subsurf modifier Subdivision options can now be found in the subsurf modifier. The modifier must be the last in the stack or the options will be unavailable. Catmull-Clark subdivision is still unavailable and will fallback to linear subdivision instead Reviewed By: brecht Differential Revision: https://developer.blender.org/D2109
2016-07-16 19:56:45 -04:00
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
mesh->set_subd_dicing_rate(subd_dicing_rate);
mesh->set_subd_max_level(max_subdivisions);
mesh->set_subd_objecttoworld(get_transform(b_ob.matrix_world()));
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
}
/* Sync */
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
void BlenderSync::sync_mesh(BL::Depsgraph b_depsgraph, BObjectInfo &b_ob_info, Mesh *mesh)
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 multithreading issue introduced in previous commit The issue is that the shaders are stolen from the original Geometry by the temporary Geometry used to accumulate data, but the main thread still needs them for syncing the attributes. So make a copy of the shader array to preserve the data on the original Geometry.
2020-11-04 13:57:28 +01:00
/* make a copy of the shaders as the caller in the main thread still need them for syncing the
* attributes */
array<Node *> used_shaders = mesh->get_used_shaders();
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
Mesh new_mesh;
Cycles: fix multithreading issue introduced in previous commit The issue is that the shaders are stolen from the original Geometry by the temporary Geometry used to accumulate data, but the main thread still needs them for syncing the attributes. So make a copy of the shader array to preserve the data on the original Geometry.
2020-11-04 13:57:28 +01:00
new_mesh.set_used_shaders(used_shaders);
Fix cycles crash when voxel attributes changed This could happen e.g. when changing smoke type from flow to domain or connecting a volume shader with to a domain without an actual flow type around. Fixes T58569, T68359 Reviewers: brecht Maniphest Tasks: T58569, T68359 Differential Revision: https://developer.blender.org/D5478
2019-08-14 10:48:25 +02:00
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
if (view_layer.use_surfaces) {
Fix T60615: Cycles baking not working with some modifiers. Refactors Cycles mesh export a bit to avoid unnecessary copies and to be in sync with the Blender baker.
2019-01-15 13:03:09 +01:00
/* Adaptive subdivision setup. Not for baking since that requires
* exact mapping to the Blender mesh. */
Fix #131814: Cycles bake crash with geometry nodes instances Don't rely on object name matching, this is not reliable when there can be multiple instances with the same name. Pull Request: https://projects.blender.org/blender/blender/pulls/132496
2025-01-02 12:48:21 +01:00
Mesh::SubdivisionType subdivision_type = (b_ob_info.real_object != b_bake_target) ?
object_subdivision_type(b_ob_info.real_object,
preview,
experimental) :
Mesh::SUBDIVISION_NONE;
new_mesh.set_subdivision_type(subdivision_type);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix (unreported) Cycles not rendering correctly modified curves/surfaces/texts. Meshes from evaluated objects may already have modifiers applied, but that's not the case for curves, we need to do that when converting them to meshes.
2018-11-28 16:23:39 +01:00
/* For some reason, meshes do not need this... */
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
bool need_undeformed = new_mesh.need_attribute(scene, ATTR_STD_GENERATED);
Cycles: Pass explicit subdivision type to object_to_mesh This allows us to do some extra logic checks there based on particular subdivision type. Additionally avoids implicit cast of enum to bool.
2017-01-11 16:23:54 +01:00
BL::Mesh b_mesh = object_to_mesh(
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
b_data, b_ob_info, b_depsgraph, need_undeformed, new_mesh.get_subdivision_type());
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles: add Use Surfaces and Use Hair option to render layers, to disable rendering of hair and surfaces, similar to blender internal options.
2013-05-10 13:34:49 +00:00
if (b_mesh) {
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
/* Motion blur attribute is relative to seconds, we need it relative to frames. */
Cycles: support rendering PointCloud motion blur from attribute This adds support to render PointCloud motion blur from a standard "velocity" attribute. This implementation is similar to that of the Mesh geometry, and perhaps some code could be deduplicated through a more generic API. `mesh_need_motion_attribute` was renamed `object_need_motion_attribute` as it does not really require a mesh and moved to `util.h` so that it can be shared. This fixes T94622. Reviewed By: brecht Maniphest Tasks: T94622 Differential Revision: https://developer.blender.org/D13719
2022-01-04 01:58:34 +01:00
const bool need_motion = object_need_motion_attribute(b_ob_info, scene);
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
const float motion_scale = (need_motion) ?
scene->motion_shutter_time() /
(b_scene.render().fps() / b_scene.render().fps_base()) :
0.0f;
Fix T60615: Cycles baking not working with some modifiers. Refactors Cycles mesh export a bit to avoid unnecessary copies and to be in sync with the Blender baker.
2019-01-15 13:03:09 +01:00
/* Sync mesh itself. */
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
if (new_mesh.get_subdivision_type() != Mesh::SUBDIVISION_NONE) {
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
create_subd_mesh(scene,
&new_mesh,
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
b_ob_info,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
*static_cast<const ::Mesh *>(b_mesh.ptr.data),
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
new_mesh.get_used_shaders(),
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
need_motion,
motion_scale,
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
dicing_rate,
max_subdivisions);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
else {
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
create_mesh(scene,
&new_mesh,
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
*static_cast<const ::Mesh *>(b_mesh.ptr.data),
Modifiers: export motion blur velocity through attribute Previously fluid simulation and Alembic modifiers had a dedicated function to query the velocity for motion blur. Now use a more generic system where those modifiers output a velocity attribute. Advantages: * Geometry and particle nodes can output velocity through the same mechanism, or read the attribute coming from earlier modifiers. * The velocity can be preserved through modifiers like subdivision surface or auto smooth. * USD and Alembic previously only output velocity from fluid simulation, now they work with velocity from other sources too. * Simplifies the code for renderers like Cycles and exporters like Alembic and USD. This breaks compatibility: * External renderers and exporters accessing these velocities through the Python API now need to use the attribute instead. * Existing modifier node setups that create an attribute named "velocity" will render differently with motion blur. Differential Revision: https://developer.blender.org/D12305
2021-09-09 17:22:20 +02:00
new_mesh.get_used_shaders(),
need_motion,
motion_scale,
false);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
free_object_to_mesh(b_data, b_ob_info, b_mesh);
Cycles: fix crash syncing curve/text object with no verts/faces.
2011-05-31 11:12:42 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
/* update original sockets */
Fix T82852: Cycles crashes when editing a mesh with adaptive subdivision The issue is caused by stale data on the Mesh Node which is not cleared during synchronizing since the socket API refactor so that we can detect changes. However, synchronization only updates the sockets of the Mesh, so other properties were left with outdated values. This caused an underflow when computing attribute size for undisplaced coordinates as it was using the current number of vertices minus the previous count of subdivision vertices, which at this point should be 0. Added a simple method to clear non socket data. Also modified Mesh.add_undisplaced to always use an ATTR_PRIM_GEOMETRY as the data is not subdivided yet and it avoids any further issues regarding computing attribute sizes.
2020-12-10 02:31:25 +01:00
mesh->clear_non_sockets();
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
for (const SocketType &socket : new_mesh.type->inputs) {
/* Those sockets are updated in sync_object, so do not modify them. */
Cleanup: clang-format
2020-11-06 10:29:00 +11:00
if (socket.name == "use_motion_blur" || socket.name == "motion_steps" ||
socket.name == "used_shaders")
{
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
continue;
}
mesh->set_value(socket, new_mesh, socket);
}
Cycles: optimize device updates This optimizes device updates (during user edits or frame changes in the viewport) by avoiding unnecessary computations. To achieve this, we use a combination of the sockets' update flags as well as some new flags passed to the various managers when tagging for an update to tell exactly what the tagging is for (e.g. shader was modified, object was removed, etc.). Besides avoiding recomputations, we also avoid resending to the devices unmodified data arrays, thus reducing bandwidth usage. For OptiX and Embree, BVH packing was also multithreaded. The performance improvements may vary depending on the used device (CPU or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive subdivision or volumes) rendered using OptiX will benefit from this work the most. On average, for a variety of animated scenes, this gives a 3x speedup. Reviewed By: #cycles, brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D9555
2021-01-22 15:01:26 +01:00
mesh->attributes.update(std::move(new_mesh.attributes));
mesh->subd_attributes.update(std::move(new_mesh.subd_attributes));
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
mesh->set_num_subd_faces(new_mesh.get_num_subd_faces());
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02: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
/* tag update */
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
bool rebuild = (mesh->triangles_is_modified()) || (mesh->subd_num_corners_is_modified()) ||
(mesh->subd_shader_is_modified()) || (mesh->subd_smooth_is_modified()) ||
(mesh->subd_ptex_offset_is_modified()) ||
(mesh->subd_start_corner_is_modified()) ||
(mesh->subd_face_corners_is_modified());
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02: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
mesh->tag_update(scene, rebuild);
}
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
void BlenderSync::sync_mesh_motion(BL::Depsgraph b_depsgraph,
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
BObjectInfo &b_ob_info,
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
Mesh *mesh,
int motion_step)
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 12:49:26 +00:00
{
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
/* Skip if no vertices were exported. */
Cycles API: encapsulate Node socket members This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-11-04 11:17:38 +01:00
size_t numverts = mesh->get_verts().size();
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
if (numverts == 0) {
Code refactor: motion blur cleanups, preparing for next commit.
2018-03-10 00:37:07 +01:00
return;
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
/* Skip objects without deforming modifiers. this is not totally reliable,
* would need a more extensive check to see which objects are animated. */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
BL::Mesh b_mesh_rna(PointerRNA_NULL);
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
if (ccl::BKE_object_is_deform_modified(b_ob_info, b_scene, preview)) {
Fix T40031: cycles deformation motion blur wrong render on last frame of animation.
2014-05-05 16:35:20 +02:00
/* get derived mesh */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
b_mesh_rna = object_to_mesh(b_data, b_ob_info, b_depsgraph, false, Mesh::SUBDIVISION_NONE);
Fix T40031: cycles deformation motion blur wrong render on last frame of animation.
2014-05-05 16:35:20 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Geometry Nodes: support for geometry instancing Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-09-06 18:22:24 +02:00
const std::string ob_name = b_ob_info.real_object.name();
Cleanup: comment, RNA spelling
2019-06-17 12:51:53 +10:00
/* TODO(sergey): Perform preliminary check for number of vertices. */
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
if (b_mesh_rna) {
const ::Mesh &b_mesh = *static_cast<const ::Mesh *>(b_mesh_rna.ptr.data);
Mesh: Rename totvert, totedge, and totloop fields Use the standard "elements_num" naming, and use the "corner" name rather than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`. This matches the existing `faces_num` field which was already renamed. Pull Request: https://projects.blender.org/blender/blender/pulls/116350
2023-12-20 02:21:48 +01:00
const int b_verts_num = b_mesh.verts_num;
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::float3> positions = b_mesh.vert_positions();
if (positions.is_empty()) {
free_object_to_mesh(b_data, b_ob_info, b_mesh_rna);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
return;
}
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
/* Export deformed coordinates. */
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
/* Find attributes. */
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
Attribute *attr_mP = mesh->attributes.find(ATTR_STD_MOTION_VERTEX_POSITION);
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
Attribute *attr_mN = mesh->attributes.find(ATTR_STD_MOTION_VERTEX_NORMAL);
Attribute *attr_N = mesh->attributes.find(ATTR_STD_VERTEX_NORMAL);
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
bool new_attribute = false;
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
/* Add new attributes if they don't exist already. */
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
if (!attr_mP) {
attr_mP = mesh->attributes.add(ATTR_STD_MOTION_VERTEX_POSITION);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
if (attr_N) {
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
attr_mN = mesh->attributes.add(ATTR_STD_MOTION_VERTEX_NORMAL);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
new_attribute = true;
}
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
/* Load vertex data from mesh. */
Code refactor: motion blur cleanups, preparing for next commit.
2018-03-10 00:37:07 +01:00
float3 *mP = attr_mP->data_float3() + motion_step * numverts;
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
float3 *mN = (attr_mN) ? attr_mN->data_float3() + motion_step * numverts : nullptr;
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
/* NOTE: We don't copy more that existing amount of vertices to prevent
* possible memory corruption.
*/
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
for (int i = 0; i < std::min<size_t>(b_verts_num, numverts); i++) {
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
mP[i] = make_float3(positions[i][0], positions[i][1], positions[i][2]);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
if (mN) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
const blender::Span<blender::float3> b_vert_normals = b_mesh.vert_normals();
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
for (int i = 0; i < std::min<size_t>(b_verts_num, numverts); i++) {
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
mN[i] = make_float3(b_vert_normals[i][0], b_vert_normals[i][1], b_vert_normals[i][2]);
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
}
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
}
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
if (new_attribute) {
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
/* In case of new attribute, we verify if there really was any motion. */
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
if (b_verts_num != numverts ||
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
memcmp(mP, mesh->get_verts().data(), sizeof(float3) * numverts) == 0)
Clang Format: bump to version 17 Along with the 4.1 libraries upgrade, we are bumping the clang-format version from 8-12 to 17. This affects quite a few files. If not already the case, you may consider pointing your IDE to the clang-format binary bundled with the Blender precompiled libraries.
2024-01-02 18:12:54 +01:00
{
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
/* no motion, remove attributes again */
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
if (b_verts_num != numverts) {
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_WARNING << "Topology differs, disabling motion blur for object " << ob_name;
Cycles: Improve logging about motion blur a bit
2016-04-26 16:17:11 +02:00
}
else {
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_DEBUG << "No actual deformation motion for object " << ob_name;
Cycles: Improve logging about motion blur a bit
2016-04-26 16:17:11 +02:00
}
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
mesh->attributes.remove(ATTR_STD_MOTION_VERTEX_POSITION);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
if (attr_mN) {
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
mesh->attributes.remove(ATTR_STD_MOTION_VERTEX_NORMAL);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
}
Code refactor: motion blur cleanups, preparing for next commit.
2018-03-10 00:37:07 +01:00
else if (motion_step > 0) {
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_DEBUG << "Filling deformation motion for object " << ob_name;
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
/* motion, fill up previous steps that we might have skipped because
* they had no motion, but we need them anyway now */
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
float3 *P = mesh->get_verts().data();
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
float3 *N = (attr_N) ? attr_N->data_float3() : nullptr;
Code refactor: motion blur cleanups, preparing for next commit.
2018-03-10 00:37:07 +01:00
for (int step = 0; step < motion_step; step++) {
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
memcpy(attr_mP->data_float3() + step * numverts, P, sizeof(float3) * numverts);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
if (attr_mN) {
Fix T40031: cycles deformation motion blur wrong render on last frame of animation.
2014-05-05 16:35:20 +02:00
memcpy(attr_mN->data_float3() + step * numverts, N, sizeof(float3) * numverts);
Cleanup: use braces for sources in intern/ Omitted intern/itasc as some of these sources are from KDL: https://www.orocos.org/kdl.html
2023-09-17 09:01:48 +10:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cycles code refactor: add motion sampled normals attribute.
2014-03-29 13:03:46 +01:00
}
Cycles code refactor: improve vertex motion attribute storage and export. This now supports multiple steps and subframe sampling of motion. There is one difference for object and camera transform motion blur. It still only supports two steps there, but the transforms are now sampled at subframe times instead of the previous and next frame and then interpolated/extrapolated. This will give different render results in some cases but it's more accurate. Part of the code is from the summer of code project by Gavin Howard, but it has been significantly rewritten and extended.
2014-03-29 13:03:46 +01:00
}
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
else {
Mesh: Remove redundant custom data pointers For copy-on-write, we want to share attribute arrays between meshes where possible. Mutable pointers like `Mesh.mvert` make that difficult by making ownership vague. They also make code more complex by adding redundancy. The simplest solution is just removing them and retrieving layers from `CustomData` as needed. Similar changes have already been applied to curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of the pointers generally makes code more obvious and more reusable. Mesh data is now accessed with a C++ API (`Mesh::edges()` or `Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`). The CoW changes this commit makes possible are described in T95845 and T95842, and started in D14139 and D14140. The change also simplifies the ongoing mesh struct-of-array refactors from T95965. **RNA/Python Access Performance** Theoretically, accessing mesh elements with the RNA API may become slower, since the layer needs to be found on every random access. However, overhead is already high enough that this doesn't make a noticible differenc, and performance is actually improved in some cases. Random access can be up to 10% faster, but other situations might be a bit slower. Generally using `foreach_get/set` are the best way to improve performance. See the differential revision for more discussion about Python performance. Cycles has been updated to use raw pointers and the internal Blender mesh types, mostly because there is no sense in having this overhead when it's already compiled with Blender. In my tests this roughly halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million face grid). Differential Revision: https://developer.blender.org/D15488
2022-09-05 11:56:34 -05:00
if (b_verts_num != numverts) {
Cleanup: add verbose logging category names instead of numbers And use them more consistently than before.
2022-06-16 19:39:13 +02:00
VLOG_WARNING << "Topology differs, discarding motion blur for object " << ob_name
<< " at time " << motion_step;
Refactor: Cycles: Automated clang-tidy fixups in Cycles * Use .empty() and .data() * Use nullptr instead of 0 * No else after return * Simple class member initialization * Add override for virtual methods * Include C++ instead of C headers * Remove some unused includes * Use default constructors * Always use braces * Consistent names in definition and declaration * Change typedef to using Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:59 +01:00
memcpy(mP, mesh->get_verts().data(), sizeof(float3) * numverts);
Refactor: Cycles: Use nullptr instead of NULL Pull Request: https://projects.blender.org/blender/blender/pulls/132361
2024-12-26 17:53:55 +01:00
if (mN != nullptr) {
Cycles: Fix corrupted mesh render when topology differs at the next frame
2017-04-07 12:48:43 +02:00
memcpy(mN, attr_N->data_float3(), sizeof(float3) * numverts);
}
}
}
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
Cycles: Use Blender headers to access geometry data, avoid copy Since 34b44878449d67a56fd2, attributes are always made mutable when accessed from the RNA API. This can result in unnecessary copies, which increases memory usage and reduces performance. Cycles is the only user of the C++ RNA API, which we'd like to remove in the future since it doesn't really make sense in the big picture. Hydra is now a better alternative for external render engines. To start that change and fix the unnecessary copies, this commit moves to use Blender headers directly for accessing attribute and other geometry data. This also removes the few places that still had overhead from the RNA API after the changes ([0]) in 3.6. In a simple test with a large grid, I observed a 1.76x performance improvement, from 1.04 to 0.59 seconds to extract the mesh data to Cycles. [0]: https://wiki.blender.org/wiki/Reference/Release_Notes/3.6/Cycles#Performance Pull Request: https://projects.blender.org/blender/blender/pulls/112306
2023-09-18 02:50:09 +02:00
free_object_to_mesh(b_data, b_ob_info, b_mesh_rna);
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
return;
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 12:49:26 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: split Cycles export into smaller files
2020-02-02 13:09:18 +01:00
/* No deformation on this frame, copy coordinates if other frames did have it. */
Cleanup: split Cycles Hair and Mesh classes, with Geometry base class
2020-02-02 12:04:19 +01:00
mesh->copy_center_to_motion_step(motion_step);
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 12:49:26 +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
CCL_NAMESPACE_END
Reference in New Issue Copy Permalink