QuickDraw 3D , или сокращенно QD3D , — это API 3D-графики , разработанный Apple Inc. (тогда Apple Computer, Inc.) начиная с 1995 года, первоначально для компьютеров Macintosh , но поставляемый как кроссплатформенная система. [1]
QD3D был разделен на два слоя. Система более низкого уровня, известная как RAVE (Виртуальный движок ускорения рендеринга), обеспечивала уровень аппаратной абстракции с функциональностью, аналогичной Direct3D или урезанным версиям OpenGL , таким как MiniGL . Помимо этого существовала объектно-ориентированная система графов сцен , собственно QD3D, которая обрабатывала загрузку модели и манипулирование ею на уровне, аналогичном OpenGL++ . [2] Система также включала ряд высокоуровневых утилит для преобразования форматов файлов и стандартное приложение просмотра для Mac OS.
QD3D оказал незначительное влияние на компьютерный рынок как из-за тяжелого положения Apple в середине 1990-х, так и из-за нескольких судьбоносных решений, принятых командой дизайнеров относительно будущих изменений на рынке 3D-оборудования, которые не сбылись. Apple прекратила работу над QD3D после того, как в 1998 году к власти пришел Стив Джобс , и объявила, что будущая поддержка 3D в Mac OS будет основана на OpenGL .
Каноническим 3D API 1990-х годов был OpenGL. Он был написан SGI и изначально точно соответствовал возможностям их систем рабочих станций , работая как уровень абстракции оборудования. API OpenGL состоял в основном из инструкций по настройке состояний для настройки режимов рисования, таких как цвет краски или положение камеры, а также системы для отправки геометрии в систему, обычно в виде сетки треугольников. Комбинация этих инструкций сохранялась в списке отображения , который затем обрабатывался для получения выходных данных.
В OpenGL не хватало многих функций, необходимых для создания полноценной 3D-программы. Сохранение и загрузка геометрических данных, сбор этих данных в группы для создания объектов модели и контроль состояния — все это оставалось на усмотрение программиста. Это считалось преимуществом в эпоху, когда производительность была ограничена, а прямой контроль над такого рода функциями был путем к повышению производительности.
Однако отсутствие высокоуровневой функциональности затрудняло быстрое написание простых программ, а также приводило к отсутствию совместимости. Начался ряд усилий по созданию стандартизированных API более высокого уровня, таких как OpenGL++ и (позже) Fahrenheit , которые выполняли многие из наиболее распространенных задач бухгалтерского учета, таких как загрузка геометрии из файлов и обеспечение отображения. Эти стандартизированные системы графов сцен означали, что программисту нужно было предоставить только графический интерфейс программы.
Хотя OpenGL в основном является низкоуровневым, он включал в себя некоторые концепции более высокого уровня, которые действительно использовались только в системах SGI. Это привело к созданию еще одной серии API, в которой эти функции были удалены, чтобы упростить реализацию на обычном оборудовании. Самый известный из них — MiniGL , который не является отдельным API, а просто списком тех функций OpenGL, которые гарантированно поддерживаются на всем оборудовании, что гарантирует, что программа, ограничивающаяся этими вызовами, будет работать с максимальной производительностью.
QD3D с самого начала разрабатывался для работы на компьютерах со значительно меньшей мощностью, чем рабочие станции. Это привело к совместным усилиям по четкому разделению верхнего и нижнего уровней API, при этом система RAVE нижнего уровня с самого начала была ближе к MiniGL. Преимущество этого подхода заключалось в предоставлении чистого и минимального API, который можно было легко переносить на другое оборудование.
Поскольку портировать нужно было только RAVE, API верхнего уровня можно было сделать настолько сложными, насколько хотелось, а система QD3D включала полный граф сцены, стандартизированный формат файла модели, 3DMF и даже базовые объекты графического интерфейса, которые их использовали. Чтобы написать простое приложение в QD3D, программисту нужно было всего лишь включить несколько библиотек, а затем поместить элементы графического интерфейса в свою программу с помощью ResEdit или подобных инструментов.
Дополнительная функциональность включала «подключаемую» систему рендеринга, которая позволяла приложению отображать сцену в различных стилях. Не меняя модель или свой код, разработчики могли визуализировать одну и ту же сцену в интерактивном режиме или (с подходящими плагинами) с использованием таких методов, как трассировка лучей или затенение Фонга.
API QD3D представлял собой объектно-подобную систему, основанную на чистом коде C. Различные структуры были тщательно построены так, чтобы содержать указатели на другие важные объекты. Объекты знали все необходимые им состояния рисования, тем самым устраняя код, который обычно необходим при разработке под OpenGL.
С другой стороны, многоуровневое представление QD3D привело к проблемам с производительностью. Например, система сохраняла и автоматически устанавливала состояние каждого объекта перед рисованием. Это значительно упростило разработку, но также привело к падению производительности, которое разработчик не мог контролировать напрямую. Те приложения, которым производительность важнее простоты программирования, могут вместо этого использовать напрямую уровень RAVE.
Еще одна проблема, вызывающая беспокойство, заключается в том, что граф сцены был скрыт от просмотра, и можно добиться значительного улучшения производительности рендеринга, тщательно «отбраковывая» граф и удаляя те объекты, которые не видны. Хотя более поздние выпуски QD3D получили возможность автоматически выполнять отсечение видимости (на основе группировки объектов в графе сцены), отсутствие поддержки этой функции в OpenGL обычно вынуждало разработчиков реализовывать ее с самого начала.
Хорошая низкоуровневая производительность 3D зависит не только от программиста, создающего эффективные модели, но и от высококачественных драйверов для оборудования. Хотя RAVE был разработан как кроссплатформенный, драйверы для него создавали только разработчики оборудования, поддерживающие Mac ( ATI , NVIDIA и 3dfx ). Это оставило любое сравнение между QD3D и альтернативными API односторонним, поскольку за пределами Mac QD3D был вынужден вернуться к программной реализации RAVE.
По мере того, как OpenGL набирал популярность в Windows (часто приписывают id Software , которая отстаивала API вместо D3D), разработчики оборудования все чаще проектировали будущее оборудование с учетом будущего набора функций, запланированного для Microsoft D3D. Благодаря своему механизму расширения OpenGL мог относительно легко отслеживать эти изменения, в то время как набор функций RAVE оставался относительно фиксированным.
На выставке Macworld Expo в январе 1999 года Apple объявила, что ни QuickDraw 3D, ни RAVE не будут включены в Mac OS X. Компания уволила штат разработчиков в июне 1999 года , заменив собственную технологию OpenGL после покупки реализации Mac и ключевого персонала у Conix Enterprises.
После того, как Apple отказалась от поддержки QD3D, внешняя реализация QD3D API с открытым исходным кодом была разработана. Эта реализация, известная как Quesa , сочетает в себе концепции более высокого уровня QD3D с средством рендеринга OpenGL. Помимо кросс-платформенного аппаратного ускорения, эта библиотека также позволяет использовать QD3D API на платформах, никогда не поддерживаемых Apple (например, Linux ). Последнее обновление датировано 2023 годом. [3]
Среди сотен приложений, опубликованных с использованием RAVE, можно выделить: