텍스처가 항상 2의 제곱을 갖는 이유는 무엇입니까? 그렇지 않은 경우 어떻게합니까?

게임에서 텍스처의 해상도가 항상 2의 제곱 (128x128, 256x256, 512x512, 1024x1024 등) 인 이유는 무엇입니까? 게임의 파일 크기를 저장하고 텍스처를 UV 래핑되지 않은 모델에 정확히 맞추는 것이 현명하지 않습니까?

2의 거듭 제곱이 아닌 텍스처가 있으면 어떻게됩니까?

텍스처가 256x512 또는 512x1024와 같은 것이 잘못된 것입니까? 아니면 이로 인해 2의 제곱이 아닌 텍스처가 발생할 수있는 문제가 발생합니까?

게임에서 텍스처의 해상도가 항상 2의 제곱 (128x128, 256x256, 512x512, 1024x1024 등) 인 이유는 무엇입니까?

Byte56는 암시 된 바와 같이, "파워 두개의"크기의 제한은 (이었다) 각 치수 여야 독립적으로 2의 거듭 제곱이 아닌 텍스처 제곱이어야 및 2의 거듭 제곱이다 치수를 갖는다.

그러나 최신 카드와 최신 그래픽 API에서이 "제한"은 텍스처 차원이 원하는대로 거의 모든 것이 될 수 있도록 크게 완화되었습니다. 하나:

게임의 파일 크기를 저장하고 텍스처를 UV 래핑되지 않은 모델에 정확히 맞추는 것이 현명하지 않습니까? 2의 거듭 제곱이 아닌 텍스처가 있으면 어떻게됩니까?

텍스처 치수가 2의 거듭 제곱을 보장함으로써 그래픽 파이프 라인은 2의 거듭 제곱 작업시 효율성과 관련된 최적화를 활용할 수 있습니다. 예를 들어, 2 개의 제곱을 나누고 곱하는 것이 더 빠를 수 있습니다 (그리고 전용 GPU와 매우 영리한 최적화 컴파일러를 사용하기 몇 년 전). 밉맵의 계산 및 사용과 같이 파이프 라인 내에서 단순화 된 두 가지 연산을 수행하는 경우 (2의 거듭 제곱은 항상 반으로 균등하게 분할되므로 반올림해야하는 시나리오를 처리 할 필요가 없음) 밉맵 크기를 위 또는 아래로).

이런 식으로 일부 공간을 "폐기"하는 것이 사실이지만 추가 공간은 일반적으로 렌더링 성능의 균형을 위해 가치가 있습니다. 또한 여러 이미지를 하나의 텍스처 공간에 압축 또는 압축하여 저장 낭비를 줄일 수있는 기술이 있습니다.

텍스처가 항상 2의 제곱을 갖는 이유는 무엇입니까?

텍스처가 아닌 항상 사각형 도 아니다은 항상 두 가지의 힘 . 이들이 2의 제곱 인 경향 이있는 이유 는 일반적으로 그 제한을 가한 구형 비디오 카드와의 호환성을 높이기 위해서입니다. 정사각형이 아닌 텍스처의 경우 일반적으로 문제가되지 않습니다. 요약:

• 텍스처는 일반적으로 될 필요가 없습니다 광장 의 DirectX는 가지고 있지만 - D3DPTEXTURECAPS_SQUAREONLY기능을하지만 난 아무런 문제도 오래된 하드웨어 비 평방 텍스처와 함께 일했습니다.
• 많은 구형 그래픽 카드가 여전히 필요하기 때문에 텍스처는 2의 거듭 제곱 이어야 합니다. 이러한 제한의 이유는 텍스처 매핑 작업에 대해 일부 최적화를 수행 할 수 있기 때문입니다. 대부분의 최신 그래픽 카드에는이 제한이 없습니다.

그래픽 카드 최적화와 관련이 있습니다. 이러한 방식으로 처리하도록 설계되었습니다. 요즘 대부분의 카드 는 2의 거듭 제곱이 아닌 치수로 텍스처를로드 할 수 있지만 성능에 부정적인 영향을 줄 수 있습니다. 로드 할 때 실제로는 시간이 걸리고 메모리를 절약하지 않으면 서 비용이 변환 될 가능성이 높습니다. 치수가 2의 제곱 인 한 비 정사각형 텍스처는 일반적으로 좋습니다.

홀수 크기 텍스처를 처리하는 한 가지 방법은 Texture Atlas를 사용하는 것 입니다. 기본적으로 여러 텍스처를 단일 텍스처에 배치하고 정점의 텍스처 좌표를 사용하여 필요한 특정 이미지를 참조합니다. 상태 변경을 피할 수 있기 때문에 성능상의 이점도 추가로 제공됩니다. 이것의 일반적인 사용은 인터페이스의 모든 요소를 ​​단일 텍스처에 배치하는 것입니다. 즉, 인터페이스 정점을 단일 버퍼 객체로 배치하면 텍스처를 전환하는 대신 단일 호출로 모든 것을 그릴 수 있습니다. 여러 번 그리고 각각에 대해 별도의 그리기 호출을합니다.

