자바의 3D 그래픽 프로그래밍, Part 3 : OpenGL

자바의 3D 그래픽 프로그래밍에 대한이 시리즈의 마지막 기사 (이 칼럼의 끝 부분에서 자세히 설명합니다) 이후 오랜 시간이 지났습니다. 마지막으로 논의한 내용과 중단 한 부분에 대한 간단한 복습이 있습니다.

앞의 두 열 (참고 자료 참조)에서 우리는 Java 3D를 살펴 보았다. 정적 콘텐츠와 작은 장면에 대해 논의한 다음 더 큰 장면 그래프를 사용하고 일부 기본 3D 세계에 상호 작용을 구축했습니다.

이제 Java 3D 사용에 대해 조금 알았으므로 3D 그래픽에 대한 Java 3D 접근 방식을 주요 그래픽 API 경쟁자 인 OpenGL과 비교하고 대조 할 차례입니다.

이 기사는 원래 코드 집약적 인 것이었지만 Magician 바인딩 (아래 참조)과 관련하여 Arcane Technologies의 최신 결정으로 인해 코드 예제를 제거해야했습니다. 이 기사의 내용이 OpenGL Consortium에서는 아직 사용할 수 없지만 향후 Java-OpenGL 바인딩에 맞게 조정될 수 있기를 바랍니다.

어쨌든 저는이 칼럼 끝에있는 리소스에 모든 관련되고 유용한 OpenGL 관련 참조 및 URL을 제공하기 위해 노력했습니다. Java-OpenGL에 대해 더 자세히 알고 싶다면 이러한 참조를 검토하는 것이 좋습니다.

Java 3D와 Java-OpenGL 비교

Java 3D에 대한 이전 기사에서는 그래픽 응용 프로그램에 Java 3D를 사용할 때의 장단점 목록을 제공했습니다. 목록을 다시 작성하되 Java 3D 기반 솔루션 대신 Java-OpenGL 기반 솔루션의 강점과 약점을 살펴 보겠습니다.

OpenGL 사용의 강점 (확장 및 명시한 경우 Java-OpenGL 바인딩) :

  • OpenGL은 그래픽의 절차 적 모델을 제공합니다.

    이것은 그래픽 프로그래머가 역사적으로 사용했던 많은 알고리즘 및 방법과 거의 일치합니다. 절차 적 모델은 많은 숙련 된 3D 그래픽 애호가에게 직관적이고 간단합니다.

  • OpenGL은 렌더링 파이프 라인에 대한 직접 액세스를 제공합니다.

    이것은 대부분의 Java 바인딩을 포함하여 다양한 언어 바인딩에 해당됩니다. OpenGL은 프로그래머가 그래픽을 렌더링하는 방법을 직접 지정할 수 있도록합니다. 하나는 Java 3D와 마찬가지로 힌트요청 이 아닙니다 .

  • OpenGL은 상상할 수있는 모든 방식으로 최적화됩니다.

    OpenGL은 가장 저렴한 PC 및 게임 콘솔에서 최고급 그래픽 슈퍼 컴퓨터에 이르기까지 하드웨어 및 소프트웨어 및 대상 플랫폼에 최적화되어 있습니다.

  • 모든 종류의 3D 그래픽 관련 하드웨어 공급 업체가 OpenGL을 지원합니다.

    OpenGL은

    그만큼

    하드웨어 공급 업체가 그래픽 기술을 측정하는 기준은 없습니다. Microsoft가 Fahrenheit 이니셔티브에서 SGI와 합류함에 따라 OpenGL이 2D 및 3D 그래픽에 대한 API 전쟁에서 승리했다는 Microsoft의 간접적 인 인정이 많은 사람들에게 점점 더 분명해졌습니다.

반면에 완벽한 것은 없습니다. OpenGL과 확실히 Java-OpenGL 바인딩에는 몇 가지 중요한 단점이 있습니다.

  • 그래픽 프로그래밍에 대한 절차 적 접근 방식의 강점은 동시에 많은 Java 프로그래머에게 약점입니다.

    객체 지향 방법론을 사용하여 Java로 처음으로 공식 프로그래밍 지침을받은 비교적 새로운 프로그래머의 경우 OpenGL의 절차 적 방법은 객체 지향 접근 방식 및 우수한 엔지니어링 관행과 잘 맞지 않습니다.

  • 많은 공급 업체의 OpenGL 최적화는 하드웨어 선택을 줄이기위한 것입니다.

    독점적 확장을 구축하고 자체 하드웨어를 더 많이 판매하기 위해 독점적 최적화를 수행하는 것은 각 공급 업체의 최대 이익입니다. 모든 하드웨어 최적화와 마찬가지로 하나의 플랫폼에 대한 각 최적화가 다른 여러 플랫폼에 대한 이식성과 성능을 저하 시킨다는 점을 이해하고 가속기 별 OpenGL 최적화를 사용해야합니다. Java 3D의보다 범용적인 최적화는 대부분 Java 3D 애플리케이션의 이식성을 최대화하는 것을 목표로합니다.

  • OpenGL에 대한 C 인터페이스는 유비쿼터스이지만 Java 인터페이스는 아직 표준화되지 않았으며 널리 사용되지 않습니다.

    Arcane Technologies의 Magician 제품은 최근까지이 이식성 문제를 바꾸기 위해 시장에 나와 있었지만, 그 종말과 함께 적어도 현재는 Java-OpenGL에 대한 크로스 플랫폼 이야기의 대부분이 진행되고 있습니다. 자세한 내용은 아래에서 확인하세요.

  • OpenGL이 렌더링 프로세스의 내부 세부 사항을 노출하면 단순한 3D 그래픽 프로그램이 상당히 복잡해질 수 있습니다.

    성능과 유연성은 복잡성의 대가를 치릅니다. 오늘날 기술 세계의 빠른 개발주기에서 복잡성은 그 자체로 가능하면 피해야합니다. 버그에 대한 오래된 격언은 사실입니다. 코드 줄이 많을수록 버그가 많아집니다 (일반적으로).

OpenGL 기반 접근 방식의 장단점에서 알 수 있듯이 Java-OpenGL은 Java 3D가 약한 많은 영역에서 강합니다. OpenGL은 프로그래머에게 Java 3D가 명시 적으로 피하는 렌더링 프로세스에 대한 저수준 액세스를 제공하며 OpenGL은 현재 Java 3D (Magician 제외)보다 훨씬 많은 플랫폼에서 사용할 수 있습니다. 그러나 이러한 유연성은 잠재적 인 가격을 동반합니다. 프로그래머는 최적화 할 여지가 많으며, 이는 반대로 작업을 망칠 여지가 많다는 것을 의미합니다. Java 3D에는 Java, 3D 그래픽 작업 또는 네트워크 및 분산 그래픽 프로그래밍을 처음 접하는 프로그래머에게 특히 유용한 것으로 입증 될 수있는 더 많은 내장 최적화와 더 쉬운 프로그래밍 모델이 있습니다.