Not an Engine but a Foundation
When we set out to develop our tech stack, we did not envision a single application that fits all. Such monolithic application result in compromises: as a software gets more complex, the required training time goes up, usability goes down, maintenance cycles get longer, customisations get harder to do and so forth. And even if one only considers a single application, in today’s world there should be a desktop app, a mobile app, perhaps a web app and each of these categories is multiplied by the number of platforms to be supported. E.g. one usually cannot do an Android app as a 1:1 port of an iPhone app, Windows apps use different metaphors as macOS apps.
So instead we built an SDK, a flexible toolkit that provides its functionality in optional components. An application therefore becomes a matter of developing the UI and combining ready made components. This has four main advantages:
- The UI/app can be custom tailored for the specific use case. One can reduce the user interface to just the actions required for the specific use case and not overburden the user.
- The app can support platform-specific features and combine them with the foundation provided in the SDK. E.g. on iOS, an app can support iCloud syncing although the importer/exporter in the SDK do not even know that technology exists.
- One can easily integrate parts of the SDK’s functionality – such as the file importer/exporter – in an existing app without having to use other parts – such as the render backend or input handling.
- Extensibility. If the SDK does not support a specific format, the user can write an extension and integrate it into the SDK such that it will be treated as a first-class citizen. Similarly, one can write a custom render backend and the scene graph won’t even know it exists,
The following is a small selection of highlights, more information is provided in the SDK’s documentation.
Modules & Extensions
The Core SDK is separated into modules, from common functionality such as logging, math and multi-level progress reporting via the scene graph to the rendering backend. Each lower level has no knowledge of the higher level and can therefore be used independently.
With the exception of a few, dedicated classes such as the Apple Metal Rendering Backend, all of the Core itself is platform-independent C++14 code. To facilitate easy integration on macOS and iOS, a set of Objective-C wrappers is provided. Same for Windows where there are C# wrappers.
There are multiple extension points where custom implementations can be inserted into the Core. For example, a new importer can be developed using the scenegraph and geometry classes and then registered in the runtime instance of the Core. This way the file I/O API can leverage it and the user gets the benefit of post-import processing as well as being able to use a unified open-method that handles all file formats. In a similar fashion, render backends, view augmentations and input handlers can be plugged-in.
The render layout helps compose both multiple views and/or multiple output displays to a single consistent layout. When using the Core SDK for rendering, the render layout is the highest-level element of organization. Most apps will typically only use a single layout but multiple layouts can be used as well.
The layout serves a unified pixel space that aligns and composes different rendering parts onto a single, virtual surface. It thus supports various use cases:
- a display wall (e.g. 4×4, 10×6, …) showing a single scene correctly with bezel compensation
- overlapping multiple projector images of the same scene
- combining multiple views of the same scene in one output image (e.g. the typical top/front/left/all quad view of a modeling application)
- side-by-side stereographic rendering of a VR/AR device.
It also helps managing input mapping, especially for tricky situations where the area covered by an input device (such as a 3D laser or sensor) does not necessarily match the area of the display surfaces.
We are particularly proud of our custom, render-agnostic scene graph. While most scene graphs are primarily developed for rendering and make compromises when it comes to usability or data consistency, our scene graph focuses on user data and usability while making no compromises for efficient rendering.
It supports multiple-instancing of nodes, assembly handling / part references (e.g. a file can include content from another file), override materials and many more features that make working with it a pleasure. It has no knowledge of the used render-backend but provides a flat list of elements that is ideal for modern rasterization based realtime-rendering using APIs such as Apple’s Metal, OpenGL, DirectX 10+ or Vulkan. It also does minimal updating such that transformation matrices and material properties are only recalculated in the sub-parts of the scene graph where changes actually occur.
Here are some more highlights that come with the Core SDK.
Custom Native Importers
The quality of your final result depends on the quality of your data. That’s why we developed custom importer and repair code for the following formats: Alembic, CSB, COLLADA, IGES, JT, LWO/LWS, OFF, OBJ, PLY Rhino3D, STEP (AP 203), STL
Advanced Geometry Kernel
The advanced geometry kernel has full triangle/quad/n-gon support, topology repair functionality and a parametric tessellator to polygonize your CAD data. The custom mesh class features an extensible property system and of course supports per-face-per-vertex information (e.g. more than one normal or texture coordinate per vertex).
Deep Platform Integration
Our technology is developed as platform-independent C++14 code with a platform-specific user interface on top. This allows for deep, native platform integration and apps that perfectly fit into your environment while building on the same foundation. Supported platforms are Windows, OSX and iOS with more to follow.
The infrastructure supports a wide variety of hardware devices, from rendering strechted over multiple displays to using VR hardware, from mouse and keyboard to touch, pen and 3D space mouse.
Out of the box, we support OpenGL 3.3, OpenGL ES 3.0 and Apple Metal to bring you the best rendering performance available on your platform. It’s even simple to implement your own rendering system (e.g. a raytracing solution) or composite it with your application’s existing output.
In order to ensure the high quality of our algorithms, we use extensive automatic testing. However, especially import of CAD is difficult due to the complexity of the formats and the fact that quite a number of exporters included in well know products actually produce non-conformant outputs! If you encounter a problem with one of your files, please let us know, we’re interested in analyzing it and adding it to our automatic test suite of files.