Định dạng hình ảnh tốt nhất (phổ biến nhất?) Cho kết cấu [đóng]


13

Được rồi, vì vậy tôi đang sử dụng C ++ với OpenGL và tôi sẽ tạo một trình tải để tải họa tiết cho trò chơi 3D của mình. (Nhưng kết cấu là 2D). Tôi muốn tùy chọn minh bạch, ngay cả khi tôi quyết định không sử dụng nó. Tôi cần chất lượng tốt, mặc dù nó không phải là đỉnh cao. Các bạn đề nghị gì cho định dạng (PNG, TGA, v.v.). Ngoài ra, có thể làm cho nó một cái gì đó dễ dàng để tạo một trình tải cho (Tôi sẽ không sử dụng một trình tạo đã được tạo.). Và ngoài ra, nếu bạn có bất kỳ liên kết / mẹo nào để trợ giúp với trình tải, điều đó sẽ được đánh giá cao.

Câu trả lời:


15

Tôi không hiểu lý do tại sao bạn không muốn sử dụng trình tải ngoài giá. Ví dụ, PNG là một lựa chọn tốt cho định dạng nhưng rất phức tạp để viết trình tải mục đích chung cho (và có lẽ không đáng để viết một tập tin chỉ tải tập hợp con cụ thể của định dạng PNG mà bạn quan tâm).

Cho rằng yêu cầu hơi bất thường, TGA có lẽ là đặt cược tốt nhất của bạn. TGA 2.0 có kênh alpha và tương đối đơn giản so với PNG.


3
+1 cho TGA nếu OP muốn tự viết. Tôi đã viết trình tải TGA của riêng tôi một lần. Vì vậy, nhanh chóng và không đau.
Vịt Cộng sản

4
@Duck: Không đau đớn miễn là bạn đang thực hiện các TGA đơn giản mà không cần nén hoặc bất kỳ tính năng ưa thích nào. Nếu bạn muốn một trình tải TGA tuân thủ đầy đủ, tôi đã thấy đó là một chút đau khổ. Đó là một định dạng lạ.
ZorbaTHut

1
@Zorba, nén đủ dễ. Nó chỉ là cho dù bạn quan tâm đến phần mở rộng hay không.
giảm tốc

10

Định dạng kết cấu hình ảnh là một lựa chọn hiệu suất quá. Tôi khuyên bạn nên sử dụng kết cấu nén càng nhiều càng tốt. Trên nền tảng di động, nó có thể cải thiện hiệu năng rất lớn (40% hoặc thậm chí nhiều hơn), sử dụng bộ nhớ và tải thời gian.

Xem xét một kết cấu 1024 * 1024:

  • RGB hoặc RGBA (16 bit): 2Mo (.5 giây để tải trên SGS)
  • RGBA (32 bit): 4Mo (1 giây để tải trên SGS)
  • PVRT (4bpp): 512ko (.125s để tải trên SGS)
  • ETC1 + Alpha: 1.5Mo (.4 giây để tải trên SGS)

Trong các trò chơi của chúng tôi, chúng tôi có tài sản (kết cấu) ở nhiều định dạng:

  • Định dạng DDS cho kết cấu DXTC (Nền tảng máy tính để bàn: OS X, Linux, Windows & Tegra)
  • Định dạng DDS cho kết cấu ATC (GPU Andreno)
  • Định dạng PVR cho định dạng PVRT (GPU PowerVR)
  • Định dạng PKM cho kết cấu ETC1 (Tất cả các thiết bị tương thích với thiết bị OGLES 2.0)

Cuối cùng, chúng tôi sử dụng định dạng thô để tương thích nhưng đó là tính tương thích hoặc các yếu tố GUI

  • Định dạng PNG cho kết cấu thô. Nó dành cho kết cấu RGBA 16, 24 hoặc 32 bit (chúng tôi sử dụng trình tải được cấp phép của MIT). Đó là kết cấu không nén.

Hoạ tiết ETC1 không có kênh alpha nên chúng tôi sử dụng một shader đặc biệt với hai kết cấu (kết cấu rgb và kết cấu alpha). Định dạng nén rất dễ tải (100 hoặc 200 loc).

Trên máy tính để bàn, DXTC (S3TC) có mặt trên nhiều thẻ. Vì vậy, bạn nên sử dụng nó.

Hoạ tiết nén

Chuyên nghiệp

  • Cải thiện kết cấu
  • Tải họa tiết (4x trở lên)
  • Dễ tải

Con

  • Không được hỗ trợ trên tất cả các nền tảng
  • đồ tạo tác

6
Có một sự khác biệt lớn giữa các kết cấu được nén trên videocard (ví dụ: DXTC) và các kết cấu chỉ được nén trong khi được lưu trữ và phải được giải nén trong khi tải (ví dụ: PNG). PNG sẽ tải chậm hơn so với kết cấu không nén vì trước tiên nó phải được giải nén. Chúng là một kích thước tệp nhỏ hơn, vâng, nhưng dung lượng bộ nhớ đồ họa tiêu thụ là như nhau.
jhocking

