Convert OBJ to GLB — Web3D & AR Ready, No Upload

They're the same format — glTF is the spec, GLB is the packaging. A .gltf file is human-readable JSON plus separate .bin (geometry) and texture files, sometimes 5-10 files for one model. A .glb file packs everything into a single binary container. For production, GLB wins every time: one HTTP request instead of many, no broken texture paths, no CORS headaches serving separate files. The only reason to use .gltf is debugging — you can open it in a text editor and read the scene graph. This converter outputs GLB because that's what you actually deploy.

Partially, and it's worth understanding what changes. OBJ uses the old Phong/Blinn shading model (.mtl file). GLB uses physically-based rendering (PBR metallic-roughness). The converter maps diffuse color (Kd) to baseColorFactor, diffuse texture (map_Kd) to baseColorTexture, and approximates specular (Ks) as roughness. What gets lost: specular maps, bump maps are approximated as normal maps (not identical), and ambient occlusion doesn't have a direct MTL equivalent. If your OBJ has a simple color or diffuse texture, the GLB will look nearly identical. If it relies on complex Phong specular highlights, you'll want to tweak the PBR parameters in Blender or gltf.report after conversion.

Yes — import GLTFLoader from three/addons, call loader.load("model.glb", callback), and add the scene to your Three.js scene. But here's the gotcha that trips up every beginner: the model looks flat gray or washed out. That's because PBR materials need proper lighting to look right. At minimum, add a DirectionalLight and an AmbientLight. For realistic results, use an environment map: new RGBELoader().load("studio.hdr", (texture) => { scene.environment = texture; }). The environment map provides reflections and ambient lighting that PBR materials are designed for. Without it, metallic surfaces look like matte plastic.

Almost always lighting, occasionally tone mapping. Blender's viewport uses its own HDRI for lighting and applies filmic color management. Your Three.js scene probably has basic lights and linear tone mapping. Fix: (1) Add an environment map to your Three.js scene (scene.environment = hdrTexture). (2) Set renderer.toneMapping = THREE.ACESFilmicToneMapping and renderer.toneMappingExposure = 1.0 — this matches Blender's filmic look. (3) Set renderer.outputColorSpace = THREE.SRGBColorSpace. After these three changes, the visual match is usually within 5%. If metallic surfaces still look wrong, check that roughness values transferred correctly — open the GLB in gltf.report to inspect material parameters.

Upload a ZIP file containing your .obj, .mtl, and all texture images (PNG/JPG). The converter reads the .mtl file to find texture references and embeds them into the GLB. Important: the texture filenames in the .mtl must match the actual files exactly (case-sensitive). If your .mtl says "map_Kd wood_diffuse.png" but the file is named "Wood_Diffuse.PNG", it won't be found. Common fix: open the .mtl in a text editor, check the map_Kd/map_Ks/bump lines, and rename files to match. If you're exporting from Blender, use "Copy" path mode in the OBJ export dialog to bundle textures.

Google's model-viewer web component. Add one script tag and one HTML element: <script type="module" src="https://ajax.googleapis.com/ajax/libs/model-viewer/3.5.0/model-viewer.min.js"></script> then <model-viewer src="model.glb" alt="3D model" auto-rotate camera-controls shadow-intensity="1" style="width:100%;height:400px"></model-viewer>. For AR on mobile, add the attributes ar ar-modes="webxr scene-viewer quick-look" — this enables AR preview on both iOS (Quick Look) and Android (Scene Viewer) with zero additional code. For e-commerce, add poster="preview.webp" so users see a static image while the 3D model loads.

Under 5 MB for most use cases. A 1 MB GLB loads in ~0.4s on a typical broadband connection; 5 MB takes ~2s; 15 MB and you're losing mobile users. The biggest contributor to file size is usually textures, not geometry. A 100K-triangle mesh is only ~2 MB of geometry, but a single 4096x4096 PNG texture can be 15+ MB uncompressed. Optimization checklist: (1) Resize textures to 1024x1024 or 2048x2048 max, (2) Use JPEG or WebP instead of PNG for photos (the converter embeds the original format), (3) Apply Draco compression with gltf-transform: npx @gltf-transform/cli optimize input.glb output.glb --compress draco — this typically reduces geometry size by 60-80%. After all optimizations, most product visualization GLBs land at 1-3 MB.