Geobasisdaten sind heute besser verfügbar als je zuvor. Bayern gibt Höhenmodelle, 3D-Gebäudemodelle und Luftbilder als Open Data frei, der Bund hat Deutschland flächendeckend per Laserscan erfasst. Der Engpass liegt nicht mehr bei den Daten, sondern bei dem, was zwischen Datensatz und Bildschirm passiert.

GIS-Software zeigt Geodaten korrekt an. Sie erzeugt aber keine Szene, die begehbar ist, Kollision hat, mit stabiler Bildrate läuft und auf einer VR-Brille funktioniert. Genau dieser Schritt ist unsere Arbeit.
Gelände, Flächennutzung, Bewuchs und Gebäude aus amtlichen Geodaten

Was wir aufbereiten

Geländemodell, Flächennutzung, Bewuchs, Gebäude, Messdaten

  • Gelände. Aus digitalen Geländemodellen wird ein Landscape-Actor mit passender Kachelung und Auflösung — nicht ein Mesh mit Millionen Dreiecken, sondern die Struktur, mit der die Engine tatsächlich arbeitet.
  • Oberflächen. Aus Flächennutzungsdaten werden Weightmaps, aus denen die Engine Materialien mischt: Wald, Wiese, Acker, Siedlung. Das spart Texturspeicher und sieht in jeder Entfernung richtig aus.
  • Bewuchs. Wälder und Grünflächen werden nicht aus Scandaten rekonstruiert, sondern prozedural bepflanzt — gesteuert über dieselben Flächendaten, ausgespart entlang von Straßen und Wegen.
  • Gebäude. Aus amtlichen 3D-Gebäudemodellen (CityGML, LOD2) entstehen saubere, flache Fassaden. Wo Bildmaterial vorliegt, texturieren wir sie damit.
  • Vermessene Details. Wo es auf Genauigkeit ankommt, kommen die Daten aus dem Scan — eine Straßenoberfläche, ein Bauwerk, eine Anlage. Der Rest der Szene entsteht aus den Katasterdaten drumherum.
Wie die Scandaten selbst dorthin kommen, ist ein eigener Arbeitsschritt.

Wie wir Punktwolken verarbeiten
GIS-Ansicht: korrekt dargestellt, aber nicht echtzeitfähig

Warum das nicht aus der GIS-Software fällt

Geometrisch korrekt ist nicht echtzeitfähig

Ein Datensatz, der geometrisch korrekt ist, ist noch lange nicht echtzeitfähig. Zwischen beidem liegen Detailstufen, Kollisionsgeometrie, Texturbudgets, Draw-Call-Disziplin und die Frage, was überhaupt als eigenes Objekt existieren muss und was in die Landschaft eingebacken gehört.

Diese Entscheidungen trifft keine Konvertierung automatisch. Sie hängen davon ab, was die Szene leisten soll: eine Planungsansicht am Monitor hat andere Budgets als eine VR-Anwendung auf einer autarken Brille, und eine Simulation braucht Ground Truth, die ein Rendering nicht liefert.
Typische Aufgaben rund um Geodaten in Echtzeit-Engines

Typische Aufgaben

Womit Kunden auf uns zukommen

  • Ein bestehendes 3D-Stadtmodell in einer Engine begehbar machen
  • Eine Geländeszene aus offenen Geodaten aufbauen, inklusive Bewuchs und Bebauung
  • Vermessene Bereiche in eine generierte Umgebung einpassen
  • Ein Importwerkzeug bauen, das den Weg wiederholbar macht, statt ihn jedes Mal von Hand zu gehen
  • Eine vorhandene Szene so umbauen, dass sie auf einer VR-Brille läuft

Womit wir arbeiten

Engines, Eingangsdaten, Werkzeuge, Austauschformate

EnginesUnreal Engine, Unity
EingangsdatenDigitale Geländemodelle, CityGML/LOD2, Orthophotos, OpenStreetMap, Laserscans, Drohnenbefliegungen
WerkzeugeLandscape und Weightmaps, Runtime Virtual Textures, Procedural Foliage, Nanite, Cesium for Unreal
AustauschformateglTF, FBX, USD

Was wir nicht machen

Und wo wir ins Spiel kommen

Wir liefern keine Vermessung und keine Geodatenhaltung — dafür gibt es Bessere. Wir kommen dort ins Spiel, wo korrekte Daten in eine Anwendung müssen, die jemand bedient. Wie weit wir diesen Weg in einem Forschungsprojekt bereits gegangen sind, steht unter RoadRender Pro.

Projekt anfragen Direkt anrufen
Softwareentwicklung seit 1999 - Made in Germany

Made in Germany

Softwareentwicklung seit 1999

Entwickelt zu 100 % in Deutschland — an unseren Standorten Nürnberg und Kempten (Allgäu). Über 1.170 abgeschlossene Projekte, über 80 % unseres Umsatzes machen wir mit Bestandskunden. Wenn Sie in der Nähe sind: Kommen Sie auf einen Kaffee vorbei.