STEP AP242 vs glTF vs JT vs 3MF: Choosing Lightweight CAD Formats for Digital Twins and PLM

Every digital twin program eventually hits the same wall: the CAD model that engineering trusts is too heavy, too exact, or too locked-down for the place where the twin actually lives. A 40,000-part assembly exported as exact surfaces will not stream into a browser, and a browser-friendly triangle soup will not tell a quality engineer which face carries a flatness tolerance. The format you pick decides what survives that trip.

The honest framing of STEP AP242 vs glTF is not “which is better”. They sit at opposite ends of a fidelity spectrum, with JT and 3MF filling two specific middle positions. STEP AP242 carries exact boundary representation (B-rep) geometry plus semantic product and manufacturing information (PMI). glTF 2.0 carries triangles, scene hierarchy and physically based materials, built for fast runtime delivery. This post compares all four on geometry model, PMI, assemblies, materials, standards status and tooling, shows a runnable Python conversion pipeline, and ends with a decision matrix you can apply to a real PLM-to-twin hand-off.

What this covers: the B-rep versus mesh divide, what each format keeps and drops, a verified standards map, a pythonOCC plus trimesh conversion sketch, the lossy steps to budget for, and a decision matrix.

Context and Background

CAD systems store parts as B-rep: faces bounded by edges, where each face lies on an analytic surface (plane, cylinder, cone) or a freeform one (NURBS, non-uniform rational B-splines). That representation is exact to the kernel’s modelling tolerance, which is why a machinist can trust a hole diameter read from it. It is also why the files are heavy and why viewing them needs a tessellator that converts every face to triangles on the fly.

A mesh format skips the exact surfaces and stores triangles directly. Meshes are what GPUs consume, so a mesh-based format loads quickly and renders everywhere. The cost is permanent: once a cylinder becomes a faceted approximation, the radius is no longer a stored fact, only something you could estimate by fitting.

The four formats here were designed for different jobs, and the standards bodies reflect that. STEP is ISO 10303, with AP242 (“Managed model-based 3D engineering”) as the application protocol for 3D product data; its third edition was published in December 2022 according to the ISO catalogue entry, which also notes that edition has since been withdrawn in favour of a 2025 edition. JT is ISO 14306, last published in 2017. glTF 2.0 became ISO/IEC 12113:2022, issued July 2022. And 3MF became ISO/IEC 25422:2025, published June 2025, as the “3D Manufacturing Format specification suite”.

A common mix-up deserves correcting before we go further. ISO/ASTM 52915 is often cited as “the 3MF standard”, but that number is the Additive Manufacturing File Format (AMF) version 1.2, a different and older XML format. 3MF’s international standard is ISO/IEC 25422. If you are writing a procurement clause, cite the right one.

For the twin context, the practical question is what each consumer needs. A simulation or metrology system needs exact geometry and tolerances. A web viewer or game-engine twin needs light meshes with materials. A printer needs a watertight mesh with units, colour and build instructions. Our companion post on STEP AP242 vs JT vs QIF for model-based definition and PMI goes deeper on the quality-data side; this one widens the lens to the lightweight formats twins actually ship.

The Fidelity Ladder: What Each Format Is Actually For

Direct answer: STEP AP242 is the exact, semantic exchange format (B-rep, assemblies, PMI). JT is a visualization and lightweight-collaboration format that can carry B-rep alongside tessellated levels of detail. 3MF is a manufacturing-ready mesh package for printing. glTF 2.0 is a runtime mesh-and-materials delivery format. Digital twins typically use all four at different stages.

Figure 1: The fidelity ladder. Geometry gets lighter and more portable moving right and down, while exactness and semantic PMI are shed along the way.

The diagram reads as a one-way pipeline. STEP holds the authoritative geometry. JT sits next to it, optionally keeping the B-rep and adding pre-computed triangles. Everything downstream (3MF, glTF, and an OpenUSD scene composed from glTF-derived assets) is tessellated. The dashed edge from STEP to glTF is the important one: it is a direct conversion, and the semantic link to PMI does not travel with it unless you build a side channel.

STEP AP242: the exact, semantic source

AP242 exists to carry what a downstream engineer needs to reconstruct design intent without the original CAD system. That includes exact B-rep, product structure (assemblies with placement transforms), and PMI. PMI in AP242 comes in two forms: graphical presentation (the dimension arrows and text as drawn polylines or curves) and semantic representation (the tolerance as structured data: a position tolerance of a stated value, referenced to named datums, applied to a specific feature).

