Details on Vectorworks Graphics Module (VGM) in new Vectorworks 2014

While Nemetschek Vectorworks Inc. has been praised for its decision (several years ago) to adopt the Siemens Parasolid geometry modeling kernel, a decision aimed at laying the foundation for its 3D modeling future, that task took several years and several major updates to complete. The full conversion to Parasolid completed itself in version 2013 last year.

(see, Architosh, “Architosh Talks to Dr. Biplab Sarkar about Parasolid,” 13 September 2008. )

With that huge task behind it, Nemetschek Vectorworks this past year focused its sights on other major updates to more fully modernize its core technology, prepare for the future, and provide substantial benefits to is users in this latest release.

With an important and newish software development center in Bulgaria behind it, in addition to their headquarters and development center in Maryland, the company turned its attention to something quite important: its OpenGL abilities. New in this release is a complete rewrite of its OpenGL pipeline. So dramatic is this new “plumbing” that the company has named this entire set of software code Vectorworks Graphics Module.

What’s VGM and Why Should I Care

Dr. Biplab, Sarkar, Nemetschek Vectorworks’ chief technology officer and head of development, took the time this week to explain to me the basic essentials behind Vectorworks Graphics Module and the sub-components behind it.

It should first be stated that the company didn’t have to rewrite their own OpenGL render pipeline from scratch. They could have–and actually considered–several third-party APIs that would have aided in that process. For instance, they did look at RedSDK (see, Architosh, “Redway 3D rendering API is new for Mac platform joining others such as Lightworks,” 14 August 2013) as well as others, including HOOPS by Tech Soft 3D.

Yet despite how good these third-party technology API solutions are–and they are indeed proven solutions to hundreds of leading products around the globe–Nemetschek chose to innovate using its own development team. What they have ended up with, in the end, with VGM is what Dr. Sarkar noted was a cross between HOOPS and the Unity Game engine, itself a worldwide innovative leader. If this doesn’t pique the interest of existing Vectorworks users it should. And others as well.

next page: More Details

More Details

We will cover more details about the performance in this change later. For now you may want to understand more about what VGM is. Vectorworks Graphics Module is specifically an OpenGL rendering engine providing high-quality interactive renders with shadows, edges, anti-aliasing and more. It consist, importantly of four (4) main components or sub-modules which can be extended, modified or even replaced if necessary without destroying the entire VGM system.

• VGM Engine — This is the system and primary sub-module that transfers data from Vectorworks to the VGM and is responsible for syncing object and material data and for issuing calls to render. A big change with this engine is that while currently the syncing process involves transferring all tessellation data, material data, and state data (necessary to render a job) at once, as the VGM is expanded it should be possible to move to an “on-demand” data transfer model, which would allow the system to call back to the core or return data to Vectorworks.
• VGM Scene Graph — The sub-module organizes all the data transferred to the VGM engine described above. The Scene Graph keeps track of the layers, viewports, symbols, et cetera, such that the VGM can keep track of document state and minimize the amount of data transfer required.  There is also an internal representation that takes place which allows a decoupling of the core from the VGM and thereby allows Nemetschek Vectorworks more flexibility in optimizing and processing the data further. Finally, the Scene Graph is responsible for flattening the data into a quick representation that is quick to process and render.
• VGM Geometry Engine — This is not something that replaces Parasolid but rather works in tandem with that technology. After completion of the Scene Graphs processing of the data, it gets transferred to this geometry engine which calculates things like object bounds and sorts data into rendering acceleration structures. These rendering acceleration structures are modular and can be extended to support 2D as well as 3D operations. This is also the part of the system responsible for preprocessing items such as the shadows and lighting as well as section geometry and the Clip Cube.
• VGM Render Engine — Once data is sorted into “accelerated structures” by the geometry engine the render engine processes things into a series of render queues that store the data necessary to render the scene. This data is consumed by the render engine and is rendered to the OpenGL buffers.

So that is the Vectorworks Graphics Module (VGM) which powers the new OpenGL render pipeline. Some additional notes include that the VGM is solely focused on 3D solid and line renderings but can be extended to support 2D or even swapped out for entirely new systems such as PDF or SVG renders. In other words, Nemetschek Vectorworks’ new OpenGL focused VGM is flexible enough to substitute out entire submodules to create further value in the area of 3D and rendering.

Brass Tacks

Okay, so what does this all mean for actual purposes within the application? Well, it will be existing users who will experience this new OpenGL pipeline immediately if they work in 3D. Here is a list of the big changes in working in 3D OpenGL mode that cover the details of why it will work so much faster.

• Immediate performance improvement in flyover mode or navigation in OpenGL rendered views
• There is no waiting for geometry changes when creating new objects in OpenGL rendered views
• Occlusion prevents the cursor from snapping to elements behind elements, while the new X-Ray Select feature allows you to still select elements hidden by other elements
• Edits, moves, adjustments to objects do not require waiting for geometry to be re-rendered
• You can now edit symbols in 3d mode without leaving OpenGL rendered mode, all other elements will gray out or be hidden (depends on setting option) — all of this without recalculation of geometry by the OpenGL render pipeline
• Because of occlusion it is far easier to select walls because you do not accidentally select geometry behind those wall elements–thus speeding up wall translations and adjustments
• OpenGL performance with shadows (even high quality) is dramatically faster
• You can now move lighting directions and see results instantly without geometry recalculation of the whole scene
• changes to layers and classes gets instant OpenGL rendered results–no more recalculation of the OpenGL scene, including graying of layers and classes
• Draw edges in OpenGL now look better and look, actually, identical to SketchUp. Additionally, edges do not scale with scene complexity or numbers of objects–edges are a constant computation cost to the GPU
• The occlusion feature also works in Fast Renderworks and if you change an object in that scene the OpenGL mode kicks in. This also includes navigation (fly over for example) so you can work in Fast Renderworks mode with only a small delay compared to OpenGL

A big feature adjustment that affects performance is the support for OpenGL occlusion. When using the Clip Cube in version 2013 even though you can drill into just a tiny segment of a whole building, because occlusion is not happening the invisible objects data is still being sent to the graphics card so there is no speed-up due to a lighter render calculation. Now with occlusion support the Clip Cube saves you time by speeding up the scene because only what remains in the Clip Cube is sent to the graphics card.

In short, the OpenGL occlusion support is what truly makes the Clip Cube a more powerful tool. See our other report on Vectorworks 2014, soon to be announced.