버전 4.1 기준으로 OpenGL에서 텍스트 렌더링을위한 최첨단 기술은 무엇입니까? [닫은]

OpenGL의 텍스트 렌더링에 대한 많은 질문이 이미 있습니다.

• GUI에서 OpenGL 라이브 텍스트 렌더링을 수행하는 방법은 무엇입니까?

그러나 대부분 논의 된 것은 고정 기능 파이프 라인을 사용하여 텍스처 쿼드를 렌더링하는 것입니다. 확실히 쉐이더가 더 나은 방법을 만들어야합니다.

나는 국제화에 대해 정말로 걱정하지 않습니다. 대부분의 문자열은 음표 눈금 레이블 (날짜와 시간 또는 순수 숫자)입니다. 그러나 플롯은 화면 새로 고침 빈도로 다시 렌더링되며 화면에 수천 개의 글리프가 아니라 하드웨어 가속 레이아웃이 충분할 정도로 약간의 텍스트가있을 수 있습니다.

최신 OpenGL을 사용한 텍스트 렌더링에 권장되는 방법은 무엇입니까? (이 방법을 사용하여 기존 소프트웨어를 인용하는 것은 그것이 잘 작동한다는 좋은 증거입니다)

• 위치 및 방향 및 문자 시퀀스를 받아들이고 텍스처 쿼드를 방출하는 형상 쉐이더
• 벡터 글꼴을 렌더링하는 지오메트리 셰이더
• 위와 같이 테셀레이션 셰이더를 대신 사용
• 폰트 래스터 화를위한 계산 셰이더

총 12 자만 렌더링하지 않는 한 렌더링 외곽선은 곡률을 추정하기 위해 문자 당 필요한 정점 수로 인해 "없음"으로 유지됩니다. 픽셀 쉐이더에서 베 지어 곡선을 평가하는 접근 방법이 있었지만, 이들은 앤티 앨리어싱이 쉽지 않기 때문에 거리 맵 텍스쳐 쿼드를 사용하는 것이 쉽지 않으며 쉐이더의 곡선을 평가하는 데 여전히 필요한 것보다 훨씬 비쌉니다.

"빠른"품질과 "품질"간의 최상의 균형은 여전히 ​​서명 된 거리 필드 텍스처를 가진 텍스처 쿼드입니다. 그것은이다 아주 약간 하지만 너무 느린 일반 정상적인 질감 쿼드를 사용하는 것보다. 반면에 품질은 완전히 다른 야구장에 있습니다. 결과는 정말 놀랍고, 최대한 빨리 얻을 수 있으며, 글로우와 같은 효과도 쉽게 추가 할 수 있습니다. 또한 필요한 경우이 기술을 이전 하드웨어로 다운 그레이드 할 수 있습니다.

이 기술에 대한 유명한 밸브 용지 를 참조하십시오 .

이 기법은 다각형을 생성하지 않지만 암시 적 표면 (메타 볼 등)의 작동 방식과 개념적으로 유사합니다. 전적으로 픽셀 쉐이더에서 실행되며 텍스처에서 샘플링 된 거리를 거리 함수로 사용합니다. 선택한 임계 값 (일반적으로 0.5)을 초과하는 모든 항목은 "in"이고 다른 모든 항목은 "out"입니다. 가장 간단한 경우, 10 살짜리 셰이더가없는 하드웨어에서 알파 테스트 임계 값을 0.5로 설정하면 정확한 효과를 얻을 수 있습니다 (특수 효과 및 앤티 앨리어싱 제외).
글꼴 (가짜 굵은 체)에 약간 더 많은 가중치를 추가하려면 한 줄의 코드를 수정하지 않고도 임계 값이 조금 더 작습니다 ( "font_weight"유니폼 변경). 글로우 효과의 경우, 단순히 하나의 임계 값을 초과하는 모든 것을 "in"으로 간주하고 다른 (작은) 임계 값을 초과하는 모든 것을 "out, but in glow"로 간주하고 LERP는 둘 사이를 고려합니다. 앤티 앨리어싱도 비슷하게 작동합니다.

단일 비트가 아닌 8 비트 부호있는 거리 값을 사용하여이 기법은 텍스처 맵의 유효 해상도를 각 차원에서 16 배 증가시킵니다 (흑백 대신 모든 가능한 음영이 사용되므로 256 배 동일한 저장소를 사용하는 정보). 그러나 16 배 이상으로 확대하더라도 결과는 여전히 타당합니다. 긴 직선은 결국 약간 흔들리지 만 전형적인 "블록킹"샘플링 아티팩트는 없습니다.

