So sánh các định dạng file 3D: STL, OBJ và glTF
Tại sao việc lựa chọn định dạng file lại thực sự quan trọng
Chọn sai định dạng file 3D và bạn sẽ phải mất hàng giờ vật lộn với việc thiếu texture, lỗi hình học, hay một phần mềm slicer không chịu mở file mô hình của bạn. STL, OBJ, và glTF là các định dạng bạn sẽ thấy thường xuyên nhất, nhưng chúng ra đời ở những thập kỷ khác nhau với những mục đích hoàn toàn khác biệt. STL được chuẩn hóa từ tận năm 1987 cho các máy in 3D đời đầu. OBJ xuất hiện vào khoảng năm 1992 như một định dạng trao đổi linh hoạt từ Wavefront Technologies. Còn glTF 2.0? Nó được Khronos Group phê chuẩn vào năm 2017, được xây dựng từ đầu cho việc render thời gian thực trên web. Khoảng cách 30 năm giữa định dạng cũ nhất và mới nhất đã giải thích gần như mọi khác biệt trong thực tế. Một file in hoàn hảo trong PrusaSlicer có thể trông như một khối xám xịt trong trình xem trên web, và một mô hình sẵn sàng cho game thường hoàn toàn thừa thãi cho một máy in FDM để bàn đơn giản. Hướng dẫn này sẽ phân tích cấu trúc, tính năng và kích thước file điển hình của mỗi định dạng, giúp bạn đưa ra lựa chọn đúng đắn trước cả khi nghĩ đến việc chuyển đổi—hoặc trước khi bạn nhờ một công cụ như CocoConvert làm việc đó cho bạn.
STL: 'Con ngựa thồ' của ngành in 3D
STL là viết tắt của Standard Tessellation Language, mặc dù bạn cũng sẽ nghe người ta gọi nó là STereoLithography. Định dạng này đơn giản đến mức trần trụi: nó biểu diễn một bề mặt 3D dưới dạng một lưới các hình tam giác. Chỉ có vậy thôi. Không màu sắc, không texture, không vật liệu, chỉ có hình học thuần túy. Mỗi tam giác được định nghĩa bởi ba đỉnh và một véc-tơ pháp tuyến hướng ra ngoài. Trong một file STL nhị phân, thông tin này được gói gọn trong 50 byte—12 cho pháp tuyến, 36 cho các đỉnh, và 2 byte cho số 'thuộc tính' mà gần như luôn bị bỏ qua. Hiệu quả này có nghĩa là một mô hình với một triệu tam giác sẽ có kích thước khoảng 50 MB. Có một phiên bản ASCII mà con người có thể đọc được, nhưng nó lớn hơn 5-6 lần, vì vậy định dạng nhị phân là lựa chọn tối ưu. Đối với in 3D, sự đơn giản của STL chính là thế mạnh lớn nhất của nó. Các phần mềm slicer như PrusaSlicer, Cura, Bambu Studio, và Chitubox đều mở file STL một cách tự nhiên mà không cần hỏi han gì. Khi bạn xuất file từ một chương trình như Fusion 360 (File → Export → .stl), bạn có thể tinh chỉnh độ mịn, đặt dung sai hợp âm (chord tolerance) xuống thấp tới 0.001 mm. Con số này quyết định mức độ các tam giác phẳng bám sát vào bề mặt cong lý tưởng. Dung sai thấp hơn sẽ tạo ra nhiều tam giác hơn và file lớn hơn, nhưng đó là chìa khóa để có được những đường cong mượt mà trên bản in cuối cùng. Nhưng những hạn chế của định dạng này cũng rõ ràng không kém. Vì chỉ chứa thông tin hình học, nó không thể xử lý bất kỳ thông tin hình ảnh nào. Nếu mô hình của bạn cần nhiều màu sắc hoặc các bề mặt vật liệu khác nhau, STL sẽ không giúp được bạn. Nó cũng không có khái niệm về đơn vị. Một giá trị '1.0' có thể là một milimét hoặc một inch, một nguồn cơn bực bội kinh điển cho bất kỳ ai từng nhập một mô hình và phát hiện ra nó chỉ nhỏ bằng hạt bụi hoặc to bằng một tòa nhà chọc trời.
OBJ: Hình học kèm vật liệu, nhưng có cái giá của nó
Theo mặc định, các file OBJ là dạng văn bản thuần ASCII liệt kê các đỉnh (v), tọa độ texture (vt), pháp tuyến (vn), và các mặt (f) dưới dạng các dòng riêng lẻ. Một file MTL (Material Template Library) đi kèm riêng biệt sẽ định nghĩa các vật liệu và trỏ đến các file ảnh texture bên ngoài như JPEG hoặc PNG. Cấu trúc đa file này là cơn đau đầu lớn nhất khi làm việc với OBJ. Nếu bạn chỉ gửi cho ai đó file .obj, họ sẽ nhận được một mô hình không có thông tin màu sắc nào cả. Bạn phải cẩn thận đóng gói file .obj, .mtl, và tất cả các texture được tham chiếu vào một file Zip hoặc một thư mục chia sẻ, nếu không người nhận sẽ chỉ nhìn thấy một đối tượng màu xám phẳng lì. Điểm cứu cánh của OBJ là sự hỗ trợ phần mềm khổng lồ của nó. Blender, Maya, Cinema 4D, ZBrush, Rhino—về cơ bản mọi ứng dụng 3D hiện có đều có thể đọc và ghi nó. Nó cũng có một vài ưu điểm chính so với STL, như hỗ trợ nhiều đối tượng được đặt tên trong cùng một file, giúp nó phù hợp hơn cho các cảnh phức tạp. Thêm vào đó, nó có thể định nghĩa các mặt bằng cách sử dụng các đa giác bốn cạnh (quads) và n-cạnh (n-gons), không chỉ là tam giác. Điều này cực kỳ quan trọng đối với các nghệ sĩ sử dụng quy trình mô hình hóa chia nhỏ bề mặt (subdivision modeling), vì nó bảo toàn được cấu trúc topo sạch sẽ mà họ đã dày công tạo ra trước khi nó bị tam giác hóa cho lần render hoặc in cuối cùng. Kích thước file có thể trở nên rất lớn. Một mô hình kiến trúc chi tiết có thể có một file OBJ 200 MB, một file MTL nhỏ xíu 5 KB, và lượng texture độ phân giải cao trị giá 800 MB. Định dạng này không có tính năng nén tích hợp, mặc dù một số công cụ có cung cấp một biến thể nén .objz. OBJ cũng hoàn toàn thiếu hỗ trợ cho các tính năng hiện đại như hoạt ảnh, rigging xương, hoặc hệ thống phân cấp cảnh phức tạp. Điều này làm cho nó trở thành một lựa chọn tồi cho tài sản game hoặc bất kỳ trải nghiệm tương tác nào. Để cung cấp các mô hình tĩnh, giàu chi tiết hình ảnh qua lại giữa các phần mềm khác nhau, OBJ vẫn là một điều xấu cần thiết—chỉ cần nhớ giữ tất cả các file bạn bè của nó trong cùng một thư mục.
glTF: 'JPEG của các định dạng 3D'
Khronos Group nổi tiếng gọi glTF 2.0 là 'JPEG của thế giới 3D', và sự ví von này thật hoàn hảo. Nó là một định dạng được xây dựng để phân phối hiệu quả và tải nhanh, chứ không phải để chỉnh sửa tích cực. Một file glTF dựa trên JSON và có thể tham chiếu đến dữ liệu nhị phân bên ngoài (.bin) và các texture. Tốt hơn nữa, nó có thể được đóng gói thành một file nhị phân duy nhất, khép kín với phần mở rộng .glb. Đối với bất kỳ hình thức phân phối nào, bạn nên luôn sử dụng GLB. Nó là một file duy nhất, không có khả năng thiếu tài sản, và nó thường nhỏ hơn 20–40% so với gói OBJ tương đương sau khi các texture được nhúng vào. glTF 2.0 được thiết kế với phần cứng đồ họa hiện đại trong tâm trí, đó là lý do tại sao nó hỗ trợ vật liệu kết xuất dựa trên vật lý (PBR) ngay từ đầu. Mô hình vật liệu cốt lõi của nó sử dụng các tham số metallic-roughness (kim loại-nhám) ánh xạ trực tiếp đến những gì các engine như Three.js, Babylon.js, Unity, và Unreal mong đợi. Đặt giá trị metallic là 1.0 và roughness là 0.1, và bạn sẽ có một lớp chrome thuyết phục. Đặt metallic là 0.0 và roughness là 0.8, bạn sẽ có một lớp nhựa mờ phẳng. Các thuộc tính này được lưu trữ ngay trong file, đảm bảo mô hình trông giống nhau ở mọi nơi mà bạn không cần phải gán lại vật liệu thủ công trong mỗi ứng dụng. Đây cũng là điểm mà glTF vượt xa các định dạng cũ. Nó hỗ trợ các mục tiêu biến dạng (morph targets), hoạt ảnh xương (skeletal animation), nhiều camera, và một hệ thống phân cấp cảnh đầy đủ. Các phần mở rộng thậm chí còn thêm hỗ trợ cho các hiệu ứng hình ảnh nâng cao như thủy tinh (transmission) và các vật liệu giống sáp (subsurface scattering). Một file GLB duy nhất có thể cung cấp năng lượng cho một trình cấu hình sản phẩm trên một trang web, một bản xem trước AR trong một ứng dụng di động, và một nhân vật trong một trò chơi trình duyệt. Nhưng glTF là một định dạng tồi tệ cho việc chỉnh sửa lặp đi lặp lại. Bạn sẽ không mô hình hóa trực tiếp bằng glTF cũng như bạn sẽ không chỉnh sửa một cuốn tiểu thuyết trong một file PDF. Mỗi lần bạn xuất ra glTF, hình học thường bị tam giác hóa và các shader vật liệu phức tạp được 'nung' thành các texture PBR đơn giản. Quá trình chuyển đổi qua lại một mô hình thông qua quy trình này sẽ làm suy giảm chất lượng của nó. Vì vậy, hãy coi glTF là định dạng phân phối cuối cùng cho các dự án web và thời gian thực, nhưng luôn giữ các file nguồn gốc của bạn ở định dạng gốc như `.blend`.
So sánh trực diện: Một tài liệu tham khảo thực tế
Đây là cách ba định dạng này đối đầu nhau qua các tiêu chí thực sự quan trọng trong một quy trình sản xuất. **Hỗ trợ hình học:** Cả ba đều có thể xử lý một lưới tam giác cơ bản. OBJ linh hoạt hơn, thêm hỗ trợ cho các đa giác bốn cạnh (quads) và n-cạnh (n-gons), điều này hữu ích cho việc mô hình hóa. glTF tập trung vào dữ liệu sẵn sàng để render, hỗ trợ các tam giác và bộ đường thẳng (cho khung dây). **Màu sắc và vật liệu:** STL 'mù màu'; nó không có hỗ trợ gốc. OBJ sử dụng các file MTL bên ngoài để định nghĩa các vật liệu cơ bản với đổ bóng Phong. glTF là người chiến thắng rõ ràng ở đây, với một mô hình vật liệu PBR đầy đủ được tích hợp trực tiếp vào định dạng. **Textures:** Một lần nữa, STL không có. OBJ dựa vào các file hình ảnh bên ngoài được tham chiếu từ file MTL đi kèm của nó. glTF có thể tham chiếu đến các texture bên ngoài hoặc, trong định dạng GLB, nhúng chúng trực tiếp. Nó có các khe cắm chuyên dụng cho các map màu cơ bản, pháp tuyến, kim loại-nhám, che khuất và phát sáng. **Hoạt ảnh (Animation):** Cái này thì dễ. STL và OBJ không hỗ trợ hoạt ảnh. glTF hỗ trợ cả hoạt ảnh xương và hoạt ảnh biến dạng, làm cho nó trở thành lựa chọn duy nhất trong ba định dạng cho nội dung có hoạt ảnh. **Kích thước file điển hình:** Đối với một mô hình có độ phức tạp trung bình (khoảng 500 nghìn tam giác, một vật liệu), một file STL nhị phân sẽ khoảng 25 MB. File OBJ tương đương với MTL và các texture của nó có thể từ 35–120 MB tùy thuộc vào kích thước texture. Một file GLB, nhờ vào các phương pháp nén hiện đại, có thể thu nhỏ con số đó xuống chỉ còn 8–25 MB. **Tương thích phần mềm:** STL là ngôn ngữ phổ quát của các công cụ in 3D và sản xuất. OBJ là định dạng trao đổi cổ điển, được hỗ trợ bởi gần như mọi công cụ tạo nội dung kỹ thuật số (DCC). glTF hiện là thế lực thống trị cho mọi thứ liên quan đến thời gian thực và web, với sự hỗ trợ trong các ứng dụng DCC ngày càng được cải thiện. **Trường hợp sử dụng chính:** Gửi một file STL đến máy in 3D FDM, SLA, hoặc SLS của bạn. Sử dụng OBJ để di chuyển một mô hình tĩnh giữa các chương trình mô hình hóa và render khác nhau. Chọn glTF (cụ thể là GLB) cho các trình xem web, AR/VR, game engine, và thương mại điện tử. Nếu bạn đang in một bộ phận vật lý, hãy xuất file STL. Nếu bạn đang gửi một mô hình kiến trúc chi tiết cho một nghệ sĩ render, OBJ là một lựa chọn an toàn (mặc dù FBX có thể tốt hơn). Nếu bạn đang đưa một sản phẩm lên một trang web hoặc vào một ứng dụng AR, GLB là câu trả lời duy nhất.
Chuyển đổi giữa các định dạng: Cái nào được và cái nào không
CocoConvert có thể xử lý các công việc chuyển đổi phổ biến nhất: STL sang OBJ, OBJ sang STL, OBJ sang glTF/GLB, và GLB sang OBJ. Khi bạn chỉ chuyển đổi hình học—đặc biệt là bất cứ thứ gì liên quan đến STL—quá trình này cực kỳ ổn định. STL chỉ chứa dữ liệu tam giác, và thông tin đó ánh xạ một cách sạch sẽ vào các phần hình học của cả OBJ và glTF. Thách thức thực sự là đi từ một định dạng phong phú xuống một định dạng đơn giản hơn. Nếu bạn chuyển đổi một file OBJ có đầy đủ texture thành một file STL, tất cả dữ liệu vật liệu và texture sẽ bị loại bỏ. Tại sao? Bởi vì định dạng STL theo đúng nghĩa đen là không có chỗ để chứa nó. CocoConvert sẽ cảnh báo bạn về điều này, nhưng nó không thể tạo ra các tính năng một cách kỳ diệu trong một định dạng không hỗ trợ chúng. Đối với hầu hết mọi người, việc lấy hình học thô cho máy in 3D dù sao cũng chính là thứ họ cần. Chuyển đổi từ OBJ sang GLB là một tác vụ phổ biến, nhưng nó không phải là một ánh xạ 1:1 đơn giản. CocoConvert cố gắng dịch các tham số MTL dựa trên mô hình Phong cũ thành các tương đương PBR hiện đại. Màu khuếch tán (diffuse color) trở thành màu cơ bản, và số mũ phản xạ (giá trị 'Ns' trong file MTL) được sử dụng để ước tính độ nhám. Đây là một sự ước tính, không phải là một bản dịch hoàn hảo. Một lớp nhựa bóng trông hoàn hảo trong một trình render cũ có thể trông hơi khác một chút trong một trình xem PBR. Đối với công việc mang tính trọng yếu, bạn sẽ nhận được kết quả tốt nhất bằng cách xuất trực tiếp sang glTF từ ứng dụng tác giả gốc của bạn (như Blender hoặc Maya), điều này cho phép bạn kiểm soát hoàn toàn việc thiết lập vật liệu PBR. Cũng cần biết rằng CocoConvert hiện không hỗ trợ các file GLB có hoạt ảnh. Nếu bạn tải lên một file GLB chứa hoạt ảnh xương và chuyển đổi nó sang OBJ, dữ liệu hoạt ảnh đó sẽ bị mất, để lại cho bạn một lưới tĩnh ở tư thế mặc định của nó. Chúng tôi đang tích cực làm việc trên các chuyển đổi nhận biết hoạt ảnh, nhưng hiện tại, trình xuất glTF tích hợp của Blender (File → Export → glTF 2.0) là công cụ đáng tin cậy nhất để xử lý các tài sản có hoạt ảnh.
Chọn đúng định dạng cho dự án của bạn
Lựa chọn đúng thực ra đơn giản hơn bạn tưởng một khi bạn biết file sẽ đi về đâu. Liệu mô hình của bạn có được đưa đến máy in 3D không? Hãy dùng STL. Chỉ đơn giản vậy thôi. Mọi phần mềm slicer trên hành tinh này đều ưa thích nó, các file có kích thước hợp lý, và việc nó thiếu các tính năng không quan trọng vì máy in không render vật liệu. Chỉ cần đảm bảo xuất ra file STL nhị phân, không phải ASCII, và đặt dung sai hợp âm (chord tolerance) đủ chặt để có các đường cong mượt mà—0.01 mm là một điểm khởi đầu tuyệt vời cho một mô hình cao 200 mm. Liệu mô hình của bạn có đang được di chuyển giữa các chương trình mô hình hóa 3D khác nhau hoặc gửi đến một nghệ sĩ render không? OBJ là định dạng trao đổi cổ điển, an toàn. Chỉ cần có kỷ luật: giữ file MTL và tất cả các file texture trong cùng một thư mục với tên rõ ràng. Và làm ơn, tránh dùng dấu cách trong tên file; bạn sẽ ngạc nhiên khi biết có bao nhiêu công cụ cũ vẫn gặp sự cố với chúng. Nếu cảnh của bạn phức tạp, bạn cũng có thể cân nhắc FBX, định dạng này tốt hơn trong việc bảo toàn hệ thống phân cấp cảnh và hoạt ảnh, mặc dù nó có những điểm kỳ quặc độc quyền của riêng mình. Liệu mô hình của bạn có dành cho web, một ứng dụng AR, một trò chơi, hay bất kỳ trình xem thời gian thực nào không? Hãy dùng GLB. Không có lựa chọn nào tốt hơn. Gói một file duy nhất ngăn chặn việc thiếu tài sản, mô hình vật liệu PBR đảm bảo tính nhất quán về hình ảnh, và các phương pháp nén hiện đại như Draco và KTX2 có thể thu nhỏ một tài sản 50 MB xuống còn 5 MB mà hầu như không mất chất lượng. Đó là ngôn ngữ mẹ đẻ của web 3D hiện đại. Nếu bạn không chắc chắn khách hàng hoặc cộng tác viên của mình cần gì, chỉ cần hỏi họ sử dụng phần mềm nào. Một câu hỏi đó sẽ cho bạn câu trả lời. Một người dùng Cura cần một file STL. Một nghệ sĩ Blender có thể làm việc với OBJ hoặc GLB. Một nhà phát triển web xây dựng trình xem sản phẩm chắc chắn sẽ yêu cầu một file GLB. Việc khớp định dạng với công cụ đích sẽ giúp mọi người đỡ đau đầu.