griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
92f2b77e78a841854d65041e0be4bce511ed5607
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.

373 lines
15 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;
struct GPUIndexBuf;
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;
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 ListBase;
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;
Support for Batchs split by material for objects of type Curve, Surface, and Text **ToDo:** - add vertbuff for UV (what can be adapted from `dl_surf_to_renderdata`)
2017-12-14 12:21:38 -02:00
struct MetaBall;
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_mball_batch_cache_dirty_tag(struct MetaBall *mb, 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_mball_batch_cache_validate(struct MetaBall *mb);
Fix T51210: Draw Manager: Support for Metaball Drawing Differential Revision: D2914
2017-11-16 15:12:32 -02:00
void DRW_mball_batch_cache_free(struct MetaBall *mb);
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: 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_mesh_batch_cache_free(struct Mesh *me);
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);
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);
struct GPUBatch *DRW_curve_batch_cache_get_normal_edge(struct Curve *cu);
DrawManager: Add Edge Detection To DisplayLists Objects that internally uses DispList do not cast shadow in the workbench. Their outline is also not visible in object mode. The reason for this is that edge detection was not implemented for Display Lists. This patch will implement the edge detection. Reviewed By: fclem Maniphest Tasks: T62479 Differential Revision: https://developer.blender.org/D4605
2019-03-28 14:51:29 +01:00
struct GPUBatch *DRW_curve_batch_cache_get_edge_detection(struct Curve *cu, bool *r_is_manifold);
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
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_triangles_with_normals(struct Curve *cu);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch **DRW_curve_batch_cache_get_surface_shaded(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 GPUMaterial **gpumat_array,
uint gpumat_array_len);
struct GPUBatch *DRW_curve_batch_cache_get_wireframes_face(struct Curve *cu);
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
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Metaball
* \{ */
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_metaball_material_count_get(struct MetaBall *mb);
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
struct GPUBatch *DRW_metaball_batch_cache_get_triangles_with_normals(struct Object *ob);
Cleanup: macro hygiene, line length
2018-12-21 10:46:26 +11:00
struct GPUBatch **DRW_metaball_batch_cache_get_surface_shaded(struct Object *ob,
struct MetaBall *mb,
struct GPUMaterial **gpumat_array,
uint gpumat_array_len);
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_metaball_batch_cache_get_wireframes_face(struct Object *ob);
DrawManager: Add Edge Detection To DisplayLists Objects that internally uses DispList do not cast shadow in the workbench. Their outline is also not visible in object mode. The reason for this is that edge detection was not implemented for Display Lists. This patch will implement the edge detection. Reviewed By: fclem Maniphest Tasks: T62479 Differential Revision: https://developer.blender.org/D4605
2019-03-28 14:51:29 +01:00
struct GPUBatch *DRW_metaball_batch_cache_get_edge_detection(struct Object *ob,
bool *r_is_manifold);
Fix T51210: Draw Manager: Support for Metaball Drawing Differential Revision: D2914
2017-11-16 15:12:32 -02:00
Cleanup: move public doc-strings into headers for 'draw' Ref T92709
2021-12-08 20:29:39 +11:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name DispList
* \{ */
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_displist_vertbuf_create_pos_and_nor(struct ListBase *lb,
struct GPUVertBuf *vbo,
const struct Scene *scene);
Fix crash with wireframe on highpoly curves on some AMD gpus. Differential Revision: https://developer.blender.org/D4433
2019-03-01 12:36:34 -03:00
void DRW_displist_vertbuf_create_wiredata(struct ListBase *lb, struct GPUVertBuf *vbo);
DRW: Add support for tangent on objects using display lists. Only Metaballs are left unsupported. However, the implementation does not match 100% with cycles which converts all objects to meshes. Fixes T63424 EEVEE: Normal map node doesn't works with curve objects
2020-01-30 01:07:28 +01:00
void DRW_displist_vertbuf_create_loop_pos_and_nor_and_uv_and_tan(struct ListBase *lb,
struct GPUVertBuf *vbo_pos_nor,
struct GPUVertBuf *vbo_uv,
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
struct GPUVertBuf *vbo_tan,
const struct Scene *scene);
Fix T61801: Wireframes on curves not working
2019-02-25 19:37:08 +01:00
void DRW_displist_indexbuf_create_lines_in_order(struct ListBase *lb, struct GPUIndexBuf *ibo);
void DRW_displist_indexbuf_create_triangles_in_order(struct ListBase *lb, struct GPUIndexBuf *ibo);
void DRW_displist_indexbuf_create_triangles_loop_split_by_material(struct ListBase *lb,
Curve Batch Cache: Add back support for shaded geometry This changes a bit the batches data structure. Instead of using one vbo per material we use one for all material and use index buffers for selecting the correct triangles. This is less optimized than before but has potential to become more optimized by merging the wireframe data vbo into the shading one. Also the index buffers are not strictly necessary and could be just ranges inside the buffer. But this needs more adding things inside GPUIndexBuf.
2018-12-14 00:42:16 +01:00
struct GPUIndexBuf **ibo_mat,
uint mat_len);
DrawManager: Add Edge Detection To DisplayLists Objects that internally uses DispList do not cast shadow in the workbench. Their outline is also not visible in object mode. The reason for this is that edge detection was not implemented for Display Lists. This patch will implement the edge detection. Reviewed By: fclem Maniphest Tasks: T62479 Differential Revision: https://developer.blender.org/D4605
2019-03-28 14:51:29 +01:00
void DRW_displist_indexbuf_create_edges_adjacency_lines(struct ListBase *lb,
struct GPUIndexBuf *ibo,
bool *r_is_manifold);
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
/** \} */
/* -------------------------------------------------------------------- */
/** \name Hair
* \{ */
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
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);
struct GPUBatch *DRW_pointcloud_batch_cache_get_dots(struct Object *ob);
PointCloud: Initial rendering support for Workbench Also includes outline overlays. Removes the temp overlay drawing We make the geometry follow camera like billboards this uses less geometry. Currently we use half octahedron for now. Goal would be to use icospheres. This patch also optimize the case when pointcloud has uniform radius. However we should premultiply the radius prop by the default radius beforehand to avoid a multiplication on CPU. Using geometry instead of pseudo raytraced spheres is more scalable as we can render as low as 1 or 2 triangle to a full half sphere and can integrate easily in the render pipeline using a low amount of code. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8301
2020-07-15 20:10:45 +02:00
struct GPUBatch *DRW_pointcloud_batch_cache_get_surface(struct Object *ob);
struct GPUBatch **DRW_cache_pointcloud_surface_shaded_get(struct Object *ob,
struct GPUMaterial **gpumat_array,
uint gpumat_array_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 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);
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);
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);
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 GPUBatch *DRW_mesh_batch_cache_get_edit_vnors(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_lnors(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);
struct GPUVertBuf *DRW_curve_batch_cache_pos_vertbuf_get(struct Curve *cu);
struct GPUVertBuf *DRW_mball_batch_cache_pos_vertbuf_get(struct Object *ob);
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
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
/* See 'common_globals_lib.glsl' for duplicate defines. */
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