Inviwo Tutorials: Data Structutres & Memory Representations

Main ideas & concepts (Inviwo: Data Structures & Memory Representations)

Goal of the tutorial

• Explain the main data structures in Inviwo and how they relate to OpenGL concepts.
• Show how data is stored and moved between different storage devices and contexts.
• Demonstrate how to access data on the CPU safely and generically.

Core data structures in Inviwo

Volume

• Represents data on a 3D structured grid.
• Each voxel can be:
  • Any basic numerical type, or
  • Vectors of such types.

Volume images

• Similar to OpenGL framebuffers.
• An Inviwo “image” can consist of multiple layers (like different framebuffer attachments).
• Layers may be of different types.

Mesh

• Contains a set of buffer objects.
• Each buffer can hold:
  • An arbitrary number of elements,
  • Elements of arbitrary type.
• Standard mesh buffers include:
  • Tag-free position buffer
  • Normal buffer
  • Color buffer
  • One or more index buffers
• Mesh buffer content is conceptualized as handle-based (see below).

Important clarification: handles vs stored data

• The most relevant Inviwo data types (volume, image/volume images, mesh, buffers) do not directly store the actual data.
• Instead, they are handles that refer to underlying memory representations.

Memory representation abstraction

• Provides device-independent access to actual data storage.
• For each data structure, Inviwo maintains representations per storage type (examples given for volume):
  • Disk representation (volume data on disk)
  • RAM representation (in CPU memory)
  • GPU representation (in GPU memory, within an OpenGL context)
• There may be multiple representations per device depending on the framework (example mentioned):
  • An OpenCL representation stored on a GPU
  • A CUDA representation if using CUDA code

Representation converters and synchronization

• Converters handle:
  • Transferring data to the needed device/context
  • Wrapping it in the appropriate representation type
• Using converters means users can work with handles (e.g., Volume, Mesh) without manually:
  • Managing exact storage details
  • Synchronizing updates across devices/contexts

---

Example methodology: Rendering a mesh bounding box

Step-by-step flow (as described)

Setup

• Goal: render a mesh including its bounding box.
• The mesh handle has multiple buffers, but the tutorial focuses on the vertex buffer.

1) Ensure CPU-side buffer exists

• The vertex buffer is initialized with a buffer RAM representation.
• Where it comes from:
  • The mesh source loads from the hard drive into RAM.
• For mesh vertex buffer:
  • There is no disk representation mentioned (unlike volumes).

2) Compute the bounding box on the CPU

• Inviwo requests the vertex buffer as a buffer RAM representation.
• Reason:
  • Since this representation already exists, no transfers are needed.

3) Choose best available representation when needed

• If a requested representation is not available or not up to date:
  • Inviwo finds the representation that is:
    • Up to date, and
    • Has the shortest conversion chain to reach the desired representation.

4) Upload to GPU for rendering

• Rendering in an OpenGL context requires GPU buffers.
• The system uploads/converts:
  • buffer RAM representations → buffer OpenGL (buffer “gia” in subtitles) representations
• The CPU bounding box computation result is then available for use in GPU rendering.

---

Accessing representations and editing behavior

Access methods

• To get data, you can request:
  • A read-only representation via a “get representation” call.
  • An editable representation via an “get editable representation” call.

Editing invalidation rule

• If you edit a representation:
  • Inviwo invalidates all other representations associated with that data handle.
• Effect:
  • Other representations become outdated because they still reflect the old data.

Rebuilding consequence

• After modification, any other requested representation must be rebuilt using:
  • Two converters (as stated in the subtitles),
  • Because existing representations share old data while the edited one is new.

---

Safe, generic CPU data access: dispatch

How you access the data pointer

• When a representation is obtained (“at hand”):
  • You get direct access to a void pointer pointing to the memory address holding the desired data.

Using dispatch to compute safely

• Use the dispatch method to:
  • Access data safely in the correct type.
• dispatch features described:
  • It has a type parameter specifying the computation result type.
    • Example bounding box result: a pair of vectors (lower-left and upper-right corners), each with four components.
  • It takes a lambda that receives the typed data.
  • Benefit for computation authoring:
    • With C++ type deduction, the computation can be written type-invariant.
    • The same code can work whether vertex coordinates are stored as:
      • float, double, or integer
  • The lambda uses auto (in the subtitles as “auto type”) so C++ instantiates the correct typed version automatically.

Core lesson

• You can work with Inviwo data without managing:
  • Storage devices,
  • Data type differences,
  • Manual synchronization.

---

Speakers / sources featured

• No individual speakers or named sources are explicitly identified in the provided subtitles.
• The content appears to be narrated by the video author/instructor, but the person is not named.