Post Lists

2019년 10월 16일 수요일

외적 합목적성. 의지의 객관화의 여러 단계

p 271 ~ 272.
 하지만 우리는 또한 의지의 적절한 객관성과 떼어놓을 수 없는, 의지 현상이 단계별로 나타나야 한다는 내적인 필연성도 이러한 현상 자체의 전체에서 외적인 필연성을 통해 표현되는 것을 발견한다. 말하자면 외적 필연성에 의해 인간이 자신을 유지하기 위해서는 도움이 필요하며, 이들 동물은 단계별로 하위의 동물과 아울러 식물도 필요로 하며, 식물은 다시 땅을 필요로 해서, 물이나 화학적 요소 및 그 화합물을 필요로 하며, 행성이나 태양, 이러한 태양을 중심으로 한 자전과 공전, 황도의 경사 등을 필요한다. 요컨대 이것은 의지 이외에는 아무것도 없고, 또 의지는 허기진 의지이기 때문에 의지 자체가 자신을 먹어치우며 살아가야 하는데 기인한다. 추구, 불안 및 고뇌가 생기는 것은 이 때문이다.

현상들이 한없이 상이하고 다양하지만 물자체인 의지가 단일하다는 인식이야말로 자연의 모든 산물들이 놀라울 정도로 확실히 유사하다는 사실과, 함께 주어진 것은 아니지만 같은 테마의 변종이라고 볼 수 있는 친족 간의 유사성에 대해 진정한 해명을 해주듯이, 우리가 방금 살펴본 등급의 필연성, 세계의 모든 부분들의 본질적인 연관인 앞서 말한 화음, 같은 정도로 분명하고도 깊이 파악된 이런 것을 인식함으로써 우리에게는 내적인 본질, 우리가 심지어 고찰하고 평가하면서 선천적이라고 전제하는 모든 유기적인 자연 산물의의 부인할 수 없는 합목적성의 의미를 참되고도 충분하게 통찰할 수 있는 길이 열리게 될 것이다.

이러한 합목적성에는 두 가지 종류가 있다. 한 가지는 내적 합목적성으로, 즉 어떤 개별적인 유기체의 모든 부분들이 질서 있게 일치해서 그로 인해 유기체와 그 것의 류가 유지되고, 그 때문에 유기체와 그 류의 유지가 질서의 목표로 나타나는 것이 내적 합목적성이다. 그런데 다른 한 가지는 외적 합목적성으로, 말하자면 전체 유기적 자연이나, 또는 개별적인 동물 류의 유지를 가능하게 하고, 그 때문에 이러한 목표에 대한 수단으로서 우리의 평가에 맞서는, 일반적으로 비유기적인 자연의 유기적인 자연에 대한 관계나, 또는 유기적 자연의 개별적 부분들 상호간의 관계도 외적 합목적성이다.

우리는 의지한다. 의지의 현상이기 때문에. 우리는 어떤 것을 의지하기 위해, 여러 가지 단계들을 거쳐 생겨났다. 의지의 객관화의 낮은 것 부터 높은 것 까지 거쳐서 우리가 의식하며 행동을 하게 된 것이다. 우리는 그 단계 없이는 존재할 수 없는 것이다.

모든 사람 사이의 관계도 그렇다. 낮은 단계에서부터 높은 단계로 올라가는 것이다. 내가 현재 이렇게 살아갈 수 있는 것은 가장 낮은 단계에서부터 높은 단계를 거쳐 나를 도와준 모든 것들이 있기 때문이다. 우리는 의지의 특성대로 그러한 낮은 단계에서부터 먹어치우며 살아오게 된 것이다.

내적 합목적성에 관한 것은 여러가지 관계 비유를 통해 드러나기 때문에 다음에 다뤄야 할 것 같다.

2019년 10월 15일 화요일

NVIDIA G-Sync Review

https://www.anandtech.com/show/7582/nvidia-gsync-review

그것은 CES에서 거의 12달 전에 시작했었다. NVIDIA는 GeForece Experience를 발표했는데, 그것은 너가 플레이하는 게임들에서 너의 PC를 위한 최적의 graphics settings을 골라주는 문제에 대한 소프트웨어 솔루션이다. 콘솔 게임들로는, 그 개발자는 이미 visual quality와 frame rate의 올바른 균형인 것을 고르도록 했다. PC에서, 이러한 결정권은 최종 사용자에게 넘겨진다. 우리는 몇 게임들이 이용가능한 그래픽 옵션들을 제한하여 그 문제를 시도하려 해결했지만, 그것을 제외하고, 많이 널리퍼진 관심을 보지 않은 것이 문제이다. 결국, PC 게이머들은 설정을 만지작 거리는데 익숙하다 - 그것은 경험의 예측된 부분이다. PC gaming user base를 넓히려는 시도로서 (다음 세대 console wins의 부재에 의해 어느정도 동기부여 받은), NVIDIA는 GeForece Experience를 내놓았다. NVIDIA는 이미 넓은 범위의 NVIDIA 하드웨어에 걸쳐서 수 많은 게임들을 테스트 했다. 그래서 그것은 각 게임/PC 조합에 대해 무엇이 가장 좋은 설정인지에 대한 좋은 아이디어를 가지고 있다.

또한 CES 2013에서, NVIDIA는 Project Shield를 발표했는데, 나중에 그냥 Shield로 다시 이름 붙여졌다. 어느정도 이상하지만놀랍게 멋진 portable Android gaming system은 또 다른 기능의 역할을 했다 : 그것은 너의 TV에서 PC 게임들을 플레이하도록 사용될 수 있는데, 너의 PC로부터 직접 스트리밍 한다.

마침내, NVIDIA는 조용히 (최근에 매우 조용히는 아니고), Valve와 함께, 그것의 SteamOS and Steam Machine efforts에 참여했다 (인정하건데, AMD도 그랬다).

내 견해로는, 그것은 확실히, NVIDIA가 콘솔 게임의 어떤 측면들을 PC로 가져오려는 것처럼 보인다. 너는 더 나아가서, NVIDIA가 더 높은 퀄리티의 그래픽스와 더 높은 프레임율을 집중하기 보다는 여러 방식들로 게이밍을 향상시키기 위해 매우 동기부여 받은 것처럼 보인다고 말할 수 있다.

이러한 모든 것은 결국 이해가 된다. ATI와 AMD가 완전히 통합하면서, 그리고 Intel이 마침내 그래피스를 (어느정도) 진지하게 여기면서, NVIDIA는 앞으로 나아가는 산업에서 관련되도록 (그리고 주가 되도록) 좀 더 많은 것을 할 필요가 있었다. 간단히 좋은 GPUs를 만드는 것은 지금까지 그 회사만 필요할 것이다.

