Simdify Document Rendering

You need one of the following products to complete this exercise: Simdify® Free Edition

Once you take your first steps to create your own shader modules, it will be critical to understand how a Simdify shader module is rendered. Let's take a look!

Start The Module Application

  1. Start the Module app. (Start > Programs > Scenomics > Module) or (Windows® key and then type 'Module' to find the app icon.)

    The application displays a splash screen and then the application desktop appears. The main menu is composed of three items that contain commands relevant to the current context (which is an empty document). The interface changes when you create a new file or load a file from disk.

    This is a picture of the desktop.

Open Reference Document

  1. Examine the main menu and select File > Open From GLSL Reference Library....

    The software presents a dialog that allows you to choose the GLSL version, pixel format, and topology of the GLSL reference shader you wish to locate. The third option allows you to open the reference document in the application or to open an Explorer® window to the location of the GLSL reference shader.

    This is a picture of the reference shader selector dialog.
  2. Set Select GLSL Version to 430.
  3. Set Select Sampler Type to sampler2D.
  4. Click OK or hit ENTER when you are finished.

    The software presents an Explorer® in the directory containing the desired GLSL reference shader.

    This is a picture of the file open dialog.
  5. Select sampler2D.box and click Open or hit ENTER when you are finished.

    The software opens the GLSL reference document.

    This is a picture of the GLSL reference document.

Please refer to the following definitions as you learn about document rendering.

Relationship Description
Parent A parent is a node that contains child nodes.
Child A child is a node that has a parent. Every node in the directed acyclic graph has a parent except the root node.
Sibling A sibling is a node that has the same parent as another node.
Connection A node can have a connection to another node, but unlike parent, child, and sibling relationships, this type of relationship is not visible in the hierarchy itself. You can view the connection between one node and another by moving the mouse over the node, or by double clicking the node and reviewing its properties in the property sheet.

Traversal & Rendering

Simdify shader module documents use a directed acyclic graph to store content. Most of the time we'll refer to this as the hierarchy or the graph. Since it's a directed acyclic graph, everything is node-based as you would expect. Shader module document hierarchies are usually fairly flat, but that's not always the case. It's also important to note that not every node needs to be rendered. Nodes are also frequently used to do things such as organize content or build metadata into a document.

The rendering loop starts at the root of the document (named Module in this case) and traverses (or visits) nodes using a breadth-first search. The application makes a rendering decision as it traverses each node. Note that traversal is not the same as rendering: traversal is simply the process of visiting each node. Most of the time, rendering only takes place if certain conditions, such as object visibility, are met.

It can be helpful to think of traversal happening as you go from the top of the hierarchy to the bottom. If a node visited during traversal has child nodes, they will be rendered if certain conditions are met. These conditions are usually specified by the node itself.

Figure 1.1. sampler2D.box. In this document, we'll discuss the structure and meaning of this node hierarchy.

This is a picture of the GLSL reference document.