문제는 일부 하드웨어가 2 차원의 힘을 갖지 않는 텍스처에 대한 지원이 제한되어 있다는 것입니다.

예를 들어 http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx 의 맨 아래를보고 각주 3과 4를 읽으십시오.

³ 피처 레벨 9_1, 9_2 및 9_3에서 디스플레이 장치는 두 가지 조건에서 2의 거듭 제곱이 아닌 치수의 2 차원 텍스처 사용을 지원합니다. 첫째, 각 텍스처에 대해 하나의 MIP 맵 레벨 만 작성할 수 있으며 둘째, 텍스처에 대한 랩 샘플러 모드가 허용되지 않습니다 (즉, D3D11_SAMPLER_DESC의 AddressU, AddressV 및 AddressW 멤버는 D3D11_TEXTURE_ADDRESS_WRAP로 설정할 수 없음).

⁴ 피처 레벨 10_0, 10_1 및 11_0에서 디스플레이 장치는 2의 거듭 제곱이 아닌 치수의 2-D 텍스처 사용을 무조건 지원합니다.

그래픽 하드웨어는 매트릭스 연산, 프래그먼트 연산 및 벡터 연산에 최적화되어 있습니다. 블록에서 계산이 수행 될 수 있기 때문에 (제곱 조각이라고도 함) 하드웨어가 블록 작업에 최적화되어 있기 때문에 사각형 행렬을 다루기가 더 쉽습니다. 파일 버퍼와 같은 것이 있기 때문에 RAM 블리트는 블록까지 디스크에 블리트되지 않습니다. 채워졌습니다. 그래픽 메모리도 마찬가지입니다.

프레임 버퍼는 정사각형 조각으로 구성됩니다. 예를 들어 해상도가 800x600이고 RGB 색상 공간 (0-255)이있는 화면에는 각 채널에 3 바이트의 800x600 포인트가 있으며 프레임 버퍼에서 처리 할 총계는 3x800x600 = 1,440,000 바이트입니다. 이는 256x256x3 바이트 인 1,875 개의 주소 지정 가능한 조각이 있음을 의미합니다. 텍스처 데이터가 정사각형이므로 바이 큐빅 스케일링을 사용하여 GRAM 매트릭스에서 화면 버퍼 매트릭스로 매핑하기가 훨씬 쉬워집니다. 여기서 더 긴 쪽의 바이어스는 정사각형이 아닌 것처럼 필요할 때 계산하는 데 더 많은 시간이 걸립니다 규모가 조정됩니다.

많은 그래픽 API는 UV 매핑 좌표를 부동 소수점 데이터로 받아들이 기 때문에 정사각형이 아닌 텍스처 데이터를 받아들입니다. 그러나 GPU로 전송되면 패딩이 텍스처 데이터에 추가됩니다. 이미지의 실제 비율은 매핑을 변경하지 않기 때문입니다. GPU는 영향을받지 않는 것처럼 보이지만 GPU는 완벽한 정사각형으로 주소 지정하기를 좋아하기 때문에 텍스처 데이터에 패딩이 추가되었습니다.

따라서 100x1024 이미지가 사용되고 1024x1024 인 이미지가 사용되면 946,176 바이트가 낭비됩니다. 패딩 데이터가 합성 텍스처에 영향을 미치지 않아야 함을 나타 내기 위해 알파 채널이 추가되어야하기 때문에 합성이 수행되는 경우에도 더욱 그러하다.

우리의 디지털 세계는 이진 계산과 함께 작동하여 값을 왼쪽 또는 오른쪽으로 "이동"할 수있는 값을 2로 멀티 플레이하거나 나눕니다.

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

"2의 거듭 제곱"값으로 작업하는 것이 CPU에서 더 쉽습니다.

최신 하드웨어는 두 가지 기반 텍스처의 비 전력에서 랩 모드를 활성화하는 데 (마지막으로) 대처할 수 있지만, 두 텍스처의 비 전력은 너비 에 따라 하드웨어 특정 양만큼 패딩되는 경향이 있기 때문에 GPU 메모리를 낭비하는 경향이 있습니다. 타일 ​​크기 또는 텍스처를 포함하는 두 크기의 다음 거듭 제곱으로 올림).

이것은 하드웨어에 의존하고 벤더는 일반적으로 이러한 세부 사항의 세부 사항을 다루지 않으므로 GPU 램을 낭비하지 않도록 텍스처에 2 차원의 힘을 계속 사용하는 것이 가장 안전합니다.