NVIDIA의 최신 시도는 G-Sync인데, 지원되는 NVIDIA graphics card에 의해 주도되는 semi-variable refresh rate를 활성화 하는 hardware solution이다. 그 전제는 이해하기에 간단하다. Displays와 GPUs는 본질적으로 비동기적으로 컨텐츠를 업데이트 한다. 한 display panel은 고정된 간격으로 (그것의 refresh rate로) 그 자체를 업데이트 하는데, 보통 대부분의 패널들에 대해 60 times per second (60 Hz) 이다. 게임에 특화된 displays는 120Hz 또는 144Hz의 더 높은 refresh rates를 지원할지도 모른다. 반면 GPUs는 가능한 빠르게 frames를 렌더링하고, 그것들이 처리될 때 마다 그것들을 display에게 보여준다.

너가 refresh 중간에 도착한 한 frame을 가질 떄, 그 display는 동시에 그 스크린에 여러 프레임들의 일부를 그리게 된다. 동시에 여러 frames의 일부를 그리는 것은 visual artifacts, or teras의 결과를 만들 수 있고, 개별 프레임들을 분리한다. 너는 tearing이 screen에 스크롤되는 것처럼 수평의 lines/artifacts된 것을 눈치챌 것이다. 그것은 매우 산만하다.

GPU와 display가 sync를 맞추어 tearing을 피할 수 있다. vsync를 활성화하는 것은 이것을 한다. 그 GPU는 panel의 refresh rate로 display에 sync를 맞추어 frames들을 전달할것이다. Tearing은 사라지지만, 너는 새로운 artifact를 얻는다 : stuttering.

한 게임의 각 frame의 내용은 급격하게 변할 수 있기 때문에, 그 GPU의 frame rate는 비슷하게 가변적일 수 있다. 또 다시, 우리는 GPU가 그 display로 sync없이 한 프레임을 보여주길 원하는 상황에 있는 우리자신을 발견하게 된다. vsync가 활성화 되었을 때, 그 GPU는 다음 refresh period까지 그 frame을 전달하는 것을 기다리는데, 이것은 그 중간에서 한 반복적인 프레임을 만들어 낸다. 이 반복된 frame은 그 자체로 stuttering으로서 명백해진다. 너가 완벽하게 너의 refresh rate와 일치하지 않는 frame rate를 가지는 한, 너는 보이는 stuttering의 잠재성을 얻게 된다.


G-Sync는 두 세계의 최상의 것을 제안한다고 주장한다. 간단히 말해서, G-Sync는 GPU가 새로운 프레임으로 준비가 될 때 까지, 그 display가 refresh 하는 것을 기다리도록 만들려고 시도한다. tearing도 없고, 어떠한 stuttering도 없이 - 그냥 buttery smoothness가 되도록. 물론, G-Sync display가 있는 NVIDIA GPUs들에서만 이용가능 하다. 항상 그렇듯이, 악은 세부사항에 있다.

How it Works
G-Sync는 hardware solution이고, 이 경우에, 그 hardware는 G-Sync가 활성화된 display안에 있다. NVIDIA는 G-Sync board를 위해 display의 scaler를 바꾸는데, 그 panel과 timing controller (TCON)를 손대지 않는다. display chain에서 그것의 physical location에도 불구하고, 현재의 G-Sync board는 실제로 hardware scaler의 특징을 가지지 않는다. 그것의 의도된 목적을 이ㅜ해서, 어떠한 scaling hardware의 결여는 큰 문제가 아니다. 너가 panel을 움직이고 모든 scaling duties를 처리하는 가능한 한 개 이상의 GPU를 가질 것이기 때문이다.

G-Sync는 그 display의 VBLANK (vertical blanking interval)를 조작하여 작동한다. VBLANK는 현재 프레임의 마지막 line을 rasterizing하는 display와 그 다음 프레임의 첫 번째 line을 그리는 display 사이의 시간 주기이다. 이것은 한 interval이라고 불려지는데, 이 주기동안 어떠한 screen updates가 발생하지 않기 때문에 그 display는 static하게 남아 있는데, 다음의 것을 그리기 전에 현재 프레임을 보여주고 있게 된다. VBLANK는 CRT 시절의 남응ㄴ 부분인데, 거기에서 CRTs에게 그 display의 top에서 scanning을 시작할 시간을 주는 것이 필수적이였다. 그 interval은 오늘날 LCD flat panels에서 남아 있는데, 비록 그것이 기술적으로 필수적일지 아니라도. display안의 G-Sync module은 GPU가 새로운 것을 가져다 줄 준비가 될 때 까지 display가 현재의 frame을 유지하도록 VBLANK를 수정한다.

G-Sync가 활성화된 display로, 그 모니터가 현재 프레임을 그리는 게 끝났을 때, 다음의 draw process가 시작하기전에 그것은 그 GPU가 display를 위해 준비된 또 다른 것을 가질 때 까지 기다린다. 그 delay는 순수하게 VBLANK interval를 조정하여 제어디ㅗㄴ다.

근데 너는 VBLANK 조작으로만 그렇게 할 수 있다. 현재의 구현에서, NVIDIA가 단일 프레임을 유지할 수 있는 가장 긴 시간은 33.3ms (30Hz)이다. 만약 그 다음 프레임이 그 때 까지 준비가 되지 않았다면, 그 G-Sync module은 그 display에게 그 마지막 frame을 다시 그리라고 말할 것이다. 상한은 이 시점에서 panel/TCON에 의해서 제한되는데, 오늘날 이용가능한 유일한 G-Sync monitor는 6.94ms(144Hz)까지 올라간다. NVIDIA는 그 144Hz 제한이 G-Sync limit이 아니라, panel limit이라고 언급했다.

그 G-Sync board는 그 자체로 FPGA와 DDR3 memory 768MB 특징을 가진다. NVIDIA는 on-board DRAM이 너가 일반적으로 디스플레이 안에서 보는 scaler보다 더 크지 않다고 주장한다. 그 추가된 DRAM은 부분적으로 메모리에 대해 좀 더 많은 bandwidth를 고려하는데 필수적이다 (추가적인 physical DRAM devices). NVIDIA는 많은 것들을 위해 그 메모리를 사용하는데, 그것 중의 하나는 이전 프레임을 저장하는 것이다. overdrive calculations에 대해 들어오는 frame에 대해 비교될 수 있게 하기 이ㅜ해서이다.

