Resource usage comparison

Resource usage comparison

objtools moves geometry off the heap to a memory-mapped disk workspace. That tradeoff matters most when a mesh's working data would consume too much RAM in an importer that retains it in memory. Existing PNG/JPEG textures can also be transferred without decoding all their pixels. Image conversion has a different memory cost; see Images.

The examples below illustrate those tradeoffs against obj2gltf and Blender for conversion, and glTF Transform and TexMetro for inspection. They are four synthetic workloads on one workstation, with one recorded run per configuration. They are not a neutral benchmark or a general speed ranking. The methodology explains the choices, commands and shortcuts.

The samples

Each OBJ is a connected triangle grid in one object, with explicit normals. The two texture cases have the same total image pixel count. Solid-color PNGs keep the input files small while exercising large decoded dimensions.

Sample	Source positions / triangles	Textures	OBJ size
Small, untextured	10,000 / 19,602	None	0.57 MiB
Large, untextured	10,000,000 / 19,987,002	None	787 MiB
One large texture	99,856 / 198,450	One 16k × 16k PNG	11.7 MiB
Several large textures	99,856 / 198,450	Four 8k × 8k PNGs, four materials	11.7 MiB

They do not represent complex scans, UV seams, many-object scenes or expensive triangulation.

Converting OBJ to glTF

Each completed run writes glTF JSON, an external geometry buffer and external images. Cells show peak process RSS / elapsed time, rounded deliberately. See the methodology for measurement limits and export settings.

Sample	objtools	obj2gltf 3.2.0	Blender 5.2.1
Small, untextured	12 MiB / ~0.1 s	147 MiB / 1.0 s	364 MiB / 2.9 s
Large, untextured	500 MiB / 22 s	1.7 GiB / 63 s	Failed at 8 GiB RSS guard
One large texture	12 MiB / 0.3 s	195 MiB / 1.2 s	1.5 GiB / 5.6 s
Several large textures	12 MiB / 0.7 s	189 MiB / 2.4 s	1.5 GiB / 11 s

For the texture cases, objtools and obj2gltf kept their existing PNGs without a forced re-encode in these runs; Blender's path used substantially more memory. This does not predict the result when objtools must decode and convert an image.

An input larger than the allowed memory

Couldn't be reliable compared across software. Due to kernel's management of memory-mapped pages, exact heap requirements couldn't be computed from usage.

Inspecting models

The commands answer different questions, so the comparison is limited to processing time and memory usage. Neither comparison establishes the relative speed of equivalent algorithms.

Sample	objtools inspect	glTF Transform 4.5.0 inspect	TexMetro full analysis
Small, untextured	12 MiB / ~0.1 s	130 MiB / 0.4 s	—
Large, untextured	12 MiB / ~0.1 s	1.0 GiB / 10 s	—
One large texture	42 MiB / 0.7 s	131 MiB / 0.6 s	4.2 GiB / 19 s
Several large textures	40 MiB / 0.8 s	131 MiB / 1.0 s	1.5 GiB / 19 s

objtools and glTF Transform inspect the same objtools-generated glTF, so these times exclude OBJ import. TexMetro reads the original textured OBJ and runs its full analysis. Its rows use a source-linked local build with Qt's image allocation limit raised to accept the 16k image.

Methodology, scripts and caveats · How it works