Shader Frameworks Overview

Introduction

Shader support has been available in MeVisLab for many years, starting with the old SoShader framework. Today, MeVisLab offers various distinguished shader frameworks for different rendering tasks, which we will introduce in this overview.

shader1.png shader2.png shader3.png

What is GLSL?

All the shader support in MeVisLab is based on GLSL - the OpenGL Shading language. GLSL is

  • a high-level shading language with a syntax that is based on that of C,
  • independent of the used platform or graphics card, and
  • used to code vertex, tessellation, geometry, and fragment shaders in the context of the graphics pipeline

It’s the magic juice of our shading frameworks.

Available Frameworks

You may wonder why there is a need for domain-specific frameworks when it ultimately comes down to the generation of GLSL shaders. However, each of the different frameworks addresses a specific domain and provides features that would not be achievable with a single generic framework. The following GLSL based frameworks are available in MeVisLab:

  • SoShader (surface rendering)
  • GVR shader pipeline (volume rendering)
  • SoShaderPipeline (surface rendering)
  • SoView2DShaderOverlay (2D rendering)
  • SoPostEffectRenderer (screen space effects)

SoShader

This was the first framework for shader support in MeVisLab and is still the basic foundation for all the other frameworks. Originally, it was mainly aimed at changing the rendering of polygonal surfaces in a 3D Open Inventor rendering. It contains:

The SoShader framework only allows specifying a complete GLSL shader, making it unsuitable for writing combinable extensions. For example, if your shader needs to support depth peeling, it must explicitly include code to handle that, in contrast to SoShaderPipeline, which will be explained later.

For more details, have a look at GLSL shader framework

GVR Shader Pipeline

Originally, the SoGVRVolumeRenderer generated a GLSL shader internally, without being extensible by the user. A modular combination of various effects was not possible that way. So the first modular shader framework in MeVisLab was born and it is based on the SuperShader concept. It subdivides the rendering shader into a dynamic shader pipeline, which allows for the interactive addition of custom shader code to the volume rendering. A pipeline step is modeled as a subset of several shader pipeline functions represented by instances of SoGVRShaderFunction, which contain the GLSL shader code. Hence, only certain snippets of the vertex or fragment shader code of the GVR are replaced. An important part of the concept is the state, a data structure that is available in all functions and which allows for passing information between the various steps. Since the SoGVRVolumeRenderer can also be used to render slabs on a SoView2D using SoView2DScene, the shaders can also be used to render special effects on 2D viewers, like contours/edge detection or shading the distance to some object.

Additional information:

  • Morgan McGuire “The SuperShader” in SHADERX4 Ed. Wolfgang Engel, p. 485
  • Rieder, Christian; Palmer, Stephan; Link, Florian; Hahn, Horst K., “A Shader Framework for Rapid Prototyping of GPU-Based Volume Rendering”, Computer Graphics Forum, 2011, EuroVis Special Issue

For more details, have a look at Giga Voxel Renderer and SoGVRShaderFunction.

SoShaderPipeline

This applies the SuperShader concept to the old SoShader framework. It is very similar to the GVR shader pipeline. The module SoShaderPipelineFunction is used similarly to SoGVRShaderFunction. The module SoShaderPipeline is used to activate the pipeline. There are additional C++ Inventor modules that encapsulate effects, for example:

This framework should be preferred over SoShader + SoVertexShader or SoFragmentShader whenever possible. The only reason to use SoShader is if there is a need to modify the geometry shader, as SoShaderPipeline does not yet support this feature. The major advantage of the SoShaderPipeline is that it allows rendering modules to modify only specific steps of the shading pipeline. For example, the SoDrawInstanced module uses the SoShaderPipeline to add per-instance transformation and coloring without affecting the lighting model. The SoDepthPeelRenderer extends the shader with correct depth-peeling code without impacting other parts of the shader pipeline. Various other rendering modules have also become possible due to the pipeline’s extensible nature.

For more details, have a look at GLSL Shader Pipeline

SoView2DShaderOverlay

This also applies the SuperShader concept, this time to modify rendering in a SoView2D. For that, SoView2DShaderFunction is used in combination with SoView2DShaderOverlay. The results of the evaluation of SoView2DOverlayMPR or SoView2DOverlay in the current viewing plane can be used in the shader and combined in any manner. For example, it can be used to implement a checker pattern, blending between two overlays, or to add contour detection using the shader, as seen in View2DIsoContourShader. However, this does not provide access to the 3D texture, only to the current 2D overlay textures. The SoView2DExtensionSampler module can be used to render the result of any SoView2D extension into a texture, which can then be used in the shader.

In contrast to the previous frameworks, only the fragment shader is modified and the 2D coordinate system is provided by the SoView2D.

For more details, have a look at SoView2DShaderOverlay and its various example networks.

SoPostEffectRenderer

Finally, there is the SoPostEffectRenderer framework. Essentially, you use this if you want to modify the final rendering result by applying global effects to the scene in screen space. This approach differs slightly as it prioritizes out-of-the-box effects and their combination:

In the past, combining such effects was not easy. Check out the many available examples. Additionally, custom effects can be implemented using SoPostEffectCustomPass, which can also be used to render your own overlay on top of the rendering. This is essentially what was previously done with SoImagePlane + SoShader.

For more details, have a look at GLSL Post-Processing Effect Framework

Common Features & Compatibility

Although the SoVertexShader and SoFragmentShader modules from the original SoShader framework are now obsolete, all other modules remain important. They are used to provide additional information to shaders and can be utilized with all the new frameworks. However, the SoMLSampler modules should only be used in the GVR and SoView2D pipelines when the framework-specific modules for providing images (GVR: SoGVRSecondaryVolume, SoGVRSecondaryVolume, SoGVRTransformedVolume; SoView2D: SoView2DOverlayMPR, SoView2DOverlay) are insufficient.

The frameworks can be combined in various ways, with no technical barriers. The basic concepts of the four new shader frameworks are similar. Most of these frameworks feature diagnostic modules for inspecting the pipelines and include modules that allow defining functions reusable by multiple shader modules.