그 첫 번째 G-Sync module은 DisplayPort 1.2에 대해서 output만을 지원하는데, 비록 기술적으로 NVIDIA가 미래 버전의 HDMI/DVI에 대한 지원을 추가하는 것을 막는 것은 없을지라도. 유사하게, 현재 G-Sync board는 audio를 지원하지 않지만, NVIDIA는 그것이 미래 버전에 추ㅏㄱ될 수 있다고 주장한다 (NVIDIA의 생각은 여기에서, 대부분의 게이머들이 그들의 displays에 통합된 스피커보다는 다른 어떤 것을 원할 것이라는 것이다). 그 첫 번째 G-Sync 구현의 마지막 한계는, 그것은 오직 LVDS의 displays에만 연결될 수 있다느 ㄴ것이다. NVIDIA는 G-Sync module의 다음 버전에서 V-by-One 지원을 활성화할 계획인데, 비록 그것이 eDP support를 또한 활성화하는 것을 막을게 없을지라도.

G-Sync를 활성화 하는 것은 작지만 frame rate에 측정할만한 성능의 영향으 락진다. 그 GPU가 G-Sync가 활성화된채로 한 프레임을 렌더링한 후에, 그것은 그 GPU가 scan out의 중간에 scan을 하지 않을 것으 보장하기 위해 그것이 VBLANK period에 있는지 아닌지를 보기위해 display를 조회하기 시작한다. 그 조회는 약 1ms가 걸리는데, 이것은 v-sync on에 비교하여 3-5% 성능 영향을 가진다. NVIDIA는 그 polling을 전적으로 제거하려고 작업중이지만, 현재 그것이 처리되는 방법이다.


... 하드웨어에 대한 주 내요이라 생략...

반발력과 견인력

의지와 표상으로서의 세계 p.264
마침내 우리는, 말하자면 의지 현상의 본질이
칸트에 의해 반발력과 견인력으로 올바로 표현된 한에서,
심지어 단순한 물질에서 이미, 투쟁 그 자체로서 보면,
이제까지 고찰한 모든 의지 현상들의 서로에 대한 투쟁을 다시 인식할 수 있다.
그리하여 물질은 서로에 맞서는 힘들의 투쟁 속에서만 자신의 존재를 갖게 된다.

만약 우리가 물질의 모든 화학적 차이를 도외시하거나,
또는 원인과 결과의 연쇄를 아주 멀리, 화학적 차이가 없는 곳 까지
거슬러 올라가 생각해보면, 우리에게 남는 것은 이제 단순한 물질,
구형으로 된 세계, 그 세계의 삶, 즉 의지의 객관화를 이루는 견인력과
반발력 간의 투쟁인 것이다.

오늘은 카페에 와서 쇼펜하우어를 잠시 읽었다. 제대로 집중해서 책을 읽은지가 오래 되었었다. 오늘은 약간 무언가 착잡하고 외로운 기분이 들었지만, 위의 구절을 읽고나서 부정적인 기운이 달아나 버렸다. 항상 무언가 힘들어질려고 할 때 마다 나에게 힘을 주는 책이다. 나도 이러한 도움이되는 나의 철학을 글로 써서 남들을 도와주고 싶다.

오늘 예비군 훈련이 끝나고 돌아오고 나서, 밥 먹으러 나오면서 고민했다. 지금 나는 삶의 의미를 잃고 있는 거 같다고. 나는 이전 포스트들 중에서도 말했듯이, 나의 삶의 의미가 무엇인지 알지만, 그것을 항상 명확히 인지하고 체화하는 수준이 되지 못했다. 그래서 삶의 의미를 찾는다는 것은 무엇일까? 라는 생각을 하면서 밥을 먹으러 갔고 밥을 먹었다. 밥을 먹으러 가는 중에 생각한 것은 삶의 의미를 찾는다는 것은 "돈을 잘 벌게 되는 것일까", "유명세를 얻어 인기 있어 지는 것일까", 등의 여러 물질적인 것, 의미 없는 것들에 대해 생각이 나왔지만, 그런 것들은 반드시 아니라는 생각이 나의 마음속에서 튀어나 왔다. 밥을 먹고 나와서는 생각 없이 카페에 와서 위의 구절을 읽고 머리 속에 있던 복잡하고 부정적인 생각들이 깔끔히 사라졌다. 쇼펜하우어가 내 머릿 속을 정리해준 느낌이였다.

다시 아까 집을 나서면서 가졌던 질문들에 대해서 이야기 하자면, 내가 아까 생각했던 질문에 대한 물질적인 답은 '삶의 의미'에 대한 것이고, '삶의 의미를 찾는 것'은 좀 더 다른 것이다. 어쨋든 그 두 가지에 대해서 다시 정리를 해야할 것이다. '삶의 의미를 찾는 것'은 나를 찾는 것이다. 나 자신이 되는 것이다. 그리고 나는그렇게 되려고 시도 했고, 그 시도는 성공했다. 그 결과로 나는 '삶의 의미'에 대한 답을 이미 알고 있었었기에, 이전에 찾아 놓았었기에, 그리고 또 다시 그것이 맞다고 생각했기에, '삶의 의미'도 자연스럽게 나에게 다시 들어오게 되었다. 사람의 고유의 성격은 바뀌지 않는다.

2019년 10월 14일 월요일

Fast Sync & SLI Updates : Less Latency, Fewer GPUs

https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/13

2012년의 Kepler와 GTX 680 이후로, GPU 개발에서 NVIDIA의 side projects들 중 하나는 input lag를 줄이는 방법들을 고안하는 것이다. NVIDIA의 뛰어나고 (그리고 다재다능한 front man) Tom Petersen 엔지니어의 조심스러운 시야아래에서, 그 회사는 그 문제를 다루기 위해 몇년 간 두 개의 다른 기술들을 도입했다. Kepler는 adaptive v-sync를 도입했다 - 그 frame rate가 refresh rate아래로 내려갈 때, v-sync를 동적으로 비활성화하는 능력이다.  그리고 2013년에 물론, 그 회사는 그들의 G-sync variable refresh rate technology를 도입했다.

그 때 이후로, Tom의 team은 v-sync의 규칙을 바꿀 또 다른 방법을 아직 작업 중이다. Pascal과 관련된 것은 NVDIA가 Fast sync라고 부르는 새로운 v-sync 모드이다. 그리고 v-sync를 유지하면서 input lag를 줄이는 또 다른 방법을 제안하도록 설계되었다.

Fast Sync가 완전 새로운 아이디어가 아니라, 오히려 오래된 아이디어의 현대의 그리고 좀 더 일관적인 태도라는 것을 주목하는 것이 흥미롭다 : triple buffering. 현대에서, triple buffering은 순차적인 frame queue로서 작동하는 3개의 내부 버퍼인데, 몇 게임들과 비디오 카드들은 triple buffering은 조금 다르게 처리했다. 3개의 버퍼들을 순차적인 queue로서 사용하기 보다는, 그것들은 대신에 항상 가장 오래된 buffer에 덮어쓰곤 했다. 이 작은 변화는 input lag에 잠재적으로 중요한 변화를 가졌었다. 그리고 만약 너가 old school triple buffering과 친숙하다며 너는 어디에서 이것이 발생하는지를 안다.