점에서 쿼드를 생성하기 위해 지오메트리 쉐이더를 사용할 수 있지만 (버스 대역폭 감소) 솔직히 게인은 다소 미미합니다. GPG8에 설명 된 인스턴스화 된 문자 렌더링의 경우에도 마찬가지입니다. 인스 턴싱의 오버 헤드는 많은 그릴 텍스트가 . 필자의 의견으로는 추가 된 복잡성과 비 다운 그레이드 가능성과 관련이 없다고 생각합니다. 또한 상수 레지스터의 양에 제한을 받거나 캐시 일관성에 대해 최적이 아닌 텍스처 버퍼 객체에서 읽어야합니다 (및 의도는 처음부터 최적화하는 것입니다!). 경우에만 상각됩니다
. 단순하고 평범한 오래된 정점 버퍼는 업로드 시간을 조금 앞당겨 예약하고 지난 15 년 동안 구축 된 모든 하드웨어에서 실행되는 것처럼 빠릅니다 (아마도 빠릅니다). 또한 글꼴의 특정 문자 수 또는 렌더링 할 특정 문자 수로 제한되지 않습니다.

글꼴에 256자를 초과하지 않는 경우 텍스처 셰이더는 지오메트리 셰이더의 포인트에서 쿼드를 생성하는 것과 유사한 방식으로 버스 대역폭을 제거하는 것이 좋습니다. 배열 텍스처를 사용할 때 모든 쿼드의 텍스처 좌표는 동일하고, 상수 s이며, t좌표 는 동일 하며 좌표 만 다릅니다 r. 이는 렌더링 할 문자 인덱스와 같습니다.
그러나 다른 기술과 마찬가지로 이전 세대 하드웨어와 호환되지 않으면 예상되는 이득은 미미합니다.

거리 텍스처를 생성하기위한 Jonathan Dummer의 편리한 도구가 있습니다 : description page

업데이트 :
최근에 프로그래밍 가능한 정점 풀링 (D. Rákos, "OpenGL Insights", pp. 239) 에서 지적했듯이 최신 GPU의 셰이더에서 프로그래밍 방식으로 정점 데이터를 가져 오는 것과 관련된 추가 대기 시간이나 오버 헤드는 없습니다. 표준 고정 기능을 사용하여 동일한 작업을 수행하는 것과 비교할 때
또한 최신 세대의 GPU는 점점 더 합리적인 크기의 범용 L2 캐시 (예 : 엔비디아 케플러의 1536kiB)를 가지므로 버퍼 텍스처에서 쿼드 코너에 대한 임의의 오프셋을 가져올 때 비 일관적인 액세스 문제가 발생할 수 있습니다. 문제.

따라서 버퍼 텍스처에서 일정한 데이터 (예 : 쿼드 크기)를 가져 오는 아이디어가 더 매력적입니다. 따라서 가상 구현은 다음과 같은 접근 방식으로 GPU 메모리뿐만 아니라 PCIe 및 메모리 전송을 최소로 줄일 수 있습니다.

• 이 색인을 통과하는 정점 셰이더에 대한 유일한 입력으로 문자 색인 (표시 할 문자 당 하나) 만 업로드 gl_VertexID하고을 형상 쉐이더의 4 점으로 증폭하여 문자 색인과 정점 ID를 유지하십시오. "버텍스 쉐이더에서 사용할 수있는 gl_primitiveID")가 유일한 속성으로 변환 피드백을 통해이를 캡처합니다.
• 두 가지 출력 속성 (GS의 주요 병목 현상) 만 있고 두 단계 모두에서 "no-op"에 가깝기 때문에 이것은 빠릅니다.
• 글꼴의 각 문자에 대해 기준점을 기준으로 질감 처리 된 쿼드의 정점 위치를 포함하는 버퍼 텍스처를 바인딩합니다 (기본적으로 "글꼴 메트릭"임). 이 데이터는 왼쪽 하단 정점의 오프셋 만 저장하고 축 정렬 상자의 너비와 높이를 인코딩하여 쿼드 당 4 개의 숫자로 압축 할 수 있습니다 (반 부동 수를 가정하면 문자 당 8 바이트의 상수 버퍼 임). 일반적인 256 문자 글꼴은 2kiB의 L1 캐시에 완전히 들어갈 수 있습니다).
• 기준선에 유니폼을 설정
• 버퍼 오프셋을 수평 오프셋과 바인딩합니다. 이것들 은 아마도 GPU에서 계산 될 수도 있지만, CPU에서 이런 종류의 작업에 훨씬 쉽고 효율적입니다. 왜냐하면 엄격하게 순차적 인 작업이므로 전혀 중요하지 않습니다 (커닝에 대한 생각). 또한 다른 피드백 포인트가 필요하며 이는 다른 동기 점입니다.
• 피드백 버퍼에서 이전에 생성 된 데이터를 렌더링하면 정점 셰이더는 기준점의 수평 오프셋과 버퍼 객체에서 코너 정점의 오프셋을 가져옵니다 (기본 ID 및 문자 색인 사용). 제출 된 정점의 원래 정점 ID는 이제 "기본 ID"입니다 (GS가 정점을 쿼드로 바꾼 것을 기억하십시오).