The semantic form is the point. A machine can read it, check it against inspection results, and feed it to a CMM (coordinate measuring machine) program. Edition 3 extended this further. According to STEP Tools’ release notes for AP242 edition 3, it added annotation leader-line entities, a basic round hole definition, edge-based topological representation with length, and geometry-to-topology associativity at item and model level. The same notes say the schema name is unchanged and that edition 3 has no known attribute changes, so code written for earlier editions should keep working.

AP242 also supports tessellated geometry: a part can carry triangulated shapes inside the STEP file, either alone or alongside the exact B-rep. I am flagging this because it is frequently overlooked. A STEP file is not necessarily heavy; it can be an exact-plus-mesh container, and the writer decides.

JT: B-rep plus levels of detail, built for the review loop

JT originated at Siemens (previously UGS) and is standardized as ISO 14306. Its design goal is fast visualization of large assemblies. A JT file is organized as a table of contents plus segments, and a part’s shape can be stored as several tessellated levels of detail (LOD), so a viewer can load coarse proxies first and refine on demand. JT can also embed exact B-rep (commonly described as XT B-rep in the JT literature) and PMI, though how faithfully any given exporter writes PMI varies by vendor. I treat that variability as something to test per toolchain rather than assume.

Two structural details matter for twins. JT assemblies can be split across files (one assembly file referencing per-part files), which suits PLM vaults that version parts independently. And the LOD mechanism is the closest thing in this group to a first-class “lightweight representation” concept, which glTF lacks natively; glTF has a vendor extension for LOD (MSFT_lod, listed in the Khronos extension registry) but it is not a ratified Khronos standard extension.

3MF: a manufacturing package, not an engineering exchange

3MF is a zip-based package (an Open Packaging Conventions container) holding XML parts. The core specification defines a mesh with vertices and triangles, units, build items with transforms, and components for reusing a mesh object in multiple places. Extensions add materials and properties (colour, textures, composite materials), beam lattices for implicit lattice structures, slice data for pre-sliced printing, and production information such as UUIDs for traceability. The ISO/IEC 25422 suite covers the core and these extension specifications.

3MF’s strength is that it removes ambiguity that STL left open: units are explicit, meshes are required to be manifold, and colour and material are carried in the file. For a twin that includes additively manufactured parts, 3MF is the format that tells you what the printer was actually asked to build. It is not an assembly-semantics format: it has no PMI and no feature tree.

glTF 2.0: the runtime asset format

glTF is a JSON scene description (nodes, meshes, materials, cameras, animations) that references binary buffers of vertex and index data, with an optional single-file binary container, GLB. Meshes are triangles, lines or points; units are metres; the coordinate system is right-handed with +Y up. Materials use a physically based metallic-roughness model, which maps directly to modern real-time renderers.

The format is deliberately minimal and extensible. The Khronos extension registry lists ratified extensions relevant to heavy industrial assets: KHR_draco_mesh_compression and EXT_meshopt_compression for geometry compression, KHR_texture_basisu for GPU-compressed textures, KHR_mesh_quantization for smaller vertex attributes, EXT_mesh_gpu_instancing for repeated parts such as fasteners, and a family of KHR_materials_* extensions (clearcoat, transmission, sheen and others) for richer appearance. The registry I checked does not list any CAD or PMI extension, which is the central gap for PLM use.

From B-rep to Triangles: The Conversion Walk-through

Converting STEP to glTF or 3MF is a tessellation problem wrapped in an assembly-traversal problem. The tessellator decides how many triangles represent each face, controlled mainly by a linear deflection (maximum distance between the true surface and the triangle chord) and an angular deflection. Those two numbers are the quality dial for the entire downstream twin, so they deserve to be set deliberately rather than left at defaults.

A worked tessellation budget

The geometry of a chord gives a precise rule. For a circle of radius r approximated by a regular polygon with n sides, the maximum gap between the polygon edge and the circle (the sagitta) is r(1 – cos(pi/n)). Solving for the number of segments that keeps that gap under a deflection d gives n = pi / arccos(1 – d/r).