Fast Sync로, NVIDIA는 driver level에서 old school triple buffering을 구현했고, 또 다시, 현대의 그리픽 카드로 사용가능하게 만들었다. Fast Sync를 구현하는 목적은 refresh rate보다 더 높은 frame rate를 만들 수 있는 현대의 게임에서 input lag를 줄이기 위해서 인데, NVIDIA는 구체적으로 CS:GO과 다른 그래픽적으로 간단한 twitch games들을 타겟으로 한다.

그러나 어떻게 Fast Sync가 실제로 input lag를 줄이는가? 이것을 좀 더 들어가기 위해, 내가 아래에서 작성한 2009년의 old school triple buffering에 좋은 글이 있다. 7년 후에, 그 이름을 제외하고 기술적 세부사항은 여전히 NVIDIA의 Fast Sync 구현과 정확하다.

What are Double Buffering, V-sync, and Triple Buffering
한 컴퓨터가 한 모니터에 어떤 것을 display하길 원할 때, 그것은 그 스크린이 어떻게 보내져야 하는지의 그림을 그리고, (우리가 한 버퍼라고 부를) 이 사진을 모니터에게 보낸다. 옛날시절에, 오직 한 개의 버퍼가 있었고, 그것은 지속적으로 모니터에게 그려지고 보내지는 둘 다가 되었다. 이 접근법에 몇 가지 이점들이 있지만, 매우 큰 단점들이 있다. 가장 뚜렷하게, display에 있는 objects들이 업데이트 될 때, 그것들은 종종 깜빡 거린다.

그 같은 buffer에 drawing하는 동안 reading하는 것의 문제와 싸우기 위해, 최소한 double buffering이 이용된다. double buffering 뒤에 있는 아이디어는 그 컴퓨터가 오직 한 버퍼에만 ("back" buffer라고 불려지는) 그리고 그 다른 버퍼를 ("front" buffer라고 불려지는) 것을 스크린에 보낸다. 그 컴퓨터가 그 back buffer를 다 그리고나서, 그 drawing을 하는 그 프로그램은 buffer "swap"이라고 불려지는 것을 한다. 이 swap은 어떠한 것도 움직이게 하지 않는다 : 그 두 버퍼들의 이름만 바꾼다: 그 front buffer가 back buffer가 되고, back buffer가 front buffer가 된다.

buffer swap 이후에, 그 software는 새로운 back buffer에 그리기 시작할 수 있고, 그리고 그 컴퓨터는 그 다음 buffer swap이 발생할 때 까지 그 모니터에 새로운 front buffer를 보낼 수 있다.

double buffering의 이 형태에서, 한 swap은 언제든지 발생할 수 있다. 그것은 그 컴퓨터가 모니터에 데이터를 보내는 동안, 그 swap이 발생할 수 있다는 것을 의미한다. 이것이 발생할 때, 그 스크린의 나머지는 그 새로운 front buffer가 포함하는 것을 따라 그려진다. 만약 그 새로운 front buffer가 이전의 front buffer와 충분히 다르다면, "tearing" 이라고 알려진 visual artifact가 보일 수 있다.  이러한 유형의 문제는 갑자기 빠르게 움직일 때의 high framerate FPS 게임들에서 종종 보일 수 있다. 빠른 움직임 때문에, 모든 frame은 매우 다르고, drawing하는 동안 한 swap이 발생할 때, 그 불일치는 크고, 산만해질 수 있다.

tearing과 싸우는 가장 흔한 접근법은 그 monitor가 또 다른 image가 준비될 때 까지 swap buffers를 기다리는 것이다. 그 모니터는 완전히 그것에게 보내진 것을 그리고, 다음 vertical refresh cycle이 시작하려 한 후에 준비가 된다. Vertical refresh로 buffer swaps를 Synchronizing하는 것은 V-sync라고 불려진다.

V-sync를 활성화 하는 것은 tearing을 고치지만, 그것은 또한 게임의 내부 frame rate를 최대 monitor의 refresh rate로 설정한다 (일반적으로 대부분의 LCD panels에 대해 60Hz). 이것은 비록 그 게임이 60 FPS로 작동하지 않을지라도, 성능에 해를 줄 수 있다. 동기화 효과를 위해 추가된 인공적인 지연이 여전히 있을 것이기 때문이다. 성능은 모든 프레임이 16.67ms (1초의 1/60)보다 더 길게 걸리는 half cases 경우에 거의 줄어들 수 있다. 그러한 경우에, frame rate는 그 게임이 60 FPS로 작동해야 한다는 사실에도 불구하고, 30FPS로 떨어질 것이다. 그러나, tearing의 제거와, framerate의 일관성은 V-sync 없는 double buffering이 보여줄 수 없는 추가된 부드러움에 기여한다.

Input lag(입력 지연)은 V-sync가 활성화 되었을 때 좀 더 문제가 된다. 이것은 왜냐하면 도입된 artificial delay(인공 지연)이 실제로 발생했을 때 (그 프레임이 그려지고 있을 때)와 그것이 스크린에 보일 때 사이의 차이를 증가시키기 때문이다. Input lag는 항상 존재하지만 (스크린에 현재 발생하는 것을 즉각적으로 그리는 것은 불가능하다), 그 trick은 그것을 최소화하는 것이다.

double buffering으로 우리가 가진 옵션들은 V-sync없이 tearing같은 가능한 visual problems와 부정적으로 성능에 영향을 미치고, V-sync가 활성화되어 input lag를 증가시킬 수 있는 artificial delay 사이의 선택이다. 그러나 걱정할 것 없이, quality or actual performance에서 희생없이 두 개의 세계의 최상의 것들을 합치는 옵션이 있다. 그 옵션은 triple buffering이다.

그 이름은 많은 것을 준다 : triple buffering은 두개 대신에 세 개의 버펃르을 사용한다. 이 추가적인 버퍼는 그 컴퓨터에게 한 버퍼가 모니터에 보내지는동안 그 버퍼가 locked 되도록 유지할 충분한 space를 제공한다 (tearing을 피하기 위해서). 또한 그 소프트웨어가 그것이 가급적인 가능한 빠르게 그리는 것을 방해하지 않도록 하면서 (심지어, 한 개의 locked buffer와 함께, 그 소프트웨어가 앞 뒤로 bounce할 수 있는 두 개가 여전히 있다). 그 소프트웨어는 그 두 개의 back buffers 사이에 앞뒤로 그리고, refresh마다, 그 front buffer는 가장 최근에 완료되어 완전히 렌더링된 프레임을 포함한 back buffer에 대해 swapped 된다. 이 것은 그래픽 카드의 메모리에서 추가 공간을 잡아먹지만, 적어도 현재 그래픽카드가 512MB를 가지면서, 이 추가 공간은 더 이상 실제 문제가 아니다.