8

Hoạ tiết là bộ sưu tập của một hoặc nhiều hình ảnh. Điều này có nghĩa là một kết cấu có thể được biểu thị bằng TGA hoặc PNG, nhưng không định dạng nào có khả năng thể hiện tất cả các tính năng có thể có của kết cấu. Tại sao?

Bởi vì mỗi người chỉ có thể giữ một hình ảnh duy nhất . Không có mipmap. Không có kết cấu 3D có thể. Không có kết cấu mảng. Không có hình khối. Mỗi tệp đó chỉ là một hình ảnh 2D. Chúng có thể là một phần của kết cấu, nhưng trừ khi bạn không sử dụng mipmapping (và tôi khuyên bạn không nên sử dụng mipmap trừ khi bạn có nhu cầu cụ thể), một tệp hình ảnh trong các định dạng này có thể là một kết cấu.

Chúng là các định dạng hình ảnh tốt, nhưng chúng làm cho các định dạng kết cấu kém .

DDS là ứng dụng tiên phong của các định dạng kết cấu bởi vì nó thực sự hỗ trợ những thứ cần kết cấu. Nó hỗ trợ mipmaps và cubemaps. Nó hỗ trợ kết cấu 3D. DDSv10 hỗ trợ kết cấu mảng. Bạn có thể đóng gói một kết cấu trong DDS theo cách mà bạn không thể với PNG hoặc TGA.

DDS hỗ trợ dữ liệu kết cấu không nén và nén. Miễn là định dạng kết cấu nén là một trong các định dạng kết cấu DXT / BC.

PKM rất hữu ích để đóng gói hình ảnh được nén ETC1, nhưng giống như với PNG, nó không hỗ trợ các tính năng kết cấu thực tế.

Các tệp PVR dường như tương đương với DDS trên thiết bị di động (mặc dù tại sao chúng không thể sử dụng DDS, tôi không biết). Chúng hỗ trợ các kỹ thuật nén khác nhau, nhưng chúng thiếu các tính năng DDSv10 tiên tiến như kết cấu mảng, cũng như hỗ trợ kết cấu 3D.

Vì vậy, DDS chiến thắng về mặt hỗ trợ kết cấu toàn diện.


2
Nói hoàn toàn cho các tính năng, TIFF hỗ trợ tất cả những điều DDS làm và hơn thế nữa. Muốn có một kết cấu với các kênh xa IR, gần IR, R, G, B và UV ngoài Alpha? Trong 64 bit điểm nổi IEEE trên mỗi kênh? Được nén bởi bất kỳ thuật toán nào (bao gồm JPEG và JPEG2000) có phù hợp với kênh không? Với nhiều hình ảnh trên mỗi tệp và siêu dữ liệu phong phú cho mỗi một trong số chúng? Nó có thể làm tất cả những điều này, và nhiều hơn nữa. Đó cũng là định dạng "bản địa" của Photoshop từ lâu. Bây giờ, như để viết một trình tải cho nó ...
Martin Sojka

Cho phép tôi thêm thông tin về yêu cầu chỉ sử dụng định dạng kết cấu DXT / BC trong bộ chứa DDS; có vẻ như không phải vậy Tôi đã thấy Trình nén sử dụng các định dạng nén và đầu ra khác nhau dưới dạng .dds cho tất cả (có thể thấy gợi ý này từ đầu ra trợ giúp khi thực hiện cli của nó) và [this] (câu trả lời) trên SO nói rằng bạn có thể sử dụng bất kỳ định dạng nén nào (cài đặt FourCC khác nhau sau đó tự xử lý).
haxpor

1
@haxpor: Bạn có thể chuyển bất cứ thứ gì bạn muốn trong một tệp và gọi nó là DDS. Câu hỏi đặt ra là liệu một ứng dụng có thể đọc các tệp DDS bình thường có thể đọc được tệp của bạn hay nó sẽ phải được mã hóa đặc biệt để làm như vậy? Định dạng DDS chỉ xác định các định dạng nén DXT / BC (và tôi cho rằng ASTC ngày nay). Điều gì xảy ra nếu bạn sử dụng định dạng khác là giữa chương trình viết nó và chương trình đọc nó. Nhưng đó là sự thật của khá nhiều bất kỳ định dạng hình ảnh.
Nicol Bolas

@NicolBolas Cảm ơn bạn đã tóm tắt. Tôi nghĩ rằng đây là nó.
haxpor

5

Nhóm Khronos khuyến nghị định dạng tệp KTX để lưu trữ kết cấu cho các ứng dụng OpenGL và OpenGL ES. Bạn có thể sử dụng libktx để làm việc với định dạng này.

