Skip to main content

C++ API reference

The complete reference for every class, function, and enumeration that SGCT exposes is generated directly from the comments in the include/sgct headers:

Browse the C++ API reference

It is regenerated from the SGCT sources every time this site is deployed, and the revision it was built from is shown next to the SGCT name in its sidebar. This page is only a map of what you will find there.

Namespaces​

Everything lives under the sgct namespace, with a handful of nested namespaces for the parts that are only interesting in specific situations:

  • sgct contains the classes an application interacts with, along with free functions such as loadCluster, parseArguments, and time
  • sgct::config is a direct mirror of the JSON configuration file; every struct in it corresponds to an object described in the Configuration section
  • sgct::correction holds the readers for the supported warping mesh formats, which are listed under the mesh attribute of a viewport
  • sgct::text contains the font handling used to draw text overlays

Where to start​

A single umbrella header pulls in everything an application normally needs:

#include <sgct/sgct.h>

From there, the types that matter for a first application are:

  • Engine is the central object. It is created once through Engine::create, owns the frameloop started by Engine::instance().render(), and dispatches to the callbacks your application provides. The First application example uses nothing else
  • Engine::Callbacks is the struct of std::function members that you fill in to hook into the frameloop. The order in which they are called is laid out in How it works
  • RenderData is handed to the draw callbacks and carries the window, viewport, and matrices for the pass currently being rendered
  • Log is the logging facility that SGCT itself uses, and that applications are encouraged to use so that messages from all nodes end up in one place

Once an application grows beyond a single window, the objects behind the configuration file become relevant: Node, Window, Viewport, and the NonLinearProjection hierarchy that implements fisheye, cylindrical, equirectangular, spherical mirror, and cubemap rendering. Applications that need to keep state synchronized between the nodes of a cluster do so through SharedData.

Configuration objects​

The structs in sgct::config are worth calling out separately, because they are the same objects that the Configuration section documents from the JSON side. The reference describes what each field means to a person writing a configuration file; the C++ API reference describes the types, defaults, and nesting as the compiler sees them. loadCluster returns a config::Cluster, so an application can also construct or amend that object in code instead of reading it from a file.