Bijgewerkt 13 september 2026
Wat een 3D-conversie behoudt en wat het kost
Het converteren van een mesh is niet gratis en is geen verliesloze operatie. GLB en glTF bewaren alles. OBJ bewaart de afzonderlijke objecten en hun materiaelnamen, maar verwerpt de vertexkleur. STL bewaart alleen de driehoeken. PLY bewaart de vertexkleur, maar maakt de scène plat tot één enkele mesh. USDZ bewaarde de twee objecten en de UV's, verloor de vertexkleur en materiaelnamen bij het opnieuw inlezen, en schrijft een zip van USDA. De onderstaande cijfers zijn gemeten, niet geschat.
Elke cijfer op deze pagina komt van het uitvoeren van dezelfde converter die deze site gebruikt, met echte bestanden, en van het direct lezen van de attributen uit de bytes die het schreef. Gemeten met 13 september 2026 met three.js r179. De methode staat aan het eind van de pagina en het script staat in de repository.
Wat behoudt elk formaat?#
Een referentiescène met twee kubussen met verschillende namen, elk met hun eigen metalen materiaal met naam, vertexkleur, UV-coördinaten en normals, werd omgezet naar de zes bestemmingen. GLB en glTF kwamen volledig terug. Alle andere formaten verloren iets, en elk verloor iets anders.
| Bestemming | Twee objecten | UV-coördinaten | Kleur per vertex | Materiaalnamen | Aantal vertices |
|---|---|---|---|---|---|
| GLB | Worden bewaard 2 | Wordt bewaard | Wordt bewaard | Wordt bewaard | 48 vertices |
| glTF | Worden bewaard 2 | Wordt bewaard | Wordt bewaard | Wordt bewaard | 48 vertices |
| OBJ | Worden bewaard 2 | Wordt bewaard | Verloren | Wordt bewaard | 72 vertices |
| STL | Samengevoegd in 1 | Verloren | Verloren | Verloren | 72 vertices |
| PLY | Samengevoegd in 1 | Wordt bewaard | Wordt bewaard | Verloren | 48 vertices |
| USDZ | Worden bewaard 2 | Wordt bewaard | Verloren | Verloren | 72 vertices |
Waarom voegen STL en PLY een scène samen tot één enkel mesh?#
Geen van beide formaten heeft een scenesgrafiek. GLB, glTF en OBJ kunnen meerdere benoemde objecten in één bestand beschrijven; STL beschrijft één enkel solide en PLY één enkele lijst van elementen, dus de twee kubussen komen aan als één enkel mesh en er is geen manier om ze weer te scheiden.
Het is het verlies dat het meest verrast, omdat het niet zichtbaar is. Het geconverteerde model ziet er identiek uit in een viewer. Pas wanneer je probeert te selecteren, het materiaal te wijzigen of een van de onderdelen te animeren, ontdek je dat de onderdelen niet meer bestaan.
Als het model scheidbaar moet blijven, moet de bestemming GLB, glTF of OBJ zijn. Als het naar een laminator of een enkele-materialenprint gaat, kost de fusie niets.
Hoeveel groeit het bestand?#
Meer dan de meesten verwachten. In een echt gegenereerd mesh, nam de OBJ 5,6 keer zoveel ruimte in als de oorspronkelijke GLB, en de PLY 1,4 keer. Beide bevatten dezelfde geometrie.
| Conversie | Bron | Resultaat | Verhouding | Geschreven vertices |
|---|---|---|---|---|
| mug.glb a GLB | 880 KB | 1.173 KB | 1,3x | 25.000 |
| mug.glb a glTF | 880 KB | 1.564 KB | 1,8x | 25.000 |
| mug.glb a OBJ | 880 KB | 4.928 KB | 5,6x | 150.000 |
| mug.glb a STL | 880 KB | 2.441 KB | 2,8x | 150.000 |
| mug.glb a PLY | 880 KB | 1.221 KB | 1,4x | 25.000 |
| mug.glb a USDZ | 880 KB | 2.927 KB | 3,3x | 150.000 |
| lion.glb a GLB | 8.768 KB | 11.690 KB | 1,3x | 249.369 |
| lion.glb a glTF | 8.768 KB | 15.587 KB | 1,8x | 249.369 |
| lion.glb a OBJ | 8.768 KB | 51.880 KB | 5,9x | 1.496.202 |
| lion.glb a STL | 8.768 KB | 24.352 KB | 2,8x | 1.496.202 |
| lion.glb a PLY | 8.768 KB | 12.176 KB | 1,4x | 249.369 |
| lion.glb a USDZ | 8.768 KB | 30.487 KB | 3,5x | 1.496.202 |
Waarom vermenigvuldigen OBJ en STL het aantal vertices?#
Omdat geen van beide hoekpunten deelt tussen driehoeken. Een goed geïndexeerd mesh slaat elke hoek slechts één keer op en verwijst ernaar vanuit alle driehoeken die eraan raken; OBJ en STL, zoals hier geschreven, slaan de drie hoeken van elk driehoek afzonderlijk op. In de test met lion.glb, dat veranderde 249.369 hoekpunten in 1.496.202, ongeveer 6 keer meer.
De geometrie verandert niet. Hetzelfde oppervlak, dezelfde driehoeken, dezelfde silhouet; alleen de boekhouding kost meer, en het bestand groeit min of meer in dezelfde verhouding.
PLY is het nuttige tegenvoorbeeld. Het behoudt de index, dus hetzelfde mesh wordt geschreven met een grootte die dicht bij het origineel ligt en blijft de kleur per vertex behouden. Voor een groot mesh waarbij alleen de geometrie behouden hoeft te worden, is PLY de goedkoopste eerlijke bestemming van deze lijst.
De tekst tegenover het binaire maakt het erger. glTF is JSON met de buffers gecodeerd in base64, wat ongeveer één 33 procent meer kost dan de identieke GLB, omdat base64 elke drie bytes in vier omzet.
Waarom groeide het bestand zelfs bij de conversie van GLB naar GLB?#
Omdat de converter de vertexnormaal van elk mesh berekent dat zonder deze aankomt en ze daarna opslaat. Een gegenereerd mesh heeft vaak geen normale-attribuut, dus de heen- en terugreis voegt een extra vector per vertex toe.
De test met mug.glb is een duidelijk voorbeeld: ze komen binnen 880 KB en gaan eruit 1.173 KB, zonder enige wijziging in de geometrie. De toegevoegde normaalwaarden zijn het verschil.
Het is een bewuste keuze, geen defect. Een mesh zonder normaalwaarden ziet er vlak en faceted uit in de meeste viewers, dus de converter berekent ze eenmaal bij het laden in plaats van dat elke vervolgtool ze moet raden.
Verandert de conversie de vorm?#
Nee. Elke bestemming werd geconverteerd en daarna opnieuw gelezen, en het oppervlak kwam identiek terug: hetzelfde aantal driehoeken en hetzelfde totale oppervlakte, tot de meetgrens, in een mesh van 498.734 driehoeken. Geometrie is het deel van een 3D-bestand dat intact blijft bij conversie.
| Bestemming | Driehoeken daarna | Oppervlaktefout | Hoe coördinaten worden opgeslagen |
|---|---|---|---|
| GLB | geen veranderingen | 0% | float32 binair |
| glTF | geen veranderingen | 0% | Base64-buffer |
| OBJ | geen veranderingen | 0% | tekst met 17 decimalen |
| STL | geen veranderingen | 0% | float32 binair |
| PLY | geen veranderingen | 0% | float32 binair |
| USDZ | geen veranderingen | 0% | USDA-zip |
Dus, verliest 3D-conversie gegevens of niet?#
Beide, en het onderscheid is wat nuttig is. Geometrie verliest niets: de vorm die erin gaat, is de vorm die eruit komt. Alles wat de geometrie omringt gaat wel verloren, en welke delen je verliest hangt volledig af van de gekozen bestemming.
Hier verknippert niets de coördinaten. GLB, STL en PLY schrijven binaire floats van 32 bits. glTF sluit dezelfde binaire buffer in als base64 binnen zijn JSON. USDZ schrijft een zip van USDA. OBJ is de enige die de posities als decimale tekst schrijft, en schrijft ze met volledige precisie in plaats van ze af te ronden, wat een deel van de reden is waarom zijn bestanden veel groter zijn.
Dat betekent dat de gebruikelijke zorg, dat elke conversie het model een beetje degradeert, zoals het opnieuw opslaan van een JPEG, niet van toepassing is. Converteren van GLB naar OBJ en terug versoepelt het netwerk niet.
Wat het wel doet, is negeren wat hoger op deze pagina verschijnt: de scènesgrafiek in STL en PLY, de kleur per vertex in OBJ, STL en USDZ, de materiaalaanduidingen in STL, PLY en USDZ, en de UV's in STL. Die verliezen zijn permanent, in de zin dat opnieuw converteren ze niet opnieuw kan verzinnen.
Welk doel moet je kiezen?#
Kies het doel op basis van wat moet overleven, niet op basis van de extensie die de ontvangende tool als eerste op zijn lijst zet. Dit zijn de verdedigbare keuzes op basis van wat hierboven is gemeten.
| Als je nodig hebt | Kies | Waarom |
|---|---|---|
| Alles behouden, in één bestand | GLB | De enige bestemming die de scènegrafiek, materiaarnamen, UV's en vertexkleur samenhield, met de kleinste grootte van de volledige formaten. |
| Alles bewaard, leesbaar door een persoon | glTF | Dezelfde inhoud als GLB, ongeveer een 33 procent groter omdat de buffers in base64 binnen de JSON worden geplaatst. |
| Apart benoemde objecten in een desktopprogramma | OBJ | Bevond beide objecten en beide materiaarnamen. Negeert de vertexkleur en schrijft het grootste bestand van de zes. |
| 3D-printen | STL | Driehoeken en niets anders, wat alles is wat een slicer leest. De kleinste van de bestemmingen die geen glTF zijn in een echt mesh. |
| Geometrie en vertexkleur, met weinig gewicht | PLY | De enige bestemming die geen glTF is die de kleur per vertex heeft behouden, en de index behoudt, dus blijft het dicht bij de oorspronkelijke grootte. |
| Quick Look van Apple / AR op iPhone | USDZ | Behield de twee objecten en de UV's in de referentiescène. Verloor de kleur per vertex en de materiaalnamen bij het opnieuw inlezen. Een zip van USDA die een telefoon kan openen. |
Wat deze formaten definieert#
De bovenstaande metingen zijn van ons; wat elk formaat kan bevatten, beslissen wij niet. Dit zijn de specificaties en de formatreferenties die dat bepalen, zodat wat op deze pagina staat gecontroleerd kan worden bij de bron in plaats van het zomaar te geloven.
- Specificatie van glTF 2.0The Khronos Group
Definieer de scenegrafiek, de materialen en de accessoires die GLB en glTF dragen, en leg uit waarom ze de enige bestemmingen waren die hier intact overleefden.
- Mediumtype model/gltf-binaryIANA
Het geregistreerde type voor GLB, de binaire container die hierboven is gemeten.
- Mediumtype model/stlIANA
STL zoals geregistreerd: driehoeken en vlaknormaal, zonder enig veld voor kleur, UV, materialen of objectnamen.
- Het Wavefront OBJ-bestandsformaatPaul Bourke
De standaardreferentie voor OBJ, dat geen eigen veld voor vertexkleur heeft, overeenkomend met wat de conversie heeft weggegooid.
- Het PLY-polygonenbestandsformaatPaul Bourke
Documenteer de eigenschappen per vertex, inclusief kleur, die van PLY de enige bestemming maken die niet glTF is en het hier behoudt.
- Specificatie van het USDZ-bestandsformaatPixar / OpenUSD
USDZ is een zip waarvan de eerste entry de USDA-scène is. Dat is het pakket dat deze converter schrijft en leest.
Hoe gemeten#
De meting voert het product uit, geen beschrijving ervan. Het script importeert dezelfde loaders en exporters als de browserconverter, met dezelfde opties, en staat in de repository zodat de cijfers gereproduceerd of besproken kunnen worden.
- Een referentiescène bouwen met twee benoemde kubussen, elk met een benoemd metalen materiaal, vertexkleur, UV-coördinaten en normalen.
- Laad echt gegenereerde meshes op dezelfde manier waarop de converter het bestand laadt dat je geeft, inclusief de stap die de vertexnormaalschalen berekent wanneer een mesh zonder deze arriveert.
- Exporteer naar GLB, glTF, OBJ, STL, PLY en USDZ met dezelfde exporters die de converter aanroept en met dezelfde binaire instellingen.
- Registreer de grootte in bytes van elk resultaat.
- Lees de attributen rechtstreeks uit de geschreven bytes en niet uit een opnieuw geladen scène, omdat een loader bedenkt wat het bestand niet bevat: een OBJ zonder vn-lijnen wordt nog steeds opnieuw geladen met een gesynthetiseerd normaalattribuut.
- Publiceer de tabel rechtstreeks vanuit dat resultaat. Gemeten het 13 september 2026 met three.js r179.
Vragen
- Verliest het converteren van een 3D-bestand kwaliteit?
- De vorm niet. Elke bestemming werd geconverteerd en opnieuw ingelezen, en het aantal driehoeken en de totale oppervlakte kwamen identiek uit op een mesh van 498.734 driehoeken, zonder coördinaten in enig formaat af te kappen. Wat verloren gaat, is alles wat de geometrie omringt, en dat hangt af van de bestemming: STL verwijdert de UV's, de kleur, de materialen en de scènedatabase; OBJ verwijdert de per-vertex kleur; PLY verwijdert materiaa-namen en voegt de scène samen; USDZ verwijdert de per-vertex kleur en de materiaa-namen bij het opnieuw inlezen; GLB en glTF behielden alles.
- Welk 3D-formaat neemt het minst in?
- GLB, in een echte mesh. In deze tests schreef GLB 1.173 KB waar OBJ schreef 4.928 KB voor hetzelfde model, omdat GLB binair is en een gedeelde vertexindex behoudt, terwijl de resulterende OBJ tekst is en elke hoek van elke driehoek afzonderlijk opslaat.
- Waarom neemt mijn OBJ veel meer ruimte in dan de GLB waar het uit kwam?
- Om twee redenen, beide maten: OBJ is tekst en geen binair, en de OBJ die hier wordt geschreven deelt geen vertices tussen driehoeken, dus het aantal vertices wordt vermenigvuldigd met een factor 6 in een goed geïndexeerd mesh. Het oppervlak is identiek; de boekhouding niet.
- Behoudt STL de kleur?
- Nee. Een binaire STL slaat een face normal en drie hoeken per driehoek op, en heeft geen veld voor kleur, UV, materialen of objectnamen. Dat is nageleefd in alle STL die in deze tests zijn geschreven.
- Kan ik de kleur per vertex behouden zonder GLB?
- Ja, met PLY. In deze tests was het de enige bestemming die niet glTF is en die een kleurattribuut in de header verklaarde. Dat gezegd hebbende, vouwt het een scène met meerdere objecten samen in één mesh, dus behoud je de kleur maar verlies je de onderdelen.
- Degradeert het om een 3D-model telkens opnieuw te converteren?
- Nee. In tegenstelling tot het opnieuw opslaan van een JPEG, stapelt een 3D-conversie geen fouten op: de coördinaten worden gekopieerd als binaire floats of, in het geval van OBJ, geschreven als decimalen met volledige precisie. Een heen-en-weer reis door een van deze formaten gaf hetzelfde oppervlak terug. Wat niet terugkomt, is de materiaal- en scène-informatie die de bestemming vanaf het begin niet kon ondersteunen.
- Kan ik deze cijfers reproduceren?
- Ja. Het meetscript staat in de repository, in scripts/measure-conversions.mjs, en schrijft de JSON die deze pagina leest. Het werd voor het laatst uitgevoerd op 13 september 2026 met three.js r179.