X3D (Extensible 3D) format: ISO/IEC 19775 — OSM scene export with interactivity

X3D (Extensible 3D) is the ISO-standardized successor to VRML97, developed by the Web3D Consortium since 2001 to lift interactive 3D graphics out of the era of ASCII parsers into one of XML, profiles, and HTML-embedded web scenes. Where VRML97 was a monolithic text format vintage 1997, X3D split the architecture into seven profiles (Core, Interchange, Interactive, CADInterchange, Immersive, MedicalInterchange, Full) and three encodings (XML .x3d, Classic VRML .x3dv for backward compatibility, JSON .x3dj since 2015). This preserved the full scene graph with behavior (Events, Sensors, Scripts, Routes), interactivity, and full backward compatibility while adding machine readability for modern pipelines. ISO/IEC 19775-1 describes the architecture, 19776 the encodings, 19777 the language bindings. On osm2cdr.ru x3d_exporter.py runs through Building3DExporter and bakes an XML scene with <IndexedFaceSet> / <IndexedTriangleSet> geometry, <Appearance> with <Material> and optional <ImageTexture>, opening in any X3DOM viewer right inside the browser without plugins.

History: from VRML97 to X3D 4.0

X3D's story is inseparable from VRML's. At the First WWW Conference in Geneva in 1994, Mark Pesce and Tony Parisi proposed the term "VRML" (Virtual Reality Modeling Language) and the idea of declarative 3D on the web. VRML 1.0 (1995) was based on SGI's Open Inventor text syntax. VRML 2.0 / VRML97 (December 1997, ISO/IEC 14772-1) added behavior, events, and sensors, becoming the first true interactive 3D web standard.

By the late 1990s it was clear that VRML97's ASCII text format meshed poorly with 2000s web infrastructure: parsers were hand-written, XML tooling was missing, the encoding wasn't modular — take it all or nothing. In 1998 the VRML Consortium renamed itself the Web3D Consortium and started work on X3D — a new architecture with XML encoding and modular profiles. X3D 1.0 shipped in 2001; ISO/IEC 19775-1 was ratified in 2004.

Later versions: X3D 3.0 (2007) — expanded component system; X3D 3.3 (2014) — geospatial component, VolumeRendering; X3D 4.0 (2023) — HTML5 integration via X3D-in-HTML, physically-based rendering (PBR) materials, glTF interop. The 2010s brought X3DOM — an open-source library from Fraunhofer IGD that parses <X3D> elements directly inside HTML and renders via WebGL with no plugin. That brought X3D back into the browser a decade after the death of VRML plugins like Cortona3D and BS Contact.

By 2026 X3D is a niche but living standard: used in academic research, at CAD seminars, in CityGML 2.0/3.0 export pipelines (LOD levels map to X3D Shape), in medical visualization (MedicalInterchange profile). Mainstream web 3D went to glTF, but X3D stays where ISO compliance, a declarative scene graph, and a behavior model are required.

Inside the file: Scene Graph, profiles, encodings

Conceptually X3D is a directed acyclic graph of nodes (scene graph). The root is an <X3D> element with version and profile attributes. Inside — <Scene>, then a hierarchy of <Transform> (position/rotation/scale), <Shape> (geometry + appearance), <Group> (container), <Inline> (an embedded scene from a URL).

A minimal X3D document:

<?xml version="1.0" encoding="UTF-8"?>
<X3D version="4.0" profile="Interchange">
  <Scene>
    <Transform translation="0 0 0">
      <Shape>
        <Appearance>
          <Material diffuseColor="0.7 0.7 0.8"/>
        </Appearance>
        <IndexedFaceSet coordIndex="0 1 2 3 -1" solid="true">
          <Coordinate point="0 0 0  10 0 0  10 0 10  0 0 10"/>
        </IndexedFaceSet>
      </Shape>
    </Transform>
  </Scene>
</X3D>

Profiles are the main differentiator of X3D from VRML. A profile decides which components are available in the scene. Core has the bare minimum (just the basic scene graph). Interchange — for static 3D exchange (our OSM export). Interactive adds sensors and pointing devices. CADInterchange — for engineering models with BREP geometry. Immersive — full VRML97 equivalent with anchors, sounds, scripts. MedicalInterchange — for medical visualization with volumes and DICOM mapping. Full — every component.

Encodings. XML (.x3d) — primary, readable, supports XPath/XSLT. Classic VRML (.x3dv) — text syntax inherited from VRML97 for backward compatibility. JSON (.x3dj, since 2015) — for JavaScript pipelines and React/Vue components. Binary X3D (.x3db) — encoded XML with compression for the web. All four encodings describe the same scene-graph model — they are equivalent and interconvertible via xj3d, view3dscene, or X3D-Edit.

Behavior model. Unlike glTF (transmission-only), X3D carries a full behavior model: Sensors (TouchSensor, ProximitySensor, TimeSensor) generate events; Routes connect outputs of one node to inputs of another; Script nodes run JavaScript. This lets you describe an interactive 3D document — for example, a building that highlights on mouseover — without external JS. For OSM export we don't use behavior (static scene), but it remains an option for downstream tools.