이와 같이, 단일 정점 만 렌더링 할 수는 있지만 필요한 정점 대역을 75 %까지 줄일 수 있습니다. 한 번의 호출로 여러 줄을 렌더링하려면 유니폼을 사용하는 대신 버퍼 텍스처에 기준선을 추가해야합니다 (대역폭이 더 작아짐).

그러나 "합리적인"양의 텍스트를 표시하는 정점 데이터가 약 50-100kiB (실제로 0)GPU 또는 PCIe 버스에 해당) 이기 때문에 75 % 감소를 가정하더라도 여전히 복잡성이 추가되는 것은 의심됩니다. 이전 버전과의 호환성을 잃는 것은 실제로 문제가 될만한 가치가 있습니다. 0을 75 % 줄이면 여전히 0입니다. 나는 위의 접근법을 시도하지 않았으며, 진정한 자격을 갖춘 진술을하기 위해서는 더 많은 연구가 필요할 것입니다. 그러나 여전히 누군가가 정말 놀라운 성능 차이 (수십억자가 아닌 "일반적인"양의 텍스트를 사용함)를 보여줄 수 없다면, 내 관점은 정점 데이터의 경우 단순하고 평범한 오래된 정점 버퍼가 충분히 훌륭하다는 것입니다. "최신 솔루션"의 일부로 간주됩니다. 간단하고 간단합니다.

위에서 " OpenGL Insights " 를 이미 참조 했으므로 Stefan Gustavson의 "거리 필드 별 2D 모양 렌더링" 장을 참조하여 거리 필드 렌더링에 대해 자세히 설명합니다.

2016 업데이트 :

한편, 극단적 인 배율에서 방해되는 코너 라운딩 인공물을 제거하는 것을 목표로하는 몇 가지 추가 기술이 존재한다.

한 가지 접근 방식은 단순히 거리 필드 대신 의사 거리 필드를 사용합니다 (차이는 실제 윤곽선이 아니라 가장자리 또는 가장자리 위로 튀어 나오는 가상 선 까지의 최단 거리라는 차이점이 있습니다). 이것은 약간 더 좋으며 같은 양의 텍스처 메모리를 사용하여 같은 속도 (동일한 셰이더)로 실행됩니다.

다른 접근법은 github에서 사용 가능한 3 채널 텍스처 세부 사항 및 구현에서 3 중위를 사용합니다 . 이는 이전에 문제를 해결하기 위해 사용 된 해킹 및 / 또는 해킹에 비해 개선되는 것입니다. 좋은 품질, 약간, 거의 눈에 띄지는 않지만 느리지 만 텍스처 메모리의 3 배를 사용합니다. 또한 추가 효과 (예 : 광선)를 제대로 맞추기가 더 어렵습니다.

마지막으로, 캐릭터를 구성하는 실제 베 지어 곡선을 저장하고 프래그먼트 셰이더로 평가하는 것은 약간 열악한 성능 (그러나 문제가되지는 않지만)과 가장 높은 배율에서도 놀라운 결과를 제공하여 실용적이되었습니다 .
이 기술을 사용하여 대형 PDF를 실시간으로 렌더링하는 WebGL 데모는 여기 에서 볼 수 있습니다 .

http://code.google.com/p/glyphy/

GLyphy와 다른 SDF 기반 OpenGL 렌더러의 주요 차이점은 대부분의 다른 프로젝트가 SDF를 텍스처로 샘플링한다는 것입니다. 여기에는 샘플링에 발생하는 모든 일반적인 문제가 있습니다. 즉. 윤곽을 왜곡하고 품질이 낮습니다. 대신 GLyphy는 GPU에 제출 된 실제 벡터를 사용하여 SDF를 나타냅니다. 결과적으로 고품질 렌더링이 가능합니다.

단점은 코드가 OpenGL ES가있는 iOS 용이라는 것입니다. 아마도 Windows / Linux OpenGL 4.x 포트를 만들 것입니다 (필자는 저자가 실제 문서를 추가 할 것입니다).

