How to Analyze a 3D Model Online
What GLBKit's analyzer actually measures, which numbers are exact and which are estimated, and how to read vertex counts, memory estimates and bounds well enough to catch a broken asset.
What the analyzer measures
The analyzer answers questions about a file that are hard to answer by looking at it. How many triangles does this actually have? Is it one mesh or four hundred? Does it carry textures, and how big are they? Is there geometry out at the origin that will break my framing?
It reads the scene that the workspace has already loaded rather than parsing the file separately, so what it reports is what the importer actually produced. That matters: the report reflects the file as this toolchain sees it, including anything a loader normalised along the way. It also means there is nothing to analyze until a model is loaded. The same scene is what you see in the 3D model viewer, so you can read the numbers and inspect the model side by side.
Its most useful property is restraint. Metrics the format does not carry are reported as unavailable rather than filled in with a guess, so an empty section is information: STL genuinely has no materials.
| Group | Metrics |
|---|---|
| Geometry | Vertices, Triangles, Indices, Geometries, Meshes, Primitives |
| Rendering | Estimated Draw Calls, Material Groups, Instanced Meshes, Skinned Meshes |
| Materials | Materials, Unique Materials, Transparent Materials, Double-sided Materials |
| Textures | Textures, Unique Textures, Dimensions, Total Pixels, Estimated Texture Memory |
| Scene | Objects, Groups, Meshes, Bones, Lights, Cameras |
| Bounds | Width, Height, Depth, Bounding Sphere |
Two further groups sit alongside these. Memory reports estimated geometry, texture and total resource figures, and Animations lists clip names with durations.
Step by step
Open the 3D Model Analyzer
Load GLBKit's 3D Model Analyzer, or open the Analyzer tab in the workspace once a model is loaded.
Upload a model
Drag a file onto the drop zone or use Browse Files. Any format the viewer can open works: .glb, .gltf, .obj, .fbx, .stl, .ply, .pcd, .usd, .usda, .usdc, .usdz, .zip, .3mf, .dae, .x3d, .vrm, .off, .wrl, .vrml, .las, .laz, .step, .stp, .3ds, .x. A .zip is unpacked and its first supported model analyzed.
Wait for the report
The analyzer reads the loaded scene, so it measures what the importer produced rather than parsing the file separately. Nothing is transmitted — the report is built in your browser.
Read the Geometry and Rendering groups
Vertices, Triangles, Indices, Geometries, Meshes and Primitives describe the mesh, while Estimated Draw Calls, Material Groups, Instanced Meshes and Skinned Meshes describe how it will be drawn.
Check materials, textures and memory
The Materials and Textures groups cover counts and per-texture dimensions. The Memory group adds estimated geometry, texture and total resource footprints.
Verify the bounds and hierarchy
Bounds reports width, height, depth and bounding sphere in model units, and Scene Hierarchy lists the node tree. A bounding box far larger than the visible object usually means stray geometry.
Reading the geometry numbers
Geometry and Rendering answer different questions. Geometry is how much there is; Rendering is how many times the GPU has to be asked for it.
| Metric | What it counts |
|---|---|
| Vertices | Unique vertex positions across the scene. |
| Triangles | Rendered faces. The main geometry budget figure. |
| Indices | Index buffer entries used to address vertices. |
| Geometries | Distinct geometry objects, which may be shared. |
| Meshes | Renderable mesh nodes in the scene graph. |
| Primitives | Estimated draw units within those meshes. |
| Estimated Draw Calls | Expected draw calls the scene will issue. A scene-structure cost, not a geometry cost. |
| Material Groups | Batches separated by differing materials. |
| Instanced Meshes | Meshes drawn repeatedly from one definition. |
| Skinned Meshes | Meshes deformed by a skeleton. |
Why mesh count matters more than you expect
A thousand triangles in a single mesh is cheap. A thousand triangles spread across a thousand meshes is not, because each mesh becomes a draw call with its own state changes. When an asset feels heavier than its triangle count suggests, the mesh and material group counts are where the answer usually is.
Instanced and skinned meshes
Instanced meshes are drawn many times from one definition, which is how repeated geometry stays affordable; a low instanced count on an asset full of identical parts usually means the duplication was baked in instead. Skinned meshes are deformed by a skeleton, and their count tells you whether animation is actually rigged.
Materials and textures
The Materials group separates how many materials exist from how many are actually distinct, which is the number that affects batching.
| Metric | What it tells you |
|---|---|
| Materials | Material slots referenced by the scene. |
| Unique Materials | Distinct materials after deduplication. This is the one that costs draw calls. |
| Transparent Materials | Materials using alpha blending, which needs sorting and costs more fill rate than opaque rendering. |
| Double-sided Materials | Materials rendered from both faces, so back faces are drawn as well instead of being culled. |
| Textures | Image references across all materials. |
| Unique Textures | Distinct images after deduplication. |
| Dimensions | Pixel width and height of each texture, listed by name. |
| Total Pixels | Summed pixel count across textures. |
| Estimated Texture Memory | Calculated from pixel dimensions and channel count. |
The Dimensions list is the most actionable item in the whole report. A single 4096 × 4096 texture holds as many pixels as 64 textures of 512 × 512, and finding it by name tells you exactly which image to downscale.
Memory estimates
The Memory group gives three figures: estimated geometry memory, estimated texture memory, and estimated total resource memory. All three are calculated rather than observed, and GLBKit marks them accordingly.
The full list of estimated values in the report is: Primitives, Estimated Draw Calls, Estimated Texture Memory, Estimated Geometry Memory, Estimated Total Resource Memory, Duration. Treating them as planning figures rather than measurements keeps them useful. Comparing two assets with the same method gives a reliable relative answer. Quoting a single number as a device budget does not, because the real footprint depends on texture compression, mip mapping and how the driver stores the data.
For a worked example of how texture size turns into memory on a real GPU, see the large-model section of How to Use a 3D Model Viewer.
Bounds and scene hierarchy
Bounds reports Width, Height, Depth and Bounding Sphere in the model's own units, to three decimal places. It is the quiet hero of the panel because it catches a specific, common and easily-missed failure.
A model with one stray vertex parked at the origin has a bounding box that spans the distance between the object and that vertex — often many times the model's actual size. Nothing looks wrong in the viewport until you recenter, at which point the model is a speck in the middle of an enormous empty frame. Toggling Bounding Box in the top-right toolbar shows the problem directly.
Scene Hierarchy lists the node tree with a type badge on each entry, which is where you find out whether an asset has a sensible structure or a hundred empty transforms left over from an export.
Animation is counted, not profiled
The report includes an animation count with each clip's name and duration. That is enough to catch the common problem — an asset that was supposed to animate but arrived with zero clips, for example because the exporter skipped animation or the format never carried it.
Clip duration is worth reading on its own. An animation of zero seconds means the clip has no keyframes or only a single pose, which often points to a broken export rather than an intentionally empty track. For anything more specific — keyframe counts, interpolation types — you need a dedicated rig tool. What the analyzer gives you here is presence and length, which answers "did the animation survive the round trip at all".
Formats without some of the data
GLBKit opens 25 extensions and the analyzer reports on the scene each one produces. Not every format carries every category of data, and the report says so rather than estimating.
| Format | Available | Unavailable |
|---|---|---|
| STL, OFF | Geometry, indices, bounds | Materials, textures, animation, hierarchy |
| PLY mesh | Geometry, vertex colours, bounds | Image textures, materials |
| PLY point cloud | Point positions, colours | Triangles, surfaces |
| PCD, LAS, LAZ | Point data, colours, bounds | Triangles, materials, textures |
| STEP, STP | Tessellated geometry, CAD colours, bounds | Original B-Rep surfaces, textures |
| OBJ | Geometry, plus materials and textures when the .mtl and images are bundled in a zip | Materials and textures if the companion files are missing |
| 3MF | Geometry, colours, bounds | Image textures (GLBKit does not read them from 3MF) |
| GLB, GLTF, FBX | Full report | Nothing, if the file is complete and any companion files are bundled in a zip |
To look at one of these files before analyzing it, each has its own viewer: OBJ, STL, PLY, 3MF, OFF, PCD, LAS, LAZ, STEP.
Using the report to make a decision
The report is useful because it supports comparisons and budgets, not because any single number is a verdict.
Checking an export went wrong
Compare the file against what you exported. A material count of zero on a model that should have materials, or a mesh count far below the source, points at the export step. Bounds catches geometry that escaped during processing. This is the analyzer's most reliable use, because a bad export is unambiguous when you have the original numbers to compare with.
Deciding whether to optimise
Look at texture dimensions first, then unique materials and mesh count, then triangles. Optimisation effort pays off most where the numbers are disproportionate — a 4096px texture on a small prop, or four hundred identical one-triangle meshes that should be instanced.
When the numbers point to a problem, glTF Transform and gltfpack handle most of the fixes, and the Khronos glTF Validator confirms the result is still a valid file. If a leaner format is the answer, see How to Convert 3D Models or open the 3D model converter.
Before capturing a screenshot
Bounds decides framing. A healthy bounding box means Recentering will frame the object properly; a broken one means every capture comes out small and off-centre. Once the bounds look right, the 3D Model Screenshot tool is the next step.
FAQ
What is the difference between an exact and an estimated metric?
Exact metrics are read directly from the loaded scene — vertex and triangle counts, mesh counts, material counts, bounds. Estimated metrics are calculated rather than observed, and GLBKit labels them: Primitives, Estimated Draw Calls, Estimated Texture Memory, Estimated Geometry Memory, Estimated Total Resource Memory, Duration. An estimate is a useful planning figure, not a measurement.
Why does my STL report no materials?
Because STL stores geometry only — triangles and normals, with no material or texture fields at all. The analyzer reports what the file contains rather than inventing values, so those metrics are genuinely unavailable. Convert to GLB or 3MF if you need appearance data.
What counts as a high triangle count?
It depends on the use. A hero asset seen close up can justify hundreds of thousands of triangles, while a background prop with the same count is wasteful. The number only means something next to the platform target and the asset's screen size.
What is Estimated Draw Calls telling me?
How many separate render passes the scene is likely to need. A model with 300 meshes produces far more draw calls than one with 3 at the same triangle count, and that overhead matters more than geometry on most real-time platforms. It is an estimate derived from scene structure, not a captured GPU counter.
How accurate are the memory estimates?
They are calculated from geometry and texture dimensions rather than read from a profiler, so treat them as planning figures — useful for comparing two assets, not for capacity planning on a specific device. The exact byte size depends on how the texture is compressed and resident on the GPU.
What does a very large bounding box mean?
Almost always stray geometry — a single vertex left at the origin or far from the model, a failed boolean, or a leftover from a previous export. It matters because recentering frames the bounding box rather than the object, so the model appears small and off-centre in screenshots. Toggle the Bounding Box control in the top-right toolbar to see it.
Can I analyze a point cloud?
Yes. Point cloud formats such as PCD, LAS, LAZ and point-cloud PLY load through the same importers, and the report reflects points rather than surfaces. Metrics that require triangles are unavailable for those files rather than approximated.
Does the analyzer tell me whether a model will run at 60fps?
No, and no static analysis can. It gives you the inputs — geometry density, draw call estimate, material and texture counts, memory footprint — but real-time performance also depends on the target hardware, the other assets in the scene and the shaders being used.
Related guides
Open the 3D Model Analyzer
Load a model and get counts for geometry, materials, textures, scene structure and bounds, plus estimated memory. Files up to 150 MB, processed in your browser.