griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
4e027fdde6ea0940be97b4e64317980ebf5cc175
test/source/blender/draw/intern/draw_cache_extract.hh

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

331 lines
10 KiB
C++
Raw Normal View History

File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
/* SPDX-License-Identifier: GPL-2.0-or-later
* Copyright 2019 Blender Foundation. */
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
/** \file
* \ingroup draw
*/
Cleanup: use header guards
2019-09-13 21:12:26 +10:00
#pragma once
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
#include <algorithm>
#include "BLI_utildefines.h"
DrawManager: Graph Task Scheduling This patch uses a graph flow scheduler for creating all mesh batches. On a Ryzen 1700 the framerate of Spring/020_02A.anim.blend went from 10 fps to 11.5 fps. For each mesh where batches needs to be updated a sub-graph will be added to the task_graph. This sub-graph starts with an extract_render_data_node. This fills/converts the required data from Mesh. Small extractions and extractions that can't be multi-threaded are grouped in a single `extract_single_threaded_task_node`. Other extractions will create a node for each loop exceeding 4096 items. these nodes are linked to the `user_data_init_task_node`. the `user_data_init_task_node` prepares the userdata needed for the extraction based on the data extracted from the mesh. Note: If the `lines` and `lines_loose` are requested, the `lines_loose` sub-buffer is created as part of the lines extraction. When the lines_loose is only requested the sub-buffer is created from the existing `lines` buffer. It is assumed that the lines buffer is always requested before or together with the lines_loose what is always the case (see `DRW_batch_requested(cache->batch.loose_edges, GPU_PRIM_LINES)` in `draw_cache_impl_mesh.c`). Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D7618
2020-06-02 15:07:17 +02:00
Revert "Revert "Eevee: support accessing custom mesh attributes"" This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a. And also fix a compilation issue on windows. Differential Revision: https://developer.blender.org/D12969
2021-10-26 18:16:33 -03:00
#include "DNA_customdata_types.h"
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
#include "DNA_mesh_types.h"
#include "DNA_view3d_enums.h"
Revert "Revert "Eevee: support accessing custom mesh attributes"" This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a. And also fix a compilation issue on windows. Differential Revision: https://developer.blender.org/D12969
2021-10-26 18:16:33 -03:00
#include "BKE_attribute.h"
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
#include "BKE_object.h"
Revert "Revert "Eevee: support accessing custom mesh attributes"" This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a. And also fix a compilation issue on windows. Differential Revision: https://developer.blender.org/D12969
2021-10-26 18:16:33 -03:00
Cleanup: Split draw_cache_extract_mesh into multiple files. draw_cache_extract_mesh for task scheduling. Will be refactored to draw_cache_extract_mesh_scheduling later on after migrating to CPP. draw_cache_extract_mesh_render_data extraction of mesh render data from edit mesh/mesh into a more generic structure. draw_cache_extract_mesh_extractors containing all the extractors. This will be split up further into a single file per extractor.
2021-06-01 09:23:37 +02:00
#include "GPU_batch.h"
#include "GPU_index_buffer.h"
#include "GPU_vertex_buffer.h"
EEVEE: support Curves attributes rendering This adds support to render Curves attributes in EEVEE. Each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via create_requested which we cannot rely on anyway as contrary to the mesh batch, we do cannot really tell if attributes need to be updated or else via some `DRW_batch_requested`. Since point attributes need refinement, and since attributes are all cast to vec4/float4 to account for differences in type conversions between Blender and OpenGL, the refinement shader for points is used as is. The point attributes are stored for each subdivision level in CurvesEvalFinalCache. Each subdivision level also keeps track of the attributes already in use so they are properly updated when needed. Some basic garbage collection was added similar to what is done for meshes: if the attributes used over time have been different from the currently used attributes for too long, then the buffers are freed, ensuring that stale attributesare removed. This adds `CurvesInfos` to the shader creation info, which stores the scope in which the attributes are defined. Scopes are stored as booleans, in an array indexed by attribute loading order which is also the order in which the attributes were added to the material. A mapping is necessary between the indices used for the scoping, and the ones used in the Curves cache, as this may contain stale attributes which have not been garbage collected yet. Common utilities with the mesh code for handling requested attributes were moved to a separate file. Differential Revision: https://developer.blender.org/D14916
2022-05-24 05:02:57 +02:00
#include "draw_attributes.h"
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct DRWSubdivCache;
struct MeshRenderData;
struct TaskGraph;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
/* Vertex Group Selection and display options */
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct DRW_MeshWeightState {
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
int defgroup_active;
int defgroup_len;
short flags;
char alert_mode;
Cleanup: spelling
2021-07-08 13:26:55 +10:00
/* Set of all selected bones for Multi-paint. */
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
bool *defgroup_sel; /* #defgroup_len */
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
int defgroup_sel_count;
Weight Paint: Implement a new Lock-Relative mode. This check box alters how weights are displayed and painted, similar to Multi Paint, but in a different way. Specifically, weights are presented as if all locked vertex groups were deleted, and the remaining deform groups normalized. The new feature is intended for use when balancing weights within a group of bones while all others are locked. Enabling the option presents weight as if the locked bones didn't exist, and their weight was proportionally redistributed to the editable bones. Conversely, the Multi-Paint feature allows balancing a group of bones as a whole against all unselected bones, while ignoring weight distribution within the selected group. This mode also allows temporarily viewing non-normalized weights as if they were normalized, without actually changing the values. Differential Revision: https://developer.blender.org/D3837
2018-10-07 18:25:51 +03:00
/* Set of all locked and unlocked deform bones for Lock Relative mode. */
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
bool *defgroup_locked; /* #defgroup_len */
bool *defgroup_unlocked; /* #defgroup_len */
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
/* DRW_MeshWeightState.flags */
enum {
DRW_MESH_WEIGHT_STATE_MULTIPAINT = (1 << 0),
DRW_MESH_WEIGHT_STATE_AUTO_NORMALIZE = (1 << 1),
Weight Paint: Implement a new Lock-Relative mode. This check box alters how weights are displayed and painted, similar to Multi Paint, but in a different way. Specifically, weights are presented as if all locked vertex groups were deleted, and the remaining deform groups normalized. The new feature is intended for use when balancing weights within a group of bones while all others are locked. Enabling the option presents weight as if the locked bones didn't exist, and their weight was proportionally redistributed to the editable bones. Conversely, the Multi-Paint feature allows balancing a group of bones as a whole against all unselected bones, while ignoring weight distribution within the selected group. This mode also allows temporarily viewing non-normalized weights as if they were normalized, without actually changing the values. Differential Revision: https://developer.blender.org/D3837
2018-10-07 18:25:51 +03:00
DRW_MESH_WEIGHT_STATE_LOCK_RELATIVE = (1 << 2),
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
};
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
enum eMRIterType {
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
MR_ITER_LOOPTRI = 1 << 0,
DRW: optimize mesh data extraction Change extraction callbacks to take index ranges instead of calling them for each mesh element (poly, loop, vert & edge). This gives a minor overall performance gain in my tests, ~5% on average. Details: - Use typed parameter structs and macros for looping over elements. Without this, changes to these callbacks is time consuming as changes need to be made in many places. - Avoid iterating over polygon-loops when iterating over polygons is sufficient. - Simplify logic to access adjacent loops for faster line extraction. - Rename 'loop' iterators to 'poly' (as they take polygon ranges) the iterator callbacks can operator on either polygon or loop data. - Use term 'last' for the last index (inclusive), use 'end' when this value (not inclusive).
2020-07-01 00:13:39 +10:00
MR_ITER_POLY = 1 << 1,
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
MR_ITER_LEDGE = 1 << 2,
MR_ITER_LVERT = 1 << 3,
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
DrawManager: Use CPP for Mesh Extraction Scheduling. More cleanups will come to make this more CPP-like.
2021-06-01 12:12:13 +02:00
ENUM_OPERATORS(eMRIterType, MR_ITER_LVERT)
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
enum eMRDataType {
Cleanup: move extract points into own compile unit.
2021-06-07 13:27:38 +02:00
MR_DATA_NONE = 0,
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
MR_DATA_POLY_NOR = 1 << 1,
MR_DATA_LOOP_NOR = 1 << 2,
MR_DATA_LOOPTRI = 1 << 3,
Fix T90017: Bone widget drawing inconsistent with editing The `lines_loose` extractor did not trigger loose geometry caching.
2021-07-21 14:46:41 -03:00
MR_DATA_LOOSE_GEOM = 1 << 4,
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
/** Force loop normals calculation. */
Fix T90017: Bone widget drawing inconsistent with editing The `lines_loose` extractor did not trigger loose geometry caching.
2021-07-21 14:46:41 -03:00
MR_DATA_TAN_LOOP_NOR = 1 << 5,
Draw Cache: extract tris in parallel ranges The `ibo.tris` extraction in multithread is currently only done if the mesh has only 1 material. Now we cache a map indicating the index of each polygon after sort and thus allow the extraction of tris with materials in multithreaded. As caching is a heavy operation and was already being performed in multi-thread for triangle offsets, no significant improvements are expected. The benefit will be much greater when we can skip updating the cache while transforming a geometry. **Profiling:** ||master:|PATCH: |---|---|---| |large_mesh_editing_materials:|Average: 13.855380 FPS|Average: 15.525684 FPS ||rdata 9ms iter 36ms (frame 71ms)|rdata 9ms iter 29ms (frame 64ms) |subdiv_mesh_final_only_materials:|Average: 28.113742 FPS|Average: 28.633599 FPS ||rdata 0ms iter 1ms (frame 36ms)|rdata 0ms iter 1ms (frame 35ms) 1.1x overall speedup Differential Revision: https://developer.blender.org/D11445
2021-07-20 11:43:38 -03:00
MR_DATA_POLYS_SORTED = 1 << 6,
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Draw Cache: extract tris in parallel ranges The `ibo.tris` extraction in multithread is currently only done if the mesh has only 1 material. Now we cache a map indicating the index of each polygon after sort and thus allow the extraction of tris with materials in multithreaded. As caching is a heavy operation and was already being performed in multi-thread for triangle offsets, no significant improvements are expected. The benefit will be much greater when we can skip updating the cache while transforming a geometry. **Profiling:** ||master:|PATCH: |---|---|---| |large_mesh_editing_materials:|Average: 13.855380 FPS|Average: 15.525684 FPS ||rdata 9ms iter 36ms (frame 71ms)|rdata 9ms iter 29ms (frame 64ms) |subdiv_mesh_final_only_materials:|Average: 28.113742 FPS|Average: 28.633599 FPS ||rdata 0ms iter 1ms (frame 36ms)|rdata 0ms iter 1ms (frame 35ms) 1.1x overall speedup Differential Revision: https://developer.blender.org/D11445
2021-07-20 11:43:38 -03:00
ENUM_OPERATORS(eMRDataType, MR_DATA_POLYS_SORTED)
DrawManager: Use CPP for Mesh Extraction Scheduling. More cleanups will come to make this more CPP-like.
2021-06-01 12:12:13 +02:00
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
BLI_INLINE int mesh_render_mat_len_get(const Object *object, const Mesh *me)
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
{
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
if (me->edit_mesh != NULL) {
const Mesh *editmesh_eval_final = BKE_object_get_editmesh_eval_final(object);
if (editmesh_eval_final != NULL) {
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
return std::max<int>(1, editmesh_eval_final->totcol);
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
}
Materials: support changing materials during evaluation This commit allows that the evaluated geometry of an object has different materials from the original geometry. This is needed for geometry nodes. The main thing that changes for render engines and exporters is that the number of material slots on an object and its geometry might not match anymore. For original data, the slot counts are still equal, but not for evaluated data. Accessing material slots though rna stays the same. The behavior adapts automatically depending on whether the object is evaluated. When accessing materials of an object through `BKE_object_material_*` one has to use a new api for evaluated objects: `BKE_object_material_get_eval` and `BKE_object_material_count_eval`. In the future, the different behavior might be hidden behind a more general C api, but that would require quite a few more changes. The ground truth for the number of materials is the number of materials on the geometry now. This is important in the current design, because Eevee needs to know the number of materials just based on the mesh in `mesh_render_mat_len_get` and similar places. In a few places I had to add a special case for mesh edit mode to get it to work properly. This is unfortunate, but I don't see a way around that for now. Differential Revision: https://developer.blender.org/D11236
2021-05-19 10:23:09 +02:00
}
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
return std::max<int>(1, me->totcol);
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
}
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct MeshBufferList {
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* Every VBO below contains at least enough data for every loop in the mesh
* (except fdots and skin roots). For some VBOs, it extends to (in this exact order) :
* loops + loose_edges * 2 + loose_verts */
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
struct {
GPUVertBuf *pos_nor; /* extend */
GPUVertBuf *lnor; /* extend */
GPUVertBuf *edge_fac; /* extend */
GPUVertBuf *weights; /* extend */
Mesh Batch Cache: Split UV an tangent into 2 distinct VBOs This is done because they don't have the same update frequency. UV can be persistent even on geometry update (ex: skinned object) but tangents can change if the normals change. Also the name buffer per vbo was too small to contain all names.
2019-08-14 22:43:44 +02:00
GPUVertBuf *uv;
GPUVertBuf *tan;
Sculpt: Render Mask and Face Sets with modifiers active This removes the limitation of the sculpt overlays not being visible with modifiers active. Reviewed By: fclem Maniphest Tasks: T68900 Differential Revision: https://developer.blender.org/D8673
2020-09-18 19:30:02 +02:00
GPUVertBuf *sculpt_data;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
GPUVertBuf *orco;
/* Only for edit mode. */
GPUVertBuf *edit_data; /* extend */
GPUVertBuf *edituv_data;
Cleanup: use edituv prefix for stretch area/angle data
2021-02-17 15:36:18 +11:00
GPUVertBuf *edituv_stretch_area;
GPUVertBuf *edituv_stretch_angle;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
GPUVertBuf *mesh_analysis;
GPUVertBuf *fdots_pos;
GPUVertBuf *fdots_nor;
GPUVertBuf *fdots_uv;
// GPUVertBuf *fdots_edit_data; /* inside fdots_nor for now. */
GPUVertBuf *fdots_edituv_data;
Fix T68380 Skin modifier root not displayed
2019-10-15 01:49:53 +02:00
GPUVertBuf *skin_roots;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
/* Selection */
GPUVertBuf *vert_idx; /* extend */
GPUVertBuf *edge_idx; /* extend */
GPUVertBuf *poly_idx;
GPUVertBuf *fdot_idx;
Revert "Revert "Eevee: support accessing custom mesh attributes"" This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a. And also fix a compilation issue on windows. Differential Revision: https://developer.blender.org/D12969
2021-10-26 18:16:33 -03:00
GPUVertBuf *attr[GPU_MAX_ATTR];
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
GPUVertBuf *attr_viewer;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
} vbo;
/* Index Buffers:
* Only need to be updated when topology changes. */
struct {
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* Indices to vloops. Ordered per material. */
GPUIndexBuf *tris;
/* Loose edges last. */
GPUIndexBuf *lines;
/* Sub buffer of `lines` only containing the loose edges. */
GPUIndexBuf *lines_loose;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
GPUIndexBuf *points;
GPUIndexBuf *fdots;
/* 3D overlays. */
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* no loose edges. */
GPUIndexBuf *lines_paint_mask;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
GPUIndexBuf *lines_adjacency;
/* Uv overlays. (visibility can differ from 3D view) */
GPUIndexBuf *edituv_tris;
GPUIndexBuf *edituv_lines;
GPUIndexBuf *edituv_points;
GPUIndexBuf *edituv_fdots;
} ibo;
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct MeshBatchList {
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
/* Surfaces / Render */
GPUBatch *surface;
GPUBatch *surface_weights;
/* Edit mode */
GPUBatch *edit_triangles;
GPUBatch *edit_vertices;
GPUBatch *edit_edges;
GPUBatch *edit_vnor;
GPUBatch *edit_lnor;
GPUBatch *edit_fdots;
GPUBatch *edit_mesh_analysis;
GPUBatch *edit_skin_roots;
/* Edit UVs */
GPUBatch *edituv_faces_stretch_area;
GPUBatch *edituv_faces_stretch_angle;
GPUBatch *edituv_faces;
GPUBatch *edituv_edges;
GPUBatch *edituv_verts;
GPUBatch *edituv_fdots;
/* Edit selection */
GPUBatch *edit_selection_verts;
GPUBatch *edit_selection_edges;
GPUBatch *edit_selection_faces;
GPUBatch *edit_selection_fdots;
/* Common display / Other */
GPUBatch *all_verts;
GPUBatch *all_edges;
GPUBatch *loose_edges;
GPUBatch *edge_detection;
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* Individual edges with face normals. */
GPUBatch *wire_edges;
/* Loops around faces. no edges between selected faces */
GPUBatch *wire_loops;
/* Same as wire_loops but only has uvs. */
GPUBatch *wire_loops_uvs;
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
GPUBatch *sculpt_overlays;
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
GPUBatch *surface_viewer_attribute;
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
#define MBC_BATCH_LEN (sizeof(MeshBatchList) / sizeof(void *))
Cleanup: Fix missing-braces warning in draw manager Good side effect of the change is that it makes it so that the size of an array is more likely to be calculated at a compile time. More ideally we'll be using bli::Array instead of the bare array, but that is outside of the scope of this change.
2022-06-07 10:31:28 +02:00
#define MBC_VBO_LEN (sizeof(MeshBufferList::vbo) / sizeof(void *))
#define MBC_IBO_LEN (sizeof(MeshBufferList::ibo) / sizeof(void *))
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
#define MBC_BATCH_INDEX(batch) (offsetof(MeshBatchList, batch) / sizeof(void *))
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
enum DRWBatchFlag {
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
MBC_SURFACE = (1u << MBC_BATCH_INDEX(surface)),
MBC_SURFACE_WEIGHTS = (1u << MBC_BATCH_INDEX(surface_weights)),
MBC_EDIT_TRIANGLES = (1u << MBC_BATCH_INDEX(edit_triangles)),
MBC_EDIT_VERTICES = (1u << MBC_BATCH_INDEX(edit_vertices)),
MBC_EDIT_EDGES = (1u << MBC_BATCH_INDEX(edit_edges)),
MBC_EDIT_VNOR = (1u << MBC_BATCH_INDEX(edit_vnor)),
MBC_EDIT_LNOR = (1u << MBC_BATCH_INDEX(edit_lnor)),
MBC_EDIT_FACEDOTS = (1u << MBC_BATCH_INDEX(edit_fdots)),
MBC_EDIT_MESH_ANALYSIS = (1u << MBC_BATCH_INDEX(edit_mesh_analysis)),
MBC_SKIN_ROOTS = (1u << MBC_BATCH_INDEX(edit_skin_roots)),
MBC_EDITUV_FACES_STRETCH_AREA = (1u << MBC_BATCH_INDEX(edituv_faces_stretch_area)),
MBC_EDITUV_FACES_STRETCH_ANGLE = (1u << MBC_BATCH_INDEX(edituv_faces_stretch_angle)),
MBC_EDITUV_FACES = (1u << MBC_BATCH_INDEX(edituv_faces)),
MBC_EDITUV_EDGES = (1u << MBC_BATCH_INDEX(edituv_edges)),
MBC_EDITUV_VERTS = (1u << MBC_BATCH_INDEX(edituv_verts)),
MBC_EDITUV_FACEDOTS = (1u << MBC_BATCH_INDEX(edituv_fdots)),
MBC_EDIT_SELECTION_VERTS = (1u << MBC_BATCH_INDEX(edit_selection_verts)),
MBC_EDIT_SELECTION_EDGES = (1u << MBC_BATCH_INDEX(edit_selection_edges)),
MBC_EDIT_SELECTION_FACES = (1u << MBC_BATCH_INDEX(edit_selection_faces)),
MBC_EDIT_SELECTION_FACEDOTS = (1u << MBC_BATCH_INDEX(edit_selection_fdots)),
MBC_ALL_VERTS = (1u << MBC_BATCH_INDEX(all_verts)),
MBC_ALL_EDGES = (1u << MBC_BATCH_INDEX(all_edges)),
MBC_LOOSE_EDGES = (1u << MBC_BATCH_INDEX(loose_edges)),
MBC_EDGE_DETECTION = (1u << MBC_BATCH_INDEX(edge_detection)),
MBC_WIRE_EDGES = (1u << MBC_BATCH_INDEX(wire_edges)),
MBC_WIRE_LOOPS = (1u << MBC_BATCH_INDEX(wire_loops)),
MBC_WIRE_LOOPS_UVS = (1u << MBC_BATCH_INDEX(wire_loops_uvs)),
MBC_SCULPT_OVERLAYS = (1u << MBC_BATCH_INDEX(sculpt_overlays)),
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
MBC_VIEWER_ATTRIBUTE_OVERLAY = (1u << MBC_BATCH_INDEX(surface_viewer_attribute)),
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
MBC_SURFACE_PER_MAT = (1u << MBC_BATCH_LEN),
};
ENUM_OPERATORS(DRWBatchFlag, MBC_SURFACE_PER_MAT);
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
BLI_STATIC_ASSERT(MBC_BATCH_LEN < 32, "Number of batches exceeded the limit of bit fields");
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct MeshExtractLooseGeom {
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
int edge_len;
int vert_len;
int *verts;
int *edges;
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
Fix T88456: DrawManager: Keep subset RenderMeshData around when geometry does not change. Reuse loose geometry during selection (and other operations) from previous calculation. Loose geometry stays the same, but was recalculated to determine the size of GPU buffers. This patch would reuse the previous loose geometry when geometry wasn't changed. Although not the main bottleneck during selection it is measurable. Master. `rdata 46ms iter 55ms (frame 410ms)` This patch. `rdata 5ms iter 52ms (frame 342ms)` Reviewed By: mano-wii Differential Revision: https://developer.blender.org/D11339
2021-05-31 09:32:37 +02:00
/**
* Data that are kept around between extractions to reduce rebuilding time.
*
* - Loose geometry.
*/
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct MeshBufferCache {
Cleanup: move the buffer list to 'MeshBufferCache' The cache is used to fill the buffer list.
2021-08-23 13:28:55 -03:00
MeshBufferList buff;
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
MeshExtractLooseGeom loose_geom;
DrawManager: Cache material offsets. When using multiple materials in a single mesh the most time is spend in counting the offsets of each material for the sorting. This patch moves the counting of the offsets to render mesh data and caches it as long as the geometry doesn't change. This patch doesn't include multithreading of this code. Reviewed By: mano-wii Differential Revision: https://developer.blender.org/D11612
2021-06-15 15:31:17 +02:00
struct {
Draw Cache: extract tris in parallel ranges The `ibo.tris` extraction in multithread is currently only done if the mesh has only 1 material. Now we cache a map indicating the index of each polygon after sort and thus allow the extraction of tris with materials in multithreaded. As caching is a heavy operation and was already being performed in multi-thread for triangle offsets, no significant improvements are expected. The benefit will be much greater when we can skip updating the cache while transforming a geometry. **Profiling:** ||master:|PATCH: |---|---|---| |large_mesh_editing_materials:|Average: 13.855380 FPS|Average: 15.525684 FPS ||rdata 9ms iter 36ms (frame 71ms)|rdata 9ms iter 29ms (frame 64ms) |subdiv_mesh_final_only_materials:|Average: 28.113742 FPS|Average: 28.633599 FPS ||rdata 0ms iter 1ms (frame 36ms)|rdata 0ms iter 1ms (frame 35ms) 1.1x overall speedup Differential Revision: https://developer.blender.org/D11445
2021-07-20 11:43:38 -03:00
int *tri_first_index;
int *mat_tri_len;
DrawManager: Cache material offsets. When using multiple materials in a single mesh the most time is spend in counting the offsets of each material for the sorting. This patch moves the counting of the offsets to render mesh data and caches it as long as the geometry doesn't change. This patch doesn't include multithreading of this code. Reviewed By: mano-wii Differential Revision: https://developer.blender.org/D11612
2021-06-15 15:31:17 +02:00
int visible_tri_len;
Draw Cache: extract tris in parallel ranges The `ibo.tris` extraction in multithread is currently only done if the mesh has only 1 material. Now we cache a map indicating the index of each polygon after sort and thus allow the extraction of tris with materials in multithreaded. As caching is a heavy operation and was already being performed in multi-thread for triangle offsets, no significant improvements are expected. The benefit will be much greater when we can skip updating the cache while transforming a geometry. **Profiling:** ||master:|PATCH: |---|---|---| |large_mesh_editing_materials:|Average: 13.855380 FPS|Average: 15.525684 FPS ||rdata 9ms iter 36ms (frame 71ms)|rdata 9ms iter 29ms (frame 64ms) |subdiv_mesh_final_only_materials:|Average: 28.113742 FPS|Average: 28.633599 FPS ||rdata 0ms iter 1ms (frame 36ms)|rdata 0ms iter 1ms (frame 35ms) 1.1x overall speedup Differential Revision: https://developer.blender.org/D11445
2021-07-20 11:43:38 -03:00
} poly_sorted;
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Fix T88456: DrawManager: Keep subset RenderMeshData around when geometry does not change. Reuse loose geometry during selection (and other operations) from previous calculation. Loose geometry stays the same, but was recalculated to determine the size of GPU buffers. This patch would reuse the previous loose geometry when geometry wasn't changed. Although not the main bottleneck during selection it is measurable. Master. `rdata 46ms iter 55ms (frame 410ms)` This patch. `rdata 5ms iter 52ms (frame 342ms)` Reviewed By: mano-wii Differential Revision: https://developer.blender.org/D11339
2021-05-31 09:32:37 +02:00
Cleanup: move the buffer list to 'MeshBufferCache' The cache is used to fill the buffer list.
2021-08-23 13:28:55 -03:00
#define FOREACH_MESH_BUFFER_CACHE(batch_cache, mbc) \
for (MeshBufferCache *mbc = &batch_cache->final; \
mbc == &batch_cache->final || mbc == &batch_cache->cage || mbc == &batch_cache->uv_cage; \
mbc = (mbc == &batch_cache->final) ? \
&batch_cache->cage : \
((mbc == &batch_cache->cage) ? &batch_cache->uv_cage : NULL))
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
struct MeshBatchCache {
Cleanup: move the buffer list to 'MeshBufferCache' The cache is used to fill the buffer list.
2021-08-23 13:28:55 -03:00
MeshBufferCache final, cage, uv_cage;
Fix T88456: DrawManager: Keep subset RenderMeshData around when geometry does not change. Reuse loose geometry during selection (and other operations) from previous calculation. Loose geometry stays the same, but was recalculated to determine the size of GPU buffers. This patch would reuse the previous loose geometry when geometry wasn't changed. Although not the main bottleneck during selection it is measurable. Master. `rdata 46ms iter 55ms (frame 410ms)` This patch. `rdata 5ms iter 52ms (frame 342ms)` Reviewed By: mano-wii Differential Revision: https://developer.blender.org/D11339
2021-05-31 09:32:37 +02:00
Cleanup: Isolate the batch list struct into a struct called MeshBatchList This allows for a simplification of macros and combines with `MeshBufferList`.
2021-08-23 12:46:14 -03:00
MeshBatchList batch;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Move 'tris_per_mat' member out of 'MeshBufferCache' `MeshBufferCache` is a struct representing a list of buffers. As such, `GPUIndexBuf **tris_per_mat` is out of place as it does not represent one of the buffers in the list. In fact this member should be close to `GPUBatch **surface_per_mat` as they are related. The code for dependencies between buffer and batch had to be reworked as it relies on the member's position. Differential Revision: https://developer.blender.org/D12227
2021-08-23 09:52:13 -03:00
/* Index buffer per material. These are subranges of `ibo.tris` */
GPUIndexBuf **tris_per_mat;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
GPUBatch **surface_per_mat;
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
DRWSubdivCache *subdiv_cache;
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
DRWBatchFlag batch_requested;
DRWBatchFlag batch_ready;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* Settings to determine if cache is invalid. */
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
int edge_len;
int tri_len;
int poly_len;
int vert_len;
int mat_len;
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
/* Instantly invalidates cache, skipping mesh check */
bool is_dirty;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
bool is_editmode;
bool is_uvsyncsel;
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
DRW_MeshWeightState weight_state;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
DRW_MeshCDMask cd_used, cd_needed, cd_used_over_time;
EEVEE: support Curves attributes rendering This adds support to render Curves attributes in EEVEE. Each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via create_requested which we cannot rely on anyway as contrary to the mesh batch, we do cannot really tell if attributes need to be updated or else via some `DRW_batch_requested`. Since point attributes need refinement, and since attributes are all cast to vec4/float4 to account for differences in type conversions between Blender and OpenGL, the refinement shader for points is used as is. The point attributes are stored for each subdivision level in CurvesEvalFinalCache. Each subdivision level also keeps track of the attributes already in use so they are properly updated when needed. Some basic garbage collection was added similar to what is done for meshes: if the attributes used over time have been different from the currently used attributes for too long, then the buffers are freed, ensuring that stale attributesare removed. This adds `CurvesInfos` to the shader creation info, which stores the scope in which the attributes are defined. Scopes are stored as booleans, in an array indexed by attribute loading order which is also the order in which the attributes were added to the material. A mapping is necessary between the indices used for the scoping, and the ones used in the Curves cache, as this may contain stale attributes which have not been garbage collected yet. Common utilities with the mesh code for handling requested attributes were moved to a separate file. Differential Revision: https://developer.blender.org/D14916
2022-05-24 05:02:57 +02:00
DRW_Attributes attr_used, attr_needed, attr_used_over_time;
Revert "Revert "Eevee: support accessing custom mesh attributes"" This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a. And also fix a compilation issue on windows. Differential Revision: https://developer.blender.org/D12969
2021-10-26 18:16:33 -03:00
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
int lastmatch;
/* Valid only if edge_detection is up to date. */
bool is_manifold;
Fix T63755: Area Stretching Overlay Support for UV Stretching overlay during multi object editing. The VBO now holds the ratios per fase. In the shader these ratios will be compared against the global ratios. The global rations are created from all selected objects. The current implementation does not fit well with the draw module. The plan is to move the drawing of other spaces towards the draw manager what leads to a better fit. Currently the details on this solution is unclear but this requirement will become an attentionpoint in the future design. Reviewed By: fclem Differential Revision: https://developer.blender.org/D5665
2019-09-03 13:42:11 +02:00
/* Total areas for drawing UV Stretching. Contains the summed area in mesh
* space (`tot_area`) and the summed area in uv space (`tot_uvarea`).
*
* Only valid after `DRW_mesh_batch_cache_create_requested` has been called. */
float tot_area, tot_uv_area;
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
bool no_loose_wire;
Refactor: Unify vertex and sculpt colors into new color attribute system. This commit removes sculpt colors from experimental status and unifies it with vertex colors. It introduces the concept of "color attributes", which are any attributes that represents colors. Color attributes can be represented with byte or floating-point numbers and can be stored in either vertices or face corners. Color attributes share a common namespace (so you can no longer have a floating-point sculpt color attribute and a byte vertex color attribute with the same name). Note: this commit does not include vertex paint mode, which is a separate patch, see: https://developer.blender.org/D14179 Differential Revision: https://developer.blender.org/D12587 Ref D12587
2022-04-05 11:42:55 -07:00
eV3DShadingColorType color_type;
bool pbvh_is_drawing;
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
};
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
DRW: sanitize 'DRW_mesh_batch_cache_dirty_tag' Create maps that specify which batches have vbo or ibo as a reference and use these maps to discard batches along with buffers. Differential Revision: https://developer.blender.org/D11588
2021-06-14 08:00:42 -03:00
#define MBC_EDITUV \
(MBC_EDITUV_FACES_STRETCH_AREA | MBC_EDITUV_FACES_STRETCH_ANGLE | MBC_EDITUV_FACES | \
MBC_EDITUV_EDGES | MBC_EDITUV_VERTS | MBC_EDITUV_FACEDOTS | MBC_WIRE_LOOPS_UVS)
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
namespace blender::draw {
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
void mesh_buffer_cache_create_requested(TaskGraph *task_graph,
Cleanup: warnings
2021-08-26 12:36:13 +10:00
MeshBatchCache *cache,
MeshBufferCache *mbc,
Fix depsgraphs sharing IDs via evaluated edit mesh The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-11 15:42:07 +01:00
Object *object,
Mesh Batch Cache: Refactor + Multithread For clarity sake, the batch cache now uses exclusively per Loop attributes. While this is a bit of a waste of VRAM (for the few case where per vert attribs are enough) it reduces the complexity and amount of overall VBO to update in general situations. This patch also makes the VertexBuffers filling multithreaded. This make the update of dense meshes a bit faster. The main bottleneck is the IndexBuffers update which cannot be multithreaded efficiently (have to increment a counter and/or do a final sorting pass). We introduce the concept of "extract" functions/step. All extract functions are executed in one thread each and if possible, using multiple thread for looping over all elements. Reviewed By: brecht Differential Revision: http://developer.blender.org/D5424
2019-07-14 16:49:44 +02:00
Mesh *me,
Cleanup: remove redundant const qualifiers for POD types MSVC used to warn about const mismatch for arguments passed by value. Remove these as newer versions of MSVC no longer show this warning.
2022-01-07 11:38:08 +11:00
bool is_editmode,
bool is_paint_mode,
bool is_mode_active,
BMesh: remove BMEditMesh.ob use for draw manager
2020-01-07 14:06:33 +11:00
const float obmat[4][4],
Cleanup: remove redundant const qualifiers for POD types MSVC used to warn about const mismatch for arguments passed by value. Remove these as newer versions of MSVC no longer show this warning.
2022-01-07 11:38:08 +11:00
bool do_final,
bool do_uvedit,
DRW: New High Quality Normal & Tangent extract This patch adds a dedicated path to extract 16bit normals instead of packing them into 10bits/comp. The tangents are also packed to 10bits/comp if not using the new High Quality Normal option. Fix T61024 Degraded texture shading on dense meshes Reviewed By: brecht Differential Revision: https://developer.blender.org/D6614
2020-02-19 01:44:52 +01:00
const Scene *scene,
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
const ToolSettings *ts,
Cleanup: remove redundant const qualifiers for POD types MSVC used to warn about const mismatch for arguments passed by value. Remove these as newer versions of MSVC no longer show this warning.
2022-01-07 11:38:08 +11:00
bool use_hide);
DrawManager: Use CPP for Mesh Extraction Scheduling. More cleanups will come to make this more CPP-like.
2021-06-01 12:12:13 +02:00
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
void mesh_buffer_cache_create_requested_subdiv(MeshBatchCache *cache,
MeshBufferCache *mbc,
Cleanup: Comments and formatting in mesh extract headers Also remove accidentally committed WIP commented code.
2022-06-05 12:15:22 +02:00
DRWSubdivCache *subdiv_cache,
MeshRenderData *mr);
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
Cleanup: Move remaining mesh draw code to C++ After this commit, all mesh data extraction and drawing code is in C++, including headers, making it possible to use improved types for future performance improvements and simplifications. The only non-trivial changes are in `draw_cache_impl_mesh.cc`, where use of certain features and macros in C necessitated larger changes. Differential Revision: https://developer.blender.org/D15088
2022-06-05 12:04:42 +02:00
} // namespace blender::draw
Reference in New Issue Copy Permalink