Take a 10 mm radius bore. At a deflection of 0.1 mm you need 23 segments around the circumference; at 0.01 mm you need 71; at 0.001 mm you need 223. A 100 mm radius at 0.1 mm needs 71. These figures follow directly from the formula, not from any benchmark. They show that a tenfold tighter deflection costs roughly 3x more segments per circle, but because a cylindrical face is a strip of such segments extruded along its length, and freeform faces tessellate in two dimensions, triangle counts on real parts grow faster than that, closer to the square of the segment count for doubly-curved surfaces.

For a twin, the lesson is to choose deflection by consumer. A web viewer showing a plant floor can tolerate 0.5 mm or coarser on large items. A clash-detection service might need 0.05 mm. A measurement-comparison twin that overlays scan data should not use a mesh at all, but go back to the STEP.

Figure 2: A conversion pipeline. The assembly tree and the face geometry are read in parallel, then rejoined in a scene graph that exports to GLB or 3MF.

The key design point in Figure 2 is that the assembly tree and the tessellated faces are separate streams. If you flatten everything into one mesh early, you lose the part names, instance reuse and transforms that a PLM-linked twin needs to map a mesh back to a part number.

A runnable sketch with pythonOCC and trimesh

The following script reads a STEP file with the Open CASCADE technology (OCCT) bindings in pythonOCC, tessellates each solid, and writes a GLB and a 3MF through trimesh. It is a minimal sketch: it handles colours and instancing poorly and ignores the assembly hierarchy by walking solids, so treat it as a starting point rather than a production converter. I have not benchmarked it; run it on your own parts.

# pip install pythonocc-core trimesh numpy lxml
import numpy as np
import trimesh
from OCC.Core.STEPControl import STEPControl_Reader
from OCC.Core.IFSelect import IFSelect_RetDone
from OCC.Core.BRepMesh import BRepMesh_IncrementalMesh
from OCC.Core.TopExp import TopExp_Explorer
from OCC.Core.TopAbs import TopAbs_FACE, TopAbs_SOLID
from OCC.Core.TopoDS import topods
from OCC.Core.BRep import BRep_Tool
from OCC.Core.TopLoc import TopLoc_Location

LINEAR_DEFLECTION = 0.1   # model units, usually mm
ANGULAR_DEFLECTION = 0.5  # radians

def read_step(path):
    reader = STEPControl_Reader()
    if reader.ReadFile(path) != IFSelect_RetDone:
        raise RuntimeError(f"cannot read {path}")
    reader.TransferRoots()
    return reader.OneShape()

def solid_to_trimesh(solid):
    BRepMesh_IncrementalMesh(solid, LINEAR_DEFLECTION, False, ANGULAR_DEFLECTION, True)
    verts, tris, offset = [], [], 0
    exp = TopExp_Explorer(solid, TopAbs_FACE)
    while exp.More():
        face = topods.Face(exp.Current())
        loc = TopLoc_Location()
        tri = BRep_Tool.Triangulation(face, loc)
        if tri is not None:
            trsf = loc.Transformation()
            for i in range(1, tri.NbNodes() + 1):
                p = tri.Node(i).Transformed(trsf)
                verts.append((p.X(), p.Y(), p.Z()))
            for i in range(1, tri.NbTriangles() + 1):
                a, b, c = tri.Triangle(i).Get()
                # Face orientation: flip winding for reversed faces
                if face.Orientation() == 1:
                    a, b = b, a
                tris.append((a - 1 + offset, b - 1 + offset, c - 1 + offset))
            offset += tri.NbNodes()
        exp.Next()
    return trimesh.Trimesh(np.array(verts), np.array(tris), process=False)

shape = read_step("assembly.step")
scene = trimesh.Scene()
exp = TopExp_Explorer(shape, TopAbs_SOLID)
n = 0
while exp.More():
    mesh = solid_to_trimesh(topods.Solid(exp.Current()))
    mesh.apply_scale(0.001)          # glTF is in metres; STEP here assumed mm
    scene.add_geometry(mesh, node_name=f"solid_{n:04d}",
                       geom_name=f"solid_{n:04d}")
    n += 1
    exp.Next()

scene.export("assembly.glb")         # glTF 2.0 binary
scene.export("assembly.3mf")         # needs lxml
print(f"{n} solids exported")

Several details in that script are load-bearing. The scale factor exists because glTF defines units as metres, while STEP files carry their own length unit, usually millimetres. The face orientation flip matters because OCCT stores a face’s triangles relative to its underlying surface, and a reversed face needs inverted winding or normals point inward. And the 3MF export step requires lxml, which the trimesh documentation lists as a soft dependency for XML formats.

