Expert Talk with TrianGraphics: Building a Better World

May 18th, 2022 | by GEONATIVES

(5 min read)

No, this is not a post about a charitable organization. It’s about the people who have been building digital twins for the past 20 years – triangle by triangle.

In late November 2021, we enjoyed a web-meeting with Stephan Kußmaul, managing shareholder of TrianGraphics GmbH, Berlin. TrianGraphics provides tools for creating 3d environment databases for road, rail, and flight simulation applications from various data sources. This product line is complemented by a service team, which builds custom 3d environments.

Their Domain

Stephan explained that TrianGraphics’s databases are mostly created as replicas of real locations; generic databases are not considered of high relevance to their business and if, they are made with the help of real world data as well (cue: “geo-typical”). The reason is simple: building something that is known to exist and is, usually, already covered by some data source (e.g., maps, aerial imagery) is less controversial than inventing and justifying purely artificial scenes. Or, in short: nothing beats reality.

Creating databases is a trade-off between fidelity and efficiency. TrianGraphics’s main focus is efficiency at sufficient fidelity level. This is to be seen in contrast to the content of computer games where each polygon might be highly optimized, but the overall extent of databases is small.

Road database (image by TrianGraphics)

Scalability is a big aspect of efficiency. When creating flight databases, whole countries may need to be covered, whereas, when creating driving databases, small details matter. Being able to roll out sufficiently large and realistic databases in rather short time is key to TrianGraphics’s success.

Flight database (image by TrianGraphics)

Building Blocks

How do they build their digital twins? First, they don’t start from scratch. For driving simulation, the key to their virtual worlds is an underlying road network, which may originate from real-world surveys (e.g., by companies such as atlatec or 3D Mapping Solutions, combined with open-source data from, for example, OpenStreetMap and complemented by aerial imagery or 3rd party Shapefiles. Processing these data will lead to visual models of the road networks and the general terrain. For buildings and other infrastructure items, TrianGraphics uses rule sets that help populate the map. Structures may be derived from actual footprints (extracted, again, from e.g. OpenStreetMap or 3rd party sources) and by applying design patterns that take the height and type into account.

This will not necessarily give you the 100 percent visually correct digital twin of a specific location, but the situation that may be experienced by a system-under-test will be deemed realistic. And, at any time, users who want to see a closer match to reality, may add more information to feed the design patterns or even add so-called landmarks, i.e. highly realistic 3d models of actual structures, directly to their scene. The depth of your pocket is the only limit here.

When asked about users’ preferences, Stephan confirmed that most users in his market segment are looking for realistic databases but not for the ones that are highly geo-specific in all detail. This was also confirmed by the fact that material attribution, used, for example, in physics-based sensor simulation, is not on top of the requirements list for databases at the moment (although TrianGraphics claims capability to provide per-pixel material attribution in their processing pipeline).

Quality Matters

Hardly anything matters more than quality. Therefore, we asked Stephan the question, which is also central to our post on Marketplaces: how is the quality of 3d environments quantified? His simple answer: it’s good enough when a customer can fulfill his use case.

But, of course, it’s not as simple as this short answer might indicate – especially if you think about objective quantification of quality.

When using initial data from surveys or map providers, the spatial accuracy of features in a database (e.g. lanes, road signs, road-side elements) is determined by exactly these data. TrianGraphics’s tools provide means to edit imported data but that won’t necessarily increase their accuracy. Therefore, the old principle of garbage-in/garbage-out also applies to this processing tool chain and you are requested to properly select the source data for your projects.

It’s in the feature-density of 3d environments, where quality can be influenced most and where, on the downside, substantial workload may be created. Depending on the use case, highly detailed vegetation might be of interest, for example, or country-specific texturing of buildings. And often the driving simulator use cases requesting such databases do not require high accuracy. Therefore, with a lack of commonly accepted quality indicators for 3d environments, Stephan’s answer is valid: quality is in the eye of the customer.

Format Wars

Another pet subject of our blog is the large variety of data formats that exists in various domains. Most prominently, map formats are of key interest to TrianGraphics: OpenDRIVE, HD-Live Map, NDS, OpenStreetMap, custom Shapefiles – just to name a few. Data in these formats provide the base layer for creating 3d environments.

Standardization has helped quite a bit (see ASAM OpenDRIVE) but, still, any two data providers do not necessarily fill the same data format in identical ways. By working with a rather limited set of data sources, TrianGraphics has “profiled” (read: “tweaked”) their data importers so that data from any of the known sources can be put to work within their pipeline. But, of course, life would be much easier if the same importer could be used for data from various sources (which is basically the idea of standardization).

As Stephan told us, Shapefiles have proved to be one very versatile way of describing data sets and seem to impose the least workload when it comes to converting their content to anything that can make it through TrianGraphics’s pipeline.

A quick side note on Shapefiles:

When talking about Shapefiles, we as GEONATIVES see it as our duty to remind our receptive readers that Shapefiles are an ancient evil from the past: Among many others, hard limits regarding attribute naming, attribute types and character encoding not seldom lead to bad surprises on data consumer’s side. We prefer to exchange vector data with OGC’s GeoPackage, especially when dealing with more than just flat data models (e.g. HD road network data).

Graphics formats for triangulated data (OSGB, FBX, glTF, Universal Scene Description etc.) are the same story downstream in the pipeline. An FBX export for one game engine may need to be filled differently than an FBX file for another renderer. So the task, again, is with the tool provider and its capabilities to adapt to specific requirements.

Therefore, to summarize it, data processing the way TrianGraphics does it, isn’t simply garbage-in/garbage out, it is:

garbage in – deciphering – creating something meaningful – adjusting – result out

This, in itself, is a pipeline where the 20+ years Stephan and his colleagues have already been in business are quite beneficial.


What’s next? The TrianGraphics team seems to be comfortable in its niche of the market: providing medium to high fidelity 3d environments based on a large variety of source data and exported to a no less impressive list of target formats. All of this packaged in a tool that may be licensed to the end-user or which will otherwise be used within dedicated professional services.

One trend that we currently see in the automotive industry is the sourcing of real-world scenarios from drone captures and other (quasi-)static sensors. Providers of these data are good at extracting dynamic objects’ characteristics like trajectories, types etc. from the data, but building the 3d environment and/or the road semantics in the respective target formats may be something that might be easier to solve with established tools and services, especially if the scene that has to be created is rather small. For facilitating this process, drones should generate their output in already established data formats.

Whatever the direction Stephan’s team takes, we will definitely follow the news on TrianGraphics and will sneak in again before long.

Thanks to Stephan for taking the time to talk to us.

Add a Comment

Your email address will not be published. Required fields are marked *