QuickDraw 3D: 3D-графический API от Apple

Введение

3D графический API, разработанный Apple Inc.

QuickDraw 3D, или QD3D, – это 3D графический API, разработанный Apple Inc. (ранее Apple Computer, Inc.) начиная с 1995 года, изначально для компьютеров Macintosh, но реализованный как кроссплатформенная система. QD3D был разделен на два уровня. Система нижнего уровня, известная как RAVE (Rendering Acceleration Virtual Engine), предоставляла аппаратный уровень абстракции с функциональностью, аналогичной Direct3D или упрощенным версиям OpenGL, таким как MiniGL. Выше располагалась объектно-ориентированная система построения сцен, собственно QD3D, которая обеспечивала загрузку и манипулирование моделями на уровне, сопоставимом с OpenGL++. Система также включала ряд высокоуровневых утилит для преобразования форматов файлов и стандартное приложение для просмотра на Mac OS. QD3D оказал незначительное влияние на компьютерный рынок, что было обусловлено как сложным положением Apple в середине 1990-х годов, так и несколькими неудачными решениями, принятыми командой разработчиков относительно будущих изменений на рынке 3D-оборудования, которые так и не произошли. Apple прекратила разработку QD3D после прихода Стива Джобса в 1998 году и объявила, что будущая поддержка 3D в Mac OS будет основана на OpenGL.

OpenGL в 1990-х годах

Каноническим 3D API 1990-х годов был OpenGL. Он был разработан компанией SGI и изначально тесно соответствовал возможностям их рабочих станций, выступая в качестве аппаратного слоя абстракции. API OpenGL состоял главным образом из инструкций по настройке состояния для установки режимов отрисовки, таких как цвет или положение камеры, и системы для передачи геометрии в систему, обычно в виде сеток треугольников. Комбинация этих инструкций сохранялась в списке отображения, который затем рендерился для получения результата. OpenGL не обладал многими функциями, необходимыми для создания полноценной 3D-программы. Сохранение и загрузка геометрических данных, объединение этих данных в группы для создания модельных объектов и управление состоянием полностью возлагались на программиста. Это считалось преимуществом в эпоху, когда производительность была ограничена, и прямой контроль над подобными функциями был путем к её повышению. Однако отсутствие высокоуровневой функциональности затрудняло быструю разработку простых программ, а также приводило к недостаточной совместимости. Было предпринято несколько попыток создания стандартизированных API более высокого уровня, таких как OpenGL++ и (позже) Fahrenheit, которые обрабатывали многие распространенные задачи, такие как загрузка геометрии из файлов и организация отображения. Эти стандартизированные системы сценографов означали, что программисту требовалось предоставить только графический интерфейс программы. Хотя OpenGL в основном является низкоуровневым, он включал в себя некоторые концепции более высокого уровня, которые фактически использовались только на системах SGI. Это привело к созданию еще одной серии API, которые исключили эти функции, чтобы упростить их реализацию на обычном оборудовании. Наиболее известным из них является MiniGL, который не является отдельным API, а представляет собой просто список функций в OpenGL, поддержка которых гарантируется на всем оборудовании, тем самым обеспечивая работу программы, ограничивающейся этими вызовами, с максимальной производительностью.

QD3D