If you need names, colours and the proper assembly tree, use OCCT’s XDE document tools (the XCAF framework in OCCT, exposed through STEPCAFControl_Reader) instead of a raw reader. Alternatively, use a converter that handles XDE already. Open-source options include FreeCAD, which uses OCCT, and Blender via community STEP importers. Commercial options include CAD Exchanger and similar SDKs; I have not verified their current format coverage this run, so confirm PMI and JT support against vendor documentation before committing.

What each format keeps: a comparison

Capability	STEP AP242	JT	3MF	glTF 2.0
Geometry model	Exact B-rep, optional tessellation	B-rep and tessellated LODs	Triangle mesh	Triangle, line, point meshes
Standard	ISO 10303-242	ISO 14306	ISO/IEC 25422	ISO/IEC 12113
Assembly structure	Yes, with transforms	Yes, multi-file capable	Components and build items	Node hierarchy
Semantic PMI	Yes	Supported, exporter-dependent	No	No
Graphical PMI	Yes	Yes, exporter-dependent	No	Only as drawn geometry
Materials	Basic colour and styling	Colour, some material attributes	Colour, textures, composite materials via extensions	PBR metallic-roughness plus KHR extensions
Units	Explicit in file	Explicit	Explicit	Metres, fixed
Compression	None native in Part 21 text	Native segment compression	Zip package	Draco, meshopt, Basis textures
Best fit	Authoritative exchange, archive	PLM visualization, review	Additive manufacturing	Web, AR, game-engine twins

Figure 3: What tessellation discards and what can be recovered with side-channel data such as per-face identifiers.

Carrying PMI across the mesh boundary

PMI is the piece teams most often assume will “just come along”. It will not, and the reason is structural. Semantic PMI in AP242 is a graph: a tolerance entity points at a datum system, which points at datum features, which point at shape aspects, which point at specific faces or edges of the B-rep. Delete the B-rep and the graph has nothing to attach to. A mesh has no faces in that sense, only triangles.

There are three workable patterns. The first is the sidecar: keep the STEP (or a QIF results file) next to the glTF and join them on stable identifiers. The viewer shows a part, the user selects it, and a service answers “what are the tolerances on this part” from the STEP. This is the lowest-risk pattern and the one I recommend as a default.

The second is graphical-only: export the PMI presentation as line geometry and text so the viewer shows dimensions in place. This is cheap and visually convincing, but a machine cannot reason about it, so it supports human review rather than automated inspection planning.

The third is face-level linking: tessellate each B-rep face as its own primitive, store the face identifier in extras, and let the sidecar resolve tolerance-to-face relationships. It costs more draw calls and more metadata, and the per-face split prevents some mesh optimizations, but it is the only pattern that lets a click on a hole highlight its position tolerance. Budget for it only where inspection workflows justify it.

Materials and appearance: what actually crosses over

STEP carries colour and surface styling that most CAD exporters populate, but it does not carry rendering-grade materials. JT can carry colour and some material attributes. 3MF’s core handles base materials and colour, with extensions for textures and composites. glTF is the only format of the four designed around a physically based shading model, using base colour, metallic and roughness factors plus optional texture maps.

The consequence is that a “realistic twin” is an authoring step, not a conversion step. Converting a STEP assembly produces grey or flat-coloured parts. To get brushed steel, painted panels or glass, you assign PBR materials downstream, ideally by mapping CAD material names or PLM material specifications to a managed material library, so that a change in the specified finish regenerates the visual. The ratified material extensions such as clearcoat, transmission and sheen then let you push realism further for automotive or consumer products.

A subtle point about 3MF: its materials describe how the printer should build the object, including composite materials and per-triangle properties, rather than how a renderer should shade it. Do not reuse 3MF material data as a visual asset without checking what it means.

Size, loading and instancing

File size is where the formats diverge in practice, and I will not quote ratios here because they depend entirely on part content, tessellation settings and exporter choices; test with your own assemblies. What can be said structurally is this. A STEP Part 21 file is plain text, which is verbose for freeform surfaces. JT compresses its segments natively. A GLB is a binary container whose geometry buffers can be shrunk with Draco or meshopt, and whose textures can use Basis Universal through KHR_texture_basisu. 3MF is zipped XML, which compresses well but still stores vertices as text.