다시 말해서, triple buffering으로, 우리는 정확히 같은 높은 실제 성능을 얻고, V-sync가 비활성화된 설정의 비슷한 감소된 input lag를 얻는다. 그리고 동시에 visual quality를 얻고, V-sync가 활성화되었을 때의 부드러움을 얻는다.

그러나, 그 소프트웨어가 triple buffering할 때, 두 개의 back buffers에 scenes 뒤의 전체 시간 동안 여전히 그리고 있다는 것을 주목해라. 이것은 그 front buffer swap이 발생할 때, double buffering과 V-sync와 ㄷ르게, 우리는 artificial delay가 없다는 것을 의미한다. V-sync가 없는 double buffering과 다르게, 우리가 한 완전히 렌더링된 프레임을 모니터에게 보낸다면, 우리는 중간에 다른 프레임으로 바꾸지 않는다.

Fast Sync의 최종 결과는 v-sync와 input lag에 관련하여, 올바른 케이스들에서 우리가 효과를 볼 수 있다는 것이다. v-sync가 꺼진 것 처럼 끊임없이 프레임들을 렌더링하고, 그러고나서 가장 최근의 frame을 잡고, 나머지를 버려서, Fast Sync는 v-sync가 발생시키는 전통적으로 높은 input lag 없이 tearing을 방지하기 위해  v-sync가 여전히 사용될 수 있다는 것을 의미한다.

실제의 input lag benefits은 몇 가지 요인들에 의존할 것인데, frame rates와 display refresh rates를 포함한다. 그 최소한의 input lag는 한 프레임을 그리는데 걸리는 시간의 양이다 - v-sync가 꺼진 것처럼 - 그러고나서 너는 실제로 그 프레임을 display하기 위해서 다음 refresh interval를 기다려야만 한다. 평균의 법칙 덕분에, 그 frame rate가 높을 수록 (렌더링 시간이 짧을 수록), 한 프레임이 screen refresh 직전에 준비되는 odds(?)가 더 좋아지는데, 이것은 input lag의 평균량을 줄여준다. 이것은 frame draws사이의 완전한 16.7ms와 전통적인 double buffered setup이 있는 경우에 60Hz displays에 특히 해당한다.

NVIDIA의 예제 수치들은 높은 speed camera를 가진 CS:GO를 모니터링하여 얻어졌다. 나는 이러한 수치들을 확인할 수 없다 - 최대한의 마케팅 노력으로, 그것은 best-case scenario일 수 있다 - 그러나, 그들의 chart가 비합리적인 것은 아닌데, 특히 만약 그들의 v-sync example이 3-deep buffer를 사용한다면. Input lag는 v-sync 없이 더 높을 것이지만, v-sync를 켜는 것 보다 더 낮다 (잠재적으로 훨씬 그렇다). 결국, 최대한의 장점은 매우 높은 프레임율인데, 이것은 NVIDIA가 CS:GO 같은 게임들을 타게팅한 이유이다. refresh rate보다 더 높은 frame rate * times은 최상긔 결과를 만들기 때문이다.

위에서 말해진 것과 함께, 나는 Fast Sync가 순수하게 input lag에 관한 것이고, 부드러움(smoothness)을 다루지 않는다는 것에 주목할 것이다. 사실, 그것은 덜 smooth하게 만들지도 모르는데, 왜냐하면 그것은 본질적으로 frames을 떨어뜨리기 때문이다. frames 사이의 simulation time의 양은 변할 수 있다. 그러나, 높은 프레임율로, 이것은 문제가 되지 않을 것이다. 한 편, Fast Sync는 v-sync의 전력을 아끼는 이점 모두를 잃는 것을 의미한다; 프레임 사이에 쉬고 시간이 지나는 기회를 가지는 GPU보다는, 그것은 이제 full speed로 전체 시간동안 v-sync가 꺼진 것처럼 렌더링하고 있다.

마지막으로, Fast Sync가 NVIDIA의 다른 input lag reduction 기술과 어떻게 맞는지 명확히하는 것은 아마 유용하다. Fast Sync는 Adaptive V-Sync 또는 G-Sync를 대체하지 않지만, 오히려 그것들을 보상한다.


  • Adaptive V-Sync : framerates가 refresh rate보다 낮을 때, v-sync를 선별적으로 비활성화 하여, input lag를 낮춘다.
  • G-Sync : 한 프레임이 준비 되었을 때, 그 display의 maximum refresh rate까지 screen을 refresh하여, input lag를 줄인다.
  • Fast Sync : framerate가 그 display의 refresh rate를 넘을 때 GPU를 지연시키지 않고 input lag를 줄인다.
Fast Sync는 구체적으로 frame rates가 display의 refresh rate를 초과할 때의 경우를 다룬다. 만약 그 frame rate가 refresh rate보다 낮다면, 그러면 Fast Sync는 아무것도 하지 않는다. 왜냐하면 그것은 시작할 single frame을 렌더링하는데 한 refresh interval보다 더 걸리기 때문이다. 그리고 이것은 대신에 Adaptive Sync가 들어오는 곳이다. 만약 바란다면.

한 편, G-Sync와 함께 할 때, Fast Sync는 그 frame rate가 그 display의 maximum refresh rate를 초과할 때에만 중요해진다. 대부분의 G-Sync 모니터에 대해, 이것은 120-144Hz이다. 이전에 max refresh rate보다 높은 G-sync 옵션들은 tear하거나 (no v-sync) 또는 GPU를 대기시키는데 (v-sync), 그래서 이것은 또한 G-Sync에 대해 tear-free input lag option을 제공한다.























2019년 9월 23일 월요일

In Practice (2) - Text Rendering

https://learnopengl.com/In-Practice/Text-Rendering

Text Rendering
너의 그래픽스 어드벤쳐의 어떤 단계에서, 너는 OpenGL에서 text를 그리길 원할 것이다.너가 기대하는 것과 대조적으로, 스크린에 간단한 string을 렌더링하는 것은 OpenL 처럼 low-level library로 꽤 어렵다. 만약 너가 128개의 다른 문자들 보다 더만이 렌더링 하는 것에 신경쓰지 안는다면, 그러면 그것은 아마도 그러게 어렵지 않다. 각 문자가 다른 width, height and margin을 가지자마자 상황은 어려워질 것이다. 너가 사는 곳을 기반으로, 너는 또는 128개 이상의 문자들을 필요할지도 모른다. 그리고 너가 수학 표현 또는 음악 기호 같은 특수 기호를 표현하고 싶으면 어떨까? 텍스트를 꼭대기에서 바닥으로 렌더링하는 건 어떨까? 너가 text의 모든 이러한 복잡한 문제들에 대해 생각한다면, 이것이 OpenGL 같은 low-level API에 소가지 않는다는 것이 너를 놀라게 하지 않을 것이다.

