이러한 부호있는 바이트가 LWJGL의 부호없는 바이트로 읽히는 이유는 무엇입니까?

Question

LJWGL 함수 glBufferData()를 사용하여 부호있는 바이트를 저장하는 ByteBuffer (java lang 객체)를 업로드하면 OpenGL이 GL_UNSIGNED_BYTE를 사용하여 해당 버퍼의 데이터를 해석하는 올바른 방법을 알 수 있습니다.

왜 이런가요? LWJGL은 ByteBuffer를 다른 형식으로 변환하지 않는 것처럼 보입니다. 여기 glBUfferData() 함수의 소스가 있습니다.

public static void glBufferData(int target, ByteBuffer data, int usage) { 
    ContextCapabilities caps = GLContext.getCapabilities(); 

    long function_pointer = caps.glBufferData; 

    BufferChecks.checkFunctionAddress(function_pointer); 
    BufferChecks.checkDirect(data); 

    nglBufferData(target, data.remaining(), MemoryUtil.getAddress(data), usage, function_pointer); 
} 

왜 그런가?

편집 :

너희들이 부호없는 바이트 바이트가 같은 방식으로 저장되기 때문에 어떤 변환을 할 수없는이 필요하다 생각하는 이유를 참조하십시오. 그러나 분명히하자면, 1 2 3 4 5 등의 정수 값을이 바이트 버퍼에 넣을 것입니다. 아마도 그것은 부호있는 바이트로 취급 될 것입니다. 이는 자바가 처리하는 것이기 때문입니다. 이 바이트들은 아마도 서명 된 해석을 사용할 때 12345를 저장하고있을 것입니다. 그렇다면 왜 서명 된 해석 대신 서명되지 않은 해석을 사용하여 12345를 읽는가가 문제입니다.

데이터의 중요성은 인덱스 버퍼임을 유의하십시오.

Answer 1

처음에는 꼭지점 버퍼 인덱스에 GL_UNSIGNED_BYTE을 사용하지 마십시오. OpenGL은 이것을 API 수준에서 지원하지만, 지난 14 년 동안 제조 된 데스크톱 GPU 하드웨어는 일반적으로 하드웨어 수준에서 지원하지 않습니다. 드라이버는 하드웨어 제약 조건을 충족시키기 위해 인덱스를 16 비트로 변환하므로 실제로 수행중인 모든 작업이 드라이버의 작업 부하를 증가시킵니다. GL_UNSIGNED_SHORT은 실제로 드라이버에 불필요한 부담을주지 않으려는 경우 사용해야하는 가장 작은 인덱스 크기입니다. 별다른 문제가 없는데, 원하는 경우 8 비트 인덱스를 사용할 수 있지만 대신 16/32 비트를 사용하면 더 나은 버텍스 성능을 얻을 수 있습니다.

, 당신은 정점 인덱스를 해석하는 GL_UNSIGNED_BYTE를 사용하는이 문제의 실제 문제를 해결하려면이 경우 데이터 유형의 범위는 색상 값을 해석하는 값 < 128 GL_UNSIGNED_BYTE 대 GL_SIGNED_BYTE 정말에만 문제에 대한 무관 GL은 [-128, 127]의 값을 재 매핑하기 위해, 고정 소수점 스케일링 않으므로 - [> ->[-1.0, 1.0]는 (부호) 또는 [0, 255] 0.0, 1.0] (서명되지 않음). 정점 인덱스의 경우

그러나, 수 5 여전히 이 부호의 서명 또는 다른 방법으로 주위로 변환 된 후 5입니다. 정점 인덱스를 해석하는 데 필요한 고정 소수점 - 부동 소수점 변환은 없으므로 값 범위는 특히 중요하지 않습니다 (오버플로 없음을 가정).

이렇게하려면 버텍스 인덱스를 사용할 때 선택의 여지가 없습니다. 유효한 열거 형은 GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT 및 GL_UNSIGNED_INT입니다.귀하의 언어가 부호없는 값을 표현할 수 없다면, OpenGL의 언어 바인딩은 이러한 열거 형의 의미와 그 처리 방법을 정확하게 파악해야 할 책임이 있습니다.

Answer 2

부호가있는 바이트와 부호없는 바이트의 주요 차이점은 비트를 해석하는 방법입니다. 음수 값은 127을 초과하는 값과 동일한 비트 패턴을 갖습니다. 두 가지 유형에 대해 서로 다른 유형의 저장과 변환이 필요 없습니다 실제로 no-op)는 2의 보수 시스템을 사용하여 자동으로 작동합니다.