Strengths and weaknesses

Strengths. ISO standard (19775/19776/19777) — guarantee of long-term compatibility and acceptance in academic/government projects. Open spec, no royalties — Web3D Consortium publishes all specifications free of charge. Declarative scene-graph model — you can hand-edit XML in a text editor. Four encodings of one model — pick by pipeline (XML for XSLT, JSON for React, Classic VRML for legacy). Behavior built into the format — interactivity without external JS. X3DOM — open-source web renderer with no plugins, works in any modern browser. CityGML mapping defined — the Web3D Consortium published an official CityGML 2.0 → X3D mapping, making X3D a natural target for city 3D models.

Weaknesses. Niche adoption — outside the Web3D community the format is little known; developers used to glTF have to relearn. XML overhead — the text format is bloated compared to JSON or binary glTF (2–3× larger for the same geometry). No browser-native loaders — you need X3DOM or X_ITE as a third-party library. The tooling ecosystem is smaller than glTF's (fewer converters, fewer online viewers). Modern game engines (Unity, Unreal) do not natively import X3D — an intermediate format is needed. The behavior model is more complex than glTF's, which scares off developers who only need "geometry transmission."

X3D vs VRML vs glTF vs COLLADA

VRML — X3D's text-based predecessor from 1997, formally deprecated in favor of X3D, but .wrl files from the 1990s–2000s still open in Blender and view3dscene. Semantically X3D is a superset of VRML97; migrating .wrl → .x3d is trivial.

glTF — the modern mainstream web/game format from Khronos Group. Transmission-only: just geometry + materials + animation, without behaviors / sensors / scripts. glTF beats X3D on performance and tooling but loses on declarative interactivity and ISO compliance. If you need an interactive document — X3D; if you need transmission to a viewer — glTF.

COLLADA (.dae) — an XML format from Khronos Group for DCC interchange (Blender/Maya/3ds Max). Conceptually similar to X3D-XML but with no profile system and no behavior model. COLLADA is on the decline, partly replaced by glTF.

Bottom line: X3D — for academic / ISO-compliant / interactive scene needs; glTF — for web/game transmission; VRML — legacy; COLLADA — DCC interchange.

Use cases

CityGML 2.0/3.0 publisher. City authorities publishing a 3D city model in CityGML produce a parallel X3D export for web access. CityGML LOD2 (simplified roofs) or LOD3 (detailed buildings) maps to X3D Shape, textures to <ImageTexture>, coordinates to EPSG:4326 / EPSG:3857. Berlin 3D, Helsinki, Singapore all publish public X3D datasets.

Academic researcher. A scientist publishes a research paper with an applied 3D visualization (molecular dynamics, biomechanics, engineering analysis). X3D is a natural fit: ISO standard for reproducibility, XML for git versioning, X3DOM for embedding in the paper's HTML layout or a Jupyter notebook.

Engineering CAD interop. A team working with CAD models in Catia / SolidWorks / NX exports an assembly to X3D CADInterchange for partners to view without CAD licenses. The profile preserves BREP geometry and the assembly hierarchy, unlike STL/OBJ.

E-learning content creator. A computer science teacher builds an interactive 3D course on computer graphics. X3D embeds in HTML5 pages via X3DOM, students move objects with the mouse, the teacher adds ProximitySensors for camera-approach highlighting. No compile step, no special player.

Medical visualization specialist. A radiologist visualizes DICOM data through X3D's MedicalInterchange profile — VolumeData, IsoSurfaceVolumeData, SegmentedVolumeData. Browser viewing via X3DOM with a volume-rendering shader.

Heritage 3D archivist. A museum laser-scans an artifact, converts the point cloud to a mesh, exports to X3D with metadata (author, period, material). ISO format is the guarantee of readability 30 years from now.

Software

X3DOM. Open-source JavaScript library from Fraunhofer IGD. Parses <X3D> elements inside HTML and renders via WebGL. The most popular way to show X3D in a browser. MIT license, one-line integration <script src="x3dom.js">.

X_ITE. Open-source X3D player in JavaScript by create3000. Alternative to X3DOM, stricter on X3D 4.0 spec compliance. Supports every encoding.

view3dscene. Free desktop X3D / VRML / Spine / glTF viewer from Castle Game Engine. Opens any encoding (XML / Classic VRML / JSON), shows the scene-graph debug view, mouse/keyboard navigation.

Instant Reality. Free (non-commercial) X3D framework and player from Fraunhofer IGD. Supports every profile including Immersive with full scripting. Used in academic projects.

Blender. Free 3D suite. X3D and VRML97 import/export built in (through the Web3D plugin). Doesn't support every profile, but Interchange / Immersive exports correctly.

MeshLab. Free mesh tool. X3D import/export for scientific mesh-data visualization.

ParaView. Free scientific visualization tool. X3D export from scientific data (CFD, FEA) for embedding in HTML reports.

