문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 OpenGL (문단 편집) == 상세 == OpenGL 이전에는 1980년대 [[실리콘 그래픽스]](SGI) 사에서 개발한 솔루션인 IRIS GL이 있었는데 여러 OS에서 사용하는데 필요한 범용성과 독립성을 고려하지 않고 만들었기 때문에 당시엔 하드웨어 뿐만 아니라 소프트웨어까지 제약이 심했던 솔루션이었다. 그래서 하드웨어와 운영체제에 제약을 받지 않는 범용적인 API 프로그래밍을 위한 OpenGL이 탄생하게 되었던 것. 2000년에 비영리 기술 컨소시엄인 [[크로노스 그룹]]이 설립되면서 GPGPU 병렬연산용 라이브러리인 [[OpenCL]]을 비롯한 다양한 용도의 라이브러리 및 [[API]]--꾸러미--로 확장 및 관리하기 시작했는데, 2006년 7월에 OpenGL도 크로노스 그룹에 의해 관리받는 것으로 전환되었다. 그래픽 쪽을 배울 때에는 꼭 접하게 된다. [[DirectX]]의 [[라이벌]] 격이라고 할 수 있다. 다만 DirectX는 그래픽 뿐만 아니라 사용자 입력과 포스피드백 같은 컨트롤러 제어, 음향 쪽도 아우르고 있어 OpenGL과 1:1로 대응되지 않는다. OpenGL은 순수하게 그래픽 출력만을 담당하니까. 순수하게 OpenGL과 대응되는 부분은 DirectX 컴포넌트의 일부인 Direct3D다. 초창기에는 [[Microsoft]]에서도 OpenGL을 지원했다. 현재까지도 그래픽카드 도움 없이 소프트웨어 렌더링인 CPU 가속으로는 OpenGL 1.1까지 지원한다. 그러다가, 독자솔루션인 DirectX를 내놓으면서 [[Microsoft]]는 OpenGL은 전문가 산업용, DirectX는 가정용 컴퓨터 게임 그래픽용이라는 기믹을 만들어 퍼뜨렸는데 [[존 카맥]]이 OpenGL이 DirectX보다 훨씬 편리하게 게임에 사용이 가능하다고 직접 코드를 보이면서 글을 올렸고, MS는 존 카맥이 사용하기 힘들다면 다른 누구에게도 힘든게 맞다면서 꼬리를 내렸다. 그러나, 1998년 초 1.2 버전 이후 OpenGL은 3년 가까이 개선 과정없이 거듭된 문제를 터뜨렸고[* 사실 문제라고 하기는 뭣 한게 오늘날 기준으로 너무 자주 버전업 되어서 쫓아가지 못 하는 개발 업체들의 모습을 보면 맞는 길이다. 하지만, 당시 하드웨어 성능으로 보면 틀린 길이었고 덕분에 점유율을 많이 잃게 되었다.] DirectX는 1999년 하반기에 발표한 7.0 버전에서 크게 발전하여 결국 역전되고 말았다. 존 카맥도 이제는 DirectX가 더 낫다고 발언한 상황. 저 원인으로 Microsoft의 음모론을 이야기하는 사람도 있는데, OpenGL 위원회에 Microsoft 측 사람이 껴있긴 했지만 딱 한 명밖에 없어서 가능성은 희박하다. 그리고, 만약 저 한 명으로 인해 그런 짓을 터뜨린 거라면 그건 그냥 OpenGL 쪽이 무능하다는 얘기밖에 안 된다. 어쨌건 지금은 OpenGL도 절치부심해서 빠르게 발전하고 있으며, 특히나 모바일 게임시장이 뜨고 Microsoft가 거기서 지지부진한 상황에서 상당한 우세를 보여주고 있다. 과거 하드웨어 T&L 시절에 비하면 트렌드에 뒤쳐지지 않을 정도로 잘 개선되고는 있지만, OpenGL 자체가 게임을 비롯한 멀티미디어만을 위한 존재가 아닌만큼 고려해야할 영역이 많은 API이다 보니 특정 업체인 Microsoft가 본래 Windows 게임을 위해 개발했던 DirectX보다 앞선 기술을 채택하기 어려울 수밖에 없다는 점을 어느 정도 이해해야할 필요가 있다. 90년대 중반까지 DirectX보다 OpenGL이 더 우위였던 건 그래픽 API에 있어서 DirectX가 OpenGL보다 3년 늦게 발표된 후발 주자였기 때문에 가능했을 뿐이다. 현 시점에서 OpenGL의 가장 큰 문제는 드라이버이다. 25년이 넘는 동안 OpenGL 스펙에 추가된 기능들이 엄청나게 많고 과거 1.x 시절의 API부터 4.x에 추가된 최신 API까지 드라이버에서 전부 지원하는 동시에 300여 개에 달하는 확장기능까지 제공해줘야 하는데, 이로 인해 드라이버의 복잡도는 상상을 초월하는 수준이다. 당연히 드라이버의 품질도 심각하게 뒤떨어질 수 밖에 없다. Direct3D처럼 관리주체의 드라이버 통제를 기대할 수 없기 때문에 드라이버의 퀄리티는 순전히 GPU 제조사에 달려 있다.[* 크로노스 그룹은 컨소시엄이라서 MS가 전부 쥐고 흔드는 Direct3D 진영에 비해서 통제력이 약할 수 밖에 없다. 그나마 최근에 test suite의 보강으로 드라이버 퀄리티 컨트롤을 하려는 노력을 하고 있는 상황이다.] 이러한 이유로 OpenGL 프로그래밍은 각종 GPU 드라이버 버그의 지뢰밭을 살금살금 피하면서 개발하는 과정의 연속이다. 사실상 무늬만 크로스플랫폼인 셈. [[Chrome]]은 Windows 버전의 경우 OpenGL을 직접 사용하는 것을 포기하고 OpenGL 명령을 Direct3D로 변환해서 돌리는 ANGLE이라고 불리는 중간 레이어를 개발해서 사용하고 있으며 그 외 플랫폼의 경우 수백개에 달하는 드라이버 버그들을 하나하나씩 우회하는 엄청나게 복잡한 렌더링 패스가 구현되어 있다. 크로노스 그룹이 OpenGL을 놔두고 [[Vulkan(API)|Vulkan]]을 만든 가장 큰 이유도 사실 이것이다. 도저히 드라이버가 관리가 안 되는 수준까지 왔기 때문. 그래서 Vulkan은 스펙을 최소화시켜서 드라이버의 역할을 최대한 줄이고 프로그래머들에게 많은 것을 위임하도록 설계되어 있다. 다만, 이로 인해 Vulkan의 개발 난이도는 엄청나게 올라가 버렸다.[* 다만 그만큼 다양한 헬퍼 라이브러리가 개발되었기에 개발을 아주 못 할정도는 아니다. ~~애초에 D3D12도 비슷한 난이도다.~~ 그래픽 드라이버의 퀄리티에 좌우되는것 보다 프로그래머가 고른 라이브러리의 퀄리티에 좌우되는것이 낫다는 것.] OpenGL의 그 외의 문제로는 전역 상태 머신 기반이라 멀티스레딩을 온전하게 사용할 수 없으며 상태머신의 내용을 추적하기 힘들기 때문에 버그를 만들기 쉽다는 점이 있다. 아무래도 API의 기본 틀은 1990년대 초반에 만들어진 것이니만큼 아무래도 요즘 프로그래밍 트렌드와 동떨어진 부분이 있다. 어지간한 [[그래픽 카드]]라면 둘 다 지원하는 경우가 많다. [[DirectX]]는 '''사실상 [[Microsoft Windows|윈도우]] 전용이므로''' 타 [[운영체제]]([[OS X]], [[Linux|리눅스]] 등)를 쓴다면 유일한 그래픽 라이브러리이기도 하다. 2010년대 시점에서는 [[일반인]] 시각으로 [[그놈이 그놈]]이다. 특히 [[안드로이드(운영체제)|안드로이드]]에서는 OpenGL이 [[메이저]]다. OpenGL은 크게 GL, GLU('''U'''tility)로 나눠져 있다. GL은 기본적인 함수들로 구성되어 있고, GLU는 GL을 좀 더 편히 사용할 수 있도록 도와주는 래핑 함수로 구성되어 있다. 참고로 GL과 GLU 둘 다 업데이트가 끊긴 지 오래되었기 때문에, 실질적으로 OpenGL을 사용하려면 GLEW 같은 외부 확장 라이브러리를 활용해야 한다. 사실 OpenGL은 인터페이스와 기능의 명세일 뿐이라, 실제 그 구현체인 라이브러리는 하나의 플랫폼에도 여럿 존재할 수 있고, 플랫폼 마다도 구현이 달라서 디바이스 컨텍스트 생성 따위의 부분이 플랫폼마다 모두 달라 완전한 크로스플랫폼은 아니다. 이 때문에 실제로 화면에 뭔가를 나타내려면 대체로 추가 라이브러리를 사용해야 한다. ~~이 때 사용하는 것이 GLUT이다.~~[* GLUT 라이브러리는 1996년(!) 이후로 업데이트된 적이 없다. [[macOS]]에서는 10.10에서 결국 Deprecated 처리되어 사용시 경고가 뜨게 되었다. OpenGL 공식 위키에서는 대안으로 FreeGLUT이나 GLFW 등을 추천하고 있다. ~~디바이스 컨텍스트에 관한 지식을 쌓은 후 WGL이나 GLX 등을 이용해 네이티브하게 구현해버려도 상관은 없지만 그러면 크로스플랫폼과는 영영 이별인지라(...)~~][* OpenGL에 입문할 때 FreeGLUT/GLFW, GLEW 이 2가지는 기본적으로 설치하고 시작하는 것이 좋다. 참고로, FreeGLUT보다 GLFW가 더 복잡하고 다양한 기능을 제공한다.][* GLFW로 화면을 구동하고 GLAD 라이브러리로 시작하는 것을 추천한다. FreeGLUT은 윈도우에서 설정한 해상도보다 16픽셀 줄어드는 문제가 있으며 Imgui 같은 플러그인 사용에도 제한이 있다. GLEW는 새로운 확장 지원이 느리다. 반면 GLAD 라이브러리는 직접 필요한 것들을 포함하여 구성할 수 있다.] 이 외에도 [[SDL]] 등과 연동해서 사용하기도 하는데 이는 대부분 크로스플랫폼을 지원한다. 대부분의 3D 그래픽이 그렇지만, 특히 OpenGL은 로우레벨 API이기 때문에 거의 모든 걸 수동으로 해줘야 해서 깊이 있게 사용하려면 어느 정도 수학과 친해져야 한다. 최소한 공대 수준의 선형대수학과 미분기하학은 이해하고 있어야 하는데, 컴퓨터공학과 특성상 이산수학을 제외하면 대학레벨의 수학을 거의 배우지 않는 경우가 많기도 하고, 신기술이 추가되면서 요구하는 수학 수준이 점점 올라가는 추세라는 점이 문제다. 단순히 API를 가져다 쓰는 정도라면 기초 미적분과 벡터 수준의 지식만 가지고도 되기는 하겠으나, 피상적인 접근에만 머무르게 될 것이다. 물론 그래픽스 자체를 연구하는 게 아니라면 그 정도로도 별 문제없기는 하다. 관련 교재와 서적으로는 Red Book과 Blue Book(레퍼런스 매뉴얼), Orange Book, Superbible이 대표적이다. 웹 사이트인 [[https://learnopengl.com/|Learn OpenGL]]도 OpenGL을 넘어 그래픽스 입문을 위한 튜토리얼로 평가받는다. 한때 [[Apple]]이 매우 애용했지만[* 사실 Windows 이외의 OS에서는 OpenGL을 빼면 다른 선택지가 없다.][* [[OS X]] 10.2이후부터 모든 시스템 그래픽은 OpenGL로 가속되어 표시된다.][* Mac OS X 이후에 등장한 [[Windows Vista]]부터, 즉 Aero UI 적용 이후부터는 Windows도 그래픽 가속을 하게 되었다. 당연하지만 기반 API는 [[DirectX]]이다.] OpenGL 4.1 버전 이후 드라이버 업데이트를 전혀 하지 않아 Apple 환경에서 OpenGL을 이용하는 개발자들에게 원성을 사고 있다가, [[WWDC]] 2014에서 자체 개발한 그래픽 라이브러리인 [[Metal(API)|Metal]] 라이브러리를, WWDC 2015에는 macOS용 Metal 라이브러리를 추가 공개하면서 앞으로의 macOS, iOS, tvOS용 앱들이 Metal 라이브러리로 개발될 것이라 발표하였다. [[안드로이드(운영체제)|안드로이드]], [[Linux|리눅스]] 등의 타 플랫폼에서는 여전히 OpenGL을 사용하고 있지만, 시장의 한 축이었던 [[iOS]], [[macOS]]에서의 점유율은 확실히 잃어버리게 되었다. [[언리얼 엔진]], [[유니티(게임 엔진)|유니티 엔진]] 등의 주요 게임 엔진들은 Metal을 정식 지원하고 있다. 2015년 3월, 차세대 그래픽 API인 [[Vulkan(API)|Vulkan]]이 최초 공개되었다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기