Instancing matters more than compression for assemblies with repeated parts. A car body might use thousands of identical fasteners. STEP and JT represent these as references to a single definition with placement transforms. In glTF, you reproduce that by pointing many nodes at the same mesh, or by using EXT_mesh_gpu_instancing so the GPU draws all copies in one call. A converter that flattens everything and duplicates the triangles discards the single most effective size reduction available to you, and it also destroys the link between repeated instances and their shared part definition.

A practical load strategy for large twins combines these ideas: convert unique parts once, instance them in the scene, compress buffers, stream by area of the plant or by assembly branch, and substitute coarse proxies at distance. glTF has no standard LOD mechanism, so the last step is something your application or a vendor extension must provide, which is exactly where JT’s LOD segments have a head start.

Round-trip reality check

Teams sometimes ask whether they can go STEP to glTF and back. You cannot recover exact geometry from triangles, and reconstruction tools that fit surfaces to meshes produce approximations, not the original design. Between STEP and JT, a round trip is more plausible when JT carries B-rep, but fidelity depends on the exporters at both ends. The safe assumption is that conversion is directional, from authoritative to derived, and that any reverse path is a reverse-engineering exercise with its own accuracy budget.

Where OpenUSD fits

OpenUSD (Universal Scene Description) is not a CAD format. It is a scene composition framework for layering, referencing and overriding assets across a pipeline, and its geometry is again mesh-based for CAD content. Twin platforms built on it typically ingest glTF, STEP-derived meshes or JT-derived meshes as leaf assets, then compose the plant scene with variants and references. I covered the decisions this raises in OpenUSD core spec for CAD and digital twin decisions; the short version is that USD is the integration layer and glTF is one of its most convenient leaf formats, not a competitor to either.

The API calls in the script follow the pythonOCC 7.7-era bindings, where Poly_Triangulation exposes Node(i) and Triangle(i) accessors. Older and newer releases have shifted these methods around, so pin your version and check the pythonOCC release notes if an attribute is missing.

Trade-offs, Gotchas, and What Goes Wrong

The biggest failure mode is silent semantic loss. A STEP-to-glTF conversion succeeds, the model looks right in the viewer, and nobody notices that the tolerance on face 214 is gone. The converter does not warn you, because from its point of view a mesh is a valid output. Add a check that compares PMI counts before and after, even a crude one, and fail the pipeline when the numbers diverge.

The second is identity loss. Tessellators merge, split and reorder faces, so triangle 8,431 means nothing in the source model. If you need a viewer click to resolve back to a B-rep face, you must carry a face identifier through the conversion: either one mesh primitive per face, or a per-triangle attribute. glTF supports custom data in extras fields on nodes, meshes and primitives, which is a practical place to store the STEP entity identifier or your PLM item number.

Third, unit and axis mistakes. STEP files in millimetres converted to glTF without scaling appear 1,000 times too large in a metre-based engine. Many CAD systems use Z-up, while glTF is Y-up, so a naive conversion lays the plant on its side. Both are one-line fixes once you know to look, but they are the most common first-week bugs in twin projects.

Fourth, tessellation seams. Faces are tessellated independently, so adjacent faces may not share vertices, leaving T-junctions and hairline cracks under certain shading. Welding vertices within a tolerance hides this, but it also merges vertices across intentional gaps. Use the smallest weld tolerance that closes the visible cracks and verify on thin-walled parts.

Fifth, JT and licensing nuance. The JT specification is an ISO standard, but writing high-fidelity JT in practice usually goes through vendor toolkits, and PMI output quality differs across them. I did not find a single authoritative statement of toolkit licensing terms this run, so ask vendors directly and test round-trips on your own assemblies. STEP, glTF and 3MF all have openly obtainable specification texts or open implementations, though the ISO documents themselves are paid.

Sixth, 3MF is not a viewer format. It will open in slicers and many CAD viewers, but streaming a large 3MF assembly into a browser is not what it was designed for, and its materials extensions are only as good as the consuming tool’s support.

Finally, compression has its own cost. Draco and meshopt shrink geometry substantially but add a decoder dependency in every client, and quantization changes vertex precision. For measurement-grade overlays, avoid lossy compression on the reference mesh.

Practical Recommendations

Start from the consumer, not the format. Decide what question the twin must answer, then pick the lightest representation that can answer it without guessing. Keep STEP AP242 as the system of record and treat every other file as a derived, regenerable artefact with a recorded source revision.