QD3D изначально разрабатывался для работы на компьютерах, значительно уступающих рабочим станциям по вычислительной мощности. Это повлекло за собой целенаправленные усилия по четкому разделению верхнего и нижнего уровней API, при этом система RAVE нижнего уровня с самого начала была ближе к MiniGL. Это давало преимущество в виде чистого и минимального API, который было легче портировать на различное оборудование. Поскольку портировать требовалось только RAVE, API верхнего уровня могли быть настолько сложными, насколько необходимо, и система QD3D включала в себя полный граф сцены, стандартизированный формат файла модели 3DMF и даже базовые объекты графического интерфейса, использующие их. Чтобы написать простое приложение в QD3D, программисту нужно было лишь подключить несколько библиотек и затем разместить элементы графического интерфейса в своей программе с помощью ResEdit или аналогичных инструментов. Дополнительные возможности включали систему рендеринга с поддержкой плагинов, позволяющую приложению рендерить сцену в различных стилях. Не изменяя модель или код, разработчики могли отображать одну и ту же сцену интерактивно или (с использованием подходящих плагинов) такими методами, как трассировка лучей или затенение Фонга. API QD3D представлял собой объектно-ориентированную систему, основанную на чистом коде C. Различные структуры были тщательно спроектированы для хранения указателей на другие важные объекты. Объекты знали все необходимые состояния отрисовки, что исключало код, обычно требуемый при разработке под OpenGL. Однако многослойность QD3D привела к проблемам с производительностью. Например, система сохраняла и автоматически устанавливала состояние для каждого объекта перед отрисовкой. Это значительно упрощало разработку, но также приводило к снижению производительности, над которым разработчик не имел прямого контроля. Приложения, требующие производительности, а не простоты программирования, могли вместо этого использовать RAVE-слой напрямую. Еще одной проблемой было то, что граф сцены был скрыт, и значительное повышение производительности рендеринга можно было достичь путем тщательного "отсечения" графа для удаления объектов, не находящихся в поле зрения. Хотя в более поздних версиях QD3D появилась возможность автоматического отсечения по видимости (на основе группировки объектов в графе сцены), отсутствие поддержки этой функции в OpenGL обычно вынуждало разработчиков реализовывать ее с самого начала.

QD3D was designed from the start to operate on computers with considerably less power than workstations. This led to a concerted effort to cleanly separate the upper and lower layers of the API, with the lower level RAVE system being closer to MiniGL from the start. This had the advantage of providing a clean and minimal API that could be more easily ported to different hardware. Since only RAVE needed to be ported, the upper layer APIs could be made as complex as desired, and the QD3D system included a complete scene graph, a standardized model file format, 3DMF, and even basic GUI objects that utilized them. To write a simple application in QD3D, the programmer only had to include a few libraries and then place the GUI elements in their program using ResEdit or similar tools. Additional functionality included a "plug in" rendering system, which allowed an application to render a scene in a variety of styles. Without changing the model or their code, developers could render the same scene interactively or (with suitable plug ins) using methods such as ray tracing or phong shading. The QD3D API was an object like system based on pure C code. The various structures were carefully constructed to contain pointers to other important objects. Objects knew all the drawing state they needed, thereby eliminating code that would normally be needed when developing under OpenGL. On the downside, QD3D's layering introduced performance issues. For instance, the system stored and automatically set state for every object before drawing. This made development much easier, but also made the performance drop in a way the developer had no direct control over. Those applications demanding performance over ease of programming could instead choose to use the RAVE layer directly. Another area of concern is that the scene graph was hidden from view, and considerable improvements in rendering performance can be made by carefully "culling" the graph to remove those objects that are not in view. Although later releases of QD3D gained the ability to automatically perform visibility culling (based on the grouping of objects in the scene graph), OpenGL's lack of support for this feature typically forced developers to implement it from the start.

Переключиться на OpenGL

Хорошая производительность 3D низкого уровня зависит не только от умения программиста создавать эффективные модели, но и от качества драйверов для аппаратного обеспечения. Хотя RAVE разрабатывался как кроссплатформенное решение, драйверы для него создавали только производители оборудования, поддерживавшие Mac (ATI, NVIDIA и 3dfx). Это делало любое сравнение между QD3D и альтернативными API предвзятым, поскольку за пределами Mac QD3D был вынужден использовать программную реализацию RAVE. По мере того, как OpenGL набирал популярность в Windows (часто это приписывают id Software, которая продвигала этот API вместо D3D), производители оборудования все чаще проектировали будущие аппаратные средства с учетом планируемого набора функций для D3D от Microsoft. Благодаря механизму расширений OpenGL мог относительно легко отслеживать эти изменения, в то время как набор функций RAVE оставался практически неизменным. На выставке Macworld Expo в январе 1999 года Apple объявила об исключении QuickDraw 3D и RAVE из Mac OS X. В июне 1999 года компания уволила разработчиков, заменив собственные технологии на OpenGL после приобретения Mac-реализации и ключевых сотрудников у Conix Enterprises. После прекращения поддержки QD3D компанией Apple была разработана внешняя реализация API QD3D с открытым исходным кодом. Эта реализация, известная как Quesa, объединяет высокоуровневые концепции QD3D с OpenGL-рендерером. Помимо кроссплатформенного аппаратного ускорения, эта библиотека позволяет использовать API QD3D на платформах, которые никогда не поддерживались Apple (например, Linux). Последнее обновление датировано 2023 годом.