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, tesselation, geometry and fragment shaders in the context of the graphics pipeline

It’s the magic juice of our shading frameworks.

Available Frameworks

You may ask yourself, why there is a need for domain specific frameworks, when it all boils down to the generation of GLSL shaders. But each of the different frameworks tackles a specific domain and offers features that would not be possible on one 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 to specify a complete GLSL shader, so it does not allow writing combinable extensions. If your shader should e.g. support depth peeling, it has to explicitly contain 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 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 to pass 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 is the SuperShader concept applied to the old SoShader framework. It is very similar to the GVR shader pipeline. The module SoShaderPipelineFunction is used analog to SoGVRShaderFunction. The module SoShaderPipeline is used to activate the usage of the pipeline. There are some additional C++ Inventor modules that encapsulate effects, for example:

This framework should be used in favor of SoShader + SoVertexShader or SoFragmentShader whenever possible. The only reason to use SoShader is the need for changing the geometry shader, since this is not supported by SoShaderPipeline yet! The big advantage of the SoShaderPipeline is that is allows rendering modules to only change certain 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. SoDepthPeelRenderer extends the shader with correct depth peeling code, without affecting any other parts of the shader pipeline. And there are various other rendering modules which only became possible because of the extensible nature of the pipeline.

For more details, have a look at GLSL Shader Pipeline

SoView2DShaderOverlay

This also uses the SuperShader concept, this time to modify the 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 can be combined in an arbitrary fashion. For instance, it can be used to implement a checker pattern, blending between two overlays. Or it can be used to add contour detection using the shader, see e.g. View2DIsoContourShader. However, this does not allow for access to the 3D texture, but 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 be used in the shader then.

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 it’s various example networks.

SoPostEffectRenderer

And finally, there is the SoPostEffectRenderer framework. Basically, you use this if you want to change the look of the final rendering result by applying global effects to the scene in screen space. This is a bit different in that it focuses on out-of-the-box effects and their combination first:

In the past it was not easy to combine such effects. Check out the many fancy examples available. In addition, own effects can be implemented using SoPostEffectCustomPass. This can also be used to render your own overlay on top of the rendering. This is basically what was done using SoImagePlane + SoShader in the past.

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

Common stuff & compatibility

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

The frameworks can be combined in many ways, there are no technical hurdles for that. The basic concepts of the four new shader frameworks are the same. Most of these frameworks feature diagnosis modules to inspect the pipelines and include modules, which allow to define functions that may be reused by multiple shader modules.