Tại sao kết cấu luôn luôn là sức mạnh vuông của hai? Nếu họ không có thì sao?


53

Tại sao độ phân giải của kết cấu trong trò chơi luôn là một sức mạnh của hai (128x128, 256x256, 512x512, 1024x1024, v.v.)? Sẽ không thông minh khi tiết kiệm kích thước tệp của trò chơi và làm cho kết cấu hoàn toàn phù hợp với mô hình chưa được bao bọc của UV?

Điều gì sẽ xảy ra nếu có một kết cấu không phải là sức mạnh của hai?

Sẽ không chính xác nếu có một kết cấu giống như 256x512 hoặc 512x1024? Hay điều này sẽ gây ra những vấn đề mà kết cấu không có sức mạnh của hai có thể gây ra?


9
Các ví dụ khác của bạn cũng là sức mạnh của hai, chỉ là không có cùng sức mạnh của hai. Sức mạnh của hai làm cho kết cấu được tối ưu hóa cho phần cứng đồ họa.
MichaelHouse

1
@ Byte56 Tôi nghĩ rằng anh ấy có nghĩa là kết cấu 2 ^ nx 2 ^ n, trong đó n thay đổi từ 1 đến vô hạn. (Không thực sự vô hạn.)
Robin

Cũng lưu ý rằng quyền hạn của hai người có lợi ích làm cho mipmaps trở nên tầm thường.
Pubby 26/03 '

Bởi vì kết cấu thường kết thúc tốt đẹp (mặc dù bạn có thể chọn điều này trong một shader tùy chỉnh), bạn không cần lãng phí bất kỳ khoảng trống nào, chỉ cần bọc tọa độ uv đa giác của bạn xung quanh các cạnh và bạn có thể sử dụng không gian có sẵn dễ dàng hơn nhiều. Nếu bạn chưa có nhu cầu nhấn thì an toàn nhất là bám vào chiều rộng = height = 2 ^ n họa tiết vì nó sẽ cho phép phạm vi phần cứng rộng hơn với chi phí bố trí uv phức tạp hơn một chút.
Daniel Carlsson

Họ không phải luôn luôn là sức mạnh của hai.
Almo

Câu trả lời:


49

Tại sao độ phân giải của kết cấu trong trò chơi luôn là một sức mạnh của hai (128x128, 256x256, 512x512, 1024x1024, v.v.)?

Như Byte56 ngụ ý, "sức mạnh của hai" giới hạn kích thước là (mỗi) kích thước, mỗi chiều phải độc lập, sức mạnh của hai, không phải là kết cấu phải vuông có kích thước là hai sức mạnh.

Tuy nhiên, trên các thẻ hiện đại và API đồ họa hiện đại, "hạn chế" này đã được nới lỏng đáng kể sao cho kích thước họa tiết có thể, theo lý do, là bất cứ thứ gì bạn thích. Tuy nhiên:

Sẽ không thông minh khi tiết kiệm kích thước tệp của trò chơi và làm cho kết cấu hoàn toàn phù hợp với mô hình chưa được bao bọc của UV? Điều gì sẽ xảy ra nếu có một kết cấu không phải là sức mạnh của hai?

Bằng cách đảm bảo kích thước kết cấu là một sức mạnh của hai, đường ống đồ họa có thể tận dụng tối ưu hóa liên quan đến hiệu quả khi làm việc với sức mạnh của hai. Ví dụ, có thể (và hoàn toàn là vài năm trước khi chúng tôi có GPU chuyên dụng và trình biên dịch tối ưu hóa cực kỳ thông minh) nhanh hơn để phân chia và nhân với sức mạnh của hai. Hoạt động với quyền hạn của hai thao tác cũng được đơn giản hóa trong đường ống, chẳng hạn như tính toán và sử dụng mipmap (một số có sức mạnh hai sẽ luôn chia đều một nửa, điều đó có nghĩa là bạn không phải đối phó với các tình huống mà bạn phải làm tròn kích thước mipmap của bạn lên hoặc xuống).

Đúng là bạn "lãng phí" một số không gian theo cách này, nhưng không gian thêm thường đáng giá cho sự đánh đổi trong hiệu suất kết xuất. Ngoài ra, còn có các kỹ thuật, chẳng hạn như nén hoặc đóng gói nhiều hình ảnh vào một không gian kết cấu duy nhất có thể làm giảm bớt một số chất thải lưu trữ.


