QuickDraw 3D , o QD3D para abreviar, es una API de gráficos 3D desarrollada por Apple Inc. (entonces Apple Computer, Inc.) a partir de 1995, originalmente para sus computadoras Macintosh , pero entregada como un sistema multiplataforma. [1]
QD3D se dividió en dos capas. Un sistema de nivel inferior conocido como RAVE (Rendering Acceleration Virtual Engine) proporcionó una capa de abstracción de hardware con funcionalidad similar a Direct3D o versiones reducidas de OpenGL como MiniGL . Encima de esto había un sistema de gráficos de escena orientado a objetos , QD3D propiamente dicho, que manejaba la carga y manipulación de modelos a un nivel similar a OpenGL++ . [2] El sistema también proporcionaba una serie de utilidades de alto nivel para la conversión de formatos de archivo y una aplicación de visualización estándar para Mac OS.
QD3D tuvo poco impacto en el mercado de las computadoras, tanto como resultado de la posición atribulada de Apple a mediados de la década de 1990, como de varias decisiones fatídicas tomadas por el equipo de diseño sobre cambios futuros en el mercado de hardware 3D que no se hicieron realidad. Apple abandonó el trabajo en QD3D después de que Steve Jobs asumiera el cargo en 1998, y anunció que el soporte 3D futuro en Mac OS se basaría en OpenGL .
La API 3D canónica de la década de 1990 fue OpenGL. Fue escrita por SGI y en un principio coincidía estrechamente con las capacidades de sus sistemas de estaciones de trabajo , operando como una capa de abstracción de hardware. La API OpenGL consistía principalmente en instrucciones de configuración de estados para configurar modos de dibujo como el color de la pintura o la posición de la cámara, y un sistema para enviar geometría al sistema, normalmente como mallas de triángulos. La combinación de estas instrucciones se guardaba en una lista de visualización que luego se procesaba para producir el resultado.
OpenGL carecía de muchas de las funciones necesarias para producir un programa 3D completo. El programador se encargaba de guardar y cargar datos geométricos, recopilarlos en grupos para producir objetos de modelo y controlar el estado. Esto se consideraba una ventaja en una época en la que el rendimiento era limitado y el control directo sobre este tipo de funciones era una forma de mejorar el rendimiento.
Sin embargo, esta falta de funcionalidad de alto nivel hizo que fuera más difícil escribir rápidamente programas simples, además de generar una falta de interoperabilidad. Se comenzaron a realizar varios esfuerzos para proporcionar API estandarizadas de alto nivel, como OpenGL++ y (más tarde) Fahrenheit , que manejaban muchas de las tareas de contabilidad más comunes, como cargar geometría desde archivos y proporcionar una pantalla. Estos sistemas de gráficos de escena estandarizados significaban que el programador solo tenía que proporcionar la GUI para el programa.
Aunque OpenGL es en su mayor parte de bajo nivel, incluía algunos conceptos de nivel superior que solo se usaban en sistemas SGI. Esto dio lugar a otra serie de API que eliminaron estas funciones para facilitar su implementación en hardware común. La más conocida de ellas es MiniGL , que no es una API independiente, sino simplemente una lista de aquellas funciones de OpenGL que se garantiza que serán compatibles con todo el hardware, lo que garantiza que un programa que se limite a esas llamadas se ejecutará con el máximo rendimiento.
QD3D fue diseñado desde el principio para funcionar en ordenadores con considerablemente menos potencia que las estaciones de trabajo. Esto llevó a un esfuerzo concertado para separar claramente las capas superior e inferior de la API, siendo el sistema RAVE de nivel inferior más cercano a MiniGL desde el principio. Esto tenía la ventaja de proporcionar una API limpia y minimalista que se podía trasladar más fácilmente a diferentes hardware.
Como solo era necesario portar RAVE, las API de la capa superior podían hacerse tan complejas como se deseara, y el sistema QD3D incluía un gráfico de escena completo, un formato de archivo de modelo estandarizado, 3DMF e incluso objetos GUI básicos que los utilizaban. Para escribir una aplicación sencilla en QD3D, el programador solo tenía que incluir algunas bibliotecas y luego colocar los elementos GUI en su programa utilizando ResEdit o herramientas similares.
La funcionalidad adicional incluía un sistema de renderizado "plug-in", que permitía a una aplicación renderizar una escena en una variedad de estilos. Sin cambiar el modelo ni el código, los desarrolladores podían renderizar la misma escena de forma interactiva o (con los plug-ins adecuados) utilizando métodos como el trazado de rayos o el sombreado phong.
La API de QD3D era un sistema de tipo objeto basado en código C puro . Las distintas estructuras se construían cuidadosamente para contener punteros a otros objetos importantes. Los objetos conocían todos los estados de dibujo que necesitaban, eliminando así el código que normalmente se necesitaría al desarrollar con OpenGL.
En el lado negativo, la superposición de QD3D introdujo problemas de rendimiento. Por ejemplo, el sistema almacenaba y configuraba automáticamente el estado de cada objeto antes de dibujarlo. Esto hizo que el desarrollo fuera mucho más fácil, pero también provocó que el rendimiento cayera de una manera que el desarrollador no podía controlar directamente. Las aplicaciones que exigían rendimiento en lugar de facilidad de programación podían optar por utilizar la capa RAVE directamente.
Otro aspecto preocupante es que el gráfico de escena estaba oculto a la vista, y se pueden lograr mejoras considerables en el rendimiento de renderizado "eliminando" cuidadosamente el gráfico para eliminar aquellos objetos que no están a la vista. Aunque las versiones posteriores de QD3D obtuvieron la capacidad de realizar automáticamente la eliminación de visibilidad (basada en la agrupación de objetos en el gráfico de escena), la falta de compatibilidad de OpenGL con esta función generalmente obligó a los desarrolladores a implementarla desde el principio.
Un buen rendimiento 3D de bajo nivel depende no solo de que el programador proporcione modelos eficientes, sino también controladores de alta calidad para el hardware. Aunque RAVE fue diseñado para ser multiplataforma, solo los desarrolladores de hardware que soportaban Mac ( ATI , NVIDIA y 3dfx ) produjeron controladores para él. Esto dejó cualquier comparación entre QD3D y API alternativas unilateral, ya que fuera de Mac, QD3D se vio obligado a recurrir a una implementación de software de RAVE.
A medida que OpenGL fue ganando terreno en Windows (lo que a menudo se atribuye a id Software , que defendió la API frente a D3D), los desarrolladores de hardware diseñaban cada vez más hardware futuro teniendo en cuenta el conjunto de características futuras planificadas para D3D de Microsoft. A través de su mecanismo de extensión, OpenGL pudo seguir estos cambios con relativa facilidad, mientras que el conjunto de características de RAVE permaneció relativamente fijo.
En la Macworld Expo de enero de 1999, Apple anunció que ni QuickDraw 3D ni RAVE se incluirían en Mac OS X. La compañía despidió al personal de desarrollo en junio de 1999 [ cita requerida ] , reemplazando la tecnología interna con OpenGL después de comprar una implementación para Mac y personal clave de Conix Enterprises.
Después de que Apple retirara el soporte para QD3D, se desarrolló externamente una implementación de código abierto de la API de QD3D. Conocida como Quesa , esta implementación combina los conceptos de nivel superior de QD3D con un renderizador OpenGL. Además de la aceleración de hardware multiplataforma, esta biblioteca también permite el uso de la API de QD3D en plataformas que nunca fueron compatibles con Apple (como Linux ). La última actualización es de 2023. [3]
Entre los cientos de aplicaciones publicadas que emplean RAVE se encuentran: