Archived issue #0030126
Visualization, Graphic3d_ShaderManager - define standard Lighting & Clipping within custom GLSL programs as template functions
Description
Currently, defining a custom GLSL program requires redefining of all major blocks, including shading (lighting) and clipping.
This limits flexibility of custom programs at application level, since when lighting is required, significant code blocks have to be copied, complicating GLSL source code and its maintenance (considering that application requires a minor customization of shader code).
It is proposed redefining major portions of standard GLSL programs as reusable functions, which custom GLSL program can mark as blocks for template substitution at Shader Manager.
This conception is already used within some custom Shader Managers within OCC Products - the approach can be adapted and improved for OpenGl_ShaderManager, and ideally custom Shader Managers can be further replaced by standard one.
Another issue is optimization of custom GLSL programs depending on number of lights and clipping planes - currently, these optimizations (handful for low-end hardware) are applicable only to built-in GLSL programs, because custom GLSL has only one cached instance within current design.
This limits flexibility of custom programs at application level, since when lighting is required, significant code blocks have to be copied, complicating GLSL source code and its maintenance (considering that application requires a minor customization of shader code).
It is proposed redefining major portions of standard GLSL programs as reusable functions, which custom GLSL program can mark as blocks for template substitution at Shader Manager.
This conception is already used within some custom Shader Managers within OCC Products - the approach can be adapted and improved for OpenGl_ShaderManager, and ideally custom Shader Managers can be further replaced by standard one.
Another issue is optimization of custom GLSL programs depending on number of lights and clipping planes - currently, these optimizations (handful for low-end hardware) are applicable only to built-in GLSL programs, because custom GLSL has only one cached instance within current design.
Public activity
No public notes
Participants are labeled by their role within this record.
Related records
- #0032152 · related to · closedVisualization - move out GLSL program generator from OpenGl_ShaderManager to Graphic3d_ShaderManager
- #0030700 · related to · closedVisualization, TKOpenGl - support PBR Metallic-Roughness shading model
- #0024192 · child of · closedAdding support for shaders to OCCT visualization toolkit
- #0025282 · child of · closedVisualization, OpenGl_PrimitiveArray - provide built-in GLSL programs as alternative to FFP
- #0030631 · child of · newVisualization - Vulkan graphic driver prototype