11
"Đúng là bạn" lãng phí "một số không gian theo cách này, nhưng không gian thêm thường đáng giá cho sự đánh đổi trong hiệu suất kết xuất." - Khoảng mười năm trước, tôi đã làm việc tại một studio đang chuyển một trò chơi PS2 sang XBox. Mặc dù về mặt kỹ thuật, PS2 không hỗ trợ kết cấu hai nguồn, nhưng trong một số trường hợp, bạn có thể buộc nó phải làm như vậy với một chút thao tác thông minh và không mất tốc độ. XBox, mặt khác, hoàn toàn không hỗ trợ họ. Kết quả cuối cùng là mặc dù XBox có gần gấp đôi RAM của PS2, chúng tôi đã phải giảm một số họa tiết để phù hợp.
ZorbaTHut 26/03 '

Tôi đang gặp khó khăn trong việc tìm kiếm một trích dẫn, nhưng tôi đã đọc trước đây rằng hình ảnh JPEG nên ở bội số 8 để đạt hiệu quả tối đa, vì bất cứ điều gì bên ngoài điều đó vẫn cần một khối 8x8.
salmonmoose

1
@salmonmoose: Đúng; JPEG nén từng khối 8x8 một cách độc lập và sẽ đệm các khối ở cạnh. Nhưng điều đó không liên quan đến câu hỏi này.
MSalters

1
JPEG được mã hóa trong các khối 8x8, vâng. Đó thực sự không phải là một sự cân nhắc hiệu quả. Và nó cũng không hẳn là sức mạnh của 2. :)
Kylotan

Một ví dụ là trên Android, nơi thường kết cấu không phải là poweroftwo dẫn đến kết cấu màu trắng.
dùng717572

17

Tại sao kết cấu luôn luôn là sức mạnh vuông của hai?

Kết cấu không phải là luôn luôn vuông cũng không phải là họ luôn quyền hạn của hai . Lý do tại sao chúng có xu hướng là sức mạnh của hai thường là để tăng khả năng tương thích với các thẻ video cũ hơn áp đặt hạn chế đó. Đối với kết cấu không vuông, đó thường không phải là một vấn đề. Để tóm tắt:

  • Hoạ tiết thường không cần phải vuông - mặc dù DirectX có D3DPTEXTURECAPS_SQUAREONLYkhả năng nhưng tôi đã làm việc với kết cấu không vuông ngay cả trong phần cứng cũ mà không gặp vấn đề gì.
  • Hoạ tiết nên là sức mạnh của hai vì nhiều card đồ họa cũ vẫn yêu cầu nó. Lý do cho sự hạn chế đó là để họ có thể thực hiện một số tối ưu hóa cho các hoạt động ánh xạ kết cấu. Hầu hết các card đồ họa hiện đại cũng không có hạn chế này.

12
Cần lưu ý rằng "thẻ đồ họa cũ" có nghĩa là những thứ được sản xuất trước năm 2006 hoặc lâu hơn.
Nicol Bolas

1
@NicolBolas Cảm ơn, tôi thực sự đã cố gắng tìm một số tài liệu tham khảo về điểm đó.
David Gouveia

7

Nó liên quan đến tối ưu hóa card đồ họa. Chúng đã được thiết kế để xử lý chúng theo cách đó. Hầu hết các thẻ ngày nay sẽ cho phép bạn tải họa tiết với kích thước không phải là sức mạnh của hai, nhưng nó có thể sẽ có tác động tiêu cực đến hiệu suất. Có một cơ hội tốt là khi nó tải nó thực sự sẽ được chuyển đổi làm bạn mất thời gian tải và không tiết kiệm bộ nhớ. Hoạ tiết không vuông thường là OK, miễn là cả hai kích thước của chúng là sức mạnh của hai.

Một cách để đối phó với kết cấu kích thước kỳ lạ là sử dụng Texture Atlas . Về cơ bản, bạn đặt nhiều kết cấu lại với nhau thành một kết cấu và sử dụng tọa độ kết cấu của các đỉnh của bạn để tham chiếu hình ảnh cụ thể mà bạn cần. Điều này cũng đi kèm với các lợi ích hiệu suất bổ sung, bởi vì nó cho phép tránh các thay đổi trạng thái. Một cách sử dụng phổ biến này là đặt tất cả các thành phần của giao diện vào một kết cấu duy nhất, nghĩa là nếu bạn đã sắp xếp các đỉnh giao diện của mình vào một đối tượng bộ đệm, bạn có thể vẽ toàn bộ mọi thứ bằng một cuộc gọi, thay vì chuyển đổi kết cấu nhiều lần và thực hiện một cuộc gọi rút thăm riêng cho từng người.


6

Vấn đề là một số phần cứng có hỗ trợ hạn chế cho kết cấu không có sức mạnh hai chiều.

Ví dụ: nhìn vào phần dưới cùng của http://msdn.microsoft.com/en-us/l Library / windows / desktop / ff476876% 28v = vs85% 29.aspx và đọc chú thích 3 và 4 ở đó.