Let's discuss traversal and rendering for this document. NOTE: Icons that are grey usually indicate a node that invisible, unused, or disabled in some way.

  1. Application visits Module This is a picture of the GLSL reference document.
    Module is a node of type <EditModel3D>. This is the root node. Traversal and rendering always starts here at the beginning of each frame. The first test checks if Module is visible or not. If Module is visible, the application visits Module's child nodes in order from top-to-bottom. If Module is invisible, the traversal process starts again, which means nothing will be traversed or rendered. In this case, Module is visible so the software visits its child nodes.
  2. Application visits Dependencies This is a picture of the GLSL reference document.
    Dependencies is a node of type <Group>. This is the first child of the root node. This node is invisible so its child nodes are not visited. This is a good example of using nodes to organize content and store metadata. Meaning, the application uses these nodes for its own purposes that have nothing to do with rendering.
  3. Application visits Includes This is a picture of the GLSL reference document.
    Includes is a node of type <IncludePaletteNode>. This node is invisible and it doesn't have any child nodes to visit.
  4. Application visits Locals This is a picture of the GLSL reference document.
    Locals is a node of type <DataPaletteNode>. This node is invisible and it doesn't have any child nodes to visit.
  5. Application visits Inputs This is a picture of the GLSL reference document.
    Inputs is a node of type <ConstraintPaletteNode>. This node is invisible so its child nodes are not visited. Note that this node and its children are used to add metadata to the document that describes what inputs the shader module requires. This node is only necessary if the shader module will be used in a workflow layout.
  6. Application visits Outputs This is a picture of the GLSL reference document.
    Outputs is a node of type <ConstraintPaletteNode>. This node is invisible so its child nodes are not visited.
  7. Application visits Shaders This is a picture of the GLSL reference document.
    Shaders is a node of type <ShaderPaletteNode>. This node is invisible so its child nodes are not visited.
  8. Application visits Textures This is a picture of the GLSL reference document.
    Textures is a node of type <TexturePaletteNode>. This node is invisible so its child nodes are not visited.
  9. Application visits Geometry This is a picture of the GLSL reference document.
    Geometry is a node of type <GeometryPaletteNode>. This node is invisible so its child nodes are not visited.
  10. Application visits Visual This is a picture of the GLSL reference document.
    Visual is a node of type <ShaderResourceNode>. This node is visible, but it has constraints that determine whether or not its child nodes will be visited. First, this node requires a certain version of GLSL to be available in the <Program> node to which it is connected. Note that the connection is not visible in the document—but you can move the mouse over the node to see the <Program> to which it is connected, or you can double click this node and examine the property sheet. Second, this node may or may not require certain OpenGL extensions to be available. So, even if this node is visible, there are used-defined constraints that control whether or not its child nodes are traversed.
  11. Application visits Bind Visual This is a picture of the GLSL reference document.
    Bind Visual is a node of type <ProgramBindNode>. This node is visible and it doesn't usually have children. When this node is visited, it renders the <Program> node to which it is connected. This activates the corresponding program in the OpenGL context, which means it can be used for rendering. This is where workload processing begins!
  12. Application visits uniform mat4x4 modelViewMatrix This is a picture of the GLSL reference document.
    uniform mat4x4 modelViewMatrix is a node of type <Float32MatrixNode>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the dark icon indicates that the node isn't active on the rendering device. That's because it's declared in the vertex shader but not used. Note that this node is used here as a fallback on certain platforms, but it's not strictly needed.
  13. Application visits uniform mat4x4 modelViewProjectionMatrix This is a picture of the GLSL reference document.
    uniform mat4x4 modelViewProjectionMatrix is a node of type <Float32MatrixNode>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the light-colored icon indicates that the node is active on the rendering device. This node captures the model-view-projection-matrix concatenation from the application's camera system and sets it as a uniform. The vertex shader uses those values to transform vertices from worldspace to normalized device coordinates (-1.0 to 1.0).
  14. Application visits uniform int image_width This is a picture of the GLSL reference document.
    uniform int image_width is a node of type <Int32Node>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the dark icon indicates that the node isn't active on the rendering device. This node captures the width of a <Texture> node and sets it as a uniform. Note that this node is used here as a fallback on certain platforms. For example: platforms that have bugs in the imageSize() function, or GLSL versions that do not support imageSize() at all.
  15. Application visits uniform int image_height This is a picture of the GLSL reference document.
    uniform int image_height is a node of type <Int32Node>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the dark icon indicates that the node isn't active on the rendering device. This node captures the height of a <Texture> node and sets it as a uniform. Note that this node is used here as a fallback on certain platforms. For example: platforms that have bugs in the imageSize() function, or GLSL versions that do not support imageSize() at all.
  16. Application visits uniform float format_min This is a picture of the GLSL reference document.
    uniform float format_min is a node of type <Float32Node>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the light-colored icon indicates that the node is active on the rendering device (because it has been initialized in the shader). This node sets the texture format minimum value as a uniform. Note that this node is used here as a fallback for certain platforms.
  17. Application visits uniform float format_max This is a picture of the GLSL reference document.
    uniform float format_max is a node of type <Float32Node>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the light-colored icon indicates that the node is active on the rendering device (because it has been initialized in the shader). This node sets the texture format maximum value as a uniform. Note that this node is used here as a fallback for certain platforms.
  18. Application visits layout( binding = 0 ) uniform sampler2D pixel_data This is a picture of the GLSL reference document.
    layout( binding = 0 ) uniform sampler2D pixel_data is a node of type <SamplerNode>. This node doesn't have a visible/invisible state, but instead has an enabled/disabled state. At present, the light-colored icon indicates that the node is active on the rendering device. This node is connected to a <Texture> that it binds to the texture unit specified by the layout( binding = 0 ) component of the sampler declaration in the GLSL. This node is the last child in the child list, so traversal returns to the parent.
  19. Application visits Render This is a picture of the GLSL reference document.
    Render is a node of type <ShaderResourceNode>. This node is visible, but it has constraints that determine whether or not its child nodes will be visited. First, this node requires a certain version of GLSL to be available in the <Program> node to which it is connected. Note that the connection is not visible in the document—but you can move the mouse over the node to see the <Program> to which it is connected, or you can double click this node and examine the property sheet. Second, this node may or may not require certain OpenGL extensions to be available. So, even if this node is visible, there are used-defined constraints that control whether or not its child nodes are traversed.
  20. Application visits Mesh This is a picture of the GLSL reference document.
    Mesh is a node of type <NodeLink>. This node is visible and will be rendered. A <NodeLink> is like a pointer to another node in the document. In this case it points at the <ParametricMesh> named Mesh. Rendering a mesh invokes a draw call that causes the shader to execute its workload. Rendering a mesh is always required to initiate rendering and produce a result unless you're using compute shaders.

Close all Simdify applications started during this exercise.