The models category covers 3D and CAD interchange formats, each carrying one small, documented solid so you have a known shape to convert and inspect. The mesh formats hold a real 10 mm cube: STL in both ASCII and binary encodings, a Wavefront OBJ, and a 3MF manufacturing package. There's a DXF drawing of the same cube as 3D line geometry, an EPS vector illustration, and minimal well-formed STEP (AP214) and IGES samples for testing header and entity parsing. Every file states its geometry, units, and structure, so you're converting against a known object rather than a mystery mesh.
Filter models on Browse · 159 files · 20 subcategories
A single animation whose four channels drive two nodes at once: the parent's translation, rotation and scale, and a spinning child that inherits all of it. The fixture for checking that channels are applied per node and per path rather than collapsed into one track.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is cubic-spline, with in/out tangents stored around each value. Three files differing only in `interpolation` — the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is linearly interpolated. Three files differing only in `interpolation` — the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is held (STEP) — the value jumps at each key. Three files differing only in `interpolation` — the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
A longer tube skinned to a four-joint chain, every joint but the root animated, so the whole limb curls rather than hinging once. Exercises joint-matrix accumulation down a hierarchy — the step that a two-bone rig cannot catch.
A tube skinned to a two-joint chain with inverse bind matrices, unsigned-byte JOINTS_0 and float WEIGHTS_0, plus a three-second rotation animation on the elbow. The shipped models category had no skinned mesh at all; this is the smallest complete one — rig, bind pose, weights and clip in a single self-contained GLB.
The same two-joint skinned bend as readable glTF JSON with its buffer embedded as a base64 data URI — the file to open in a text editor when a GLB's skin, sampler or inverse bind matrices are not doing what you expect.
The binary payload the external-buffer glTF in this group points at: tightly-packed positions, normals and indices with 4-byte alignment padding. Not viewable on its own — its bufferViews live in the JSON.
Position, normal and UV packed into ONE bufferView with byteStride 32 and three accessors at offsets 0, 12 and 24 — the GPU-friendly layout, and the one a naive parser mis-reads because it assumes each accessor owns its view. Twinned here with a tightly-packed version of the same sphere.
The third storage strategy for the identical sphere: a GLB whose buffer is the BIN chunk, with no URI at all. Compare the three file sizes in this group to see exactly what base64 and JSON whitespace cost.
The third texture-storage strategy: the PNG lives inside the GLB's BIN chunk as a bufferView, addressed by `mimeType` rather than a URI. This is what a GLB packer must produce, and extracting the image again is the round-trip test.
The same sphere with every attribute in its own bufferView and no byteStride — the layout most exporters emit and most parsers assume. The control against which the interleaved twin in this group is diffed.
The same sphere with its buffer inlined as a base64 data URI: one self-contained text file, at roughly a third more bytes than the binary it encodes. The middle point of the three storage strategies in this group.
A glTF whose single buffer is a relative URI to a sibling .bin — the layout every DCC tool writes by default, and the one that breaks the moment an asset is moved or served from a different directory. Download the .bin in this group alongside it.
Geometry inline, texture out of line: the image is a relative URI to a sibling PNG while the buffer is embedded, which is the mixed layout that trips asset packers expecting all-or-nothing. Download the PNG in this group with it.
The same textured sphere with the PNG inlined as a base64 data URI in `images[0].uri` — a single portable text file. The variant that makes a glTF e-mailable and that some loaders quietly refuse.
The 64x64 two-colour checker referenced by the external-texture glTF in this group. Small, hard-edged and axis-aligned on purpose: UV seams, wrap mode and filter choices are all visible at a glance.
A 10 mm cube drawn as 12 DXF LINE entities — the AutoCAD interchange format, written with ezdxf. For testing DXF parsers and CAD conversion.
An isometric cube as Encapsulated PostScript — a 2D vector illustration with three shaded faces. For testing EPS/PostScript rendering and vector conversion.
A minimal, well-formed IGES 5.3 file with a single LINE entity and correct Start/Global/Directory/Parameter/Terminate sections. For testing IGES parsers and CAD conversion.
A 16-tooth spur-gear profile as a closed DXF polyline with a central hub bore — real parametric CAD geometry (not a primitive). For testing DXF parsers, CAM tools, and CAD conversion.
The same 16-tooth spur-gear profile as STEP AP214 CARTESIAN_POINT entities — the CAD-exchange twin of the DXF, for testing STEP parsing.
A minimal, well-formed STEP AP214 file holding the eight corner points of a 10 mm cube. For testing STEP header and entity parsing and CAD-exchange tooling.
An unquantised sphere: 32-bit floats for both positions and normals, 24 bytes of attribute data per vertex. The uncompressed reference for the quantized and gzip twins in this group.
The same sphere with positions as normalised 16-bit and normals as normalised 8-bit integers under KHR_mesh_quantization — 66.6% of the float32 twin's bytes. The extension is in extensionsRequired, so a loader without support must refuse the file rather than render garbage.
The float32 GLB from this group as a deterministic gzip stream (no embedded filename, mtime 0) — what a CDN actually sends when a viewer advertises `Accept-Encoding: gzip`. It compresses to 29.2% of its source against 55.6% for the quantized twin, which is the point of shipping both: quantisation halves the file on disk and then gives most of that back over the wire.
The quantized GLB from this group as a deterministic gzip stream (no embedded filename, mtime 0) — what a CDN actually sends when a viewer advertises `Accept-Encoding: gzip`. It compresses to 55.6% of its source against 29.2% for the float32 twin, which is the point of shipping both: quantisation halves the file on disk and then gives most of that back over the wire.
High-resolution cylinder mesh — the ground truth for scoring a decimation / simplification tool against the low-poly member of this group.
High-resolution sphere mesh — the ground truth for scoring a decimation / simplification tool against the low-poly member of this group.
High-resolution torus mesh — the ground truth for scoring a decimation / simplification tool against the low-poly member of this group.
High-resolution vase mesh — the ground truth for scoring a decimation / simplification tool against the low-poly member of this group.
Low-poly simplification of the same cylinder shape (36 triangles vs 192). Compare against the dense ground truth to measure decimation error.
Low-poly simplification of the same sphere shape (140 triangles vs 1728). Compare against the dense ground truth to measure decimation error.
Low-poly simplification of the same torus shape (196 triangles vs 1600). Compare against the dense ground truth to measure decimation error.
Low-poly simplification of the same vase shape (100 triangles vs 480). Compare against the dense ground truth to measure decimation error.
The clean reference cube as a GLB, so the same baseline is available to glTF tooling and to the site's 3D preview. Identical topology to the OBJ twin in this group.
The duplicated-corner cube as a GLB. Because glTF stores every attribute per vertex, the duplication doubles the position and normal buffers for a shape that needs eight corners — the cheapest optimisation an asset pipeline can make, and the one this fixture measures.
The mixed-winding cube as a GLB with a default single-sided material, so the reversed faces are culled and you can see straight through the model. Turning on doubleSided hides the defect without fixing it, which is the trap this fixture is for.
The finned cube as a GLB. It renders without complaint in any viewer — rasterisation never asks about adjacency — so this is the fixture that separates tools which actually analyse topology from tools which merely draw triangles.
The same four degenerate triangles inside a structurally valid GLB. The file passes every glTF schema check — nothing in the format forbids a zero-area face — so this is the fixture for geometry validation as opposed to document validation.
A welded, manifold, consistently-wound unit cube: 8 vertices, 12 triangles, 18 edges each shared by exactly two faces, and a signed volume of exactly 1.0. This is the answer key — each defect fixture in the degenerate/ subcategory is this mesh with exactly one thing wrong.
The reference cube with all eight corners stored twice at bit-identical coordinates: the first six triangles use one copy, the last six use the other. It renders as a closed cube but is topologically two disconnected surface patches with a split seam, which is why smoothing, subdivision and boolean operations all misbehave on it.
The reference cube with three of its six cube faces (six of its twelve triangles) wound clockwise instead of counter-clockwise, and `vn` records that follow the reversed winding into the solid. The classic symptom is a model that looks half-invisible with backface culling on and half-black with it off.
The same NaN vertex in Wavefront OBJ, where the literal is the bare token `nan`. Normals are deliberately not written, because the three faces touching that vertex have no computable normal — which is exactly the state an importer must handle rather than serialise.
The reference cube with a two-triangle fin welded along one top edge, so that edge is shared by three faces instead of two. Non-manifold edges have no defined surface orientation, which is why slicers refuse them and why subdivision and offsetting produce garbage.
The reference cube plus four triangles with no area, one for each way a mesh can have one: three collinear points, two coincident vertices at different indices, a repeated index, and all three indices identical. Their face normals are undefined, which is where downstream tools produce NaN.
The duplicated-corner cube as ASCII PLY — the format scanners and photogrammetry tools emit, and the one where unwelded duplicates are most common because each captured point arrives independently.
A structurally perfect ASCII PLY in which one vertex reads `nan nan nan` — the value an exporter writes after dividing by a zero-length vector. The header, counts and face list are all correct, so the file parses; every bounding box, centroid and normal computed from it is then poisoned.
An ASCII STL of the reference cube with two extra facets that have no area and declare a null (0 0 0) normal — exactly what CAD tessellators emit at a sliver. Slicers either drop them, warn, or divide by zero; this is how you find out which.
The same unit sphere at 16,128 triangles — level 0 of a four-step ladder that spans 202x from top to bottom. Because every level is generated analytically from the same surface rather than decimated, the ladder is an exact reference: any deviation you measure is your tool's, not the fixture's.
The same unit sphere at 3,968 triangles — level 1 of a four-step ladder that spans 202x from top to bottom. Because every level is generated analytically from the same surface rather than decimated, the ladder is an exact reference: any deviation you measure is your tool's, not the fixture's.
The same unit sphere at 960 triangles — level 2 of a four-step ladder that spans 202x from top to bottom. Because every level is generated analytically from the same surface rather than decimated, the ladder is an exact reference: any deviation you measure is your tool's, not the fixture's.
The same unit sphere at 80 triangles — level 3 of a four-step ladder that spans 202x from top to bottom. Because every level is generated analytically from the same surface rather than decimated, the ladder is an exact reference: any deviation you measure is your tool's, not the fixture's.
The coarsest level as plain-text OBJ — 80 triangles you can read end to end. Small enough to paste into a bug report, which is what makes it useful when a pipeline mangles winding or normals and you need the smallest reproducer.
The densest level of the ladder as a binary little-endian PLY — 8,320 vertices and 16,128 faces, for the mesh-processing tools (MeshLab, CloudCompare, Open3D) that speak PLY rather than glTF.
A low-poly chair — a seat, four legs, and a backrest — as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly coffee mug — a cylindrical body with a looped handle — as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly house — walls, a door, and a pitched roof — as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly robot — a stacked-box character with a head, arms, legs, and antenna — as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly tree — a trunk with three stacked conical layers — as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
The same sphere and the same brushed-metal material as the OBJ+MTL pair in this group, but as a single self-contained GLB. Convert the OBJ+MTL and diff against this to score an OBJ-to-glTF material converter.
Two open half-shells with identical geometry and opposite `doubleSided` flags. Because the shells are open you can see straight into them, which is the only way to tell backface culling from a lighting difference.
A rough red base under a full-strength, near-mirror clearcoat lobe — the two-layer material that car paint, lacquered wood and phone cases all need. The base and coat roughness differ by an order of magnitude, so a renderer that collapses the layers is obvious.
Emission pushed past the core spec's 0-1 emissiveFactor clamp by a 6x strength multiplier — the extension that exists because HDR bloom needs values core glTF cannot express. A tone-mapping and bloom-threshold fixture.
A sphere whose material opts out of lighting entirely via KHR_materials_unlit — the shading path used for baked scenes, maps and stylised art. Renders as a flat silhouette in a conformant viewer and as a lit ball in one that ignores the extension, which makes the difference obvious.
One mesh, two named material variants (Copper and Cobalt) selectable at runtime — the extension behind every product configurator that swaps a finish without reloading geometry. The primitive also carries a plain `material`, so viewers with no variant support still render something.
A sphere with the glTF core metallic-roughness material — full metal, low roughness, no textures, so the numbers in the JSON are the whole material. The baseline half of the metallic-roughness vs specular-glossiness twin.
Three identical spheres differing only in alphaMode, arranged left to right. The MASK sphere's base alpha (0.45) sits deliberately just under its 0.5 cutoff, so a correct renderer discards it entirely while a renderer that treats MASK as BLEND draws it semi-transparent.
The same metal expressed in the archived specular-glossiness model, carried in `extensions` with an equivalent metallic-roughness fallback and NOT listed in extensionsRequired. The correct shape for an asset that must keep loading in viewers which dropped specular-glossiness support.
The material library for the OBJ in this group, carrying both the original Phong fields and the de-facto PBR extensions (Pr roughness, Pm metallic, Ke emissive). The file that tells you whether an importer reads MTL's PBR additions or only its 1995 subset.
A smooth-shaded sphere as Wavefront OBJ with `mtllib`/`usemtl` pointing at a sibling MTL. Downloading the OBJ alone gives you the classic missing-material case; downloading both reproduces the glTF metallic-roughness twin in this group.
A 10 mm cube as 3MF — the modern OPC-packaged manufacturing format (a ZIP of model XML plus relationships). For testing 3MF readers and slicers.
A 10 mm cube as COLLADA (.dae) — the XML digital-asset-exchange format used across 3D tools and game engines. For testing COLLADA parsers and conversion.
A 10 mm cube as binary glTF (GLB) — the dominant modern format for 3D on the web and in AR, with per-face normals packed into one self-contained file. Powers the interactive 3D preview on this site; for testing glTF loaders and conversion.
A 10 mm cube as text glTF 2.0 — the JSON scene with its binary buffer embedded as a data URI, the human-readable sibling of the GLB. For testing glTF parsers and GLB↔glTF conversion.
A 10 mm cube as a Wavefront OBJ — plain-text vertices and triangular faces, the lingua franca of 3D asset exchange. For testing OBJ importers and conversion.
A 10 mm cube as OFF (Object File Format) — the minimal vertex/face text format from Geomview, common in computational geometry. For testing OFF parsers and conversion.
A 10 mm cube as ASCII PLY (Stanford polygon format) — plain-text vertex and face lists common in 3D scanning and research. For testing PLY parsers and conversion.
The same cube as binary little-endian PLY — the compact form of the Stanford polygon format. For testing binary-PLY readers.
A 10 mm cube as ASCII STL — human-readable facet/normal/vertex records. The most portable 3D-print mesh format; for testing STL parsers and slicers.
The same 10 mm cube as binary STL — an 80-byte header, a triangle count, and packed little-endian floats. Compact; for testing binary-STL readers.
A 10 mm cube as USDZ — Pixar's Universal Scene Description packaged as a stored zip, the format Apple uses for AR Quick Look. For testing USD/USDZ readers and conversion.
A 10 mm cube as VRML97 (.wrl) — the classic Virtual Reality Modeling Language scene format, ancestor of X3D. For testing VRML parsers and conversion.
A 10 mm cube as X3D — the XML successor to VRML for web and interchange 3D. For testing X3D parsers and VRML↔X3D conversion.
A morph target stored as a sparse accessor: only 25 of 289 vertices carry a delta, and the accessor has no bufferView at all, so every other vertex reads as zero. Sparse accessors are the least-implemented corner of the glTF spec and the usual cause of a target that appears to do nothing.
The two-target plane with an animation channel whose target path is `weights` — five keyframes, ten scalars, because a weights sampler stores one value per target per key. The case that breaks players which assume every channel output is a vec3 or a quaternion.
Eight POSITION morph targets on one primitive — bumps arranged around a circle, so every active weight is visible independently. Eight is where many real-time renderers stop supporting extra targets; this is the fixture that says whether yours does.
Morph targets that displace both positions and normals, with the first target already at weight 0.3 in the bind pose. Shading that stays flat while the surface ripples is the symptom of a loader that morphs positions and forgets the normal deltas.
A 16x16 plane with two POSITION morph targets — a sine ripple and a centre bulge — both at weight 0 in the bind pose. Drive the weights yourself to check that a loader adds the deltas to the base positions instead of replacing them.
The same two-target morph plane as readable glTF JSON, so the `targets` array, the mesh-level `weights` and the target accessors can be inspected without a hex editor.
JSON semantic reference for the 3DS tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-3ds-reference.
JSON semantic reference for the AMF tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-amf-reference.
JSON semantic reference for the DRC tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-drc-reference.
JSON semantic reference for the FBX tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-fbx-reference.
JSON semantic reference for the LWO tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-lwo-reference.
Real deterministic VOX source with four occupied voxel coordinates, palette indices, and unit occupied-coordinate bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-vox.
Real deterministic 3DS tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-3ds.
Real deterministic AMF tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-amf.
Real deterministic DRC tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-drc.
Real deterministic FBX tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-fbx.
Real deterministic LWO tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-lwo.
Real deterministic VTK tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-vtk.
JSON semantic reference for the VOX fixture, publishing occupied coordinates, palette indices, empty face topology, bounds, and the voxel contract. Stable P8 artifact p8-convert-model-vox-reference.
JSON semantic reference for the VTK tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-vtk-reference.
The same 1,200-point coloured sphere as a GLB using the POINTS primitive mode — for testing point-cloud rendering in glTF viewers.
A 1,200-point coloured point cloud arranged on a sphere via a Fibonacci lattice — a vertex-only PLY (no faces), the format scanners and LiDAR tools produce. Paired with a GLB (POINTS) twin, for testing point-cloud loaders.
Dense, noise-free point cloud sampled on the dome surface — the reconstruction target for scoring a photogrammetry / point-cloud-cleanup tool.
Dense, noise-free point cloud sampled on the orb surface — the reconstruction target for scoring a photogrammetry / point-cloud-cleanup tool.
Sparse, noisy scan of the same dome surface (700 points, σ=0.05) — a realistic reconstruction / denoise input to compare against the dense clean cloud.
Sparse, noisy scan of the same orb surface (700 points, σ=0.05) — a realistic reconstruction / denoise input to compare against the dense clean cloud.
Watertight box mesh — the intended result for a mesh-repair / hole-filling tool applied to the broken member of this group.
Watertight sphere mesh — the intended result for a mesh-repair / hole-filling tool applied to the broken member of this group.
Watertight tube mesh — the intended result for a mesh-repair / hole-filling tool applied to the broken member of this group.
Deliberately broken box mesh (missing top face) — feed to a mesh-repair tool and compare the result against the watertight ground truth.
Deliberately broken sphere mesh (open hole at the base) — feed to a mesh-repair tool and compare the result against the watertight ground truth.
Deliberately broken tube mesh (open, uncapped ends) — feed to a mesh-repair tool and compare the result against the watertight ground truth.
One box mesh referenced by a 24-deep chain of nodes, each adding a translation, an 11-degree rotation and a 0.94 scale, so the result spirals. Any error in matrix accumulation compounds visibly by the tip instead of hiding in rounding.
An 8x8 field of columns built from a single 12-triangle mesh referenced by 64 nodes with seeded random heights. Core-glTF instancing needs no extension: the file is tiny, and the interesting question is whether your renderer batches the 64 draws or issues them one by one.
Thirty-two copies of one cube expressed as instance attribute accessors on a single node under EXT_mesh_gpu_instancing — the extension that moves instancing off the scene graph and onto the GPU. A viewer without support shows exactly one cube at the origin, which is the tell.
Six cubes in a ring whose nodes carry a column-major 4x4 `matrix` and no translation/rotation/scale keys — the encoding a DCC exporter uses when a transform cannot be decomposed. Paired with a TRS twin of the identical ring.
Twelve nodes reference one sphere mesh, in three groups whose parents each apply a different rotation and scale. The fixture for importers that copy geometry per node: a correct import keeps one mesh resource with twelve transforms, a naive one produces twelve meshes.
Three named scenes over three meshes, with the asset's `scene` property pointing at index 1 rather than 0. Loaders that hardcode scene 0 show the wrong content and never report an error — this is the file that catches them.
The 24-level spiral as readable JSON, so the `children` arrays and per-level TRS can be traced by eye. Useful when a converter flattens or re-parents a hierarchy and you need to see exactly where.
The same six-cube ring with translation, quaternion rotation and scale spelled out per node. Read it next to the matrix twin to check a decomposition routine, or to confirm that your quaternion component order really is xyzw.
The three-scene asset as readable JSON, where the top-level `"scene": 1` is one line you can point at in a bug report. Also the fixture for round-tripping multi-scene assets through tools that keep only one scene.
A procedurally-built teapot — a surface-of-revolution body and lid with a stepped spout, a torus handle, and a knob — as a self-contained GLB. The classic teapot shape, for testing 3D loaders and the model viewer.
Binary buffer companion for the textured mini glTF (positions, UVs, indices).
Minimal textured glTF SAMPLE (external PNG + BIN) for glTF loaders and material tests.
MTL material SAMPLE pairing with the textured OBJ.
Wavefront OBJ textured quad SAMPLE with MTL reference.
64×64 albedo PNG companion for the textured mini glTF.
Tiny ASCII STL SAMPLE (corner) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (pyramid) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (slab) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (tetra) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (wedge) for mesh importer smoke tests.
A UV-mapped cube with an embedded 128×128 checkerboard PNG texture and a PBR material, all packed into one self-contained GLB. A fixture for testing texture and UV handling, embedded-image extraction, and PBR material loading.
Mesh metadata note SAMPLE #1 for 3D asset pipelines.
Mesh metadata note SAMPLE #2 for 3D asset pipelines.
Mesh metadata note SAMPLE #3 for 3D asset pipelines.
Mesh metadata note SAMPLE #4 for 3D asset pipelines.
Mesh metadata note SAMPLE #5 for 3D asset pipelines.
Mesh metadata note SAMPLE #6 for 3D asset pipelines.
The same signpost as COLLADA with `<up_axis>Y_UP</up_axis>` and `<unit meter="1" name="metre"/>` in its asset block. Unlike glTF, OBJ and STL, COLLADA states its convention — so an importer that still gets the orientation wrong has no excuse.
The same signpost as COLLADA with `<up_axis>Z_UP</up_axis>` and `<unit meter="1" name="metre"/>` in its asset block. Unlike glTF, OBJ and STL, COLLADA states its convention — so an importer that still gets the orientation wrong has no excuse.
A 1.12 m signpost with its coordinates written in centimetres — so this file's numbers read up to 112. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
A 1.12 m signpost with its coordinates written in metres — so this file's numbers read up to 1.12. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
A 1.12 m signpost with its coordinates written in millimetres — so this file's numbers read up to 1120. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
The signpost authored +Y up, which is what the glTF specification mandates and what every conformant viewer assumes. The conformant half of the axis pair: load it, confirm the post stands, and you have calibrated your viewer before testing the Z-up twin.
The same signpost authored +Z up — what a Blender or 3ds Max glTF export produces when the axis conversion is skipped. glTF has no field in which to declare this, so the file is indistinguishable from a model that genuinely lies on its back, and every conformant viewer will show it that way.
The same signpost as OBJ with coordinates in metres. OBJ has no unit record of any kind, so the two OBJ files in this group are byte-different and semantically identical — the ambiguity that every OBJ import dialog's scale box exists to resolve.
The same signpost as OBJ with coordinates in millimetres. OBJ has no unit record of any kind, so the two OBJ files in this group are byte-different and semantically identical — the ambiguity that every OBJ import dialog's scale box exists to resolve.
The signpost as ASCII PLY with +Y up. PLY has no axis or unit element, so the convention survives only as a header comment that no parser reads — the reason scan data so often arrives rotated.
The signpost as ASCII PLY with +Z up. PLY has no axis or unit element, so the convention survives only as a header comment that no parser reads — the reason scan data so often arrives rotated.
The signpost in millimetres as ASCII STL. STL has no unit field either, but every slicer assumes millimetres — which is why an STL exported in metres arrives as a 1 mm speck and one exported in inches arrives 25.4x too big.
The signpost as USDZ with `upAxis = "Y"` and `metersPerUnit = 1` in the stage metadata. USD is the only format in this group that declares BOTH the axis and the scale, which is exactly why it is the one AR pipelines standardised on.
The signpost as USDZ with `upAxis = "Z"` and `metersPerUnit = 1` in the stage metadata. USD is the only format in this group that declares BOTH the axis and the scale, which is exactly why it is the one AR pipelines standardised on.
A cube with a different colour at each of its eight vertices, interpolated across the faces (COLOR_0 attribute) — as a GLB. Paired with a PLY twin, for testing per-vertex colour handling.
The same per-vertex-coloured cube as ASCII PLY with red/green/blue vertex properties — the Stanford-format twin of the GLB, for testing PLY colour parsing.
One small, documented solid — a real 10 mm cube — so you convert against a known object. It ships as ASCII and binary STL, Wavefront OBJ, and a 3MF package, with a matching DXF line drawing and EPS vector illustration.
Yes — minimal well-formed STEP (AP214) and IGES samples are included specifically for testing header and entity parsing.
Yes — dense↔decimated GLB pairs, broken↔repaired mesh twins, and point-cloud PLY sets share group IDs so you can test decimation, mesh-repair, and point-cloud pipelines against a reference.
Every file states its geometry, units (millimetres for the cube), and internal structure in its spec, so you're testing a known mesh rather than a mystery file.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
