griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
2ce5fc4a3e43ad8564e8e2fa5075465b0711d924
test2/source/blender/draw/intern/draw_cache_impl.h

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

334 lines
13 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 2016 Blender Foundation. */
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup draw
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
*/
#pragma once
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch;
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct GPUMaterial;
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUVertBuf;
Hair UV implementation for Eevee This implements UV support for Eevee hair, enabling the usage of textures.
2017-06-22 19:19:55 +02:00
struct ModifierData;
Draw manager: Start using more explicit API for particle edit mode
2018-05-09 11:14:27 +02:00
struct PTCacheEdit;
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct ParticleSystem;
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
struct TaskGraph;
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
struct Curve;
Curves: Rename "Hair" types, variables, and functions to "Curves" Based on discussions from T95355 and T94193, the plan is to use the name "Curves" to describe the data-block container for multiple curves. Eventually this will replace the existing "Curve" data-block. However, it will be a while before the curve data-block can be replaced so in order to distinguish the two curve types in the UI, "Hair Curves" will be used, but eventually changed back to "Curves". This patch renames "hair-related" files, functions, types, and variable names to this convention. A deep rename is preferred to keep code consistent and to avoid any "hair" terminology from leaking, since the new data-block is meant for all curve types, not just hair use cases. The downside of this naming is that the difference between "Curve" and "Curves" has become important. That was considered during design discussons and deemed acceptable, especially given the non-permanent nature of the somewhat common conflict. Some points of interest: - All DNA compatibility is lost, just like rBf59767ff9729. - I renamed `ID_HA` to `ID_CV` so there is no complete mismatch. - `hair_curves` is used where necessary to distinguish from the existing "curves" plural. - I didn't rename any of the cycles/rendering code function names, since that is also used by the old hair particle system. Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
struct Curves;
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
struct Lattice;
struct Mesh;
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
struct PointCloud;
struct Volume;
Cleanup: sort file, struct lists
2020-03-20 12:19:44 +11:00
struct bGPdata;
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
CleanUp: Introduce `eMeshBatchDirtyMode` enum It used to be an int mode.
2020-10-09 07:27:18 +02:00
#include "BKE_mesh_types.h"
Cleanup: Move curve draw cache implementation to C++ I'd like to use this file to draw curves from geometry nodes, which would otherwise require implementing a C API. The changes in this commit are minimal, mostly just casts and changing to nullptr. Differential Revision: https://developer.blender.org/D11350
2021-05-21 17:28:19 -04:00
#ifdef __cplusplus
extern "C" {
#endif
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/* -------------------------------------------------------------------- */
/** \name Expose via BKE callbacks
* \{ */
Revert "CleanUp: Introduce `eMeshBatchDirtyMode` enum" This reverts commit 0796807720882731cdb70be144aa182e9b0b9ee5.
2020-10-09 07:25:43 +02:00
void DRW_curve_batch_cache_dirty_tag(struct Curve *cu, int mode);
DRW: Make batch validation run first during iteration This reduces the cost of querying the batches to the batch cache.
2019-05-07 23:21:16 +02:00
void DRW_curve_batch_cache_validate(struct Curve *cu);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
void DRW_curve_batch_cache_free(struct Curve *cu);
CleanUp: Introduce `eMeshBatchDirtyMode` enum It used to be an int mode.
2020-10-09 07:27:18 +02:00
void DRW_mesh_batch_cache_dirty_tag(struct Mesh *me, eMeshBatchDirtyMode mode);
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
void DRW_mesh_batch_cache_validate(struct Object *object, struct Mesh *me);
Cleanup: Simplify freeing and clearing mesh runtime data Separate freeing and clearing mesh runtime data in a more obvious way. This makes it easier to see what data is meant to be cleared on certain changes, rather than conflating it with freeing all of the runtime caches. Also comment and reduce the surface area of the "mesh runtime" API. The redundancy in some functions made it confusing which one should be used, resulting in subtle bugs or unnecessary boilerplate code. Also, now bke::MeshRuntime is able to free all the data it owns by itself, which makes this area easier to reason about. That required changing the interface of a few functions to avoid passing Mesh when they really just dealt with some runtime struct. With more RAII semantics in the future, more of this manual freeing will become unnecessary.
2022-11-15 19:15:35 -06:00
void DRW_mesh_batch_cache_free(void *batch_cache);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
Revert "CleanUp: Introduce `eMeshBatchDirtyMode` enum" This reverts commit 0796807720882731cdb70be144aa182e9b0b9ee5.
2020-10-09 07:25:43 +02:00
void DRW_lattice_batch_cache_dirty_tag(struct Lattice *lt, int mode);
DRW: Make batch validation run first during iteration This reduces the cost of querying the batches to the batch cache.
2019-05-07 23:21:16 +02:00
void DRW_lattice_batch_cache_validate(struct Lattice *lt);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
void DRW_lattice_batch_cache_free(struct Lattice *lt);
Revert "CleanUp: Introduce `eMeshBatchDirtyMode` enum" This reverts commit 0796807720882731cdb70be144aa182e9b0b9ee5.
2020-10-09 07:25:43 +02:00
void DRW_particle_batch_cache_dirty_tag(struct ParticleSystem *psys, int mode);
Implement hair drawing with Draw Manager in Clay engine Part of T51378
2017-05-09 16:23:47 +02:00
void DRW_particle_batch_cache_free(struct ParticleSystem *psys);
Rename: *_batch_cache_dirty > *_batch_cache_dirty_tag
2018-08-23 10:14:29 -03:00
void DRW_gpencil_batch_cache_dirty_tag(struct bGPdata *gpd);
New Grease Pencil object for 2D animation This commit merge the full development done in greasepencil-object branch and include mainly the following features. - New grease pencil object. - New drawing engine. - New grease pencil modes Draw/Sculpt/Edit and Weight Paint. - New brushes for grease pencil. - New modifiers for grease pencil. - New shaders FX. - New material system (replace old palettes and colors). - Split of annotations (old grease pencil) and new grease pencil object. - UI adapted to blender 2.8. You can get more info here: https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/ https://code.blender.org/2018/07/grease-pencil-status-update/ This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible. Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
2018-07-31 10:22:19 +02:00
void DRW_gpencil_batch_cache_free(struct bGPdata *gpd);
Curves: Rename "Hair" types, variables, and functions to "Curves" Based on discussions from T95355 and T94193, the plan is to use the name "Curves" to describe the data-block container for multiple curves. Eventually this will replace the existing "Curve" data-block. However, it will be a while before the curve data-block can be replaced so in order to distinguish the two curve types in the UI, "Hair Curves" will be used, but eventually changed back to "Curves". This patch renames "hair-related" files, functions, types, and variable names to this convention. A deep rename is preferred to keep code consistent and to avoid any "hair" terminology from leaking, since the new data-block is meant for all curve types, not just hair use cases. The downside of this naming is that the difference between "Curve" and "Curves" has become important. That was considered during design discussons and deemed acceptable, especially given the non-permanent nature of the somewhat common conflict. Some points of interest: - All DNA compatibility is lost, just like rBf59767ff9729. - I renamed `ID_HA` to `ID_CV` so there is no complete mismatch. - `hair_curves` is used where necessary to distinguish from the existing "curves" plural. - I didn't rename any of the cycles/rendering code function names, since that is also used by the old hair particle system. Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
void DRW_curves_batch_cache_dirty_tag(struct Curves *curves, int mode);
void DRW_curves_batch_cache_validate(struct Curves *curves);
void DRW_curves_batch_cache_free(struct Curves *curves);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
Revert "CleanUp: Introduce `eMeshBatchDirtyMode` enum" This reverts commit 0796807720882731cdb70be144aa182e9b0b9ee5.
2020-10-09 07:25:43 +02:00
void DRW_pointcloud_batch_cache_dirty_tag(struct PointCloud *pointcloud, int mode);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
void DRW_pointcloud_batch_cache_validate(struct PointCloud *pointcloud);
void DRW_pointcloud_batch_cache_free(struct PointCloud *pointcloud);
Revert "CleanUp: Introduce `eMeshBatchDirtyMode` enum" This reverts commit 0796807720882731cdb70be144aa182e9b0b9ee5.
2020-10-09 07:25:43 +02:00
void DRW_volume_batch_cache_dirty_tag(struct Volume *volume, int mode);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
void DRW_volume_batch_cache_validate(struct Volume *volume);
void DRW_volume_batch_cache_free(struct Volume *volume);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Garbage Collection
* \{ */
DRW: Add batch garbage collection This is only working for shading batches for the moment and only if some Custom data layer are not needed anymore. The collection rate is hardcoded at 60 sec but could be exposed to the user. This system can be extended and discard most unused batches in the future. This commit is in prevision of removing BKE_MESH_BATCH_DIRTY_SHADING when changing shader parameters.
2019-04-19 02:22:22 +02:00
void DRW_batch_cache_free_old(struct Object *ob, int ctime);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/**
* Thread safety need to be assured by caller. Don't call this during drawing.
* \note For now this only free the shading batches / VBO if any cd layers is not needed anymore.
*/
DRW: Add batch garbage collection This is only working for shading batches for the moment and only if some Custom data layer are not needed anymore. The collection rate is hardcoded at 60 sec but could be exposed to the user. This system can be extended and discard most unused batches in the future. This commit is in prevision of removing BKE_MESH_BATCH_DIRTY_SHADING when changing shader parameters.
2019-04-19 02:22:22 +02:00
void DRW_mesh_batch_cache_free_old(struct Mesh *me, int ctime);
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
void DRW_curves_batch_cache_free_old(struct Curves *curves, int ctime);
DRW: Pointcloud: Refactor drawing to remove instancing This change the attribute binding scheme to something similar to the curves objects. Attributes are now buffer textures sampled per points. The actual geometry is now rendered using an index buffer that avoid too many vertex shader invocation. Drawcall is wrapped in a DRW function to reduce complexity of future changes.
2022-10-25 10:43:47 +02:00
void DRW_pointcloud_batch_cache_free_old(struct PointCloud *pointcloud, int ctime);
DRW: Add batch garbage collection This is only working for shading batches for the moment and only if some Custom data layer are not needed anymore. The collection rate is hardcoded at 60 sec but could be exposed to the user. This system can be extended and discard most unused batches in the future. This commit is in prevision of removing BKE_MESH_BATCH_DIRTY_SHADING when changing shader parameters.
2019-04-19 02:22:22 +02:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Generic
* \{ */
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
void DRW_vertbuf_create_wiredata(struct GPUVertBuf *vbo, int vert_len);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Curve
* \{ */
DrawManager: High quality normals for non meshes This adds high quality normals for non meshes. These include * Volumetric Object Wireframe * Metaballs * Extracted Curves * Curves in edit mode This is in preparation to fix a regression in recent AMD drivers where the `GL_INT_2_10_10_10_REV` data type isn't working in Polaris cards.
2020-12-18 16:06:26 +01:00
void DRW_curve_batch_cache_create_requested(struct Object *ob, const struct Scene *scene);
Curve Batch Cache: Rework Implementation to use new batch request Shaded triangles are not yet implemented (request from gpumaterials). This also changes the mechanism to draw curve normals to make it not dependant on normal size display. This way different viewport can reuse the same batch.
2018-12-13 01:26:07 +01:00
Fix T72593 Blender crashes when modifier change the material count Instead of changing the modifiers behavior, we make sure to always use the data->totcol instead of the ob->totcol. Also we centralize getting this number to avoid future issues. Fix T72593 Blender crashes when separating mesh Fix T72017 Crash on set visibility change
2020-01-28 16:39:33 +01:00
int DRW_curve_material_count_get(struct Curve *cu);
Curve Batch Cache: Rework Implementation to use new batch request Shaded triangles are not yet implemented (request from gpumaterials). This also changes the mechanism to draw curve normals to make it not dependant on normal size display. This way different viewport can reuse the same batch.
2018-12-13 01:26:07 +01:00
struct GPUBatch *DRW_curve_batch_cache_get_wire_edge(struct Curve *cu);
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
struct GPUBatch *DRW_curve_batch_cache_get_wire_edge_viewer_attribute(struct Curve *cu);
Curve Batch Cache: Rework Implementation to use new batch request Shaded triangles are not yet implemented (request from gpumaterials). This also changes the mechanism to draw curve normals to make it not dependant on normal size display. This way different viewport can reuse the same batch.
2018-12-13 01:26:07 +01:00
struct GPUBatch *DRW_curve_batch_cache_get_normal_edge(struct Curve *cu);
DRW: Batch Cache: Mesh: Port edit mesh batches to batch request method This also do some renaming/cleanups.
2018-12-10 15:29:04 +01:00
struct GPUBatch *DRW_curve_batch_cache_get_edit_edges(struct Curve *cu);
Fix T76126 Overlay: Glitch when hiding Nurb vertices
2020-05-13 21:20:18 +02:00
struct GPUBatch *DRW_curve_batch_cache_get_edit_verts(struct Curve *cu);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Lattice
* \{ */
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_lattice_batch_cache_get_all_edges(struct Lattice *lt,
bool use_weight,
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
int actdef);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_lattice_batch_cache_get_all_verts(struct Lattice *lt);
DRW: Batch Cache: Mesh: Port edit mesh batches to batch request method This also do some renaming/cleanups.
2018-12-10 15:29:04 +01:00
struct GPUBatch *DRW_lattice_batch_cache_get_edit_verts(struct Lattice *lt);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
Cleanup: Remove redundant doxygen section Also remove const for the object argument, since the object data is logically modified by generating the data.
2022-06-17 09:44:37 +02:00
/** \name Curves
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
* \{ */
Curves: Rename "Hair" types, variables, and functions to "Curves" Based on discussions from T95355 and T94193, the plan is to use the name "Curves" to describe the data-block container for multiple curves. Eventually this will replace the existing "Curve" data-block. However, it will be a while before the curve data-block can be replaced so in order to distinguish the two curve types in the UI, "Hair Curves" will be used, but eventually changed back to "Curves". This patch renames "hair-related" files, functions, types, and variable names to this convention. A deep rename is preferred to keep code consistent and to avoid any "hair" terminology from leaking, since the new data-block is meant for all curve types, not just hair use cases. The downside of this naming is that the difference between "Curve" and "Curves" has become important. That was considered during design discussons and deemed acceptable, especially given the non-permanent nature of the somewhat common conflict. Some points of interest: - All DNA compatibility is lost, just like rBf59767ff9729. - I renamed `ID_HA` to `ID_CV` so there is no complete mismatch. - `hair_curves` is used where necessary to distinguish from the existing "curves" plural. - I didn't rename any of the cycles/rendering code function names, since that is also used by the old hair particle system. Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
int DRW_curves_material_count_get(struct Curves *curves);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
Curves: Add sculpt selection overlay This commit adds visualization to the selection in curves sculpt mode. Previously it was only possible to see the selection when it was connected to a material. In order to obstruct the users vision as little as possible, the selected areas of the curve are left as is, but a dark overlay is drawn over unselected areas. To make it work, the overlay requests the selection attribute and then ensures that the evaluation is complete for curves. Then it retrieves the evaluated selection GPU texture and passes that to the shader. This reuses the existing generic attribute extraction system because there currently wouldn't be any benefits to dealing with selection separately, and because it avoids duplication of the logic that extracts attributes from curves and evaluates them if necessary. Differential Revision: https://developer.blender.org/D15219
2022-07-07 08:06:30 -05:00
/**
* Provide GPU access to a specific evaluated attribute on curves.
*
* \return A pointer to location where the texture will be
* stored, which will be filled by #DRW_shgroup_curves_create_sub.
*/
Cleanup: Curves: Remove GPUTexture wrappers for buffer texture These are unecessary now that we can bind buffers as textures directly.
2022-10-25 16:16:58 +02:00
struct GPUVertBuf **DRW_curves_texture_for_evaluated_attribute(struct Curves *curves,
Curves: Add sculpt selection overlay This commit adds visualization to the selection in curves sculpt mode. Previously it was only possible to see the selection when it was connected to a material. In order to obstruct the users vision as little as possible, the selected areas of the curve are left as is, but a dark overlay is drawn over unselected areas. To make it work, the overlay requests the selection attribute and then ensures that the evaluation is complete for curves. Then it retrieves the evaluated selection GPU texture and passes that to the shader. This reuses the existing generic attribute extraction system because there currently wouldn't be any benefits to dealing with selection separately, and because it avoids duplication of the logic that extracts attributes from curves and evaluates them if necessary. Differential Revision: https://developer.blender.org/D15219
2022-07-07 08:06:30 -05:00
const char *name,
bool *r_is_point_domain);
Cleanup: Remove redundant doxygen section Also remove const for the object argument, since the object data is logically modified by generating the data.
2022-06-17 09:44:37 +02:00
struct GPUBatch *DRW_curves_batch_cache_get_edit_points(struct Curves *curves);
Fix T101889: Curves editmode points are drawn from evaluated curves Editmode should display the original (non-evaluated) points unless there is something like an "On Cage" option of a modifier [which none of the curves modifiers have]. This was not the case since the introduction in rBe15320568a29. So we now draw the editpoints from the original curves. This also means that original and evaluated curves might not have the same number of points, so we have to get independent of `proc_point_buf` since that would possibly create vertexbuffers of different sizes (compared to the original curves) which is not allowed for a single batch. - remove the "pos" alias from the vertex buffer format of proc_point_buf - instead, create a new "edit_points_pos" vertex buffer - fill that with the original (un-evaluated) curves positions - dont request `proc_point_buf` anymore - rename the editpoints flags buffer to be more consistent And since original and evaluated points might also be in completely different positions, we also need to draw connecting lines between those editpoints to not have them float in thin air. For drawing these in editmode, a simple polyline was chosen (instead of drawing lines in a resolution that is take from the old particle system -- which is not depending on points even but has a hardcoded resolution that can only be upped by the hair_subdiv scene render setting) - create appropriate batch and indexbuffer for this - positions vertex buffer can be reused - reuse particle edit shader (instead of curve edi shader) to get segment highlighting {F14055436} NOTE: this also removes the broken depth handling and instead makes it work (also XRay is properly taken into account) by binding the correct overlay framebuffer. NOTE: to further clarify the distinction between curves drawing (that is based on the old partice system drawing) and drawing in editmode, the corresponding vertexbuffers have been moved out of CurvesEvalCache into CurvesBatchCache directly. NOTE: drawing the lines in editmode could be improved (taking the "real" resolution of splines into account, but since this should happen on the GPU in a compute shader, this is for later) Potentionally fixes T101889. Maniphest Tasks: T101889 Differential Revision: https://developer.blender.org/D16281
2022-12-06 14:49:44 +01:00
struct GPUBatch *DRW_curves_batch_cache_get_edit_lines(struct Curves *curves);
Cleanup: Remove redundant doxygen section Also remove const for the object argument, since the object data is logically modified by generating the data.
2022-06-17 09:44:37 +02:00
void DRW_curves_batch_cache_create_requested(struct Object *ob);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name PointCloud
* \{ */
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
int DRW_pointcloud_material_count_get(struct PointCloud *pointcloud);
DRW: Pointcloud: Refactor drawing to remove instancing This change the attribute binding scheme to something similar to the curves objects. Attributes are now buffer textures sampled per points. The actual geometry is now rendered using an index buffer that avoid too many vertex shader invocation. Drawcall is wrapped in a DRW function to reduce complexity of future changes.
2022-10-25 10:43:47 +02:00
struct GPUVertBuf **DRW_pointcloud_evaluated_attribute(struct PointCloud *pointcloud,
const char *name);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
struct GPUBatch *DRW_pointcloud_batch_cache_get_dots(struct Object *ob);
DRW: Pointcloud: Refactor drawing to remove instancing This change the attribute binding scheme to something similar to the curves objects. Attributes are now buffer textures sampled per points. The actual geometry is now rendered using an index buffer that avoid too many vertex shader invocation. Drawcall is wrapped in a DRW function to reduce complexity of future changes.
2022-10-25 10:43:47 +02:00
void DRW_pointcloud_batch_cache_create_requested(struct Object *ob);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Volume
* \{ */
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
int DRW_volume_material_count_get(struct Volume *volume);
struct GPUBatch *DRW_volume_batch_cache_get_wireframes_face(struct Volume *volume);
Volumes: support selection and outlines in viewport Previously, one could only select a volume object in the outliner or by clicking on the object origin. This patch allows you to click on the actual volume. Furthermore, the generated (invisible) mesh that is used for selection is also used to draw an outline for the volume object now. Reviewers: brecht Differential Revision: https://developer.blender.org/D9022
2020-09-29 12:39:41 +02:00
struct GPUBatch *DRW_volume_batch_cache_get_selection_surface(struct Volume *volume);
Objects: Eevee and workbench rendering of new Volume, Hair, PointCloud Only the volume drawing part is really finished and exposed to the user. Hair plugs into the existing hair rendering code and is fairly straightforward. The pointcloud drawing is a hack using overlays rather than Eevee and workbench. The most tricky part for volume rendering is the case where each volume grid has a different transform, which requires an additional matrix in the shader and non-trivial logic in Eevee volume drawing. In the common case were all the transforms match we don't use the additional per-grid matrix in the shader. Ref T73201, T68981 Differential Revision: https://developer.blender.org/D6955
2020-03-17 16:27:08 +01:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Mesh
* \{ */
/**
* Can be called for any surface type. Mesh *me is the final mesh.
*/
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
void DRW_mesh_batch_cache_create_requested(struct TaskGraph *task_graph,
struct Object *ob,
Mesh Batch Cache: Put context evaluation out of batch cache This is in order to be able to call DRW_mesh_batch_cache_create_requested outside of the draw manager
2018-12-22 21:00:23 +01:00
struct 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
const struct Scene *scene,
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_paint_mode,
bool use_hide);
DRW: Batch Cache: Add batch request system This makes it possible for engines to ask for batches and only fill their data after all engine populate functions have run. This means that, when creating the batches data we already know all the batches that are needed for this redraw and the needed data. This allows for less redundant data preparation and better attrib masking. Ideally, we should run all viewports populate function before executing the batch construction but this is not the scope of this patch. Conversion from the old request method will be progressive and both can coexist (see uses of mesh_create_pos_and_nor()).
2018-12-08 20:10:20 +01:00
DRW: Cleanup / Renaming of mesh batch cache functions THis is in order to avoid the jungle of names being different at each step of the API. Also removes some unused functions.
2018-12-18 17:10:38 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_all_verts(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_all_edges(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_loose_edges(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edge_detection(struct Mesh *me, bool *r_is_manifold);
struct GPUBatch *DRW_mesh_batch_cache_get_surface(struct Mesh *me);
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
struct GPUBatch *DRW_mesh_batch_cache_get_surface_edges(struct Object *object, struct Mesh *me);
struct GPUBatch **DRW_mesh_batch_cache_get_surface_shaded(struct Object *object,
struct Mesh *me,
Mesh Batch Cache: Optimization & Refactor shaded surface support This now only upload data per loops to the GPU, making use of index buffer to draw polygon. This make use of the vertex cache, speed up renders and saves a lot of vram. Update performance is also slightly faster and can even be improved further by updating only uvs or vcol independently. This commits breaks texture paint batches. It will be added back in another commit.
2018-12-16 15:17:31 +01:00
struct GPUMaterial **gpumat_array,
DRW: Use USHORT for vertex color and upload them in linear color to the GPU This way we remove the need for the srgb boolean uniform and a lot of code complexity. However, mesh update is going to be a bit slower. I did not benchmark the performance impact. This also fix a typo in draw_cache_impl_particles.c and fix hair not using vertex color in workbench. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D6610
2020-01-17 16:05:19 +01:00
uint gpumat_array_len);
Sculpt: Rewrite PBVH draw Rewrite PBVH draw to allocate attributes into individual VBOs. The old system tried to create a single VBO that could feed every open viewport. This required uploading every color and UV attribute to the viewport whether needed or not, often exceeding the VBO limit. This new system creates one VBO per attribute. Each attribute layout is given its own GPU batch which is cached inside the owning PBVH node. Notes: * This is a full C++ rewrite. The old code is still there; ripping it out can happen later. * PBVH nodes now have a collection of batches, PBVHBatches, that keeps track of all the batches inside the node. * Batches are built exclusively from a list of attributes. * Each attribute has its own VBO. * Overlays, workbench and EEVEE can all have different attribute layouts, each of which will get its own batch. Reviewed by: Clement Foucault Differential Revision: https://developer.blender.org/D15428 Ref D15428
2022-09-28 14:51:23 -07: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
struct GPUBatch **DRW_mesh_batch_cache_get_surface_texpaint(struct Object *object,
struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_surface_texpaint_single(struct Object *object,
struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_surface_vertpaint(struct Object *object,
struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_surface_sculpt(struct Object *object, struct Mesh *me);
DRW: Cleanup / Renaming of mesh batch cache functions THis is in order to avoid the jungle of names being different at each step of the API. Also removes some unused functions.
2018-12-18 17:10:38 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_surface_weights(struct Mesh *me);
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
struct GPUBatch *DRW_mesh_batch_cache_get_sculpt_overlays(struct Mesh *me);
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
struct GPUBatch *DRW_mesh_batch_cache_get_surface_viewer_attribute(struct Mesh *me);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Edit-Mesh Drawing
* \{ */
DRW: Batch Cache: Mesh: Port edit mesh batches to batch request method This also do some renaming/cleanups.
2018-12-10 15:29:04 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_triangles(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edit_vertices(struct Mesh *me);
Edit Mesh: Refactor Edit cage drawing to use old style drawing This is work in progress. Look is not final. This align data VBO data structure used for edti cage drawing to the one use for normal drawing. We no longer use barycentric coords to draw the lines an just rasterize line primitives for edge drawing. This is a bit slower than using the previous fast method but faster than the "correct" (edge artifact free) method. This also make the code way simpler. This also makes it possible to reuse possible and normal vbos used for shading if the edit cage matches the This also touches the UV batch code to share as much render data as possible. The code also prepare for edit cage "modified" drawing cage (with modifier applied) but is not enabled since selection and operators does not work with modified cage yet.
2019-02-04 01:13:51 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_edges(struct Mesh *me);
Cleanup: consistent naming for normals Use consistent naming for {vert/poly/loop/face}_normals.
2022-12-17 12:47:43 +11:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_vert_normals(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edit_loop_normals(struct Mesh *me);
DRW: Batch Cache: Mesh: Port edit mesh batches to batch request method This also do some renaming/cleanups.
2018-12-10 15:29:04 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_facedots(struct Mesh *me);
Fix T68380 Skin modifier root not displayed
2019-10-15 01:49:53 +02:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_skin_roots(struct Mesh *me);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Edit-mesh Selection
* \{ */
Mesh Selection: Port to batch cache request This makes it more future proof and remove baked id offset inside the vbos. Instead we add the offset as a uniform. This makes it possible to reuse the vbos instead of discarding them all the time. Also using batch request may reduce batches creation time.
2018-12-22 23:57:12 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_triangles_with_select_id(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_facedots_with_select_id(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edges_with_select_id(struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_verts_with_select_id(struct Mesh *me);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Object Mode Wireframe Overlays
* \{ */
DRW: Rework wireframe overlay implementation The shader is way simpler and run way faster on lower end hardware (2x faster on intel HD5000) but did not notice any improvement on AMD Vega. This also adds a few changes to the way the wireframes are drawn: - the slider is more linearly progressive. - optimize display shows all wires and progressively decrease "inner" wires intensity. This is subject to change in the future. - text/surface/metaballs support is pretty rough. More work needs to be done. This remove the optimization introduced in f1975a46390a5bf85bb7012375f9bc1e761fc516. This also removes the GPU side "sharpness" calculation which means that animated meshes with wireframe display will update slower. The CPU sharpness calculation has still room for optimization. Also it is not excluded that GPU calculation can be added back as a separate preprocessing pass (saving the computation result [compute or feedback]). The goal here was to have more speed for static objects and remove the dependency of having buffer textures with triangle count. This is preparation work for multithreading the whole DRW manager.
2018-12-07 05:03:01 +01:00
struct GPUBatch *DRW_mesh_batch_cache_get_wireframes_face(struct Mesh *me);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Edit-mesh UV Editor
* \{ */
/**
* Creates the #GPUBatch for drawing the UV Stretching Area Overlay.
* Optional retrieves the total area or total uv area of the mesh.
*
* The `cache->tot_area` and cache->tot_uv_area` update are calculation are
* only valid after calling `DRW_mesh_batch_cache_create_requested`.
*/
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
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_faces_stretch_area(struct Object *object,
struct Mesh *me,
Fix T69941 Assert selecting UVs Was caused by DRW_mesh_batch_cache_get_edituv_faces_stretch_area called after DRW_mesh_batch_cache_create_requested. So it was created on the wrong object/mesh.
2019-09-27 16:40:18 +02:00
float **tot_area,
float **tot_uv_area);
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
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_faces_stretch_angle(struct Object *object,
struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_faces(struct Object *object, struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_edges(struct Object *object, struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_verts(struct Object *object, struct Mesh *me);
struct GPUBatch *DRW_mesh_batch_cache_get_edituv_facedots(struct Object *object, struct Mesh *me);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name For Image UV Editor
* \{ */
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
struct GPUBatch *DRW_mesh_batch_cache_get_uv_edges(struct Object *object, struct Mesh *me);
Overlay: Mesh Analysis Enabling the drawing of the mesh analysis overlay. Currently the settings are part of the scene toolsettings. What makes sense, for 3d printing, but does not fit well with the per viewport blender 2.80 overlays. Reviewers: brecht, fclem Differential Revision: https://developer.blender.org/D4707
2019-04-18 08:00:59 +02:00
struct GPUBatch *DRW_mesh_batch_cache_get_edit_mesh_analysis(struct Mesh *me);
Cleanup: move draw-cache creation from BKE to DRW Creating draw-cache should only ever be used by the draw-manager.
2017-04-21 21:14:11 +10:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name For Direct Data Access
* \{ */
EEEVEE: Object Motion Blur: Initial Implementation This adds object motion blur vectors for EEVEE as well as better noise reduction for it. For TAA reprojection we just compute the motion vector on the fly based on camera motion and depth buffer. This makes possible to store another motion vector only for the blurring which is not useful for TAA history fetching. Motion Data is saved per object & per geometry if using deformation blur. We support deformation motion blur by saving previous VBO and modifying the actual GPUBatch for the geometry to include theses VBOs. We store Previous and Next frame motion in the same motion vector buffer (RG for prev and BA for next). This makes non linear motion blur (like rotating objects) less prone to outward/inward blur. We also improve the motion blur post process to expand outside the objects border. We use a tile base approach and the max size of the blur is set via a new render setting. We use a background reconstruction method that needs another setting (Background Separation). Sampling is done using a fixed 8 dithered samples per direction. The final render samples will clear the noise like other stochastic effects. One caveat is that hair particles are not yet supported. Support will come in another patch. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D7297
2020-06-19 17:02:55 +02:00
struct GPUVertBuf *DRW_mesh_batch_cache_pos_vertbuf_get(struct Mesh *me);
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
int DRW_mesh_material_count_get(const struct Object *object, const struct Mesh *me);
Fix T72593 Blender crashes when modifier change the material count Instead of changing the modifiers behavior, we make sure to always use the data->totcol instead of the ob->totcol. Also we centralize getting this number to avoid future issues. Fix T72593 Blender crashes when separating mesh Fix T72017 Crash on set visibility change
2020-01-28 16:39:33 +01:00
Edit Mesh: Add support for draw option parameters The visuals was already implemented but we could not toggle them off.
2018-09-05 17:02:00 +02:00
/* Edit mesh bitflags (is this the right place?) */
enum {
Edit Mesh: Refactor Edit cage drawing to use old style drawing This is work in progress. Look is not final. This align data VBO data structure used for edti cage drawing to the one use for normal drawing. We no longer use barycentric coords to draw the lines an just rasterize line primitives for edge drawing. This is a bit slower than using the previous fast method but faster than the "correct" (edge artifact free) method. This also make the code way simpler. This also makes it possible to reuse possible and normal vbos used for shading if the edit cage matches the This also touches the UV batch code to share as much render data as possible. The code also prepare for edit cage "modified" drawing cage (with modifier applied) but is not enabled since selection and operators does not work with modified cage yet.
2019-02-04 01:13:51 +01:00
VFLAG_VERT_ACTIVE = 1 << 0,
VFLAG_VERT_SELECTED = 1 << 1,
Fix curve handle color ID display Regression in 49f59092e7c8c caused all handles to display using the 'aligned' theme color. Arrange flags to fix this, add assert to avoid this happening again. Also rename flag so it's use is clearer.
2020-06-15 15:28:51 +10:00
VFLAG_VERT_SELECTED_BEZT_HANDLE = 1 << 2,
VFLAG_EDGE_ACTIVE = 1 << 3,
VFLAG_EDGE_SELECTED = 1 << 4,
VFLAG_EDGE_SEAM = 1 << 5,
VFLAG_EDGE_SHARP = 1 << 6,
VFLAG_EDGE_FREESTYLE = 1 << 7,
/* Beware to not go over 1 << 7 (it's a byte flag). */
Fix T84260: NURBS edit mode lines not showing When in edit mode, the edit lines for de-selected surfaces did not show up. The bug was caused by the is_gpencil bool which reused another flag. Both grease pencil and nurbs surfaces use the edit_curve_handle shader. A dedicated flag was added to make sure the is_gpencil bool is set correctly. Reviewed By: fclem Maniphest Tasks: T84260 Differential Revision: https://developer.blender.org/D9985
2021-01-04 15:31:53 +01:00
/* NOTE: Grease pencil edit curve use another type of data format that allows for this value. */
VFLAG_VERT_GPENCIL_BEZT_HANDLE = 1 << 30,
Edit Mesh: Add support for draw option parameters The visuals was already implemented but we could not toggle them off.
2018-09-05 17:02:00 +02:00
};
enum {
Edit Mesh: Refactor Edit cage drawing to use old style drawing This is work in progress. Look is not final. This align data VBO data structure used for edti cage drawing to the one use for normal drawing. We no longer use barycentric coords to draw the lines an just rasterize line primitives for edge drawing. This is a bit slower than using the previous fast method but faster than the "correct" (edge artifact free) method. This also make the code way simpler. This also makes it possible to reuse possible and normal vbos used for shading if the edit cage matches the This also touches the UV batch code to share as much render data as possible. The code also prepare for edit cage "modified" drawing cage (with modifier applied) but is not enabled since selection and operators does not work with modified cage yet.
2019-02-04 01:13:51 +01:00
VFLAG_FACE_ACTIVE = 1 << 0,
VFLAG_FACE_SELECTED = 1 << 1,
VFLAG_FACE_FREESTYLE = 1 << 2,
VFLAG_VERT_UV_SELECT = 1 << 3,
VFLAG_VERT_UV_PINNED = 1 << 4,
VFLAG_EDGE_UV_SELECT = 1 << 5,
VFLAG_FACE_UV_ACTIVE = 1 << 6,
VFLAG_FACE_UV_SELECT = 1 << 7,
Fix curve handle color ID display Regression in 49f59092e7c8c caused all handles to display using the 'aligned' theme color. Arrange flags to fix this, add assert to avoid this happening again. Also rename flag so it's use is clearer.
2020-06-15 15:28:51 +10:00
/* Beware to not go over 1 << 7 (it's a byte flag). */
Edit Mesh: Add support for draw option parameters The visuals was already implemented but we could not toggle them off.
2018-09-05 17:02:00 +02:00
};
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Particles
* \{ */
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_particles_batch_cache_get_hair(struct Object *object,
Cleanup: whitespace, long lines, duplicate include
2018-05-26 10:41:25 +02:00
struct ParticleSystem *psys,
struct ModifierData *md);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_particles_batch_cache_get_dots(struct Object *object,
Cleanup: whitespace, long lines, duplicate include
2018-05-26 10:41:25 +02:00
struct ParticleSystem *psys);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_particles_batch_cache_get_edit_strands(struct Object *object,
DRW: Implement Hair Weight drawing Fixes T57931 Particle weight edit mode is not supported. There is a bug that prevent refresh of the toolsettings on which is based the weight / non-weight display selection (see T58086).
2018-11-27 13:49:00 +01:00
struct ParticleSystem *psys,
struct PTCacheEdit *edit,
bool use_weight);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_particles_batch_cache_get_edit_inner_points(struct Object *object,
Cleanup: whitespace, long lines, duplicate include
2018-05-26 10:41:25 +02:00
struct ParticleSystem *psys,
struct PTCacheEdit *edit);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_particles_batch_cache_get_edit_tip_points(struct Object *object,
Cleanup: whitespace, long lines, duplicate include
2018-05-26 10:41:25 +02:00
struct ParticleSystem *psys,
struct PTCacheEdit *edit);
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
Cleanup: Move curve draw cache implementation to C++ I'd like to use this file to draw curves from geometry nodes, which would otherwise require implementing a C API. The changes in this commit are minimal, mostly just casts and changing to nullptr. Differential Revision: https://developer.blender.org/D11350
2021-05-21 17:28:19 -04:00
#ifdef __cplusplus
}
#endif
Reference in New Issue Copy Permalink