가장 널리 사용되는 기술은 여전히 ​​텍스처 쿼드입니다. 그러나 2005 년 LORIA는 벡터 텍스처라고 불리는 것을 개발했습니다. 즉 벡터 그래픽을 프리미티브의 텍스처로 렌더링합니다. 이것을 사용하여 TrueType 또는 OpenType 글꼴을 벡터 텍스처로 변환하면 다음을 얻을 수 있습니다.

http://alice.loria.fr/index.php/publications.html?Paper=VTM@2005

Mark Kilgard의 아기 NV_path_rendering (NVpr)이 위에서 언급되지 않은 것에 놀랐습니다 . 글꼴 렌더링보다 목표가 더 일반적이지만 글꼴과 커닝을 사용하여 텍스트를 렌더링 할 수도 있습니다. OpenGL 4.1도 필요하지 않지만 현재는 공급 업체 / Nvidia 전용 확장입니다. 기본적으로 glPathGlyphsNVfreetype2 라이브러리에 의존하는 메트릭을 사용하여 글꼴을 경로로 변환합니다 . 그런 다음 커닝 정보에 액세스하고 glGetPathSpacingNVNVpr의 일반 경로 렌더링 메커니즘을 사용하여 경로 "변환 된"글꼴을 사용하여 텍스트를 표시 할 수도 있습니다 . (실제로 변환되지 않으므로 곡선을 그대로 사용합니다.)

NVpr의 글꼴 기능에 대한 기록 데모는 불행하게도 특히 인상적이 아니다. (어쩌면 누군가가 intertubes에서 찾을 수 있는 많은 Snazzier SDF 데모 의 라인을 따라 만들어야 합니다 ...)

글꼴 부분에 대한 2011 NVpr API 프리젠 테이션 대화 는 여기서 시작 하여 다음 부분 에서 계속됩니다 . 프레젠테이션이 어떻게 분리되는지는 유감입니다.

NVpr에 대한보다 일반적인 자료 :

• Nvidia NVpr 허브 이지만 방문 페이지의 일부 자료는 최신 정보가 아닙니다.
• 경로 스텐 더링 방법의 두뇌를위한 Siggraph 2012 논문 , "스텐실, 그 다음 덮개"(StC); 이 백서에서는 Direct2D와 같은 경쟁 기술이 어떻게 작동하는지 간략하게 설명합니다. 폰트 관련 비트는 논문의 부록 으로 강등되었습니다 . 도 있습니다 비디오 / 데모 같은 일부 엑스트라 .
• 업데이트 상태에 대한 GTC 2014 프레젠테이션 ; 간단히 말해 이제 Google의 Skia (Nvidia는 2013 년 말과 2014 년에 코드를 제공함)에서 지원하며, 이는 Adobe Illustrator CC 2014의 베타 버전에서 Chrome과 [Skia와는 독립적으로] 사용됩니다.
• OpenGL 확장 레지스트리의 공식 문서
• USPTO는 NVpr과 관련하여 Kilgard / Nvidia에 4 개 이상의 특허를 부여했으며, St869를 직접 구현하려는 경우 US8698837 , US8698808 , US8704830 및 US8730253 과 같은 경우가 있습니다. 이 문서에 17 개의 USPTO 문서가 "발행 됨"으로 연결되어 있으며 그 중 대부분은 특허 출원이므로 그로부터 더 많은 특허가 부여 될 수 있습니다.

그리고 "stencil"이라는 단어가 내 대답 이전에이 페이지에서 어떤 조회도 생성하지 않았으므로, 지금까지이 페이지에 참여한 SO 커뮤니티의 하위 집합은 테셀레이션이없는 스텐실 버퍼- 일반적인 경로 / 글꼴 렌더링 방법. Kilgard는 OpenGL 포럼에 FAQ와 유사한 게시물을 제공하며, 테셀레이션이없는 경로 렌더링 방법이 여전히 [GP] GPU를 사용하고 있음에도 불구하고 bog 표준 3D 그래픽과 어떻게 다른지 알 수 있습니다. (NVpr에는 CUDA 가능 칩이 필요합니다.)

역사적인 관점에서, Kilgard는 1997 년 에 등장한 스텐실 기반 NVpr과 혼동해서는 안되는 고전적인 "텍스처 매핑 텍스트를위한 간단한 OpenGL 기반 API"(SGI, 1997 )의 저자이기도합니다.