3 Ở các cấp tính năng 9_1, 9_2 và 9_3, thiết bị hiển thị hỗ trợ sử dụng họa tiết 2 chiều với kích thước không phải là sức mạnh của hai trong hai điều kiện. Đầu tiên, chỉ có thể tạo một cấp độ bản đồ MIP cho mỗi kết cấu và thứ hai, không cho phép các chế độ lấy mẫu bao bọc cho kết cấu (nghĩa là, các thành viên Địa chỉ, Địa chỉ, và Địa chỉ của D3D11_SAMPLER_DESC không thể được đặt thành D3D11_TEXTURE_ADDRESS_WRAP).

4 Ở các cấp tính năng 10_0, 10_1 và 11_0, thiết bị hiển thị hỗ trợ vô điều kiện việc sử dụng họa tiết 2 chiều với kích thước không phải là sức mạnh của hai.


6

Phần cứng đồ họa được tối ưu hóa cho các hoạt động ma trận, hoạt động phân đoạn và hoạt động vector. Đơn giản chỉ cần đặt ma trận vuông dễ xử lý hơn, vì các phép tính có thể được thực hiện trong các khối (được gọi là các đoạn), phần cứng được tối ưu hóa cho các hoạt động của khối, đó là lý do tại sao có những thứ như bộ đệm tệp, blit RAM không làm hỏng đĩa cho đến khi một khối đã được dân cư. Điều tương tự cũng đúng với bộ nhớ đồ họa.

Bộ đệm khung bao gồm các mảnh hình vuông. Ví dụ: trong màn hình có độ phân giải 800x600 và không gian màu RGB (0-255), có 800x600 điểm với 3 byte mỗi kênh có tổng cộng 3x800x600 = 1.440.000 byte để giải quyết trong bộ đệm khung. Điều đó có nghĩa là có 1.875 đoạn địa chỉ là 256x256x3 byte. Vì dữ liệu kết cấu là hình vuông nên việc ánh xạ từ ma trận GRAM sang ma trận bộ đệm màn hình bằng cách sử dụng tỷ lệ bicubic dễ dàng hơn, trong khi nếu nó không vuông thì độ lệch cho mặt dài hơn sẽ mất nhiều thời gian hơn để tính toán khi cần được thu nhỏ.

Nhiều API đồ họa sẽ chấp nhận dữ liệu kết cấu không vuông, vì chúng chấp nhận tọa độ ánh xạ UV là dữ liệu điểm nổi, tuy nhiên một khi được gửi tới GPU, phần đệm được thêm vào dữ liệu kết cấu, vì tỷ lệ thực tế của hình ảnh không thay đổi ánh xạ dường như không bị ảnh hưởng, tuy nhiên phần đệm được thêm vào dữ liệu kết cấu, vì GPU thích giải quyết nó như một hình vuông hoàn hảo.

Vì vậy, nếu một hình ảnh 100x1024 được sử dụng và hình ảnh 1024x1024 được sử dụng có nghĩa là 946.176 byte bị lãng phí. Thậm chí nhiều hơn nếu việc tổng hợp được thực hiện, bởi vì một kênh alpha sẽ cần phải được thêm vào để chỉ ra rằng dữ liệu đệm không nên ảnh hưởng đến kết cấu tổng hợp.


Đây là một lời giải thích thú vị (chuẩn độ về ma trận vuông) không được tìm thấy trong sức mạnh thông thường của 2 câu trả lời (+1) - bạn có thể cung cấp một số trích dẫn nếu có thể không?
Samaursa

1

Thế giới kỹ thuật số của chúng tôi hoạt động với số nhị phân sau đó để nhân hoặc chia cho 2 giá trị bạn có thể "di chuyển" một giá trị sang trái hoặc phải, tức là

<<  Left shift      x = 5 << 1    0101 << 1     1010     10
>>  Right shift     x = 5 >> 1    0101 >> 1     0010      2

Làm việc với các giá trị "sức mạnh của hai" dễ dàng hơn cho CPU.


0

Phần cứng hiện đại có thể (cuối cùng) đối phó với việc cho phép các chế độ bao bọc không cung cấp năng lượng cho hai kết cấu dựa trên, tuy nhiên việc không sử dụng hai kết cấu vẫn có xu hướng lãng phí bộ nhớ GPU khi chúng có xu hướng được đệm dọc theo chiều rộng theo một số lượng cụ thể của phần cứng (hoặc đến một số kích thước gạch hoặc làm tròn đến sức mạnh tiếp theo của hai kích thước có chứa kết cấu).

Vì đây là phụ thuộc vào phần cứng và các nhà cung cấp thường sẽ không đi vào chi tiết cụ thể của các chi tiết này, điều an toàn nhất là tiếp tục sử dụng sức mạnh của hai chiều cho kết cấu, để không lãng phí ram GPU.

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.