FreeWRL. Open-source X3D and VRML player; runs on Linux/macOS/Windows. Alternative to view3dscene with an emphasis on VRML legacy support.

Pipeline in OSM2CDR

Our x3d_exporter.py inherits from Building3DExporter (just like vrml_exporter.py, gltf_exporter.py, obj_exporter.py). Pipeline:

1. Layer loading. PostGIS returns buildings and POIs as WKB via ST_AsBinary, skipping GeoJSON parsing (WKB fast-path).
2. Calculate building height. Each building gets a height by priority: height tag → building:levels × 3.0 m → type fallback (apartments → 15 m, skyscraper → 100 m, default 6 m).
3. Extrusion. trimesh.creation.extrude_polygon turns each OSM polygon into a prism. Multi-faceted roofs collapse to flat ones.
4. XML scene assembly. Build the XML document: <X3D version="4.0" profile="Interchange"> → <Scene> → for each building <Transform translation="x y z"> → <Shape> → <Appearance> with <Material diffuseColor> → <IndexedFaceSet> or <IndexedTriangleSet> with <Coordinate point> and indices.
5. Material assignment. Building type → diffuseColor: residential → beige (0.85 0.78 0.65), commercial → gray (0.55 0.55 0.6), industrial → brown (0.5 0.4 0.35), building=yes → default (0.75 0.75 0.78).
6. Optional textures. With textures=true — add <ImageTexture url="brick.jpg"> to Appearance for a photorealistic look. Textures come from a nature/material library.
7. Profile selection. Default is profile="Interchange" (static scene). With profile=interactive — bump to profile="Interactive" and add a TouchSensor per building (click → highlight). With profile=immersive — add a Viewpoint navigation and Anchor for cross-linking.
8. Encoding output. Default XML (.x3d). With encoding=classic → Classic VRML (.x3dv) for VRML97 compatibility. With encoding=json → JSON (.x3dj) for web pipelines.

Coordinates in X3D are meters, Y-up (important: differs from Z-up in STL/OBJ — we transpose at scene-assembly time). Origin — bottom-south-west bbox corner. CRS — EPSG:3857 (web-mercator), matching X3D's GeoCoordinate component when needed.

Validation — via xmllint against the X3D 4.0 XSD schema (http://www.web3d.org/specifications/x3d-4.0.xsd). This guarantees any compliant viewer opens the file without errors.

FAQ

X3D or glTF — which to choose for the web? If you need an interactive document with behavior (clickable objects, hover effects, navigation) without separate JS — X3D + X3DOM. If you need maximum performance and mainstream tooling support (Three.js, Babylon.js, Cesium) — glTF. For a static OSM export both formats are equivalent in result.

Can I convert .wrl (VRML97) to .x3d? Yes, trivially. view3dscene opens any VRML97 and exports to X3D XML / Classic VRML / JSON with one button. Blender also handles the migration through Import VRML → Export X3D. Semantics are preserved because X3D is a superset of VRML97.

Which profile should I use for OSM export? Default Interchange — the smallest, guaranteeing the file opens in any viewer. For interactivity (TouchSensor on buildings) — Interactive. Immersive — for scripts and animation. CADInterchange / MedicalInterchange aren't relevant for OSM.

Does X3D support textures? Yes, via <ImageTexture url="..."> inside Appearance. JPEG, PNG, GIF are supported. X3D 4.0 added PBR textures (BaseTexture, NormalTexture, MetallicRoughnessTexture) for photo-realistic rendering — the glTF 2.0 PBR equivalent.

What's X3DOM and how do I use it? X3DOM is an open-source JavaScript library (Fraunhofer IGD, MIT license) that parses <X3D> elements inside HTML and renders via WebGL. Usage: <script src="https://www.x3dom.org/release/x3dom.js"></script> + <x3d>...</x3d> in HTML. Any modern browser shows the 3D scene without plugins.

What's the maximum area for X3D export? During Open Beta, all 124+ formats on osm2cdr.ru are free without tier-based area caps. The real limits are technical, per-format (see /api/format-limits). XML overhead makes files heavy (300 MB for a mid-sized city), so for production deployment consider gzip-compressing through nginx (typical 5:1 ratio) or binary X3D encoding (.x3db).

Related

• VRML — pioneer of 3D on the web and X3D's predecessor
• glTF — modern 3D format for web and AR
• CityGML — standard for 3D city models
• COLLADA — DCC interchange XML format
• 3D map export from OSM — overview guide

Sources

• Web3D Consortium, X3D specifications — web3d.org/standards
• ISO/IEC 19775-1 X3D Architecture — iso.org/standard/60760.html
• X3DOM library (Fraunhofer IGD) — x3dom.org
• Wikipedia, X3D — en.wikipedia.org/wiki/X3D
• view3dscene (Castle Game Engine) — castle-engine.io/view3dscene.php
• CityGML 2.0 X3D mapping — web3d.org/wiki/index.php/CityGML