OBJ naar GLB omzetten

Geen browser leest OBJ, en geen enkele leest GLB van huis uit — een .glb waar je rechtstreeks naartoe navigeert wordt gedownload in plaats van getoond. Wat verschilt is het bibliotheekecosysteem. three.js, Babylon.js en het model-viewer-webcomponent nemen allemaal een GLB als hun primaire invoer en laden die in één keer, terwijl OBJ-ondersteuning een zijladen is dat ook de MTL en elke textuur als aparte verzoeken nodig heeft.

De praktische vraag is dus niet welk formaat de browser begrijpt, maar welk formaat de runtime die je gaat opnemen verwacht. Voor alles gepubliceerd na 2018 is dat antwoord GLB, en voor een productpagina waar het model de inhoud is, is vier of vijf verzoeken tot één inkorten een meetbaar verschil op een telefoon.

Een OBJ-bestand bevat zelf geen materialen. Het heeft een mtllib-regel die een .mtl ernaast noemt en usemtl-regels die tussen de items in dat bestand wisselen, en de .mtl draagt de diffuse kleur, de spiegelwaarden en de paden naar de textuurafbeeldingen. Deze converter leest v-, o-, g- en f-regels en negeert de rest.

Het gevolg is ondubbelzinnig en de moeite waard om rekening mee te houden: je GLB bevat geometrie en groepsnamen, en je viewer tekent het in wat voor standaardmateriaal hij ook heeft. Moest het model met zijn texturen getoond worden, dan is de route Blender — importeer de OBJ met zijn MTL, exporteer daarna glTF Binary, wat de afbeeldingen in de GLB verpakt. Deze pagina is voor het geval waarin de vorm de opgeleverde zaak is.

Een binaire glTF 2.0: een header van twaalf bytes, een JSON-blok met spaties opgevuld tot een grens van vier bytes, dan een binair blok opgevuld met nullen. Binnen de JSON: één mesh per OBJ-groep, één node per mesh, één scène die ze allemaal opsomt, een assetversie van 2.0, en per mesh een float32 VEC3-positieaccessor en een uint32 SCALAR-indexaccessor.

Elke positieaccessor draagt min en max. Dat is een specificatie-eis en het is ook het praktische verschil tussen een model dat verschijnt bij het laden en een dat dat niet doet — model-viewer en three.js leiden allebei de aanvangscameraafstand af van die grenzen, en bestanden zonder die grenzen zijn een gangbare oorzaak van een schijnbaar lege scène.

De lezer start een nieuwe groep bij elke o- of g-regel en de schrijver geeft één glTF-mesh per groep, elk in zijn eigen node met zijn eigen primitive. Een OBJ geëxporteerd uit CAD met een groep per vlakstuk kan honderden groepen dragen, en de GLB zal trouw honderden meshes bevatten.

Op een pagina is dat een echte kostenpost. Elke primitive is een aparte draw call en een aparte GPU-bufferbinding, en een paar honderd daarvan op een middenklassetelefoon is waar de beeldsnelheid instort. Objecten samenvoegen in Blender voordat je de OBJ exporteert, of de g-regels wegstrepen met een teksteditor als de groepen niets betekenen, is een fix van twee minuten die meer waard is dan de meeste dingen die erna gebeuren.

Er wordt geen NORMAL-attribuut geschreven. De glTF-specificatie is duidelijk over wat een viewer dan moet doen: vlakke gezichtsnormalen berekenen. Dus een bol die glad oogde in je modelleersoftware toont in de browser elke driehoek als apart facet, wat als een bewuste low-poly-stijl overkomt en dat meestal niet is.

Er zijn twee schone oplossingen. In three.js roep je computeVertexNormals aan op de geladen geometrie, wat de gezichtsnormalen per vertex middelt en vereist dat de mesh netjes aan elkaar zit — wat het geval is, want posities worden tijdens de omzetting samengevoegd op zes decimalen. Of doe de normalenpas stroomopwaarts in Blender en exporteer daar glTF vandaan, wat ook de materialen meebrengt.

glTF legt beide vast. Het is rechtshandig, Y-omhoog, en zijn lineaire eenheid is de meter. OBJ legt geen van beide vast: het is een lijst getallen zonder kop, zonder eenheid en zonder asconventie, en elke toepassing die er een schrijft heeft zijn eigen gewoonte.

Er wordt hier geen omzetting toegepast, dus een Z-omhoog-OBJ levert een GLB op wiens model op zijn rug ligt, en een in centimeters ontworpen OBJ levert er een op die tweehonderd meter hoog is. Beide zijn triviaal te herstellen zodra je weet welke je hebt — een rotatie van min negentig graden om X, en een uniforme schaal — en beide zijn onzichtbaar tot je het bestand laadt. De begrenzingsbox tegen een bekende afmeting afzetten is de snelste diagnose.

Vlakken met meer dan drie hoeken worden waaiervormig gedriehoekt vanaf de eerste hoek, wat correct is voor de convexe vierhoeken en n-hoeken die deze bestanden normaal bevatten en overlappende driehoeken kan geven bij een concaaf vlak. Negatieve vlakindexen, die terugtellen vanaf de meest recente vertex, worden opgelost terwijl het bestand wordt gelezen in plaats van achteraf, omdat hun betekenis afhangt van de positie in het bestand.

Posities worden dan samengevoegd: gematcht op zes decimalen, dus een coördinaat die in twintig driehoeken voorkomt wordt eenmaal opgeslagen en twintig keer aangehaald. Dat verkleint zowel de buffer als geeft de browser een mesh met echte samenhang, wat is wat computeVertexNormals gladde belichting laat opleveren in plaats van hetzelfde vlakke resultaat.

Twaalf bytes per vertex voor posities en twaalf bytes per driehoek voor indexen, plus een kleine JSON-header. Een model van 200.000 driehoeken met 100.000 vertices is dus rond de 3,6 MB, en niets daarvan is gecomprimeerd. Indexen zijn uitzonderingsloos uint32, wat vier bytes kost waar twee zouden volstaan onder 65.535 vertices en een voorwaarde vermijdt die stilletjes op een drempel van gedrag verandert.

Is dat getal te groot voor de pagina, dan liggen de antwoorden stroomopwaarts en stroomafwaarts, niet hier: decimeer de mesh eerst in Blender of MeshLab, en draai daarna gltf-transform voor Draco- of meshopt-compressie — met in het achterhoofd dat beide vereisen dat de browser een bijpassende decoder laadt, wat op een pagina die één model toont een eigen kostenpost is.

Als het model zijn texturen nodig heeft, converteer dan via Blender zodat de MTL en zijn afbeeldingen meekomen. Als het model een half miljoen driehoeken heeft, decimeer voor het omzetten in plaats van het te versturen en te hopen. Moet het glad ogen, regel normalen dan in de viewer of in de exporteur, want deze route levert er geen.

Waar deze pagina wel goed voor is, is het eerlijke middengeval: een schone OBJ van een onderdeel, een prop of een scan die op een pagina moet verschijnen als vorm, in één bestand, zonder het model naar iemand te uploaden. Die omzetting draait volledig in je browser, zonder engine om te downloaden en met een plafond van 100 MB, en levert een bestand op dat elke huidige webviewer aankan.