The VIM Vulkan-based renderer was built from the ground up by VIM over two years using modern GPU programming techniques and is optimized for extremely large data sets with lots of object instancing, such as those found in Engineering CAD and Architectural BIM models.

We chose to implement our own rendering stack to overcome severe performance limitations of existing game engines we tested (such as Unity and Unreal) when rendering extremely large models with lots of instancing. These problems stem from assumptions in the game engine object model about the nature of models and too many levels of abstraction between the code and the GPU.

VIM models of over 10GB (often 50GB + In Source IFC and Revit BIM files) in size can be loaded with interactive framerates (30+ fps) on basic consumer hardware with entry-level tier video cards.

Our Vulkan rendering source code has been used extensively in production on windows desktop but is platform-agnostic C++ code. We have successfully ported it to Android mobile phones.

Based on this experience, it is not a significant effort to port the Vulkan-based renderer to support iOS devices and does so using the MoltenVK library which enables Vulkan applications to run on macOS and iOS (https://github.com/KhronosGroup/MoltenVK).

The most recent VIM rendering technology is a WebGL renderer that is built on top of the popular Three.JS WebGL framework. Instanced meshes are instanced on the GPU, and non-instanced meshes are merged based on heuristics. Color information is stored in the vertex colors and element ID information in a UV channel. The VIM format was designed with WebGL in mind and can be loaded into GPU memory with very little processing in JavaScript.

At the beginning of a VIM file, information about the offset and length of each sub-buffer is provided so that the code can use JavaScript TypedArray objects to provide views of the data without having to process each data item individually. This minimizes the amount of JavaScript code executed by the web browser.

The VIM format is amenable to compression, achieving 4x or more compression ratios when using GZIP. We usually serve zipped files from our web server with the appropriate HTTP encoding set so that the web browser can automatically unzip the content using optimized native code before the JavaScript code sees it. This is much faster than performing decompression in a JavaScript client.

The capabilities of the WebGL renderer include, but are not restricted to:

The WebGL loader supports loading only selected buffers over HTTP, enabling on-demand queries of BIM data without requiring additional execution logic on the server. This enables us to load even larger data sets than is normally possible when transmitting the entire VIMs (e.g., larger than 2GB of VIM). For example, Chrome browser tabs limit out at about 1.4GB of active RAM.

The VIM WebGL API is separated into the viewing component and the BIM data query component. This allows it to be repurposed easily in different applications; in addition to our partners integrating it, we have integrated it successfully with PowerBI, SharePoint, and other online databases.

We developed the Unity-based renderer API to support clients who have a significant investment in a Unity-based technology stack. Our original Magic Leap application was developed on top of Unity (https://world.magicleap.com/en-us/details/com.vimaec.vim).

The VIM Unity API can be used by clients to load large BIM models into the editor to build custom one-off applications or can be used to load VIM models at run-time from disk or over a network.

The Unity API has been tested and used on different Unity rendering pipelines, including the High-Definition Rendering Pipeline (HDRP) and the Universal Rendering Pipeline (URP). It has also been used successfully in applications on multiple device platforms and profiles including iOS, WebGL, Desktop, Android, and Magic Leap (Lumen SDK).

When loading VIM files, by default we do not create a Game Object per item in the source file, as other CAD and BIM importing workflows do. While this approach can be enabled because it makes certain programming workflows in Unity easier for rapid prototyping, it has a severe performance penalty making large scenes untenable.

To improve performance, we perform GPU-based instancing and merge non-instanced models. We store ID information in the UV channels of the objects so that we can leverage the GPU for real-time picking and relate the geometric representations of objects to and from the BIM model data. Our API makes this easier for our clients and us.