Programación de gráficos 3D en Java, Parte 3: OpenGL

Ha pasado un tiempo desde nuestra última entrega de esta serie sobre programación de gráficos 3D en Java (más sobre eso al final de esta columna). Aquí hay un repaso rápido sobre lo que discutimos por última vez y dónde lo dejamos.

En las dos columnas anteriores (ver Recursos), exploramos Java 3D. Discutimos el contenido estático y las escenas pequeñas, luego usamos gráficos de escena más grandes y construimos la interactividad en algunos mundos 3D básicos.

Ahora que sabe un poco sobre el uso de Java 3D, es hora de comparar y contrastar el enfoque de Java 3D a los gráficos 3D con el principal competidor de API de gráficos: OpenGL.

Tenga en cuenta que este artículo originalmente tenía la intención de ser intensivo en código, pero la última decisión de Arcane Technologies con respecto al enlace de Magician (ver más abajo) requirió la eliminación de los ejemplos de código. Espero que el contenido de este artículo se pueda adaptar para un futuro enlace Java-OpenGL, que aún no está disponible en el Consorcio OpenGL.

En cualquier caso, me he esforzado por proporcionar todas las referencias y URL relevantes y útiles relacionadas con OpenGL en los Recursos al final de esta columna. Si desea profundizar más en Java-OpenGL, le recomiendo encarecidamente que revise estas referencias.

Comparación de Java-OpenGL con Java 3D

En entregas anteriores de Java 3D, proporcioné una lista de las fortalezas y debilidades del uso de Java 3D para aplicaciones gráficas. Repitamos esa lista, pero hagámoslo observando las fortalezas y debilidades de las soluciones basadas en Java-OpenGL en lugar de las soluciones basadas en Java 3D.

Puntos fuertes del uso de OpenGL (y, por extensión y cuando se indique, enlaces Java-OpenGL):

  • OpenGL proporciona un modelo de procedimiento de gráficos

    Esto coincide mucho con muchos de los algoritmos y métodos que los programadores gráficos han utilizado históricamente. El modelo procedimental es a la vez intuitivo y sencillo para muchos aficionados consumados a los gráficos 3D.

  • OpenGL proporciona acceso directo a la canalización de renderizado

    Esto es cierto con cualquiera de los varios enlaces de lenguaje, incluidos la mayoría de enlaces de Java. OpenGL permite a los programadores especificar directamente cómo se deben representar los gráficos. Uno no solo insinúa y solicita como con Java 3D, uno estipula.

  • OpenGL está optimizado de todas las formas imaginables

    OpenGL está optimizado en hardware y software y plataformas específicas que van desde las PC y consolas de juegos más baratas hasta las supercomputadoras gráficas de alta gama.

  • Los proveedores de todo tipo de hardware relacionado con gráficos 3D admiten OpenGL

    OpenGL es

    la

    estándar con el que los proveedores de hardware miden su tecnología gráfica, sin excepción. A medida que Microsoft se ha unido a SGI en la iniciativa Fahrenheit, se ha vuelto cada vez más obvio para muchos que esto es, en efecto, el reconocimiento indirecto de Microsoft de que OpenGL ganó las guerras de API para gráficos 2D y 3D.

Por otro lado, nada es perfecto. OpenGL, y ciertamente los enlaces Java-OpenGL, tienen algunas deficiencias importantes:

  • Las fortalezas del enfoque procedimental de la programación de gráficos son simultáneamente una debilidad para muchos programadores de Java.

    Para programadores relativamente nuevos, muchos de los cuales pueden haber recibido su primera instrucción de programación formal en Java utilizando metodologías orientadas a objetos, el método procedimental de OpenGL no encaja bien con un enfoque orientado a objetos y buenas prácticas de ingeniería.

  • Las optimizaciones de OpenGL de muchos proveedores están destinadas a disminuir la elección de hardware

    Lo mejor para cada proveedor es crear extensiones propietarias y realizar optimizaciones propietarias para vender más hardware propio. Al igual que con todas las optimizaciones de hardware, debe utilizar optimizaciones OpenGL específicas del acelerador con el entendimiento de que cada optimización para una plataforma disminuye la portabilidad y el rendimiento de varias otras. Las optimizaciones más generales de Java 3D tienen como objetivo principalmente maximizar la portabilidad de las aplicaciones Java 3D.

  • Si bien las interfaces C para OpenGL son ubicuas, las interfaces Java aún no están estandarizadas y no están ampliamente disponibles

    El producto Magician de Arcane Technologies había estado hasta hace poco en el mercado para cambiar este problema de portabilidad, pero con su desaparición, gran parte de la historia multiplataforma para Java-OpenGL, al menos en la actualidad. Más sobre esto a continuación.

  • La exposición de OpenGL de los detalles internos del proceso de renderizado puede complicar significativamente los programas de gráficos 3D que de otro modo serían simples

    El poder y la flexibilidad tienen el precio de la complejidad. En los rápidos ciclos de desarrollo del mundo tecnológico actual, la complejidad es en sí misma algo que debe evitarse siempre que sea posible. El viejo adagio sobre los errores es cierto: cuantas más líneas de código, más errores (en general).

Como puede ver en los pros y los contras de los enfoques basados ​​en OpenGL, Java-OpenGL es fuerte en muchas de las áreas en las que Java 3D es débil. OpenGL les da a los programadores el acceso de bajo nivel al proceso de renderizado que Java 3D evita explícitamente, y OpenGL está actualmente disponible en muchas más plataformas que Java 3D (aparte de Magician). Pero esta flexibilidad tiene un precio potencial: los programadores tienen mucho espacio para optimizar, lo que a la inversa significa que tienen mucho espacio para estropear las cosas. Java 3D tiene más optimización incorporada y un modelo de programación más sencillo que puede resultar particularmente útil para los programadores nuevos en Java, el trabajo de gráficos 3D o la programación de gráficos distribuidos y en red.