tornavis/source/blender/draw/CMakeLists.txt

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

1001 lines
42 KiB
CMake
Raw Normal View History

# SPDX-FileCopyrightText: 2016 Blender Authors
#
# SPDX-License-Identifier: GPL-2.0-or-later
set(INC
.
intern
../blenkernel
../blenloader
../blentranslation
../bmesh
../editors/include
../editors/space_view3d
../functions
../gpu
../gpu/intern
../imbuf
../makesrna
../nodes
../render
../render/intern
../compositor/realtime_compositor
../compositor/realtime_compositor/algorithms
../compositor/realtime_compositor/cached_resources
../windowmanager
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
../../../intern/opensubdiv
2023-08-17 03:53:56 +02:00
)
2023-08-17 03:53:56 +02:00
set(INC_SYS
)
set(SRC
intern/attribute_convert.cc
intern/draw_cache.cc
intern/draw_cache_extract_mesh.cc
intern/draw_cache_extract_mesh_render_data.cc
intern/mesh_extractors/extract_mesh.cc
2021-06-08 11:56:30 +02:00
intern/mesh_extractors/extract_mesh_ibo_edituv.cc
intern/mesh_extractors/extract_mesh_ibo_fdots.cc
intern/mesh_extractors/extract_mesh_ibo_lines.cc
intern/mesh_extractors/extract_mesh_ibo_lines_adjacency.cc
intern/mesh_extractors/extract_mesh_ibo_lines_paint_mask.cc
intern/mesh_extractors/extract_mesh_ibo_points.cc
intern/mesh_extractors/extract_mesh_ibo_tris.cc
intern/mesh_extractors/extract_mesh_vbo_attributes.cc
intern/mesh_extractors/extract_mesh_vbo_edge_fac.cc
intern/mesh_extractors/extract_mesh_vbo_edit_data.cc
intern/mesh_extractors/extract_mesh_vbo_edituv_data.cc
intern/mesh_extractors/extract_mesh_vbo_edituv_stretch_angle.cc
intern/mesh_extractors/extract_mesh_vbo_edituv_stretch_area.cc
intern/mesh_extractors/extract_mesh_vbo_fdots_edituv_data.cc
intern/mesh_extractors/extract_mesh_vbo_fdots_nor.cc
intern/mesh_extractors/extract_mesh_vbo_fdots_pos.cc
intern/mesh_extractors/extract_mesh_vbo_fdots_uv.cc
intern/mesh_extractors/extract_mesh_vbo_lnor.cc
intern/mesh_extractors/extract_mesh_vbo_mesh_analysis.cc
intern/mesh_extractors/extract_mesh_vbo_orco.cc
intern/mesh_extractors/extract_mesh_vbo_pos.cc
intern/mesh_extractors/extract_mesh_vbo_sculpt_data.cc
intern/mesh_extractors/extract_mesh_vbo_select_idx.cc
intern/mesh_extractors/extract_mesh_vbo_skin_roots.cc
intern/mesh_extractors/extract_mesh_vbo_tan.cc
intern/mesh_extractors/extract_mesh_vbo_uv.cc
intern/mesh_extractors/extract_mesh_vbo_vnor.cc
intern/mesh_extractors/extract_mesh_vbo_weights.cc
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
intern/draw_attributes.cc
intern/draw_cache_impl_curve.cc
intern/draw_cache_impl_curves.cc
intern/draw_cache_impl_gpencil_legacy.cc
intern/draw_cache_impl_grease_pencil.cc
intern/draw_cache_impl_lattice.cc
intern/draw_cache_impl_mesh.cc
intern/draw_cache_impl_particles.cc
intern/draw_cache_impl_pointcloud.cc
OpenSubDiv: add support for an OpenGL evaluator This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-27 16:34:47 +01:00
intern/draw_cache_impl_subdivision.cc
intern/draw_cache_impl_volume.cc
intern/draw_color_management.cc
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/draw_command.cc
intern/draw_common.cc
intern/draw_curves.cc
intern/draw_debug.cc
intern/draw_fluid.cc
2022-05-12 17:25:57 +02:00
intern/draw_hair.cc
intern/draw_instance_data.cc
2022-09-07 07:14:33 +02:00
intern/draw_manager.cc
intern/draw_manager_c.cc
intern/draw_manager_data.cc
intern/draw_manager_exec.cc
intern/draw_manager_profiling.cc
intern/draw_manager_shader.cc
intern/draw_manager_text.cc
intern/draw_manager_texture.cc
intern/draw_pbvh.cc
intern/draw_pointcloud.cc
2023-06-16 01:49:56 +02:00
intern/draw_resource.cc
intern/draw_sculpt.cc
intern/draw_select_buffer.cc
2022-05-12 20:06:01 +02:00
intern/draw_shader.cc
2021-10-20 00:17:46 +02:00
intern/draw_texture_pool.cc
2023-06-16 01:49:56 +02:00
intern/draw_view.cc
intern/draw_view_c.cc
2021-10-20 00:17:46 +02:00
intern/draw_view_data.cc
intern/draw_volume.cc
engines/basic/basic_engine.cc
engines/basic/basic_shader.cc
engines/compositor/compositor_engine.cc
engines/image/image_engine.cc
engines/image/image_shader.cc
engines/eevee/eevee_bloom.cc
engines/eevee/eevee_cryptomatte.cc
engines/eevee/eevee_data.cc
engines/eevee/eevee_depth_of_field.cc
engines/eevee/eevee_effects.cc
engines/eevee/eevee_engine.cc
engines/eevee/eevee_lightcache.cc
engines/eevee/eevee_lightprobes.cc
engines/eevee/eevee_lights.cc
engines/eevee/eevee_lookdev.cc
engines/eevee/eevee_lut_gen.cc
engines/eevee/eevee_materials.cc
engines/eevee/eevee_mist.cc
engines/eevee/eevee_motion_blur.cc
engines/eevee/eevee_occlusion.cc
engines/eevee/eevee_render.cc
engines/eevee/eevee_renderpasses.cc
engines/eevee/eevee_sampling.cc
engines/eevee/eevee_screen_raytrace.cc
engines/eevee/eevee_shaders.cc
engines/eevee/eevee_shaders_extra.cc
engines/eevee/eevee_shadows.cc
engines/eevee/eevee_shadows_cascade.cc
engines/eevee/eevee_shadows_cube.cc
engines/eevee/eevee_subsurface.cc
engines/eevee/eevee_temporal_sampling.cc
engines/eevee/eevee_volumes.cc
engines/eevee_next/eevee_ambient_occlusion.cc
2022-05-14 20:29:28 +02:00
engines/eevee_next/eevee_camera.cc
engines/eevee_next/eevee_cryptomatte.cc
engines/eevee_next/eevee_depth_of_field.cc
engines/eevee_next/eevee_engine.cc
engines/eevee_next/eevee_film.cc
2022-09-07 07:14:33 +02:00
engines/eevee_next/eevee_hizbuffer.cc
engines/eevee_next/eevee_instance.cc
engines/eevee_next/eevee_irradiance_cache.cc
engines/eevee_next/eevee_light.cc
engines/eevee_next/eevee_lightcache.cc
engines/eevee_next/eevee_lightprobe.cc
engines/eevee_next/eevee_lookdev.cc
engines/eevee_next/eevee_lut.cc
engines/eevee_next/eevee_material.cc
engines/eevee_next/eevee_motion_blur.cc
engines/eevee_next/eevee_pipeline.cc
engines/eevee_next/eevee_planar_probes.cc
engines/eevee_next/eevee_precompute.cc
EEVEE-Next: Ray-tracing Denoise Pipeline This is a full rewrite of the raytracing denoise pipeline. It uses the same principle as before but now uses compute shaders for every stages and a tile base approach. More aggressive filtering is needed since we are moving towards having no prefiltered screen radiance buffer. Thus we introduce a temporal denoise and a bilateral denoise stage to the denoising. These are optionnal and can be disabled. Note that this patch does not include any tracing part and only samples the reflection probes. It is focused on denoising only. Tracing will come in another PR. The motivation for this is that having hardware raytracing support means we can't prefilter the radiance in screen space so we have to have better denoising. Also this means we can have better surface appearance with support for other BxDF model than GGX. Also GGX support is improved. Technically, the new denoising fixes some implementation mistake the old pipeline did. It separates all 3 stages (spatial, temporal, bilateral) and use random sampling for all stages hoping to create a noisy enough (but still stable) output so that the TAA soaks the remaining noise. However that's not always the case. Depending on the nature of the scene, the input can be very high frequency and might create lots of flickering. That why another solution needs to be found for the higher roughness material as denoising them becomes expensive and low quality. Pull Request: https://projects.blender.org/blender/blender/pulls/110117
2023-08-03 15:32:06 +02:00
engines/eevee_next/eevee_raytrace.cc
engines/eevee_next/eevee_reflection_probes.cc
engines/eevee_next/eevee_renderbuffers.cc
engines/eevee_next/eevee_sampling.cc
engines/eevee_next/eevee_shader.cc
engines/eevee_next/eevee_shadow.cc
engines/eevee_next/eevee_subsurface.cc
engines/eevee_next/eevee_sync.cc
engines/eevee_next/eevee_velocity.cc
engines/eevee_next/eevee_view.cc
engines/eevee_next/eevee_volume.cc
engines/eevee_next/eevee_world.cc
engines/workbench/workbench_effect_antialiasing.cc
engines/workbench/workbench_effect_cavity.cc
engines/workbench/workbench_effect_dof.cc
engines/workbench/workbench_effect_outline.cc
engines/workbench/workbench_engine.cc
engines/workbench/workbench_materials.cc
engines/workbench/workbench_mesh_passes.cc
engines/workbench/workbench_resources.cc
engines/workbench/workbench_shader_cache.cc
engines/workbench/workbench_shadow.cc
engines/workbench/workbench_state.cc
engines/workbench/workbench_volume.cc
engines/external/external_engine.cc
engines/gpencil/gpencil_antialiasing.cc
engines/gpencil/gpencil_cache_utils.cc
engines/gpencil/gpencil_draw_data.cc
engines/gpencil/gpencil_engine_c.cc
engines/gpencil/gpencil_render.cc
engines/gpencil/gpencil_shader_c.cc
engines/gpencil/gpencil_shader_fx.cc
engines/select/select_draw_utils.cc
engines/select/select_engine.cc
engines/select/select_instance.cc
engines/overlay/overlay_antialiasing.cc
engines/overlay/overlay_armature.cc
engines/overlay/overlay_background.cc
engines/overlay/overlay_edit_curve.cc
engines/overlay/overlay_edit_curves.cc
engines/overlay/overlay_edit_mesh.cc
engines/overlay/overlay_edit_text.cc
engines/overlay/overlay_edit_uv.cc
engines/overlay/overlay_engine.cc
engines/overlay/overlay_extra.cc
engines/overlay/overlay_facing.cc
engines/overlay/overlay_fade.cc
engines/overlay/overlay_gpencil_legacy.cc
engines/overlay/overlay_grease_pencil.cc
engines/overlay/overlay_grid.cc
engines/overlay/overlay_image.cc
engines/overlay/overlay_lattice.cc
engines/overlay/overlay_metaball.cc
engines/overlay/overlay_mode_transfer.cc
engines/overlay/overlay_motion_path.cc
engines/overlay/overlay_next_engine.cc
engines/overlay/overlay_next_instance.cc
engines/overlay/overlay_next_shader.cc
engines/overlay/overlay_next_shape.cc
engines/overlay/overlay_outline.cc
engines/overlay/overlay_paint.cc
engines/overlay/overlay_particle.cc
engines/overlay/overlay_sculpt.cc
engines/overlay/overlay_sculpt_curves.cc
engines/overlay/overlay_shader.cc
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
engines/overlay/overlay_viewer_attribute.cc
engines/overlay/overlay_viewer_text.cc
engines/overlay/overlay_volume.cc
engines/overlay/overlay_wireframe.cc
2024-01-05 17:16:57 +01:00
DRW_engine.hh
DRW_pbvh.hh
DRW_select_buffer.hh
intern/DRW_gpu_wrapper.hh
2024-01-05 17:16:57 +01:00
intern/DRW_render.hh
intern/attribute_convert.hh
intern/draw_attributes.hh
2024-01-05 17:16:57 +01:00
intern/draw_cache.hh
intern/draw_cache_extract.hh
intern/draw_cache_impl.hh
2024-01-05 17:16:57 +01:00
intern/draw_cache_inline.hh
intern/draw_color_management.hh
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/draw_command.hh
intern/draw_common.hh
2024-04-01 07:48:44 +02:00
intern/draw_common_c.hh
intern/draw_common_shader_shared.hh
intern/draw_curves_private.hh
intern/draw_debug.hh
2024-04-01 07:48:44 +02:00
intern/draw_debug_c.hh
intern/draw_hair_private.hh
2022-09-07 07:14:39 +02:00
intern/draw_handle.hh
intern/draw_instance_data.hh
2022-09-07 07:14:33 +02:00
intern/draw_manager.hh
2024-04-01 07:48:44 +02:00
intern/draw_manager_c.hh
intern/draw_manager_profiling.hh
intern/draw_manager_testing.hh
intern/draw_manager_text.hh
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/draw_pass.hh
2023-12-01 00:52:08 +01:00
intern/draw_pbvh.hh
intern/draw_resource.hh
intern/draw_sculpt.hh
2024-01-05 17:16:57 +01:00
intern/draw_shader.hh
intern/draw_shader_shared.hh
intern/draw_state.hh
intern/draw_subdivision.hh
intern/draw_texture_pool.hh
2022-09-07 07:14:39 +02:00
intern/draw_view.hh
2024-04-01 07:48:44 +02:00
intern/draw_view_c.hh
intern/draw_view_data.hh
intern/mesh_extractors/extract_mesh.hh
2017-04-27 13:58:43 +02:00
engines/basic/basic_engine.h
engines/basic/basic_private.h
engines/compositor/compositor_engine.h
2017-04-27 13:58:43 +02:00
engines/eevee/eevee_engine.h
engines/eevee/eevee_lightcache.h
2024-03-23 14:59:23 +01:00
engines/eevee/eevee_private.hh
engines/eevee/engine_eevee_shared_defines.h
engines/eevee_next/eevee_ambient_occlusion.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_camera.hh
2022-10-03 03:08:43 +02:00
engines/eevee_next/eevee_cryptomatte.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_depth_of_field.hh
engines/eevee_next/eevee_engine.h
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_film.hh
engines/eevee_next/eevee_gbuffer.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_hizbuffer.hh
engines/eevee_next/eevee_instance.hh
engines/eevee_next/eevee_irradiance_cache.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_light.hh
engines/eevee_next/eevee_lightcache.hh
engines/eevee_next/eevee_lightprobe.hh
engines/eevee_next/eevee_lookdev.hh
engines/eevee_next/eevee_lut.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_material.hh
engines/eevee_next/eevee_motion_blur.hh
engines/eevee_next/eevee_pipeline.hh
engines/eevee_next/eevee_planar_probes.hh
engines/eevee_next/eevee_precompute.hh
engines/eevee_next/eevee_raytrace.hh
engines/eevee_next/eevee_reflection_probes.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_renderbuffers.hh
engines/eevee_next/eevee_sampling.hh
engines/eevee_next/eevee_shader.hh
engines/eevee_next/eevee_shadow.hh
engines/eevee_next/eevee_subsurface.hh
engines/eevee_next/eevee_sync.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_velocity.hh
engines/eevee_next/eevee_view.hh
engines/eevee_next/eevee_volume.hh
2022-08-27 06:21:59 +02:00
engines/eevee_next/eevee_world.hh
engines/external/external_engine.h
2023-06-16 01:49:56 +02:00
engines/gpencil/gpencil_engine.h
engines/image/image_batches.hh
engines/image/image_buffer_cache.hh
engines/image/image_drawing_mode.hh
engines/image/image_engine.h
2022-12-13 02:46:12 +01:00
engines/image/image_enums.hh
engines/image/image_instance_data.hh
engines/image/image_partial_updater.hh
engines/image/image_private.hh
engines/image/image_shader_params.hh
2022-03-25 02:04:14 +01:00
engines/image/image_space.hh
engines/image/image_space_image.hh
engines/image/image_space_node.hh
engines/image/image_texture_info.hh
engines/image/image_usage.hh
2023-06-16 01:49:56 +02:00
engines/overlay/overlay_engine.h
engines/overlay/overlay_next_background.hh
engines/overlay/overlay_next_empty.hh
engines/overlay/overlay_next_grid.hh
engines/overlay/overlay_next_instance.hh
engines/overlay/overlay_next_metaball.hh
engines/overlay/overlay_next_prepass.hh
engines/overlay/overlay_next_private.hh
engines/overlay/overlay_private.hh
engines/select/select_defines.hh
engines/select/select_engine.hh
2023-06-16 01:49:56 +02:00
engines/select/select_instance.hh
engines/select/select_private.hh
engines/workbench/workbench_defines.hh
2018-09-06 13:23:25 +02:00
engines/workbench/workbench_engine.h
engines/workbench/workbench_enums.hh
engines/workbench/workbench_private.hh
engines/workbench/workbench_shader_shared.h
)
set(LIB
PRIVATE bf::blenfont
bf_blenkernel
PRIVATE bf::blenlib
PRIVATE bf::depsgraph
Cleanup: CMake: Modernize bf_dna dependencies There's quite a few libraries that depend on dna_type_offsets.h but had gotten to it by just adding the folder that contains it to their includes INC section without declaring a dependency to bf_dna in the LIB section. which occasionally lead to the lib building before bf_dna and the header being missing, while this generally gets fixed in CMake by adding bf_dna to the LIB section of the lib, however until last week all libraries in the LIB section were linked as INTERFACE so adding it in there did not resolve the build issue. To make things still build, we sprinkled add_dependencies wherever we needed it to force a build order. This diff : Declares public include folders for the bf_dna target so there's no more fudging the INC section required to get to them. Removes all dna related paths from the INC section for all libraries. Adds an alias target bf:dna to signify it has been updated to modern cmake Declares a dependency on bf::dna for all libraries that require it Removes (almost) all calls to add_dependencies for bf_dna Future work: Because of the manual dependency management that was done, there is now some "clutter" with libs depending on bf_dna that realistically don't. Example bf_intern_opencolorio itself has no dependency on bf_dna at all, doesn't need it, doesn't use it. However the dna include folder had been added to it in the past since bf_blenlib uses dna headers in some of its public headers and bf_intern_opencolorio does use those blenlib headers. Given bf_blenlib now correctly declares the dependency on bf_dna as public bf_intern_opencolorio will get the dna header directory automatically from CMake, hence some cleanup could be done for bf_intern_opencolorio Because 99% of the changes in this diff have been automated, this diff does not seek to address these issues as there is no easy way to determine why a certain dependency is in place. A developer will have to make a pass a this at some later point in time. As I'd rather not mix automated and manual labour. There are a few libraries that could not be automatically processed (ie bf_blendthumb) that also will need this manual look-over. Pull Request: https://projects.blender.org/blender/blender/pulls/109835
2023-07-10 15:07:37 +02:00
PRIVATE bf::dna
PRIVATE bf::intern::clog
PRIVATE bf::intern::guardedalloc
bf_realtime_compositor
bf_windowmanager
PRIVATE bf::intern::atomic
)
set(GLSL_SRC
engines/eevee/shaders/ambient_occlusion_lib.glsl
engines/eevee/shaders/background_vert.glsl
engines/eevee/shaders/common_uniforms_lib.glsl
engines/eevee/shaders/common_utiltex_lib.glsl
engines/eevee/shaders/lights_lib.glsl
engines/eevee/shaders/lightprobe_lib.glsl
engines/eevee/shaders/lightprobe_filter_glossy_frag.glsl
engines/eevee/shaders/lightprobe_filter_diffuse_frag.glsl
engines/eevee/shaders/lightprobe_filter_visibility_frag.glsl
engines/eevee/shaders/lightprobe_geom.glsl
engines/eevee/shaders/lightprobe_vert.glsl
engines/eevee/shaders/lightprobe_vert_no_geom.glsl
engines/eevee/shaders/lightprobe_cube_display_frag.glsl
engines/eevee/shaders/lightprobe_cube_display_vert.glsl
engines/eevee/shaders/lightprobe_grid_display_frag.glsl
engines/eevee/shaders/lightprobe_grid_display_vert.glsl
engines/eevee/shaders/lightprobe_grid_fill_frag.glsl
engines/eevee/shaders/lightprobe_planar_display_frag.glsl
engines/eevee/shaders/lightprobe_planar_display_vert.glsl
engines/eevee/shaders/lookdev_world_frag.glsl
engines/eevee/shaders/closure_eval_lib.glsl
engines/eevee/shaders/closure_eval_diffuse_lib.glsl
engines/eevee/shaders/closure_eval_glossy_lib.glsl
engines/eevee/shaders/closure_eval_surface_lib.glsl
engines/eevee/shaders/closure_eval_refraction_lib.glsl
engines/eevee/shaders/closure_eval_volume_lib.glsl
engines/eevee/shaders/closure_eval_translucent_lib.glsl
engines/eevee/shaders/closure_type_lib.glsl
engines/eevee/shaders/eevee_empty.glsl
engines/eevee/shaders/eevee_empty_volume.glsl
engines/eevee/shaders/effect_bloom_frag.glsl
engines/eevee/shaders/effect_dof_bokeh_frag.glsl
engines/eevee/shaders/effect_dof_dilate_tiles_frag.glsl
engines/eevee/shaders/effect_dof_downsample_frag.glsl
engines/eevee/shaders/effect_dof_filter_frag.glsl
engines/eevee/shaders/effect_dof_flatten_tiles_frag.glsl
engines/eevee/shaders/effect_dof_gather_frag.glsl
engines/eevee/shaders/effect_dof_lib.glsl
engines/eevee/shaders/effect_dof_reduce_frag.glsl
engines/eevee/shaders/effect_dof_resolve_frag.glsl
engines/eevee/shaders/effect_dof_scatter_frag.glsl
engines/eevee/shaders/effect_dof_scatter_vert.glsl
engines/eevee/shaders/effect_dof_setup_frag.glsl
engines/eevee/shaders/effect_reflection_lib.glsl
engines/eevee/shaders/effect_reflection_resolve_frag.glsl
engines/eevee/shaders/effect_reflection_trace_frag.glsl
engines/eevee/shaders/effect_downsample_frag.glsl
engines/eevee/shaders/effect_downsample_cube_frag.glsl
engines/eevee/shaders/effect_gtao_frag.glsl
engines/eevee/shaders/effect_velocity_resolve_frag.glsl
engines/eevee/shaders/effect_velocity_tile_frag.glsl
engines/eevee/shaders/effect_minmaxz_frag.glsl
engines/eevee/shaders/effect_mist_frag.glsl
engines/eevee/shaders/effect_motion_blur_frag.glsl
engines/eevee/shaders/effect_subsurface_frag.glsl
engines/eevee/shaders/effect_translucency_frag.glsl
engines/eevee/shaders/effect_temporal_aa.glsl
engines/eevee/shaders/lightprobe_planar_downsample_frag.glsl
engines/eevee/shaders/lightprobe_planar_downsample_geom.glsl
engines/eevee/shaders/lightprobe_planar_downsample_vert.glsl
engines/eevee/shaders/object_motion_frag.glsl
engines/eevee/shaders/object_motion_vert.glsl
engines/eevee/shaders/prepass_frag.glsl
engines/eevee/shaders/shadow_accum_frag.glsl
engines/eevee/shaders/shadow_frag.glsl
engines/eevee/shaders/shadow_vert.glsl
engines/eevee/shaders/bsdf_lut_frag.glsl
engines/eevee/shaders/btdf_lut_frag.glsl
engines/eevee/shaders/bsdf_common_lib.glsl
engines/eevee/shaders/irradiance_lib.glsl
engines/eevee/shaders/octahedron_lib.glsl
engines/eevee/shaders/bsdf_sampling_lib.glsl
engines/eevee/shaders/random_lib.glsl
engines/eevee/shaders/raytrace_lib.glsl
engines/eevee/shaders/renderpass_accumulate_frag.glsl
engines/eevee/shaders/renderpass_lib.glsl
engines/eevee/shaders/renderpass_postprocess_frag.glsl
engines/eevee/shaders/cryptomatte_frag.glsl
engines/eevee/shaders/cryptomatte_vert.glsl
engines/eevee/shaders/ltc_lib.glsl
engines/eevee/shaders/ssr_lib.glsl
engines/eevee/shaders/surface_frag.glsl
engines/eevee/shaders/surface_geom.glsl
engines/eevee/shaders/surface_lib.glsl
engines/eevee/shaders/surface_vert.glsl
engines/eevee/shaders/update_noise_frag.glsl
engines/eevee/shaders/volumetric_accum_frag.glsl
engines/eevee/shaders/volumetric_lib.glsl
engines/eevee/shaders/volumetric_frag.glsl
engines/eevee/shaders/volumetric_geom.glsl
engines/eevee/shaders/volumetric_vert.glsl
engines/eevee/shaders/volumetric_resolve_frag.glsl
engines/eevee/shaders/volumetric_scatter_frag.glsl
engines/eevee/shaders/volumetric_integration_frag.glsl
engines/eevee/shaders/world_vert.glsl
engines/eevee/shaders/infos/engine_eevee_legacy_shared.h
engines/eevee/engine_eevee_shared_defines.h
engines/eevee_next/shaders/eevee_ambient_occlusion_lib.glsl
engines/eevee_next/shaders/eevee_ambient_occlusion_pass_comp.glsl
engines/eevee_next/shaders/eevee_attributes_lib.glsl
EEVEE-Next: Ray-tracing Denoise Pipeline This is a full rewrite of the raytracing denoise pipeline. It uses the same principle as before but now uses compute shaders for every stages and a tile base approach. More aggressive filtering is needed since we are moving towards having no prefiltered screen radiance buffer. Thus we introduce a temporal denoise and a bilateral denoise stage to the denoising. These are optionnal and can be disabled. Note that this patch does not include any tracing part and only samples the reflection probes. It is focused on denoising only. Tracing will come in another PR. The motivation for this is that having hardware raytracing support means we can't prefilter the radiance in screen space so we have to have better denoising. Also this means we can have better surface appearance with support for other BxDF model than GGX. Also GGX support is improved. Technically, the new denoising fixes some implementation mistake the old pipeline did. It separates all 3 stages (spatial, temporal, bilateral) and use random sampling for all stages hoping to create a noisy enough (but still stable) output so that the TAA soaks the remaining noise. However that's not always the case. Depending on the nature of the scene, the input can be very high frequency and might create lots of flickering. That why another solution needs to be found for the higher roughness material as denoising them becomes expensive and low quality. Pull Request: https://projects.blender.org/blender/blender/pulls/110117
2023-08-03 15:32:06 +02:00
engines/eevee_next/shaders/eevee_bxdf_lib.glsl
engines/eevee_next/shaders/eevee_bxdf_sampling_lib.glsl
2022-05-14 20:29:28 +02:00
engines/eevee_next/shaders/eevee_camera_lib.glsl
engines/eevee_next/shaders/eevee_closure_lib.glsl
engines/eevee_next/shaders/eevee_colorspace_lib.glsl
engines/eevee_next/shaders/eevee_cryptomatte_lib.glsl
engines/eevee_next/shaders/eevee_debug_gbuffer_frag.glsl
engines/eevee_next/shaders/eevee_debug_surfels_vert.glsl
engines/eevee_next/shaders/eevee_debug_surfels_frag.glsl
engines/eevee_next/shaders/eevee_debug_irradiance_grid_vert.glsl
engines/eevee_next/shaders/eevee_debug_irradiance_grid_frag.glsl
engines/eevee_next/shaders/eevee_deferred_capture_frag.glsl
engines/eevee_next/shaders/eevee_deferred_combine_frag.glsl
engines/eevee_next/shaders/eevee_deferred_light_frag.glsl
engines/eevee_next/shaders/eevee_deferred_planar_frag.glsl
engines/eevee_next/shaders/eevee_deferred_tile_classify_frag.glsl
engines/eevee_next/shaders/eevee_deferred_tile_compact_vert.glsl
engines/eevee_next/shaders/eevee_deferred_tile_stencil_frag.glsl
engines/eevee_next/shaders/eevee_deferred_tile_stencil_vert.glsl
engines/eevee_next/shaders/eevee_depth_of_field_accumulator_lib.glsl
engines/eevee_next/shaders/eevee_depth_of_field_bokeh_lut_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_downsample_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_filter_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_gather_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_hole_fill_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_lib.glsl
engines/eevee_next/shaders/eevee_depth_of_field_reduce_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_resolve_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_scatter_frag.glsl
engines/eevee_next/shaders/eevee_depth_of_field_scatter_vert.glsl
engines/eevee_next/shaders/eevee_depth_of_field_setup_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_stabilize_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_tiles_dilate_comp.glsl
engines/eevee_next/shaders/eevee_depth_of_field_tiles_flatten_comp.glsl
engines/eevee_next/shaders/eevee_display_probe_grid_frag.glsl
engines/eevee_next/shaders/eevee_display_probe_grid_vert.glsl
engines/eevee_next/shaders/eevee_display_probe_planar_frag.glsl
engines/eevee_next/shaders/eevee_display_probe_planar_vert.glsl
engines/eevee_next/shaders/eevee_display_probe_reflection_frag.glsl
engines/eevee_next/shaders/eevee_display_probe_reflection_vert.glsl
engines/eevee_next/shaders/eevee_film_comp.glsl
engines/eevee_next/shaders/eevee_film_cryptomatte_post_comp.glsl
engines/eevee_next/shaders/eevee_film_frag.glsl
engines/eevee_next/shaders/eevee_film_lib.glsl
engines/eevee_next/shaders/eevee_filter_lib.glsl
engines/eevee_next/shaders/eevee_forward_lib.glsl
engines/eevee_next/shaders/eevee_gbuffer_lib.glsl
engines/eevee_next/shaders/eevee_gbuffer_closure_test.glsl
engines/eevee_next/shaders/eevee_gbuffer_normal_test.glsl
engines/eevee_next/shaders/eevee_geom_curves_vert.glsl
engines/eevee_next/shaders/eevee_geom_gpencil_vert.glsl
engines/eevee_next/shaders/eevee_geom_mesh_vert.glsl
engines/eevee_next/shaders/eevee_geom_point_cloud_vert.glsl
EEVEE-Next: Add mesh volume bounds estimation This adds correct object bounds estimation. This works by creating an occupancy texture where one bit represents one froxel. A geometry pre-pass fill this occupancy texture and doesn't do any shading. Each bit set to 0 will not be considered occupied by the object volume and will discard the material compute shader for this froxel. There is 2 method of computing the occupancy map: - Atomic XOR: For each fragment we compute the amount of froxels **center** in-front of it. We then convert that into occupancy bitmask that we apply to the occupancy texture using `imageAtomicXor`. This is straight forward and works well for any manifold geometry. - Hit List: For each fragment we write the fragment depth in a list (contained in one array texture). This list is then processed by a fullscreen pass (see `eevee_occupancy_convert_frag.glsl`) that sorts and converts all the hits to the occupancy bits. This emulate Cycles behavior by considering only back-face hits as exit events and front-face hits as entry events. The result stores it to the occupancy texture using bit-wise `OR` operation to compose it with other non-hit list objects. This also decouple the hit-list evaluation complexity from the material evaluation shader. ## Limitations ### Fast - Non-manifolds geometry objects are rendered incorrectly. - Non-manifolds geometry objects will affect other objects in front of them. ### Accurate - Limited to 16 hits per layer for now. - Non-manifolds geometry objects will affect other objects in front of them. Pull Request: https://projects.blender.org/blender/blender/pulls/113731
2023-10-19 19:22:14 +02:00
engines/eevee_next/shaders/eevee_geom_volume_vert.glsl
engines/eevee_next/shaders/eevee_geom_world_vert.glsl
engines/eevee_next/shaders/eevee_hiz_debug_frag.glsl
engines/eevee_next/shaders/eevee_hiz_update_comp.glsl
engines/eevee_next/shaders/eevee_horizon_denoise_comp.glsl
engines/eevee_next/shaders/eevee_horizon_resolve_comp.glsl
engines/eevee_next/shaders/eevee_horizon_scan_eval_lib.glsl
engines/eevee_next/shaders/eevee_horizon_scan_comp.glsl
engines/eevee_next/shaders/eevee_horizon_scan_lib.glsl
engines/eevee_next/shaders/eevee_horizon_scan_test.glsl
engines/eevee_next/shaders/eevee_horizon_setup_comp.glsl
engines/eevee_next/shaders/eevee_light_culling_debug_frag.glsl
engines/eevee_next/shaders/eevee_light_culling_select_comp.glsl
engines/eevee_next/shaders/eevee_light_culling_sort_comp.glsl
engines/eevee_next/shaders/eevee_light_culling_tile_comp.glsl
engines/eevee_next/shaders/eevee_light_culling_zbin_comp.glsl
engines/eevee_next/shaders/eevee_light_eval_lib.glsl
engines/eevee_next/shaders/eevee_light_iter_lib.glsl
engines/eevee_next/shaders/eevee_light_lib.glsl
engines/eevee_next/shaders/eevee_lightprobe_eval_lib.glsl
engines/eevee_next/shaders/eevee_lightprobe_irradiance_bounds_comp.glsl
engines/eevee_next/shaders/eevee_lightprobe_irradiance_ray_comp.glsl
engines/eevee_next/shaders/eevee_lightprobe_irradiance_offset_comp.glsl
engines/eevee_next/shaders/eevee_lightprobe_irradiance_load_comp.glsl
engines/eevee_next/shaders/eevee_lightprobe_irradiance_world_comp.glsl
engines/eevee_next/shaders/eevee_lightprobe_lib.glsl
engines/eevee_next/shaders/eevee_lightprobe_volume_eval_lib.glsl
engines/eevee_next/shaders/eevee_lookdev_display_frag.glsl
engines/eevee_next/shaders/eevee_lookdev_display_vert.glsl
engines/eevee_next/shaders/eevee_ltc_lib.glsl
engines/eevee_next/shaders/eevee_lut_comp.glsl
engines/eevee_next/shaders/eevee_motion_blur_dilate_comp.glsl
engines/eevee_next/shaders/eevee_motion_blur_flatten_comp.glsl
engines/eevee_next/shaders/eevee_motion_blur_gather_comp.glsl
engines/eevee_next/shaders/eevee_motion_blur_lib.glsl
engines/eevee_next/shaders/eevee_nodetree_lib.glsl
EEVEE-Next: Add mesh volume bounds estimation This adds correct object bounds estimation. This works by creating an occupancy texture where one bit represents one froxel. A geometry pre-pass fill this occupancy texture and doesn't do any shading. Each bit set to 0 will not be considered occupied by the object volume and will discard the material compute shader for this froxel. There is 2 method of computing the occupancy map: - Atomic XOR: For each fragment we compute the amount of froxels **center** in-front of it. We then convert that into occupancy bitmask that we apply to the occupancy texture using `imageAtomicXor`. This is straight forward and works well for any manifold geometry. - Hit List: For each fragment we write the fragment depth in a list (contained in one array texture). This list is then processed by a fullscreen pass (see `eevee_occupancy_convert_frag.glsl`) that sorts and converts all the hits to the occupancy bits. This emulate Cycles behavior by considering only back-face hits as exit events and front-face hits as entry events. The result stores it to the occupancy texture using bit-wise `OR` operation to compose it with other non-hit list objects. This also decouple the hit-list evaluation complexity from the material evaluation shader. ## Limitations ### Fast - Non-manifolds geometry objects are rendered incorrectly. - Non-manifolds geometry objects will affect other objects in front of them. ### Accurate - Limited to 16 hits per layer for now. - Non-manifolds geometry objects will affect other objects in front of them. Pull Request: https://projects.blender.org/blender/blender/pulls/113731
2023-10-19 19:22:14 +02:00
engines/eevee_next/shaders/eevee_occupancy_convert_frag.glsl
engines/eevee_next/shaders/eevee_occupancy_lib.glsl
engines/eevee_next/shaders/eevee_occupancy_test.glsl
engines/eevee_next/shaders/eevee_octahedron_lib.glsl
EEVEE-Next: Ray-tracing Denoise Pipeline This is a full rewrite of the raytracing denoise pipeline. It uses the same principle as before but now uses compute shaders for every stages and a tile base approach. More aggressive filtering is needed since we are moving towards having no prefiltered screen radiance buffer. Thus we introduce a temporal denoise and a bilateral denoise stage to the denoising. These are optionnal and can be disabled. Note that this patch does not include any tracing part and only samples the reflection probes. It is focused on denoising only. Tracing will come in another PR. The motivation for this is that having hardware raytracing support means we can't prefilter the radiance in screen space so we have to have better denoising. Also this means we can have better surface appearance with support for other BxDF model than GGX. Also GGX support is improved. Technically, the new denoising fixes some implementation mistake the old pipeline did. It separates all 3 stages (spatial, temporal, bilateral) and use random sampling for all stages hoping to create a noisy enough (but still stable) output so that the TAA soaks the remaining noise. However that's not always the case. Depending on the nature of the scene, the input can be very high frequency and might create lots of flickering. That why another solution needs to be found for the higher roughness material as denoising them becomes expensive and low quality. Pull Request: https://projects.blender.org/blender/blender/pulls/110117
2023-08-03 15:32:06 +02:00
engines/eevee_next/shaders/eevee_ray_denoise_bilateral_comp.glsl
engines/eevee_next/shaders/eevee_ray_denoise_spatial_comp.glsl
engines/eevee_next/shaders/eevee_ray_denoise_temporal_comp.glsl
engines/eevee_next/shaders/eevee_ray_generate_comp.glsl
engines/eevee_next/shaders/eevee_ray_generate_lib.glsl
engines/eevee_next/shaders/eevee_ray_tile_classify_comp.glsl
engines/eevee_next/shaders/eevee_ray_tile_compact_comp.glsl
engines/eevee_next/shaders/eevee_ray_trace_fallback_comp.glsl
engines/eevee_next/shaders/eevee_ray_trace_planar_comp.glsl
EEVEE-Next: Ray-tracing Denoise Pipeline This is a full rewrite of the raytracing denoise pipeline. It uses the same principle as before but now uses compute shaders for every stages and a tile base approach. More aggressive filtering is needed since we are moving towards having no prefiltered screen radiance buffer. Thus we introduce a temporal denoise and a bilateral denoise stage to the denoising. These are optionnal and can be disabled. Note that this patch does not include any tracing part and only samples the reflection probes. It is focused on denoising only. Tracing will come in another PR. The motivation for this is that having hardware raytracing support means we can't prefilter the radiance in screen space so we have to have better denoising. Also this means we can have better surface appearance with support for other BxDF model than GGX. Also GGX support is improved. Technically, the new denoising fixes some implementation mistake the old pipeline did. It separates all 3 stages (spatial, temporal, bilateral) and use random sampling for all stages hoping to create a noisy enough (but still stable) output so that the TAA soaks the remaining noise. However that's not always the case. Depending on the nature of the scene, the input can be very high frequency and might create lots of flickering. That why another solution needs to be found for the higher roughness material as denoising them becomes expensive and low quality. Pull Request: https://projects.blender.org/blender/blender/pulls/110117
2023-08-03 15:32:06 +02:00
engines/eevee_next/shaders/eevee_ray_trace_screen_comp.glsl
engines/eevee_next/shaders/eevee_ray_trace_screen_lib.glsl
engines/eevee_next/shaders/eevee_ray_types_lib.glsl
engines/eevee_next/shaders/eevee_reflection_probe_convolve_comp.glsl
engines/eevee_next/shaders/eevee_reflection_probe_eval_lib.glsl
engines/eevee_next/shaders/eevee_reflection_probe_irradiance_comp.glsl
engines/eevee_next/shaders/eevee_reflection_probe_lib.glsl
engines/eevee_next/shaders/eevee_reflection_probe_mapping_lib.glsl
engines/eevee_next/shaders/eevee_reflection_probe_remap_comp.glsl
engines/eevee_next/shaders/eevee_reflection_probe_select_comp.glsl
engines/eevee_next/shaders/eevee_renderpass_lib.glsl
engines/eevee_next/shaders/eevee_sampling_lib.glsl
engines/eevee_next/shaders/eevee_shadow_debug_frag.glsl
engines/eevee_next/shaders/eevee_shadow_lib.glsl
engines/eevee_next/shaders/eevee_shadow_tracing_lib.glsl
engines/eevee_next/shaders/eevee_shadow_clipmap_clear_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_allocate_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_clear_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_defrag_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_free_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_mask_comp.glsl
engines/eevee_next/shaders/eevee_shadow_page_ops_lib.glsl
engines/eevee_next/shaders/eevee_shadow_tag_update_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_frag.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_lib.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_surfels_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_vert.glsl
engines/eevee_next/shaders/eevee_shadow_tag_usage_volume_comp.glsl
engines/eevee_next/shaders/eevee_shadow_test.glsl
engines/eevee_next/shaders/eevee_shadow_tilemap_amend_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tilemap_bounds_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tilemap_finalize_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tilemap_init_comp.glsl
engines/eevee_next/shaders/eevee_shadow_tilemap_lib.glsl
engines/eevee_next/shaders/eevee_spherical_harmonics_lib.glsl
engines/eevee_next/shaders/eevee_subsurface_convolve_comp.glsl
engines/eevee_next/shaders/eevee_subsurface_lib.glsl
engines/eevee_next/shaders/eevee_subsurface_setup_comp.glsl
engines/eevee_next/shaders/eevee_surf_capture_frag.glsl
engines/eevee_next/shaders/eevee_surf_deferred_frag.glsl
engines/eevee_next/shaders/eevee_surf_depth_frag.glsl
engines/eevee_next/shaders/eevee_surf_forward_frag.glsl
engines/eevee_next/shaders/eevee_surf_hybrid_frag.glsl
engines/eevee_next/shaders/eevee_surf_lib.glsl
EEVEE-Next: Add mesh volume bounds estimation This adds correct object bounds estimation. This works by creating an occupancy texture where one bit represents one froxel. A geometry pre-pass fill this occupancy texture and doesn't do any shading. Each bit set to 0 will not be considered occupied by the object volume and will discard the material compute shader for this froxel. There is 2 method of computing the occupancy map: - Atomic XOR: For each fragment we compute the amount of froxels **center** in-front of it. We then convert that into occupancy bitmask that we apply to the occupancy texture using `imageAtomicXor`. This is straight forward and works well for any manifold geometry. - Hit List: For each fragment we write the fragment depth in a list (contained in one array texture). This list is then processed by a fullscreen pass (see `eevee_occupancy_convert_frag.glsl`) that sorts and converts all the hits to the occupancy bits. This emulate Cycles behavior by considering only back-face hits as exit events and front-face hits as entry events. The result stores it to the occupancy texture using bit-wise `OR` operation to compose it with other non-hit list objects. This also decouple the hit-list evaluation complexity from the material evaluation shader. ## Limitations ### Fast - Non-manifolds geometry objects are rendered incorrectly. - Non-manifolds geometry objects will affect other objects in front of them. ### Accurate - Limited to 16 hits per layer for now. - Non-manifolds geometry objects will affect other objects in front of them. Pull Request: https://projects.blender.org/blender/blender/pulls/113731
2023-10-19 19:22:14 +02:00
engines/eevee_next/shaders/eevee_surf_occupancy_frag.glsl
engines/eevee_next/shaders/eevee_surf_shadow_frag.glsl
engines/eevee_next/shaders/eevee_shadow_page_tile_vert.glsl
engines/eevee_next/shaders/eevee_shadow_page_tile_frag.glsl
engines/eevee_next/shaders/eevee_surf_world_frag.glsl
engines/eevee_next/shaders/eevee_surfel_cluster_build_comp.glsl
engines/eevee_next/shaders/eevee_surfel_light_comp.glsl
engines/eevee_next/shaders/eevee_surfel_list_build_comp.glsl
engines/eevee_next/shaders/eevee_surfel_list_lib.glsl
engines/eevee_next/shaders/eevee_surfel_list_sort_comp.glsl
engines/eevee_next/shaders/eevee_surfel_ray_comp.glsl
engines/eevee_next/shaders/eevee_thickness_lib.glsl
engines/eevee_next/shaders/eevee_transparency_lib.glsl
engines/eevee_next/shaders/eevee_velocity_lib.glsl
engines/eevee_next/shaders/eevee_vertex_copy_comp.glsl
engines/eevee_next/shaders/eevee_volume_integration_comp.glsl
engines/eevee_next/shaders/eevee_volume_lib.glsl
engines/eevee_next/shaders/eevee_volume_material_comp.glsl
engines/eevee_next/shaders/eevee_volume_resolve_frag.glsl
engines/eevee_next/shaders/eevee_volume_scatter_comp.glsl
engines/eevee_next/eevee_defines.hh
engines/eevee_next/eevee_shader_shared.hh
engines/workbench/shaders/workbench_cavity_lib.glsl
engines/workbench/shaders/workbench_common_lib.glsl
engines/workbench/shaders/workbench_composite_frag.glsl
engines/workbench/shaders/workbench_curvature_lib.glsl
engines/workbench/shaders/workbench_effect_dof_frag.glsl
engines/workbench/shaders/workbench_effect_outline_frag.glsl
engines/workbench/shaders/workbench_effect_smaa_frag.glsl
engines/workbench/shaders/workbench_effect_smaa_vert.glsl
engines/workbench/shaders/workbench_effect_taa_frag.glsl
engines/workbench/shaders/workbench_extract_stencil.glsl
engines/workbench/shaders/workbench_image_lib.glsl
engines/workbench/shaders/workbench_matcap_lib.glsl
engines/workbench/shaders/workbench_material_lib.glsl
engines/workbench/shaders/workbench_merge_depth_frag.glsl
engines/workbench/shaders/workbench_overlay_depth_frag.glsl
engines/workbench/shaders/workbench_prepass_frag.glsl
engines/workbench/shaders/workbench_prepass_hair_vert.glsl
engines/workbench/shaders/workbench_prepass_pointcloud_vert.glsl
engines/workbench/shaders/workbench_prepass_vert.glsl
engines/workbench/shaders/workbench_shadow_caps_geom.glsl
engines/workbench/shaders/workbench_shadow_caps_vert_no_geom.glsl
engines/workbench/shaders/workbench_shadow_debug_frag.glsl
engines/workbench/shaders/workbench_shadow_geom.glsl
engines/workbench/shaders/workbench_shadow_vert.glsl
engines/workbench/shaders/workbench_shadow_visibility_comp.glsl
engines/workbench/shaders/workbench_shadow_vert_no_geom.glsl
engines/workbench/shaders/workbench_transparent_accum_frag.glsl
engines/workbench/shaders/workbench_transparent_resolve_frag.glsl
engines/workbench/shaders/workbench_volume_frag.glsl
engines/workbench/shaders/workbench_volume_vert.glsl
engines/workbench/shaders/workbench_world_light_lib.glsl
engines/workbench/workbench_shader_shared.h
intern/shaders/common_aabb_lib.glsl
intern/shaders/common_attribute_lib.glsl
intern/shaders/common_colormanagement_lib.glsl
intern/shaders/common_debug_draw_lib.glsl
intern/shaders/common_debug_print_lib.glsl
intern/shaders/common_debug_shape_lib.glsl
intern/shaders/common_fullscreen_vert.glsl
intern/shaders/common_fxaa_lib.glsl
intern/shaders/common_gpencil_lib.glsl
intern/shaders/common_grease_pencil_lib.glsl
intern/shaders/common_hair_lib.glsl
intern/shaders/common_hair_refine_comp.glsl
intern/shaders/common_intersect_lib.glsl
intern/shaders/common_math_geom_lib.glsl
intern/shaders/common_math_lib.glsl
intern/shaders/common_pointcloud_lib.glsl
intern/shaders/common_shape_lib.glsl
intern/shaders/common_subdiv_custom_data_interp_comp.glsl
intern/shaders/common_subdiv_ibo_lines_comp.glsl
intern/shaders/common_subdiv_ibo_tris_comp.glsl
intern/shaders/common_subdiv_lib.glsl
intern/shaders/common_subdiv_normals_accumulate_comp.glsl
intern/shaders/common_subdiv_normals_finalize_comp.glsl
intern/shaders/common_subdiv_patch_evaluation_comp.glsl
intern/shaders/common_subdiv_vbo_edge_fac_comp.glsl
intern/shaders/common_subdiv_vbo_edituv_strech_angle_comp.glsl
intern/shaders/common_subdiv_vbo_edituv_strech_area_comp.glsl
intern/shaders/common_subdiv_vbo_lnor_comp.glsl
intern/shaders/common_subdiv_vbo_sculpt_data_comp.glsl
intern/shaders/common_view_clipping_lib.glsl
intern/shaders/common_view_lib.glsl
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/shaders/draw_command_generate_comp.glsl
intern/shaders/draw_debug_draw_display_frag.glsl
intern/shaders/draw_debug_draw_display_vert.glsl
intern/shaders/draw_debug_info.hh
intern/shaders/draw_debug_print_display_frag.glsl
intern/shaders/draw_debug_print_display_vert.glsl
intern/shaders/draw_intersect_lib.glsl
intern/shaders/draw_math_geom_lib.glsl
intern/shaders/draw_model_lib.glsl
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/shaders/draw_resource_finalize_comp.glsl
intern/shaders/draw_view_finalize_comp.glsl
intern/shaders/draw_view_lib.glsl
intern/shaders/draw_view_reconstruction_lib.glsl
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/shaders/draw_visibility_comp.glsl
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
intern/draw_command_shared.hh
intern/draw_common_shader_shared.hh
intern/draw_defines.hh
2022-12-13 02:46:12 +01:00
intern/draw_pointcloud_private.hh
intern/draw_shader_shared.hh
engines/gpencil/shaders/gpencil_frag.glsl
engines/gpencil/shaders/gpencil_vert.glsl
engines/gpencil/shaders/gpencil_antialiasing_frag.glsl
engines/gpencil/shaders/gpencil_antialiasing_vert.glsl
engines/gpencil/shaders/gpencil_common_lib.glsl
engines/gpencil/shaders/gpencil_layer_blend_frag.glsl
engines/gpencil/shaders/gpencil_mask_invert_frag.glsl
engines/gpencil/shaders/gpencil_depth_merge_frag.glsl
engines/gpencil/shaders/gpencil_depth_merge_vert.glsl
engines/gpencil/shaders/gpencil_vfx_frag.glsl
engines/gpencil/gpencil_defines.h
engines/gpencil/gpencil_shader_shared.h
engines/select/shaders/select_id_vert.glsl
engines/select/shaders/select_id_frag.glsl
engines/select/shaders/select_lib.glsl
engines/select/select_shader_shared.hh
engines/basic/shaders/basic_conservative_depth_geom.glsl
engines/basic/shaders/basic_depth_vert.glsl
engines/basic/shaders/basic_depth_vert_conservative_no_geom.glsl
engines/basic/shaders/basic_depth_curves_vert.glsl
engines/basic/shaders/basic_depth_pointcloud_vert.glsl
engines/basic/shaders/basic_depth_frag.glsl
engines/overlay/shaders/overlay_antialiasing_frag.glsl
engines/overlay/shaders/overlay_armature_dof_solid_frag.glsl
engines/overlay/shaders/overlay_armature_dof_vert.glsl
engines/overlay/shaders/overlay_armature_envelope_outline_vert.glsl
engines/overlay/shaders/overlay_armature_envelope_solid_frag.glsl
engines/overlay/shaders/overlay_armature_envelope_solid_vert.glsl
engines/overlay/shaders/overlay_armature_shape_outline_geom.glsl
engines/overlay/shaders/overlay_armature_shape_outline_vert.glsl
engines/overlay/shaders/overlay_armature_shape_outline_vert_no_geom.glsl
engines/overlay/shaders/overlay_armature_shape_solid_frag.glsl
engines/overlay/shaders/overlay_armature_shape_solid_vert.glsl
engines/overlay/shaders/overlay_armature_shape_wire_vert.glsl
engines/overlay/shaders/overlay_armature_sphere_outline_vert.glsl
engines/overlay/shaders/overlay_armature_sphere_solid_frag.glsl
engines/overlay/shaders/overlay_armature_sphere_solid_vert.glsl
engines/overlay/shaders/overlay_armature_stick_frag.glsl
engines/overlay/shaders/overlay_armature_stick_vert.glsl
engines/overlay/shaders/overlay_armature_wire_frag.glsl
engines/overlay/shaders/overlay_armature_wire_vert.glsl
engines/overlay/shaders/overlay_background_frag.glsl
engines/overlay/shaders/overlay_clipbound_vert.glsl
engines/overlay/shaders/overlay_common_lib.glsl
engines/overlay/shaders/overlay_depth_only_frag.glsl
engines/overlay/shaders/overlay_depth_only_vert.glsl
engines/overlay/shaders/overlay_edit_curve_handle_geom.glsl
engines/overlay/shaders/overlay_edit_curve_handle_vert.glsl
engines/overlay/shaders/overlay_edit_curve_handle_vert_no_geom.glsl
engines/overlay/shaders/overlay_edit_curve_point_vert.glsl
engines/overlay/shaders/overlay_edit_curves_handle_frag.glsl
engines/overlay/shaders/overlay_edit_curves_handle_vert.glsl
engines/overlay/shaders/overlay_edit_curve_wire_vert.glsl
engines/overlay/shaders/overlay_edit_gpencil_canvas_vert.glsl
engines/overlay/shaders/overlay_edit_gpencil_guide_vert.glsl
engines/overlay/shaders/overlay_edit_gpencil_vert.glsl
engines/overlay/shaders/overlay_edit_lattice_point_vert.glsl
engines/overlay/shaders/overlay_edit_lattice_wire_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_analysis_frag.glsl
engines/overlay/shaders/overlay_edit_mesh_analysis_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_common_lib.glsl
engines/overlay/shaders/overlay_edit_mesh_depth_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_frag.glsl
engines/overlay/shaders/overlay_edit_mesh_geom.glsl
engines/overlay/shaders/overlay_edit_mesh_normal_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_skin_root_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_vert.glsl
engines/overlay/shaders/overlay_edit_mesh_vert_no_geom.glsl
engines/overlay/shaders/overlay_edit_particle_point_vert.glsl
engines/overlay/shaders/overlay_edit_particle_strand_vert.glsl
engines/overlay/shaders/overlay_edit_uv_edges_frag.glsl
engines/overlay/shaders/overlay_edit_uv_edges_geom.glsl
engines/overlay/shaders/overlay_edit_uv_edges_vert.glsl
engines/overlay/shaders/overlay_edit_uv_edges_vert_no_geom.glsl
engines/overlay/shaders/overlay_edit_uv_face_dots_vert.glsl
engines/overlay/shaders/overlay_edit_uv_faces_vert.glsl
engines/overlay/shaders/overlay_edit_uv_image_mask_frag.glsl
engines/overlay/shaders/overlay_edit_uv_image_vert.glsl
engines/overlay/shaders/overlay_edit_uv_stretching_vert.glsl
engines/overlay/shaders/overlay_edit_uv_tiled_image_borders_vert.glsl
engines/overlay/shaders/overlay_edit_uv_verts_frag.glsl
engines/overlay/shaders/overlay_edit_uv_verts_vert.glsl
engines/overlay/shaders/overlay_extra_frag.glsl
engines/overlay/shaders/overlay_extra_groundline_vert.glsl
engines/overlay/shaders/overlay_extra_lightprobe_grid_vert.glsl
engines/overlay/shaders/overlay_extra_loose_point_frag.glsl
engines/overlay/shaders/overlay_extra_loose_point_vert.glsl
engines/overlay/shaders/overlay_extra_point_vert.glsl
engines/overlay/shaders/overlay_extra_vert.glsl
engines/overlay/shaders/overlay_extra_wire_frag.glsl
engines/overlay/shaders/overlay_extra_wire_vert.glsl
engines/overlay/shaders/overlay_facing_frag.glsl
engines/overlay/shaders/overlay_facing_vert.glsl
engines/overlay/shaders/overlay_grid_background_frag.glsl
engines/overlay/shaders/overlay_grid_frag.glsl
engines/overlay/shaders/overlay_grid_vert.glsl
engines/overlay/shaders/overlay_image_frag.glsl
engines/overlay/shaders/overlay_image_vert.glsl
engines/overlay/shaders/overlay_motion_path_line_frag.glsl
engines/overlay/shaders/overlay_motion_path_line_geom.glsl
engines/overlay/shaders/overlay_motion_path_line_vert.glsl
engines/overlay/shaders/overlay_motion_path_line_vert_no_geom.glsl
engines/overlay/shaders/overlay_motion_path_point_vert.glsl
engines/overlay/shaders/overlay_outline_detect_frag.glsl
engines/overlay/shaders/overlay_outline_prepass_curves_vert.glsl
engines/overlay/shaders/overlay_outline_prepass_frag.glsl
engines/overlay/shaders/overlay_outline_prepass_geom.glsl
engines/overlay/shaders/overlay_outline_prepass_gpencil_frag.glsl
engines/overlay/shaders/overlay_outline_prepass_gpencil_vert.glsl
engines/overlay/shaders/overlay_outline_prepass_pointcloud_vert.glsl
engines/overlay/shaders/overlay_outline_prepass_vert.glsl
engines/overlay/shaders/overlay_outline_prepass_vert_no_geom.glsl
engines/overlay/shaders/overlay_paint_face_vert.glsl
engines/overlay/shaders/overlay_paint_point_vert.glsl
engines/overlay/shaders/overlay_paint_texture_frag.glsl
engines/overlay/shaders/overlay_paint_texture_vert.glsl
engines/overlay/shaders/overlay_paint_vertcol_frag.glsl
engines/overlay/shaders/overlay_paint_vertcol_vert.glsl
engines/overlay/shaders/overlay_paint_weight_frag.glsl
engines/overlay/shaders/overlay_paint_weight_vert.glsl
engines/overlay/shaders/overlay_paint_wire_vert.glsl
engines/overlay/shaders/overlay_particle_frag.glsl
engines/overlay/shaders/overlay_particle_vert.glsl
engines/overlay/shaders/overlay_point_varying_color_frag.glsl
engines/overlay/shaders/overlay_point_varying_color_varying_outline_aa_frag.glsl
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
engines/overlay/shaders/overlay_pointcloud_only_vert.glsl
engines/overlay/shaders/overlay_sculpt_curves_cage_vert.glsl
engines/overlay/shaders/overlay_sculpt_curves_selection_frag.glsl
engines/overlay/shaders/overlay_sculpt_curves_selection_vert.glsl
engines/overlay/shaders/overlay_sculpt_mask_frag.glsl
engines/overlay/shaders/overlay_sculpt_mask_vert.glsl
engines/overlay/shaders/overlay_uniform_color_frag.glsl
engines/overlay/shaders/overlay_varying_color.glsl
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
engines/overlay/shaders/overlay_viewer_attribute_curve_vert.glsl
engines/overlay/shaders/overlay_viewer_attribute_curves_vert.glsl
engines/overlay/shaders/overlay_viewer_attribute_frag.glsl
engines/overlay/shaders/overlay_viewer_attribute_mesh_vert.glsl
engines/overlay/shaders/overlay_viewer_attribute_pointcloud_vert.glsl
engines/overlay/shaders/overlay_volume_gridlines_vert.glsl
engines/overlay/shaders/overlay_volume_velocity_vert.glsl
engines/overlay/shaders/overlay_wireframe_frag.glsl
engines/overlay/shaders/overlay_wireframe_vert.glsl
engines/overlay/shaders/overlay_xray_fade_frag.glsl
engines/overlay/overlay_shader_shared.h
engines/image/shaders/image_engine_color_frag.glsl
engines/image/shaders/image_engine_color_vert.glsl
engines/image/shaders/image_engine_depth_frag.glsl
engines/image/shaders/image_engine_depth_vert.glsl
)
set(GLSL_C)
foreach(GLSL_FILE ${GLSL_SRC})
data_to_c_simple(${GLSL_FILE} GLSL_C STRIP_LEADING_C_COMMENTS)
endforeach()
blender_add_lib(bf_draw_shaders "${GLSL_C}" "" "" "")
list(APPEND LIB
PRIVATE bf::animrig
bf_draw_shaders
)
set(GLSL_SOURCE_CONTENT "")
foreach(GLSL_FILE ${GLSL_SRC})
get_filename_component(GLSL_FILE_NAME ${GLSL_FILE} NAME)
string(REPLACE "." "_" GLSL_FILE_NAME_UNDERSCORES ${GLSL_FILE_NAME})
string(APPEND GLSL_SOURCE_CONTENT "SHADER_SOURCE\(datatoc_${GLSL_FILE_NAME_UNDERSCORES}, \"${GLSL_FILE_NAME}\", \"${GLSL_FILE}\"\)\n")
endforeach()
set(glsl_source_list_file "${CMAKE_CURRENT_BINARY_DIR}/glsl_draw_source_list.h")
file(GENERATE OUTPUT ${glsl_source_list_file} CONTENT "${GLSL_SOURCE_CONTENT}")
list(APPEND SRC ${glsl_source_list_file})
list(APPEND INC ${CMAKE_CURRENT_BINARY_DIR})
target_include_directories(bf_draw_shaders PUBLIC ${CMAKE_CURRENT_BINARY_DIR})
Use DrawManager for Image/UV Editor This project moves the current UV/Image editor drawing to the draw manager. Why would we do this: **Performance**: Current implementation would draw each texel per time. Multiple texels could be drawn per pixel what would overwrite the previous result. You can notice this when working with large textures. Repeat image drawing made this visible by drawing for a small period of time and stop drawing the rest. Now the rendering is fast and all repeated images are drawn. **Alpha drawing**: Current implementation would draw directly in display space. Giving incorrect results when displaying alpha transparent images. This addresses {T52680}, {T74709}, {T79518} The image editor now can show emission only colors. See {D8234} for examples. **Current Limitations** Using images that are larger than supported by your GPU are resized (eg larger than 16000x16000 are resized to 8k). This leaves some blurring artifacts. It is a low priority to add support back of displaying individual pixels of huge images. There is a design task {T80113} with more detail. **Implementation overview** Introduced an Image Engine in the draw module. this engine is responsible for drawing the texture in the main area of the UV/Image editor. The overlay engine has a edit_uv overlay which is responsible to draw the UV's, shadows and overlays specifically for the UV Image editor. The background + checker pattern is drawn by the overlay_background. The patch will allow us to share overlays between the 3d viewport and UV/Image editor more easily. In most cases we just need to switch the `pos` with the `u` attribute in the vertex shader. The project can be activated in the user preferences as experimental features. In a later commit this will be reversed. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D8234
2020-09-11 07:59:48 +02:00
list(APPEND INC
)
if(WITH_DRAW_DEBUG)
list(APPEND SRC
engines/select/select_debug_engine.cc
)
add_definitions(-DWITH_DRAW_DEBUG)
endif()
if(WITH_OPENSUBDIV)
list(APPEND INC_SYS
${OPENSUBDIV_INCLUDE_DIRS}
)
endif()
Volumes: refactor volume grid storage This refactors how volume grids are stored with the following new goals in mind: * Get a **stand-alone volume grid** data structure that can be used by geometry nodes. Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block. * Support **implicit sharing of grids and trees**. Previously, it was possible to share data when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was not flexible enough. * Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls to some "load" function all the time. * Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block. * Get a **tiered API** for different levels of `openvdb` involvement: * No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that still work in this case. This makes it possible to write high level code for volumes that does not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`. * Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`. * "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned out to be not necessary for the common API. So this is only used for task specific APIs. At the core of the new API is the `VolumeGridData` type. It's a wrapper around an `openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading. Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid. Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit sharing. At highest level we currently have the `Volume` data-block which contains a list of `VolumeGrid`. ```mermaid flowchart LR Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid ``` The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes it easy to load and reuse entire files and individual grids from disk. It also supports caching simplify levels for grids on disk. An important new concept are the "tree access tokens". Whenever some code wants to work with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`. This access token has to be kept alive for as long as the code works with the grid data. The same token is valid for read and write access. The purpose of these access tokens is to make it possible to detect when some code is currently working with the openvdb tree. This allows freeing it if it's possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by multiple owners, but only no one is actively working with. In some sense, this is similar to the existing `ImageUser` concept. The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`. Most other changes are updates to existing code to use the new API. Pull Request: https://projects.blender.org/blender/blender/pulls/116315
2023-12-20 15:32:52 +01:00
if(WITH_OPENVDB)
list(APPEND INC
../../../intern/openvdb
)
list(APPEND INC_SYS
${OPENVDB_INCLUDE_DIRS}
)
list(APPEND LIB
bf_intern_openvdb
${OPENVDB_LIBRARIES}
)
add_definitions(-DWITH_OPENVDB ${OPENVDB_DEFINITIONS})
endif()
if(WITH_MOD_FLUID)
list(APPEND INC
../../../intern/mantaflow/extern
)
add_definitions(-DWITH_FLUID)
endif()
if(WITH_FREESTYLE)
add_definitions(-DWITH_FREESTYLE)
endif()
VR: Initial Virtual Reality support - Milestone 1, Scene Inspection NOTE: While most of the milestone 1 goals are there, a few smaller features and improvements are still to be done. Big picture of this milestone: Initial, OpenXR-based virtual reality support for users and foundation for advanced use cases. Maniphest Task: https://developer.blender.org/T71347 The tasks contains more information about this milestone. To be clear: This is not a feature rich VR implementation, it's focused on the initial scene inspection use case. We intentionally focused on that, further features like controller support are part of the next milestone. - How to use? Instructions on how to use this are here: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test These will be updated and moved to a more official place (likely the manual) soon. Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC headsets don't support the OpenXR standard yet and hence, do not work with this implementation. --------------- This is the C-side implementation of the features added for initial VR support as per milestone 1. A "VR Scene Inspection" Add-on will be committed separately, to expose the VR functionality in the UI. It also adds some further features for milestone 1, namely a landmarking system (stored view locations in the VR space) Main additions/features: * Support for rendering viewports to an HMD, with good performance. * Option to sync the VR view perspective with a fully interactive, regular 3D View (VR-Mirror). * Option to disable positional tracking. Keeps the current position (calculated based on the VR eye center pose) when enabled while a VR session is running. * Some regular viewport settings for the VR view * RNA/Python-API to query and set VR session state information. * WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data * wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU context) * DNA/RNA for management of VR session settings * `--debug-xr` and `--debug-xr-time` commandline options * Utility batch & config file for using the Oculus runtime on Windows. * Most VR data is runtime only. The exception is user settings which are saved to files (`XrSessionSettings`). * VR support can be disabled through the `WITH_XR_OPENXR` compiler flag. For architecture and code documentation, see https://wiki.blender.org/wiki/Source/Interface/XR. --------------- A few thank you's: * A huge shoutout to Ray Molenkamp for his help during the project - it would have not been that successful without him! * Sebastian Koenig and Simeon Conzendorf for testing and feedback! * The reviewers, especially Brecht Van Lommel! * Dalai Felinto for pushing and managing me to get this done ;) * The OpenXR working group for providing an open standard. I think we're the first bigger application to adopt OpenXR. Congratulations to them and ourselves :) This project started as a Google Summer of Code 2019 project - "Core Support of Virtual Reality Headsets through OpenXR" (see https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Some further information, including ideas for further improvements can be found in the final GSoC report: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report Differential Revisions: D6193, D7098 Reviewed by: Brecht Van Lommel, Jeroen Bakker
2020-03-17 20:20:55 +01:00
if(WITH_XR_OPENXR)
add_definitions(-DWITH_XR_OPENXR)
endif()
if(WITH_GTESTS)
if(WITH_GPU_DRAW_TESTS)
add_definitions(-DWITH_GPU_DRAW_TESTS)
if(WITH_OPENGL_BACKEND)
add_definitions(-DWITH_OPENGL_BACKEND)
endif()
if(WITH_METAL_BACKEND)
add_definitions(-DWITH_METAL_BACKEND)
endif()
if(WITH_VULKAN_BACKEND)
add_definitions(-DWITH_VULKAN_BACKEND)
list(APPEND INC_SYS
PUBLIC ${VULKAN_INCLUDE_DIRS}
)
endif()
endif()
endif()
if(WITH_TBB)
add_definitions(-DWITH_TBB)
if(WIN32)
# TBB includes Windows.h which will define min/max macros
# that will collide with the stl versions.
add_definitions(-DNOMINMAX)
endif()
list(APPEND INC_SYS
${TBB_INCLUDE_DIRS}
)
list(APPEND LIB
${TBB_LIBRARIES}
)
endif()
blender_add_lib(bf_draw "${SRC}" "${INC}" "${INC_SYS}" "${LIB}")
if(WITH_GTESTS)
if(WITH_GPU_DRAW_TESTS)
set(TEST_SRC
DRWManager: New implementation. This is a new implementation of the draw manager using modern rendering practices and GPU driven culling. This only ports features that are not considered deprecated or to be removed. The old DRW API is kept working along side this new one, and does not interfeer with it. However this needed some more hacking inside the draw_view_lib.glsl. At least the create info are well separated. The reviewer might start by looking at `draw_pass_test.cc` to see the API in usage. Important files are `draw_pass.hh`, `draw_command.hh`, `draw_command_shared.hh`. In a nutshell (for a developper used to old DRW API): - `DRWShadingGroups` are replaced by `Pass<T>::Sub`. - Contrary to DRWShadingGroups, all commands recorded inside a pass or sub-pass (even binds / push_constant / uniforms) will be executed in order. - All memory is managed per object (except for Sub-Pass which are managed by their parent pass) and not from draw manager pools. So passes "can" potentially be recorded once and submitted multiple time (but this is not really encouraged for now). The only implicit link is between resource lifetime and `ResourceHandles` - Sub passes can be any level deep. - IMPORTANT: All state propagate from sub pass to subpass. There is no state stack concept anymore. Ensure the correct render state is set before drawing anything using `Pass::state_set()`. - The drawcalls now needs a `ResourceHandle` instead of an `Object *`. This is to remove any implicit dependency between `Pass` and `Manager`. This was a huge problem in old implementation since the manager did not know what to pull from the object. Now it is explicitly requested by the engine. - The pases need to be submitted to a `draw::Manager` instance which can be retrieved using `DRW_manager_get()` (for now). Internally: - All object data are stored in contiguous storage buffers. Removing a lot of complexity in the pass submission. - Draw calls are sorted and visibility tested on GPU. Making more modern culling and better instancing usage possible in the future. - Unit Tests have been added for regression testing and avoid most API breakage. - `draw::View` now contains culling data for all objects in the scene allowing caching for multiple views. - Bounding box and sphere final setup is moved to GPU. - Some global resources locations have been hardcoded to reduce complexity. What is missing: - ~~Workaround for lack of gl_BaseInstanceARB.~~ Done - ~~Object Uniform Attributes.~~ Done (Not in this patch) - Workaround for hardware supporting a maximum of 8 SSBO. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:30:48 +02:00
tests/draw_pass_test.cc
2022-09-07 07:14:33 +02:00
tests/draw_testing.cc
tests/eevee_test.cc
tests/draw_testing.hh
)
set(TEST_INC
../../../intern/ghost
../gpu/tests
)
set(TEST_LIB
)
blender_add_test_suite_lib(draw "${TEST_SRC}" "${INC};${TEST_INC}" "${INC_SYS}" "${LIB};${TEST_LIB}")
endif()
endif()