ปรับปรุงล่าสุด 13 กันยายน 2569
สิ่งที่การแปลง 3 มิติเก็บไว้และค่าใช้จ่ายเท่าใด
การแปลงตาข่ายไม่ได้ฟรีและไม่ใช่การดำเนินการที่ไม่มีการสูญเสีย GLB และ glTF จะเก็บทุกสิ่งไว้ OBJ เก็บวัตถุแยกกันและชื่อวัสดุของมันไว้ แต่ละทิ้งสีตามจุดยอด STL เก็บเฉพาะสามเหลี่ยม PLY เก็บสีตามจุดยอด แต่รวมฉากไว้ในตาข่ายเดียว USDZ เก็บวัตถุทั้งสองและ UV แต่สูญเสียสีตามจุดยอดและชื่อวัสดุเมื่ออ่านใหม่ และเขียนไฟล์ zip ของ USDA ตัวเลขด้านล่างถูกวัดแล้ว ไม่ใช่การประมาณ
ตัวเลขแต่ละตัวบนหน้านี้มาจากการใช้ตัวแปลงเดียวกับที่เว็บไซต์นี้ใช้กับไฟล์จริง และอ่านคุณลักษณะโดยตรงจากไบต์ที่เขียนไว้ วัดด้วย 13 กันยายน 2569 กับ three.js r179 วิธีการอยู่ตอนท้ายของหน้าและสคริปต์อยู่ในที่เก็บ