OpenGL 내에 어떤 text capabilities에 대한 지원이 없기 때문에, 스크린에 텍스트를 렌더리아는 것에 대한 시스템을 정의하는 것은 너에게 달려있다. text characters에 대한 어떠한 그래픽적 primitives가 없기 때문에,우리는 창의적이여야만 한다. 어떤 예제기법들은: GL_LINES을통해 문자 모양을 그려서, letters의 3D meshes를 생성하거나 또는 3D 환경에서, 2Dquads에 문자 텍스쳐들을 렌더링한다.

대부분 종종 개발자들은 quads에 textures를 렌더링하는 것을 선택한다. 이러한 textured quads 자체를 렌더링하는 것은 너무 어렵지 안을 것이지만, 관련된 문자를 한 텍스쳐에 보내는 것은 어려울 수 있다. 이 튜토리얼에서, 우리는 몇 가지 방법들을 조사할 것이고, 좀 더 고급이지만 FreeType library를 사용하여 텍스트를 렌더링하는 유연한 기법을 구현 할 것이다.

Classical text rendering : bitmap fonts
이전 시절에, text를 렌더링하는 것은 너의 어플리케이션을 위해 원하는 한 font를 선택하는 것(또는 스스로 만들거나)과 그것들을 단일의 큰 텍스쳐에 복사하기 위해 이 font에서 모든 관련된 문자들을 추출하는 것을 포함했다. 이제부터 우리가 bitmap font라고 부르는 그러한 텍스쳐는 그 텍스쳐의 predefined regions에서 우리가 사용하길 원하는 모든 문자 기호들을 포함한다. 그 폰트의 이러한 문자 기호들은 glyphs라고 알려져있다. 각 glyph는 그것들과 관련된 텍스쳐좌표의 특정한 영역을 가진다. 너가한 문자를 렌더링하길 원할 때 마다, 너는 그 bitmap font의 이 섹션을 2D quad에 렌더링하여 해당 glyph를 선택한다.

여기에서, 너는 bitmap font를 가져와서 해당 glyphs를 텍스쳐로부터 샘플리아여 'OpenGL' text를 어떻게 렌더링하는지 알 수 있다. blending을 활성화하고, background를 투명하게 하여, 우리는 스크린에 렌더링된 문자열을 얻게 될 것이다. 이 특정한 bitmap font는 Codehead의 Bitmap Font Generator를 사용하여 생성되었다.

이 접근법은 몇 가지 장단점을 가진다. 첫 째로, 구현하기에 상대적으로 쉽다. 왜냐하면 bitmap fonts는 pre-rasterized 되어있기 때문에, 그것들은 꽤 효율적이다. 그러나, 그것은 유연하지 않다. 너가 다른 font를 렌더링하길 원할 때, 너는 한 완전한 새로운 bitmap font를 재컴파일 할 필요가 있다. 그리고 그 시스템은 단일 해상도로 제한된다; zooming 하는 것은 빠르게 pixelated edges를 보여줄 것이다. 게다가, 작은 문자 셋에만 제한된다. 그래서 확장된 또는 Unicode characters들은 종종 불가능하다.

이 접근법은 옛날 시절에 꽤 인기있었다 (그리고 여전히 그렇다), 왜냐하면 그것은 빠르고 어떤 플랫폼에서든지 작동하기 때문이다. 그러나 오늘날에서, 좀 더 유연한 접근법이 존재한다. 이러한 접근법들 중의 하나는 FreeType library를 사용하여 TrueType fonts를 불러오는 것이다.

Mordern text rendering : FreeType
FreeType은 fonts를 불러올 수 있고, 그것들을 bitmap에 렌더링하고, 몇 가지 font와 관련된 연산을 지원하는 소프트웨어 개발 라이브러리이다. 그것은 Mac OS X, Java, PlayStation Consoles, Linux, 그리고 Android에 의해 사용되는 인기있는 라이브러리이다. FreeType을 특히 매력적이게 만드는 것은 그것이 TrueType fonts를 불러올 수 있다는 것이다.

TrueType font는 pixels 또는 어떤 다른 scalable할 수 없는 솔루션이 아닌 수학적 공식(splines의 조합)으로 정의된 character glyphs의 집합이다. vector images와 유사ㅏ게, 그 rasterized font images는 절차적으로 너가 얻고싶어하는 선호되는 font height를 기반으로 생성될 수 있다. TrueType fonts를 사용하여, 우리는 쉽게 어떠한 퀄리티의 손실 없이, 다양한 사이즈를 가진 character glphys를 렌더링할 수 있다.

FreeType은 그것들의 웹사이트에서 다운로드 되어질 수 있다. 너는 그것들의 소스코드로부터라이브러리를 컴파일하는 것을 선택할 수 있고, 또는 만약 너의 타겟 플랫폼이 열거된다면 precompiled libraries중의 하나를 사용하는 것을 선태갈 수 있다. freetype.lib에 link하는것을 확실히 해라.그리고 너의 컴파일러가 그 헤더 파일이 어디에 있는지를 알게 하도록 ㅐ라.

그러고나서 그 적절한 헤더를 include하도록 해라.

FreeType이 하는 것은 이러한 TrueType fonts를 불러오고, 각 glyph에 대해 bitmap image를 생성하고, 몇 가지 metrics를 계산한다.우리는 텍스쳐를 생성하기 위해 이러한 bitmap imaes를 추출할 수 있고, 각 character glyph를 loaded metrics를 사용하여 적저리 위치시킬 수 있다.

한 font를 불러오기 위해, 우리가 해야하는 것은 FreeType library를 초기화하고, 그 font를 FreeType이 부르듯이 face로서 부르는 것이다. 여기에서 우리는 arial.ttf 라는 Windows/Fonts directory에서 복사된 TrueType font를 불러온다.

이러한 FreeType 함수들 각각은 에러가 발생할 때 마다 0이 아닌 정수를 반환하다.
우리가 그 face를 불러왔다면, 우리는 이 face로부터 우리가 추추라고 싶은 font size를 정의해야만 한다:

그 함수는 font의 width and height parameters를 설정한다. 그 width를 0으로 설정하는 것은 그 face가 주어진 height에 따라 width를 동적으로 계산하는 것을 허용한다.