Figure 4: Decision flow. Exactness needs push you to STEP, print jobs to 3MF, and everything else toward JT or glTF depending on whether LOD-driven CAD review or runtime delivery is the goal.

In practice a mature program ends up with a small matrix of formats rather than one. The table below summarizes the mapping I would use as a default; adjust it to your toolchain after testing.

Use case	First choice	Why	Watch out for
Authoritative archive and supplier exchange	STEP AP242	Exact geometry, semantic PMI, ISO standard	Exporter support for semantic PMI varies
PLM review of very large assemblies	JT	LODs, multi-file assemblies	PMI fidelity depends on the writer
Web, AR or game-engine twin	glTF 2.0 with meshopt or Draco	Fast loading, PBR materials	No PMI, metres and Y-up
3D printing and as-built records of printed parts	3MF	Units, materials and manifold meshes	Not for assembly semantics
Plant-scale scene composition	OpenUSD referencing glTF assets	Layering and variants	CAD content is mesh-only

A short checklist for the pipeline:

Store the source STEP revision and tessellation parameters in the glTF asset.extras or your PLM metadata so any derived mesh can be regenerated.
Carry the part number and face identifiers in extras; do not rely on node names alone.
Set tessellation deflection per consumer class and write it down.
Convert units and axes in one place, with a test that checks a known bounding box.
Compare PMI and part counts before and after conversion, and fail on mismatch.
Keep semantic PMI in a sidecar (for example the STEP file or a QIF document) and link it by identifier.
Re-test round trips whenever you upgrade a CAD exporter or converter version.

For plant-floor context, the twin’s geometry layer is only one part of the stack. How the model connects to live data is covered in our step-by-step digital transformation guide and, on the SCADA side, in the Ignition vs Wonderware vs FactoryTalk comparison, because that is where mesh nodes get bound to tags.

Frequently Asked Questions

Is glTF a replacement for STEP?

No. glTF stores triangles and materials for fast display, while STEP AP242 stores exact B-rep geometry, assembly structure and PMI. You can convert STEP to glTF for visualization, but the reverse cannot recover surfaces or tolerances. Use STEP as the authoritative source and glTF as a derived runtime asset, regenerated whenever the source changes. Treating glTF as the master copy is the most common way teams lose design intent.

Does glTF support PMI or GD&T?

Not natively. The Khronos extension registry I checked lists no CAD or PMI extension. You can draw dimensions as line geometry, which gives you graphical PMI only, and you can attach identifiers in extras that point to semantic PMI stored in STEP or QIF. Semantic GD&T such as datum-referenced position tolerances needs a separate data store linked by identifier.

Is 3MF the same as ISO/ASTM 52915?

No. ISO/ASTM 52915:2020 is the Additive Manufacturing File Format (AMF) version 1.2, an older XML format. 3MF is standardized as ISO/IEC 25422:2025, the “3D Manufacturing Format (3MF) specification suite”, published in June 2025. Both target additive manufacturing, but they are separate standards with different structures, so cite the correct one in requirements documents and supplier contracts.

Can JT replace STEP for long-term archiving?

Generally it is not the first choice. JT is optimized for visualization and collaboration, with LOD tessellation and optional B-rep, and PMI quality depends on the exporter. STEP AP242 is the format designed for neutral long-term exchange and archiving of 3D product data with semantic PMI. Some organizations do archive both: STEP as the record and JT as the viewable companion, with a link between them.

What tessellation tolerance should I use for a digital twin?

It depends on the consumer. For a chord-height deflection d on a circle of radius r, segments needed are about pi divided by arccos(1 – d/r), so a 10 mm bore needs 23 segments at 0.1 mm and 71 at 0.01 mm. Web viewers often tolerate coarse settings, clash detection needs tighter ones, and measurement comparison should use the STEP geometry directly rather than any mesh.

Where does OpenUSD fit alongside these formats?

OpenUSD is a scene composition layer, not a CAD exchange format. Twin platforms commonly bring glTF or other mesh assets into a USD stage and use references, layers and variants to assemble the plant. Treat it as the integration layer above your geometry formats. CAD semantics such as PMI still live in STEP or QIF and are linked to the USD prims by identifier.

3MF vs STEP AP242 vs glTF vs JT: Choosing Lightweight CAD Formats for Digital Twins and PLM