แต่ละรูปแบบเก็บอะไรไว้บ้าง?#
ฉากอ้างอิงที่มีลูกบาศก์สองลูกที่มีชื่อแตกต่างกัน แต่ละลูกมีวัสดุโลหะเฉพาะตัว ระบายสีตามจุดยอด มีพิกัด UV และปกติ ถูกแปลงไปยังหกปลายทาง GLB และ glTF ยังคงครบถ้วน รูปแบบอื่นทั้งหมดสูญเสียบางอย่าง และแต่ละรูปแบบสูญเสียสิ่งที่แตกต่างกัน
| ปลายทาง | สองวัตถุ | พิกัด UV | สีตามจุดยอด | ชื่อวัสดุ | จำนวนจุดยอด |
|---|---|---|---|---|---|
| GLB | ถูกเก็บรักษาไว้ 2 | ถูกเก็บรักษาไว้ | ถูกเก็บรักษาไว้ | ถูกเก็บรักษาไว้ | 48 จุดยอด |
| glTF | ถูกเก็บรักษาไว้ 2 | ถูกเก็บรักษาไว้ | ถูกเก็บรักษาไว้ | ถูกเก็บรักษาไว้ | 48 จุดยอด |
| OBJ | ถูกเก็บรักษาไว้ 2 | ถูกเก็บรักษาไว้ | สูญหาย | ถูกเก็บรักษาไว้ | 72 จุดยอด |
| STL | รวมเป็น 1 | สูญหาย | สูญหาย | สูญหาย | 72 จุดยอด |
| PLY | รวมเป็น 1 | ถูกเก็บรักษาไว้ | ถูกเก็บรักษาไว้ | สูญหาย | 48 จุดยอด |
| USDZ | ถูกเก็บรักษาไว้ 2 | ถูกเก็บรักษาไว้ | สูญหาย | สูญหาย | 72 จุดยอด |
ทำไม STL และ PLY รวมฉากให้เป็นตาข่ายเดียว?#
ไม่มีรูปแบบใดที่มีกราฟฉาก GLB, glTF และ OBJ สามารถอธิบายวัตถุหลายรายการที่มีชื่อภายในไฟล์เดียว; STL อธิบายโซลิดเดียว และ PLY รายการเดียวขององค์ประกอบ ดังนั้นลูกบาศก์ทั้งสองจึงมารวมเป็นตาข่ายเดียว และไม่มีวิธีแยกกลับ
นี่คือการสูญเสียที่สร้างความประหลาดใจมากที่สุด เพราะมันมองไม่เห็น โมเดลที่ถูกแปลงยังดูเหมือนเดิมในตัวดูตัวอย่าง แต่เมื่อคุณพยายามเลือก เปลี่ยนวัสดุ หรือสร้างแอนิเมชันให้กับส่วนใดส่วนหนึ่ง คุณจะพบว่าส่วนเหล่านั้นไม่มีอยู่แล้ว
ถ้าโมเดลต้องยังคงแยกออกได้ ปลายทางต้องเป็น GLB, glTF หรือ OBJ หากมันไปยังเครื่องลามิเนตหรือการพิมพ์วัสดุเดี่ยว การหลอมรวมจะไม่เสียค่าใช้จ่ายอะไร
ไฟล์โตขึ้นเท่าไหร่?#
มากกว่าที่คนส่วนใหญ่คาด ในตาข่ายที่สร้างขึ้นจริง OBJ ใช้พื้นที่ 5.6 เท่ากับ GLB ต้นฉบับ และ PLY 1.4 เท่า ทั้งสองมีเรขาคณิตเหมือนกัน
| การแปลง | ต้นฉบับ | ผลลัพธ์ | อัตราส่วน | จุดยอดที่เขียนไว้ |
|---|---|---|---|---|
| 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 |
ทำไม OBJ และ STL จึงเพิ่มจำนวนจุดยอด?#
เพราะไม่มีใครในทั้งสองตัวแชร์จุดยอดระหว่างสามเหลี่ยม กริดที่ทำการ index อย่างดีจะเก็บแต่ละมุมเพียงครั้งเดียวและอ้างอิงจากสามเหลี่ยมทั้งหมดที่สัมผัสมัน; OBJ และ STL ตามที่เขียนไว้ที่นี่ จะเก็บมุมทั้งสามของแต่ละสามเหลี่ยมแยกกัน ในการทดสอบกับ lion.glb นั่นแปลง 249,369 จุดยอดเป็น 1,496,202 ประมาณ 6 เท่ามากขึ้น
เรขาคณิตไม่เปลี่ยนแปลง พื้นผิวเหมือนเดิม สามเหลี่ยมเหมือนเดิม เงาเหมือนเดิม; เพียงแต่การนับออกมาแพงกว่า และไฟล์จะโตขึ้นตามสัดส่วนใกล้เคียงกัน
PLY เป็นตัวอย่างตรงข้ามที่มีประโยชน์ มันเก็บดัชนีไว้ ดังนั้นไฟล์ตาข่ายเดียวกันจะถูกเขียนด้วยขนาดใกล้เคียงกับต้นฉบับและยังคงมีสีตามจุดยอด สำหรับตาข่ายขนาดใหญ่ที่จำเป็นแค่เก็บรูปทรง PLY เป็นปลายทางที่ถูกที่สุดและตรงไปตรงมาที่สุดในรายชื่อนี้
ข้อความเมื่อเทียบกับไบนารีทำให้เรื่องแย่ลง glTF เป็น JSON โดยมีบัฟเฟอร์เข้ารหัสเป็น base64 ซึ่งมีค่าใช้จ่ายมากกว่าประมาณหนึ่ง 33 เปอร์เซ็นต์เมื่อเทียบกับ GLB ที่เหมือนกัน เนื่องจาก base64 แปลงทุกสามไบต์เป็นสี่ไบต์
ทำไมไฟล์ถึงมีขนาดใหญ่ขึ้นแม้แต่เมื่อต้องแปลงจาก GLB เป็น GLB?#
เนื่องจากตัวแปลงจะคำนวณปกติของจุดยอดสำหรับตาข่ายใด ๆ ที่เข้ามาโดยไม่มีมัน และหลังจากนั้นจะเขียนออกไป ตาข่ายที่สร้างขึ้นมามักจะไม่มีคุณสมบัติปกติใด ๆ ดังนั้นการเดินทางไปกลับจะเพิ่มเวกเตอร์เต็มหนึ่งตัวต่อจุดยอด
การทดสอบกับ mug.glb เป็นตัวอย่างที่ชัดเจน: เข้าด้วย 880 KB และออกด้วย 1,173 KBโดยไม่มีการเปลี่ยนแปลงในเรขาคณิต ปกติที่เพิ่มเข้ามาคือความแตกต่าง
นี่เป็นการตัดสินใจโดยเจตนาไม่ใช่ข้อบกพร่อง ตาข่ายที่ไม่มีปกติจะดูเป็นการแรเงาเรียบและมีเหลี่ยมในตัวอย่างส่วนใหญ่ ดังนั้นตัวแปลงจะคำนวณมันเมื่อโหลดแทนที่จะปล่อยให้แต่ละเครื่องมือภายหลังต้องเดาเอง
การแปลงเปลี่ยนรูปแบบหรือไม่?#
ไม่ แต่ละจุดหมายถูกแปลงและอ่านอีกครั้ง และพื้นผิวออกมาเหมือนเดิม: จำนวนสามเหลี่ยมเท่าเดิมและพื้นที่ผิวรวมเท่าเดิม จนถึงขีดจำกัดของการวัด ในตาข่ายของ 498,734 สามเหลี่ยม เรขาคณิตคือส่วนของไฟล์ 3D ที่ยังคงอยู่ครบถ้วนเมื่อผ่านการแปลง
| ปลายทาง | สามเหลี่ยมหลังจาก | ความผิดพลาดของพื้นที่ผิว | วิธีเก็บพิกัด |
|---|---|---|---|
| GLB | ไม่มีการเปลี่ยนแปลง | 0% | float32 แบบทวิภาค |
| glTF | ไม่มีการเปลี่ยนแปลง | 0% | บัฟเฟอร์ในรูปแบบ base64 |
| OBJ | ไม่มีการเปลี่ยนแปลง | 0% | ข้อความ ด้วย 17 ทศนิยม |
| STL | ไม่มีการเปลี่ยนแปลง | 0% | float32 แบบทวิภาค |
| PLY | ไม่มีการเปลี่ยนแปลง | 0% | float32 แบบทวิภาค |
| USDZ | ไม่มีการเปลี่ยนแปลง | 0% | ไฟล์ zip ของ USDA |
ดังนั้น การแปลง 3D สูญเสียข้อมูลหรือไม่?#
ทั้งคู่ และความแตกต่างนี่แหละที่เป็นประโยชน์ เรขาคณิตไม่สูญเสียอะไร รูปร่างที่เข้ามาคือรูปร่างที่ออกไป ทุกสิ่งที่ห่อเรขาคณิตนั้นสูญหายไป และส่วนที่จะสูญหายขึ้นอยู่กับจุดหมายที่คุณเลือกโดยสิ้นเชิง
ที่นี่ไม่มีอะไรทำให้พิกัดถูกตัด GLB, STL และ PLY เขียนตัวเลขทศนิยมแบบทวิภาคี 32 บิต glTF ฝังตัวบัฟเฟอร์ทวิภาคีเดียวกันเป็น base64 ภายใน JSON ของมัน USDZ เขียนไฟล์ zip ของ USDA OBJ เป็นเพียงตัวเดียวที่เขียนตำแหน่งเป็นข้อความทศนิยม และเขียนมันด้วยความแม่นยำเต็มแทนที่จะปัดเศษ ซึ่งเป็นส่วนหนึ่งของเหตุผลที่ไฟล์ของมันมีขนาดใหญ่กว่ามาก
นั่นหมายความว่าความกังวลที่พบบ่อย ซึ่งการแปลงแต่ละครั้งจะทำให้โมเดลเสื่อมคุณภาพเล็กน้อย เช่น การบันทึก JPEG ใหม่ ไม่สามารถใช้ได้ การแปลงจาก GLB เป็น OBJ แล้วกลับมา ไม่ทำให้ตาข่ายเรียบลง
สิ่งที่มันทำคือทิ้งสิ่งที่ปรากฏอยู่ด้านบนของหน้าหน้านี้: กราฟของฉากใน STL และ PLY, สีต่อจุดยอดใน OBJ, STL และ USDZ, ชื่อวัสดุใน STL, PLY และ USDZ, และ UV ใน STL การสูญเสียเหล่านี้เป็นถาวร ในแง่ที่ว่าการแปลงกลับมาใหม่ไม่สามารถสร้างมันขึ้นมาอีกครั้งได้
คุณควรเลือกปลายทางใด?#
เลือกปลายทางตามสิ่งที่ต้องอยู่รอด ไม่ใช่ตามนามสกุลที่เครื่องมือรับใส่มาก่อนในรายการ นี่คือตัวเลือกที่สามารถป้องกันได้ตามสิ่งที่วัดด้านบน
| ถ้าคุณต้องการ | เลือก | ทำไม |
|---|---|---|
| เก็บไว้ทั้งหมด ในไฟล์เดียว | GLB | ปลายทางเดียวที่เก็บกราฟฉาก ชื่อวัสดุ UV และสีต่อจุดยอดไว้ด้วยกัน โดยมีขนาดเล็กที่สุดในบรรดาฟอร์แมตเต็ม |
| ทุกอย่างถูกเก็บไว้ อ่านเข้าใจได้โดยคน | glTF | เนื้อหาเดียวกันกับ GLB ประมาณหนึ่ง 33 เปอร์เซ็นต์ใหญ่กว่าเล็กน้อย เพราะบัฟเฟอร์อยู่ในรูป base64 ภายใน JSON |
| วัตถุแยกตามชื่อในโปรแกรมเดสก์ท็อป | OBJ | เก็บวัตถุทั้งสองและชื่อวัสดุทั้งสอง ทิ้งสีต่อจุดยอดและเขียนไฟล์ใหญ่ที่สุดในบรรดาหกไฟล์ |
| การพิมพ์ 3D | STL | สามเหลี่ยมเท่านั้น และไม่มีอะไรเพิ่มเติม นั่นคือทั้งหมดที่เครื่องหั่นอ่านได้ เป็นปลายทางที่เล็กที่สุดที่ไม่ใช่ glTF ในตาข่ายจริง |
| เรขาคณิตและสีต่อจุดยอด โดยน้ำหนักเบา | PLY | จุดหมายปลายทางเดียวที่ไม่ใช่ glTF ซึ่งเก็บสีต่อจุดยอดไว้ และคงดัชนีไว้ ดังนั้นจึงอยู่ใกล้ขนาดต้นฉบับ |
| Quick Look ของ Apple / RA บน iPhone | USDZ | เก็บวัตถุสองชิ้นและ UV ในฉากอ้างอิงไว้ได้ สูญเสียสีต่อจุดยอดและชื่อวัสดุเมื่อนำมาเปิดใหม่ ไฟล์ zip ของ USDA ที่โทรศัพท์สามารถเปิดได้ |
สิ่งที่กำหนดรูปแบบเหล่านี้#
การวัดด้านบนเป็นของเรา; สิ่งที่แต่ละรูปแบบสามารถรองรับเราไม่ได้เป็นผู้ตัดสิน นี่คือข้อกำหนดและเอกสารอ้างอิงรูปแบบที่กำหนดไว้ เพื่อให้สิ่งที่ระบุในหน้านี้สามารถตรวจสอบได้จากแหล่งที่มาจริง แทนที่จะเชื่อโดยไม่ตรวจสอบ
- ข้อกำหนดของ glTF 2.0The Khronos Group
กำหนดกราฟของฉาก วัสดุ และอุปกรณ์เสริมที่ GLB และ glTF ใช้ และอธิบายว่าทำไมพวกมันถึงเป็นจุดหมายเดียวที่รอดชีวิตอยู่ได้เต็มรูปแบบที่นี่
- ประเภทสื่อ model/gltf-binaryIANA
ประเภทที่ลงทะเบียนสำหรับ GLB คอนเทนเนอร์ไบนารีที่ถูกวัดไว้ข้างต้น
- ประเภทสื่อ model/stlIANA
STL ตามที่ลงทะเบียน: สามเหลี่ยมและเวกเตอร์ปกติของหน้า โดยไม่มีช่องสำหรับสี UV วัสดุ หรือชื่อวัตถุ
- รูปแบบไฟล์ Wavefront OBJPaul Bourke
แหล่งอ้างอิงมาตรฐานสำหรับ OBJ ที่ไม่มีช่องเฉพาะสำหรับสีต่อเวอร์เท็กซ์ ซึ่งตรงกับสิ่งที่ถูกละทิ้งไปในการแปลง
- รูปแบบไฟล์โพลิกอน PLYPaul Bourke
บันทึกคุณสมบัติตามจุดยอด รวมถึงสี ซึ่งทำให้ PLY เป็นจุดหมายเดียวที่ไม่ใช่ glTF ที่คงรักษามันไว้ที่นี่
- ข้อกำหนดรูปแบบไฟล์ USDZPixar / OpenUSD
USDZ เป็นไฟล์ zip ที่รายการแรกคือฉาก USDA ซึ่งเป็นแพ็กเกจที่โปรแกรมแปลงนี้เขียนและอ่าน
วิธีการวัด#
การวัดทำการเรียกใช้ผลิตภัณฑ์ ไม่ใช่การอธิบายของมัน สคริปต์นำเข้าตัวโหลดและตัวส่งออกเดียวกับที่โปรแกรมแปลงเว็บเบราว์เซอร์ใช้ พร้อมตัวเลือกเดียวกัน และอยู่ในที่เก็บเพื่อให้ตัวเลขสามารถทำซ้ำหรืออภิปรายได้
- สร้างฉากอ้างอิงที่มีลูกบาศก์สองก้อนที่มีชื่อ แต่ละก้อนมีวัสดุโลหะที่มีชื่อ สีตามจุดยอด พิกัด UV และปกติ
- โหลดเมชที่สร้างขึ้นจริงในลักษณะเดียวกับที่ตัวแปลงโหลดไฟล์ที่คุณให้ รวมถึงขั้นตอนที่คำนวณเวอร์เท็กซ์นอร์มอลเมื่อเมชมาถึงโดยไม่มีมัน
- ส่งออกไปยัง GLB, glTF, OBJ, STL, PLY และ USDZ ด้วยตัวส่งออกเดียวกับที่ตัวแปลงเรียกใช้และการตั้งค่าไบนารีเดียวกัน
- บันทึกขนาดเป็นไบต์ของแต่ละผลลัพธ์
- อ่านคุณสมบัติโดยตรงจากไบต์ที่เขียนแล้ว ไม่ใช่จากฉากที่โหลดซ้ำ เพราะตัวโหลดจะสมมติสิ่งที่ไฟล์ไม่มี: OBJ ที่ไม่มีเส้น vn ก็จะถูกโหลดซ้ำพร้อมคุณสมบัตินอร์มอลสังเคราะห์
- เผยแพร่ตารางโดยตรงจากผลลัพธ์นั้น วัดที่ 13 กันยายน 2569 กับ three.js r179.
คำถาม
- การแปลงไฟล์ 3D สูญเสียคุณภาพหรือไม่?
- รูปแบบไม่ ทุกจุดหมายถูกแปลงและอ่านซ้ำ และจำนวนสามเหลี่ยมและพื้นที่ผิวรวมออกมาเท่ากันในตาข่ายของสามเหลี่ยม 498,734 โดยไม่ตัดพิกัดในรูปแบบใด ๆ สิ่งที่หายไปคือทุกอย่างรอบ ๆ เรขาคณิต และขึ้นอยู่กับจุดหมาย: STL ละทิ้ง UV, สี, วัสดุ และกราฟฉาก; OBJ ละทิ้งสีตามจุดยอด; PLY ละทิ้งชื่อวัสดุและรวมฉาก; USDZ ละทิ้งสีตามจุดยอดและชื่อวัสดุเมื่ออ่านซ้ำ; GLB และ glTF เก็บทุกสิ่งไว้อยู่ครบ.
- รูปแบบ 3 มิติใดใช้พื้นที่น้อยที่สุด?
- GLB ในโครงข่ายจริง ในการทดสอบเหล่านี้ GLB เขียน 1,173 KB ที่ OBJ เขียน 4,928 KB สำหรับโมเดลเดียวกัน เพราะ GLB เป็นไบนารีและเก็บดัชนีของเวอร์เท็กซ์ที่ใช้ร่วมกัน ในขณะที่ OBJ ที่เกิดขึ้นเป็นข้อความและเก็บมุมของสามเหลี่ยมแต่ละอันแยกกัน
- ทำไม OBJ ของฉันจึงใช้พื้นที่มากกว่า GLB ที่สร้างขึ้น?
- ด้วยสองเหตุผล ทั้งสองมาตรการ: OBJ เป็นข้อความไม่ใช่ไบนารี และ OBJ ที่เขียนที่นี่ไม่ได้ใช้เวอร์เท็กซ์ร่วมกันระหว่างสามเหลี่ยม ดังนั้นจำนวนเวอร์เท็กซ์จึงเพิ่มเป็นหลายเท่า 6 ในตาข่ายที่มีดัชนีดี พื้นผิวเหมือนกัน แต่การนับจำนวนไม่เหมือนกัน
- STL เก็บสีหรือไม่?
- ไม่ STL ไบนารีจะเก็บโนมัลของหน้าและสามมุมต่อสามเหลี่ยม และไม่มีช่องสำหรับสี UV วัสดุ หรือชื่อวัตถุ ข้อนี้เป็นไปตามที่เขียนใน STL ทุกไฟล์ในการทดสอบเหล่านี้
- ฉันสามารถรักษาสีตามจุดยอดโดยไม่ใช้ GLB ได้ไหม?
- ได้ ด้วย PLY ในการทดสอบเหล่านี้เป็นปลายทางเพียงแห่งเดียวที่ไม่ใช่ glTF ที่ประกาศคุณสมบัติสีในส่วนหัวของมัน อย่างไรก็ตาม มันจะรวมฉากที่มีหลายวัตถุให้เป็นตาข่ายเดียว ดังนั้นคุณจะรักษาสีไว้ได้แต่จะสูญเสียบางส่วนของวัตถุ
- การแปลงโมเดล 3D ซ้ำ ๆ จะทำให้เสียคุณภาพไหม?
- ไม่ แตกต่างจากการบันทึก JPEG ซ้ำแล้วซ้ำอีก การแปลง 3D จะไม่สะสมความผิดพลาด: พิกัดจะถูกคัดลอกเป็นฟลอตไบนารี หรือในกรณีของ OBJ จะถูกเขียนเป็นทศนิยมด้วยความแม่นยำเต็ม การเดินทางไปและกลับผ่านรูปแบบเหล่านี้จะให้พื้นผิวเหมือนเดิม ข้อมูลวัสดุและฉากที่ปลายทางไม่สามารถรองรับตั้งแต่ต้นจะไม่กลับคืน
- ฉันสามารถทำซ้ำตัวเลขเหล่านี้ได้ไหม?
- ใช่ สคริปต์การวัดอยู่ในที่เก็บข้อมูล ในโฟลเดอร์ scripts/measure-conversions.mjs และจะเขียน JSON ที่หน้าเว็บนี้อ่าน มันถูกรันครั้งล่าสุดเมื่อ 13 กันยายน 2569 กับ three.js r179.