FreeType face는 glyphs의 한 모음을 불러온다. 우리는 FT_Load_Char를 호출하여 active glyph로서 그러한 glyphs들 중 하나를 설정할 수 있다. 여기에서 우리는 그 문자 glyph 'X'를 부르는 것을 선택했다

FT_LOAD_RENDERER를 loadin flags중의 하나로 설정하여, 우리는 FreeType에게 우리가 face->flyph->bitmap을 통해 접근할 수 있는 우리를 위한 8-bit grayscale bitmap imae를 생성하라고 말한다.

그러나, 우리가 FreeType으로 불러오는 lyphs의 각각은 같은 size를 가지고 있지 안는다 (우리가 bitmap fonts로 가지고 있기 때문에). FreeType으로 생성된 bitmap imae는 한 문자의 visible part를 퐘하기에 충분히 크다. 예를들어, dot character '.'의 bitmap image는 문자 'X'의 bitmap image보다 더 작다. 이 이유 때문에, FreeType은 또한 각 문자가 얼마나 커야만 하는지와, 그것들을 적절히 어떻게 배치할지를 명시하는 몇 가지 측정치를 불러온다. 아래에 각 character glyph를 위해 계산하는 모든 측정치를 보여주는 이미지가 있다.

glyphs의 각각은 수평의 baseline에 있다 (horizontal arrow로 그려지는), 거기에서 어떤 lyphs는 정ㅎ확히 이 baseline의 위에 있다 ('X' 처럼) 또는 어떤 것은 baseline 아래에 있다 ('g' or 'p'처럼). 이러한 측정치들은 그 baseline에서 각 glyph를 적절히 배치하는 offsets을 정의한다. 그리고 각 glyph가 얼마나 커야하는지와 우리가 그 다음 glyph로 진해아기 위해 얼마나 많은 픽셀이 필요한지를 정의한다. 아래는 우리가 필요한 이러한 properties의 작은 목록이다.


  • width : face->glyph->bitmap.width로 접근되는 bitmap의 width (in pixels).
  • height : face->glyph->bitmap.rows로 접근되는 bitmap의 height (in pixels).
  • bearingX : horizontal bearing. face->glyph->bitmap_left로 접근되는데, 원점을 기준으로 bitmap의 horizontal position(in pixels).
  • bearingY : vertical bearing. face->glyph->bitmap_top으로 접근되는데, baseline을 기준으로 bitmap의 vertical position (in pixels).
  • advance : horizontal advance. face->glyph->advance.x를 통해 접근되는데, 현재 origin에서 다음 glyph의 origin으로 가는 horizontal distance (1 / 64th pixels).
우리는 character glyph를 가져오고, 그것의 metrics를 가져오고, 우리가 스크린에 한 문자를 렌더링하고 싶을 때 마다 한 텍스쳐를 생성할 수 있다. 그러나, 매 프레임마다 이것을 하는 것은 비효율적이다. 우리는 오히려 어플리케이션 어딘가에 생성된 데이터를 저장하고, 우리가 한 문자를 렌더링하고 싶을 때 마다 그것을 query하고 싶을 것이다. 우리는 우리가 map에 저장할 편리한 구조체를 정의할 것이다.

이 튜토리얼에 대해, 우리는 ASCII 문자 set의 처음부터 128개의 문자에 제한을 하여 상황을 간단하게 할 것이다. 각 문자에 대해, 우리는 텍스쳐를 생성하고, 그것의 관련된 데이터를 Character 구조체에 저장한다. 우리는 그 Character struct를 Characters map에 추가한다. 이 방식으로, 각 문자를 렌더링하는 요구되는 모든데이터는 나중을 위해 저장된다.

for loop내에서, 우리는 ASCII set의 128개의 문자를 열거하고, 그것들의 대응되는 character glyphs를 가져온다. 각 문자에 대해, 우리는 한 텍스쳐를 생성하고, 그것의 옵션들을 설정하고, 그것의 metrics를 저장한다. 여기에서 주목해야할 흥미로운 것은, 우리가 texture의 internalFormat과 foramt arguments로서 GL_RED를 사용한다는 것이다. 그 glyph으로부터 생성되는 bitmap은 grayscale의 8-bit image인데, 거기에서 각 color는 single byte로 나타내어진다. 이 이유 때문에, 우리는 bitmap buffer의 각 byte를 텍스쳐의 color value로서 저장하고 싶다. 우리는 각 byte가 그 텍스쳐 color의 red component로 대응되는 한 텍스쳐를 생성하여 이것을 한다. 만약 우리가 신경쓸 필요가 있는 한 텍스쳐의 컬러들을 나타내기 위히 한 single byte를 사용한다면, OpenGL의 제한은:

glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

OpenGL은 텍스쳐들이 모두 4-byte alignemtn를 가질 것을 요구한다. 예를들어, 그것들의 size는 항상 4 bytes의 배수이다. 보통, 이것은 대부분의 텍스쳐가 pixel당 4bytes 또는 4의 배수인 width를 가지고 있기 때문에 문제가 되지 않을 것이지만, 우리가 지금은 오직 pixel당 a single byte를 사용하기 때문에, 그것들은 어떤 width든 가질 수 있다. 그것의 unpack alignment를 1로 설정하여, 우리는 alignment issue가 없게 보장한다 (이것은 segmentation faults를 발생시킬 수 있다).

너가 glyphs를 처리하는 것을 마쳤다면, FreeType의 resources를 클리어하도록 해라.

Shaders
실제 glyphs를 렌더링하기 위해, 우리는 다음의 vertex shader를 사용할 것이다.

그 fragment shader는 두 개의 uniforms를 취한다. 하나는 glyph의 mono-colored bitmap image이고, 나머지 하나는 그 text의 final color를 조정하기 위한 color uniform이다. 우리는 처음에 bitmap texture의 color value를 샘플한다. 그 texture의 data는 red component에 저장되었기 때문에, 우리는 그 texture의 r 컴포넌트를 sampled alpha value로 샘플한다. 그 컬러의 alpha값을 다르게 하여, 최종 컬러는 모든 glyph의 배경 컬러에 대해 투명할 것이고, 실제 문자 픽셀에 대해 투며하지 않을 것이다. 우리는 또한 그 text color를 다르게 하기 위해 textColor uniform으로 RGB colors를 곱한다.

우리는 이것을 작동시킥 위해 blending을 활성화 시킬 필요가 있다.

projection matrix에 대해, 우리는 orthographic projection marix를 사용할 것이다. 텍스트를 렌더링하기 위해, 우리는 (보통) perspective가 필요하지 않고, orthographic projection matrix를 사용하는 것은 또한 우리가 스크린 좌표에 있는 모든 vertex 좌표를 명시하게 해준다, 만약 우리가 그것을 다음과 같이 설정한다면.