NVpr과 같은 스텐실 기반 방법이나 GLyphy와 같은 SDF 기반 방법을 포함하여이 페이지에서 논의 된 모든 최신 방법은 아니지만 대부분은 다른 답변에서 이미 다루었으므로 여기서 더 이상 설명하지 않겠지 만 한 가지 제한 사항이 있습니다. 모든 스케일링 수준에서 재기없이 기존 (~ 100 DPI) 모니터의 대형 텍스트 디스플레이에 적합하며, 작은 크기에서도 높은 DPI, 망막 같은 디스플레이에서도 멋지게 보입니다. 그러나 Microsoft의 Direct2D + DirectWrite가 제공하는 기능을 완전히 제공하지는 않습니다. 즉, 주류 디스플레이에서 작은 글리프를 암시합니다. (일반적으로 힌트에 대한 시각적 조사는 예를 들어이 오타 테크 페이지 를 참조하십시오 . antigrain.com에 대한 자세한 정보가 있습니다 .)

현재 Microsoft가 암시로 할 수있는 일을 할 수있는 개방형 및 제품화 된 OpenGL 기반 제품에 대해 잘 모릅니다. (저는 Apple이 GL 기반 글꼴 / 경로 렌더링 작업을 수행하는 방법을 공개하지 않았기 때문에 Apple의 OS X GL / Quartz 내부에 대해 무지를 인정합니다. Mac OS 9와 달리 OS X는 그렇지 않습니다. 이는 모든 암시 할 어떤 사람을 귀찮게 ) 어쨌든,이 있습니다. 주소는 OpenGL 쉐이더를 통해 암시하는 것이 하나 개의 2013 연구 논문 INRIA의 니콜라스 P. Rougier가 쓴이; OpenGL에서 암시해야 할 경우 읽을 가치가 있습니다. freetype과 같은 라이브러리가 힌트를 줄 때 이미 모든 작업을 수행하는 것처럼 보이지만 실제로는 다음과 같은 이유로 그렇지 않습니다.

FreeType 라이브러리는 RGB 모드에서 하위 픽셀 앤티 앨리어싱을 사용하여 글리프를 래스터화할 수 있습니다. 그러나 글리프의 정확한 배치를 위해 서브 픽셀 위치를 달성하기를 원하기 때문에 이것은 문제의 절반에 불과합니다. 텍스처 픽셀을 분수 픽셀 좌표로 표시해도 전체 픽셀 레벨에서 텍스처 보간 만 발생하므로 문제를 해결하지 못합니다. 대신, 서브 픽셀 영역에서 정확한 이동 (0과 1 사이)을 달성하려고합니다. 이것은 프래그먼트 셰이더에서 수행 될 수 있습니다 [...].

해결책은 간단하지 않으므로 여기에서는 설명하지 않겠습니다. (용지는 공개되어 있습니다.)

Rougier의 논문에서 배운 또 다른 것은 (Kilgard가 고려하지 않은 것 같습니다) (Microsoft + Adobe) 글꼴 기능은 하나가 아닌 두 가지 커닝 사양 방법을 만들었습니다. 이전 테이블은 소위 kern 테이블을 기반으로하며 자유형 으로 지원됩니다. 새로운 것은 GPOS라고하며 자유 소프트웨어 세계에서 HarfBuzz 또는 pango와 같은 최신 글꼴 라이브러리에서만 지원됩니다. NVpr은 이러한 라이브러리 중 하나를 지원하지 않는 것 같으므로 일부 새로운 글꼴에 대해서는 NVpr에서 커닝이 작동하지 않을 수 있습니다. 이 포럼 토론 에 따르면 야생에있는 사람들이 분명히 있습니다.

마지막으로 복잡한 텍스트 레이아웃 (CTL) 을 수행해야하는 경우 OpenGL 기반 라이브러리가 존재하지 않는 것처럼 OpenGL을 사용하면 운이 좋지 않은 것 같습니다. (다른 한편으로는 DirectWrite가 CTL을 처리 할 수 ​​있습니다.) CTL을 렌더링 할 수있는 HarfBuzz와 같은 오픈 소스 라이브러리가 있지만 스텐실 기반 방법을 사용할 때와 같이 CTL을 잘 작동시키는 방법을 모르겠습니다. OpenGL. 모양이 변경된 윤곽선을 추출하여 경로로 NVpr 또는 SDF 기반 솔루션에 공급하려면 접착 코드를 작성해야합니다.

OpenGL 백엔드 로 cairo 그래픽 을 보는 것이 가장 좋습니다 .

3.3 코어로 프로토 타입을 개발할 때 내가 겪었던 유일한 문제는 OpenGL 백엔드에서 더 이상 사용되지 않는 기능이었습니다. 1-2 년 전에 상황이 개선되었을 수 있습니다 ...

어쨌든 미래의 데스크탑 OpenGL 그래픽 드라이버가 OpenVG를 구현하기를 바랍니다.