File Formats

Which mode opens what

Extension	Mode	Notes
.step .stp .iges .igs .brep	🔷 Pre-Processing	B-rep, tessellated by OpenCascade. .step/.stp/.iges/.igs are also readable in Post-Processing since meshio++ 17.2.0 (the solid's own triangulation, and a NURBS side channel its IGA tools can refine): inside the app the active mode decides, and a file-manager launch keeps starting in Pre-Processing
.csg .scad	🔷 Pre-Processing	OpenSCAD. .csg (the fully evaluated form) is parsed and built kernel-side into a solid; .scad is evaluated first by the bundled OpenSCAD build (WebAssembly, Manifold backend — no install needed), falling back to a user-installed openscad binary only for declined constructs (import()/surface(), a missing include, over the staging caps; Settings ▸ Open Settings… ▸ CAD Viewer ▸ OpenSCAD Binary, or openscad on PATH) — without either, opening a .scad reports that rather than failing silently. Import-only: export goes to STEP/IGES/BREP or a mesh target, never back. Anything the importer approximates or skips (a hull(), a faceted cylinder) is reported on the status line
.plt	🔷 Pre-Processing	Tecplot binary result file, read and exported through meshio++ 17.13.0 in CAD mode's importer (Post-Processing does not route it)
.gltf .glb	Both	meshio++ 17.0.0's static-scene reader put these beside STL/OBJ/PLY in Post-Processing; Pre-Processing still loads them natively via Three.js (with Draco/meshopt) and is where a file-manager launch lands them
.3mf .dae .amf .usd .usda .usdc .usdz .wrl .fbx	🔷 Pre-Processing	3MF, Collada, AMF, USD, VRML and FBX (plain text, binary crate/package, or a zipped container as applicable), loaded by Three.js in the viewer. Display-only: they open and show; 3MF, USD, VRML and FBX can be exported to STL/OBJ/PLY/glTF/3MF, while Collada and AMF are import-only with no writer. The host has no triangle parser for any of them, so meshing, measurement, region fitting, Mesh Health, printability, silhouette/drawing-sheet exports and B-rep promotion are refused by name. USD and FBX unit metadata is applied to millimetres once and seeds the Units dropdown; VRML declares no unit, so its geometry is shown as authored
.mdpa	🔶 Post-Processing	Kratos model part
.vtk .vtu .vtp .vti .vts .vtr .vtm	🔶 Post-Processing	Legacy + XML VTK, multiblock, time-series
.msh .inp .bdf .nas .fem .unv .mesh .meshb .vol .su2 .xdmf .xmf .off .avs .dat .tec .mphtxt .node .ele .f3grid .pf3 .post .dato .ugrid .mfm .wkt .xml .dex .ip .mff .case .geo .poly .e .exo .ex2 .cgns .h5m .hmf .med .foam	🔶 Post-Processing	Extended formats read via meshio++ (Gmsh, Abaqus/ANSYS, Nastran, I-deas UNV, Medit (text .mesh and, since 17.3.0, binary .meshb), Netgen, SU2, XDMF, COMSOL, tetgen, EnSight Gold, Triangle, Exodus II, CGNS, MOAB, Salome MED, OpenFOAM, …), and since meshio++ 17.2.0 the STEP/IGES solid reads and glTF/GLB scenes above. Named groups (Gmsh physical groups, Abaqus *NSET/*ELSET/*SURFACE, Exodus element blocks / node sets / side sets, OpenFOAM boundary patches) arrive as SubModelParts. .e/.exo/.ex2 (Exodus) and .xdmf/.xmf describe their time steps within the dataset and drive the timeline from there (XDMF may reference a required sibling .h5; copy it too) — no <prefix>_<rank>_<step> sibling naming needed; Salome .med also accepts a time step, but reports no step count up front, so its timeline isn't discoverable before a read. .dex/.ip/.mff are field-only formats — they carry point fields with no geometry, so reading one yields a point cloud (or an empty mesh); .case/.geo (EnSight Gold) and .poly (Triangle) need their sibling file(s) alongside. .foam is an OpenFOAM case: the file you open is a 0-byte marker, and the real mesh — volume cells as Elements, boundary faces as Conditions, one named SubModelPart per boundary patch — lives in a sibling constant/polyMesh/ tree, which the preview also watches, so re-running blockMesh/snappyHexMesh refreshes the view in place. The time directories (0, 0.5, …) drive the timeline: their fields arrive as Elemental (vol*Field) or Nodal (point*Field) fields, and a patch carrying one uniform boundaryField value arrives as a Conditional field of the same variable, with the file's dimensions kept as its unit. Zones (cellZones, faceZones, pointZones) become SubModelParts; a multi-region case (one constant/<region>/polyMesh each) opens with every region merged and each region a top-level SubModelPart, and a decomposed case (processorN/constant/polyMesh plus the *ProcAddressing files) is reconstructed into one mesh with processor0's patch names — run reconstructPar first if you need its fields. Not read: #include/coded/substituted field content, binary fields, nonuniform patch values. File ▸ Save writes back into the case, and only the files it can own: a geometry- or field-only change rewrites just constant/polyMesh/points (plus the internalField of an edited field), so nothing keyed by cell/face/point number can go stale; a topology change rewrites the six polyMesh files and then refuses by file name if anything else is keyed to the old numbering (sets/, cellLevel, pointLevel, refinementHistory, surfaceIndex, a moving-mesh <time>/polyMesh, a time-directory field holding a nonuniform list), as it does for polyhedral cells; zone files (cellZones, faceZones, pointZones) are rewritten from genuine zone parts instead of blocking the save, and no new bogus zone is added. A multi-region case rewrites each changed constant/<region>/polyMesh from its wrapper part (unchanged regions byte-identical) and applies field edits per region; a decomposed case re-partitions natively over the same processor count with zones and fields regenerated per processor. Exporting into the case (another .foam name, a sub-part, a derived or batch output) is refused — use Export ▸ Solvers ▸ OpenFOAM or Save As… to write a new case directory instead
.fil .rst .rth .d3plot .t19 .op2 .xplt .h5	🔶 Post-Processing	Solver-result formats, also read via meshio++: Abaqus .fil, ANSYS MAPDL .rst/.rth, LS-DYNA .d3plot, MSC Marc .t19, MSC Nastran .op2/.h5 and FEBio .xplt. meshio++ 17.3.0 taught these to be written back too, and the Solvers export group gained Marc .t19, FEBio .xplt and MAPDL .rst for it (result-file writers keep every cell class but merge the blocks of one cell type; the .plt/.xplt/.meshb writers keep the per-region block layout and drop 0-D vertex-only blocks). Reads still report no steps from a header — so each opens as a filename series (a single frame, no timeline scrubber), the same bar CalculiX .frd sits behind. Four more upstream readers exist but are reachable by an explicit format only, because upstream finds them by file name rather than by extension: a cyclic model's full rotor, LS-DYNA binout, and the two Radioss animation forms
.stl .obj .ply .gltf .glb	Both	Opens in the currently active mode

The meshio++ 17.2.0/17.3.0 reader set also covers Code_Aster (.mail), FEBio (.feb), Femap (.neu), libMesh (.xda/.xdr, including .gz and .bz2), COMSOL binary (.mphbin), Patran (.pat/.out), Radioss (.rad), Z88 (.z88), Elmer (.elmer), MFEM partition files (.mfem-rank) and Kratos CAD JSON (.cad.json — a trimmed NURBS B-rep whose stored sampling opens as its own faces; the CAD-main guide's IGA section covers the exact-NURBS tooling). A zstd/lz4-deflated .vtu or a bzip2 libMesh file is refused by the lean wasm build with the codec named, and the read falls back to the full artifact automatically with a stated diagnostic (lzf-compressed PCD writes are lean-route, lz4/zstd are the fallback; a claimed lzma VTU file has no published build support). GiD postprocess, PVD collections, XDMF, MED, CGNS, Tecplot, VTKHDF and OpenFOAM cases can expose in-file timelines; see Post-Processing for the live-watch and resampling behavior.

Pre-Processing can also read .vtk .vtu .med .cgns .exo .e .xdmf .mdpa .msh .inp .unv .su2 .mesh .post.msh .foam — plus the 17.2.0/17.3.0 additions .cad.json .xda .xdr .xda.gz .xda.bz2 .xplt .meshb .t19 .fil .rst .d3plot and the 17.4.0/17.7.0 Nastran .op2 result writer — through meshio++, as a geometry-only boundary surface (named regions become Parts; fields are not converted, though a scalar point/cell field can be used to colour the model). Those are post-processing formats here and mesh mode reads them natively — fields, blocks and SubModelParts — so opening one always lands in Post-Processing regardless of the active mode. The Tecplot binary .plt is the one exception (Post-Processing's reader table has no key for it), so it stays a Pre-Processing import. Reach the CAD-side importer from Pre-Processing's own Open… dialog (or drag the file onto the CAD view) when you specifically want to mesh or edit that geometry.

.msh2 (Gmsh 2.2) goes the other way and opens in Pre-Processing whatever the active mode — the mesh engine never registered it at all, so cad mode is the only one that can open it.

If a file won't open

Opening a file no mode can read — from Open…, a drag-and-drop, a recent entry, or a launch from the operating system or command line — shows a warning naming the file and the suffix KKSS does not read (.post.msh is reported as a compound suffix, never as .msh), with a Supported formats button that opens this page. A file with no extension is reported as such, since its format cannot be told from the name. When several unsupported files arrive at once, one warning names the first and counts the rest. Every format either mode reads is already routed to the mode that owns it (see the table above), so a message never means "try the other mode".

Export targets

Pre-Processing (depends on the source pipeline):

• B-rep sources → STEP, IGES, BREP, STL, OBJ, PLY, glTF
• Mesh sources → STL, OBJ, PLY, glTF, 3MF — or Fit to CAD… in the Mesh Health panel, the one mesh → B-rep export: segment the skin, fit exact analytic/freeform faces and write a brand-new AP214 STEP (see Pre-Processing)
• FE meshing → Kratos MDPA (Elements+Conditions or Geometries), Gmsh .msh / .msh2 / .geo_unrolled (+ XAO companion), VTK, UNV, Abaqus .inp, Nastran .bdf, SU2, and more — plus MED, CGNS and XDMF (+ its .h5 companion) written through meshio++, which Gmsh's own writers can't produce, and the 17.3.0 solver-result writers — Tecplot binary .plt, FEBio .xplt, binary Medit .meshb, Marc .t19, Abaqus .fil, MAPDL .rst and LS-DYNA .d3plot — plus the 17.4.0/17.7.0 Nastran .op2 writer — each round-tripped against the meshio++ reader before being claimed
• Screenshot → PNG (File ▸ Screenshot…, Ctrl+Alt+P)

Every export target can optionally be unit-converted (mm/cm/m/in/ft) on the way out: a second quick-pick after the format, defaulting to native mm. This is a real geometric scale on the exported file — STEP and IGES also get their declared header unit written to match — not the display-unit selector in the view controls, which only changes how measurements read. A CGNS export of a pure surface mesh is a known gap: it writes, but meshio++'s own reader can't read it back (volume meshes are fine).

When an FE-meshing export produces a file Post-Processing can display (.mdpa, .vtk, …), the app switches to Post-Processing mode and opens it automatically — a one-way pre → post handoff. Exports the post viewer can't open (.msh, .inp, …) and shared formats (.stl/.obj/.ply) stay in Pre-Processing.

Post-Processing: MDPA, VTK (legacy), VTU, VTP, VTM, STL, OBJ, PLY — for the whole model or any single SubModelPart, or just the boundary skin of the volume cells (Advanced ▸ Export skin…) — plus 53 extended writable formats via meshio++ (Gmsh .msh, Abaqus .inp, Nastran .bdf/.nas/.fem, I-deas UNV, Medit .mesh and binary .meshb, Netgen .vol, SU2, XDMF, Triangle .poly, Exodus .e/.exo/.ex2, CGNS, MOAB .h5m, .hmf, Salome .med, and more), including the field-only .dex/.ip/.mff targets (point fields kept, geometry dropped), the write-only SVG/TikZ figure formats (a 2D/3D-projected drawing of the mesh, not a re-readable mesh), and meshio++ 17.3.0's solver-result writers: Marc .t19, FEBio .xplt and MAPDL .rst in the Solvers export group (.fil/.op2 were already there), with .meshb joining Medit as a two-way format. A .step target is the new mesh → CAD export: a closed, consistently wound all-triangle skin is auto-fitted with meshio++'s fitCad into a real B-rep (analytic faces where a primitive fits — planes, spheres, cylinders, cones, tori, fillets and threads — freeform patches where none does), and the B-rep rides beside the file as a <stem>.cad.json companion; anything else (quad skins, open surfaces, a failed fit) falls back to the faceted STEP writer, and the export's diagnostic names which ran. Since mesh 5.18.0 the fitted export also reports the skin deviation (largest face-to-skin distance with its RMS) and whether the solid closed. The Export menu asks once per STEP target — kernel defaults, analytic-only, or skip fitting — and case_export_results carries the same behaviour. File ▸ Export Mesh As groups these targets; Export… retains the picker and shortcut.

SubModelParts survive an export to .mdpa, .med (as MED families) and .inp (as real *NSET/*ELSET sets), and every mesh block keeps its name in .exo; a .msh export still carries no groups (meshio++ writes no $PhysicalNames for a mesh that didn't come from Gmsh). Exodus export remains lossy — element blocks and fields survive, genuine SubModelParts do not, and a time series flattens to one step. Native VTU does not retain SubModelPart sets: use MDPA or MED when those memberships matter, and inspect the fidelity report. VTM writes a multiblock index plus VTU companions. Structured VTK types (.vti/.vts/.vtr) are not general mesh-export targets; structured VTI has its own sample-grid export path with explicit unverified fidelity.

How format counts are measured

The routing registries currently expose 64 extended readable formats and 53 extended writable formats through meshio++. These count distinct format identifiers, not suffix aliases: Exodus .e/.exo/.ex2 count once, while alternative readers for a shared suffix count separately. Native formats are separate. The counts include field-only .dex/.ip/.mff formats; the writable count also includes SVG and TikZ figures, which cannot be read back as meshes. npm run check:packaging derives both counts from the pinned registries and rejects mismatched documentation.

Reading solids and scenes (meshio++ 17.2.0+): STEP (.step/.stp) and IGES (.igs/.iges) open as the solid's own triangulated skin — the OpenCASCADE-backed readers exist only in the full wasm artifact, which KKSS stages beside the lean build and loads only where the lean build cannot serve (a zstd/lz4-compressed .vtu or a bzip2-compressed libMesh file also falls back there, with a stated diagnostic). A STEP/IGES read keeps the model's NURBS patches on the side, which igaSample/igaRefine derivations and a .cad.json round-trip can use; glTF/GLB (.glb/.gltf) opens as the scene's static mesh. Deliberately unwritten writer keys reachable only through an explicit outputFormat: nastran_h5 (.h5 is ambiguous against the XDMF companion and MOAB), lsdyna_d3plot and radioss_anim (name-matched file families, not single files), neuroglancer and the forbidden Tecplot SZL/DOLFINx VTX pair (not in this build).