Đặc trưng:

  • Khởi tạo kết cấu OpenGL từ tệp KTX
  • Giải nén hình ảnh kết cấu nén ETC1 khi phần cứng không có hỗ trợ ETC1.
  • Xây dựng bảng băm của các cặp khóa-giá trị từ tệp KTX khi kết cấu được tải
  • Viết tệp KTX từ một mảng các hình ảnh nguồn và bảng băm tùy chọn của các cặp khóa-giá trị.
  • Xây dựng và điền vào bảng băm của các cặp khóa-giá trị.

3

Có vẻ như DDS (DirectDraw Surface) là lựa chọn phổ biến nhất cho kết cấu tại thời điểm này. Có định dạng pixel, độ trong suốt và nén khác nhau. Nó được hỗ trợ trong OpenGL thông qua tiện ích mở rộng GL_ARBSphereure_compression.

Ví dụ, có một trình tải OpenGL ở đây .


Câu trả lời của bạn được diễn đạt một chút khó hiểu. Thật vô nghĩa khi nói rằng DDS được hỗ trợ trong OpenGL. OpenGL không xử lý các định dạng hình ảnh.
rdb

3

Có một số cân nhắc ở đây:

  1. Nhanh như thế nào bạn có thể lấy kết cấu ra khỏi đĩa và vào bộ nhớ hệ thống.
  2. Tốc độ bạn có thể nhận kết cấu từ bộ nhớ hệ thống đến GPU (thông qua glTexImage2D trong trường hợp của bạn).
  3. Có bao nhiêu dung lượng đĩa và bộ nhớ RAM video trong ngân sách của bạn.
  4. Hiệu suất và chất lượng.

TGA là một lựa chọn tốt vì trong các trường hợp không nén 24 và 32 bit, bạn có thể đọc dữ liệu trong một lần duy nhất / bất cứ điều gì và gửi kết quả trực tiếp qua glTexImage2D mà không cần xử lý thêm. Đó là một lựa chọn tồi vì nó có thể có kích thước tệp lớn nhất và nếu I / O của đĩa bị nghẽn cổ chai thì việc đọc của bạn sẽ bị chậm.

PNG là một lựa chọn tốt vì nó giữ được chất lượng hình ảnh với kích thước tệp khá nhỏ. Đó là một lựa chọn tồi vì PNG có thể chậm giải nén - nếu đó là nút cổ chai của bạn thì - tốt, bạn biết đấy.

JPG là một lựa chọn tốt vì nó thường có kích thước tệp nhỏ nhất và sẽ tắt đĩa rất nhanh (tốt gấp đôi nếu bạn cần gửi tệp qua mạng). Đó là một lựa chọn tồi vì các bước giải nén phần mềm trung gian và giảm chất lượng (mặc dù bạn có thể điều chỉnh các cài đặt chất lượng để giảm thiểu điều này). Không có kênh alpha nào cả.

DDS (hoặc các định dạng nén khác) là những lựa chọn tốt vì kích thước tệp nhỏ hơn và khả năng bao gồm chuỗi mipmap dựng sẵn. Nếu đó là định dạng được hỗ trợ thực sự trong phần cứng (và DDS vốn được hỗ trợ trên hầu hết phần cứng PC tiêu dùng - cũng đã có từ lâu), bạn sẽ nhận được lợi ích tương tự như TGA - một lần nữa, một chút chọc vào tiêu đề để tìm ra một số thuộc tính hình ảnh, sau đó gửi dữ liệu thẳng mà không cần các bước trung gian. Hoạ tiết nén cũng sẽ giúp chương trình của bạn chạy nhanh hơn và sử dụng ít RAM video hơn. Chúng là những lựa chọn tồi vì chúng sử dụng nén mất mát (đôi khi có thể thực sự đáng chú ý) và có thể không được hỗ trợ trên tất cả các phần cứng.

Nếu là tôi, tôi sẽ xây dựng hỗ trợ cho cả 4 định dạng này (TGA và DDS khá đơn giản để viết trình tải cho, với JPG và PNG Tôi sẽ sử dụng thư viện hình ảnh) để người tạo nội dung có thể chọn định dạng phù hợp nhất trên một cơ sở trên mỗi kết cấu.


1
"DDS thực sự được hỗ trợ trên hầu hết các phần cứng PC tiêu dùng" DDS là một thùng chứa cho các định dạng khác nhau. Bạn không chuyển tệp DDS cho GPU, nhưng nội dung của nó!
Tara

0

Và tất nhiên, bạn luôn có thể đi với BMP 32 bit cũ, rất dễ tải (đặc biệt nếu kích thước là công suất 2 (thực tế là bội số của 8 byte IIRC)).

Mặt khác, có vẻ lạ khi bạn chỉ muốn một định dạng, jpg thực sự tuyệt vời cho kết cấu hi res trong thế giới thực đẹp (jpeg thực hiện tuyệt vời với không gian đĩa và (xuống) thời gian tải), png cho độ trong suốt và BMP 32bits đôi khi cho kết cấu tương phản (dễ dàng tạo từ tập lệnh hoặc công cụ 'nhanh và bẩn').

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.