우리는 projection matrix의 bottom parameter를 0.0으로, 그것의 top parameter를 window height와 동일하게 설정한다. 그 결과는 우리가 스크린의 bottom part (0.0f)에서, 스크린의 top part (600.0f)의 범위의 가진 y값의 좌표를 명시하는 것이다. 이것은 (0.0, 0.0) 점이 bottom-left corner와 대응되는 것을 의미한다.

마지막은 quads를 렌더링하기 위한 VBO와 VAO를 생성하는 것이다. 이제, 우리는 VBO를 초기화 할 때 충분한 메모리를 보유하는데, 우리가 나중에 문자들을 렌더링할 때, VBO의 메모리를 업데이트할 수 있게 하기 위해서이다.

2D quad는 4개의 floats 중 6개의 정점을 요구한다. 그래서 우리는 6 * 4 floats의 메모리를 보유한다. 우리는 VBO의 메모리의 내용을 꽤 종종 업데이트할 것이기 때문에, 우리는 GL_DYNAMIC_DRAW로 메모리를 할당할 것이다.

Render line of text
한 문자를 렌더링하기 위해, 우리는 Characters map의 대응되는 Character struct를 추출하고, character의 metrics를 사용하여 quad의 dimension을 계산한다. quad의 계산된 수치들로, 우리는 동적으로 6개의 정점의 한 set을 생성한다. 우리는 glBufferSubData를 사용하여 VBO에 의해 관리되는 메모리 내용을 업데이트하기 위해 그것을 사용한다.

우리는 문자들의 한 string을 렌더링하는 RenderText라고 불리는 함수를 생성한다.

그 함수의 내용은 상대적으로 자기-설명적이다: 우리는 처음에 quad의 origin position을 계산하고 (xpos와 ypos로), 그리고 그 quad의 사이즈를 계산하고 (w와 h), 그리고 2D quad를 만들기 위해 6개의 정점을 생성한다. 우리가 scale로 각 metric를 scale 한다는것에 유의해라. 우리는 그러과서 VBO의 내용을 업데이트하고, quad를 렌더링한다.

코드의 다음 라인은 몇 가지 추가 주의를 요구한다.

어떤 문자들 ('p' 또는 'g')는 다소 baseline아래로 렌더링된다. 그래서 그 quad는 또한 RenderText의 y 값 아래에 배치되어야 한다. 그 baseline 밑으로 ypos를 움직이게 하기 위해 필요한 정확한 양은 glyph metrics를 통해서 알아질수 있다.

이 거리를 계산하기 위해, 우리는 한 glyph가 그 baseline 아래로 확장되는 거리를 알아내야할 필요가 있다; 이 거리는 빨간색 화살표로 표시된다. 너가 glyph metrics로부터 볼 수 있듯이, 우리는 glyphy의 height로부터 bearingY를 빼서 이 벡터의 길이를 계산한다. 이 값은  baseline에 있는 ('X') 처럼 문자들에 대해서는 0.0이고, baseline아래에 있는 ('g' or 'j') 문자들에 대해서는 양수이다.

만약 너가 모든 것을 옳게 했다면, 너는 이제 다음의 문장으로 텍스트의 스트링들을 성공적으로 렌더링할 수 있을 것이다.

너는 여기에서 이 예제의 코드를 볼 수 있다.

너에게 우리가 그 quad의 vertices를 어떻게 계산했는지에 대한 느낌을 주기위해, 우리는 실제 렌더링이 어떻게 보이는지 보기위해 blending을 disable할 수 있다.

여기에서 너는 명백히 상상의 baseline에 있는 대부분의 quads를 볼 수 있다. 반면에, 'p', '('같은 glyphs에 대응되는 quads는 아래쪽으로 내려간다.

Going further
이 튜토리얼은 FreeType library를 사용하여 TrueType fonts로 text rendering technique을 보여주었다. 그 접근법은 유연하고, scalable하고, 많은 문자 인코딩들과 작동한다. 그러나, 이 접근법은 너의 어플리케이션에 대해 overkill할 가능성이 높다. 왜냐하면 우리가 각 glyph에 대해 텍스쳐들을 생성하고 렌더링하기 때문이다. Performance-wise bitmap fonts가 선호되는데, 우리가 오직 모든 우리의 glyphs에 대해 한 텍스쳐만을 필요하기 때문이다. 가장 좋은 접근법은 FreeType으로 로드된 모든 문자 glyphs를 특징으로 가지고 있는 bitmap font texture를 생성하여 두 개의 접근법을 합치는 것이다. 이것은 렌더러에게 중요한 텍스쳐 스위치를 덜어주고, 각 glyph가 얼마나 packed 되었는냐를 기반으로, 꽤 성능을 아낄 수 있다.

FreeType fonts가 가진 또 다른 문제는, glyph textures가 fixed font size로 저장된다는 것이다. 그래서, jagged edges를 도입할 scaling의 중요한 양이 요구될지도 모른다. 게다가, glyphs에 대한 rotations는 그것들이 blurry하게 보이게 할지도 모른다. 이것은 실제 rasterized pixel color를 저장하는 대신에, pixel당 가장 가까운 glyph outline에 대한 거리를 저장하여 완화될 수 있따. 이 기법은 singed distance fields라고 불려지고, Valve가  3D 렌더링 어플리케이션에 놀랍게도 잘 작동하는 이 기법의 그들의 구현에 대해 몇년 전에 한 논문을 출판했다.


=================================================
어쨋든 나중에 Signed Distance Field Text Rendering을 공부해야할 것이다.

https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
https://wdobbie.com/post/gpu-text-rendering-with-vector-textures/
https://lambdacube3d.wordpress.com/2014/11/12/playing-around-with-font-rendering/
https://cs.uwaterloo.ca/~dberry/ATEP/StudentLectures/ThierryDelisle.pdf
https://forum.libcinder.org/#Topic/23286000001127007






2019년 9월 22일 일요일

just writing 2

I just wanna describe what i see,listen to, feel, think.

me writing something with computer.
The fan rotating around behind me.
The speaker making a loud with Marvin Gaye's Just To Keep You Satisfied.
Kind of silence outside of my room.

That's giving me a chill.
I forgot how to feel this kind of things around me.
I forgot how cool you have this with the calm mind.
You always seek to reach the level that You can trim your water surface on your mind.

Definitely, I got that level before. However, As I've been getting busy with something else, I just abandoned my treasure. As you know, You have to find urself forever.
You have to be yourself. There is nothing more important that being yourself in this world.

So, Keep traversing on the inner part of yourself. Keep your clam on the deep inner part.
And then, you can grab the peace out of it, paint yourself with the peace. Then Happiness will just sneak to walk into you with silence.