Текст средствами OpenGL или рисуем "Hello World!"

Изучение любого языка программирования традиционно начинается с вывода всем знакомого приветствия, что считается примером простейшей программы. К сожалению, в 3D графике эта задача далеко не тривиальная, так как стандартные средства для работы с текстом в OpenGL отсутствуют.

Поговорим о деревьях.

Да, о деревьях с корнями, ветвями и листочками, но не о тех, что растут у вас за окном, а о бинарных деревьях из теории графов. Сама теория графов очень скучная наука, потому, как обычно, эту часть я упущу, желающие всегда могут найти интересующую их теоретическую информацию в интернете (к примеру, по ссылкам приведенным ниже), здесь же я коснусь вопросов практического применения октарных деревьев в компьютерной графике, в частности, для проверки видимости и поиска точки пересечения, как продолжения предыдущей темы.

Выбор объектов.

После таких сложных тем как машина состояний ОГЛ и VBO решил выбрать для рассмотрения что-то попроще, но не менее важное для графического движка., такое как банальный выбор объекта мышкой. Не смотря на повседневность этой задачи тут также есть свои нюансы, которые мы с вами и рассмотрим.

Всего существует две принципиально разные технологии выбора объектов, одна предполагает что объект будет "выбираться" аппаратно (на стороне GPU), вторая - программно (на CPU). Рассмотрим обе из них, их достоинства и недостатки.

Материалы. Часть третья, коллекции.

В предыдущей части мы затронули одну из самый серьезных проблем системы материалов GLScene - привязку текстур к материалам сцены, потому решение было очевидным - отделить свойства материалов от текстур, таким образом в VBOMesh появилось две коллекции - коллекция свойств материала (TMaterialLibrary) и коллекция текстур (TTextureLibrary). Изначально эти библиотеки были раздельно, создавались вместе с TVBOMesh и наследовались всеми создаваемыми объектами. При этом у объекта появлялось несколько дополнительных свойств: Material: TMaterial, Texture: TTexture, Blending: TCustomBlending, NoDepthTest и NoZWrite. Из названий не сложно догадаться для чего они были нужны.

Материалы. Часть вторая, путь проб и ошибок.

В предыдущей части мы с вами разобрались, что для нормального отображения нам нужно чтоб наша "поверхность" могла хранить информацию о свойствах материала, о текстурных слоях, о взаимодействии текстуры с материалом, о взаимодействии материала с вершинными атрибутами, о блендинге и работе с буфером глубины.

Если посмотреть настройки материалов в том же 3ds Max, то мы увидим более внушительный список как карт материалов так и их настроек. В частности я не рассмотрел такие эффекты как преломление или внутреннее рассеивание света, не рассмотрел так же возможность отражения в зеркальных поверхностях, не рассмотрел эффекты рельефных поверхностей и прочее. Причина по которой я это пропустил - все это реализуется с использованием шейдеров и поддержка того или иного эффекта уже зависит не столько от настроек материала, сколько от реализации шейдеров и системы эффектов. Об этом мы поговорим позже, сейчас же сделаем небольшой экскурс в историю VBOMesh и GLScene.

Материалы. Часть первая, идем за светом.

Любой современные графический движок просто обязан иметь систему материалов, так как без этого мир становится серым или даже черным :)

Вопрос материалов достаточно тривиален и тема должна быть скучная, но я постараюсь вас убедить в обратном :)

Для начала определимся что же такое материал - материал это набор "физических" свойств, описывающих поведение падающего на него света, как следствие - материал тесно связан с системой освещения. Так как мы не ставим перед собой задачу трассировки света для физически правильной освещенности, то воспользуемся упрощенными понятиями, принятыми в 3D графике и в OpenGL.

Машина состояний OpenGL. Часть третья, OGLStateEmul.

Итак, передо мной стояло три проблемы:

1. Реализовать механизм кеширования;
2. Обеспечить взаимодействие со сценой во избежании конфликтов;
3. Решить "Социальную" проблему с ленивыми программистами.

"Социальная" проблема стояла очень остро, так как 100% моего кода было написано на чистом OpenGL, без использования старого механизма работы со стэйтами. Таким образом, что бы я не придумал, мне пришлось бы править весь код, потом еще и обучать других, которые только освоили систему кеширования сцены, своей "новой" системе... Само же кеширование это задача тривиальная, но очень емкая, так как нужно описать логику работы каждой команды ОГЛ, меняющей состояния (и не только, но об этом дальше).

Машина состояний OpenGL. Часть вторая, кеширование.

Чтоб понять что не так с кешированием в сцене (и чтоб не допустить тех же ошибок) нужно разобраться как оно там устроено, для этого достаточно заглянуть в файл "glState.pas", давайте заглянем.

Машина состояний OpenGL. Часть первая, знакомство.

"OpenGL – это машина состояния. Вы задаете различные переменные состояния, и они остаются в действии, сохраняя свое состояние, до тех пор, пока вы же их не измените."

Примерно такое определение можно найти  в первых главах любого учебника по OpenGL.
Если открыть любую публикацию, посвященную повышению производительности графики в OpenGL, к примеру любую из этих:
http://www.cs.virginia.edu/~gfx/Courses/2004/RealTime/Performance-Optimisation.pdf
http://developer.amd.com/media/gpu_assets/PerformanceTuning.pdf
http://developer.amd.com/media/gpu_assets/KRI%202006-OpenGL%20optimizations.pdf
то можно найти описание одной из самых популярных проблем падения производительности - "too many state changes", что дословно переводится как "слишком много переключений состояний", тех самых состояний, на каких основана работа всего OpenGL.

Если углубиться в чтение этих (и многих других) публикаций, то можно найти простую рекомендацию - "уменьшайте количество переключений состояний". Казалось бы все очевидно, но разве мы специально вставляем лишние переключения? Откуда они берутся? И как мы можем их уменьшить?

Что внутри. VBO, часть третья, оптимизация

При работе с VBO нужно учитывать массу моментов, часть из них мы с вами уже разобрали, мы уже определились что нужен индексный буфер, что нужно уменьшать количество пакетов, что лучше рисовать все за один вызов и т.д. Сейчас мы разберем почему так, как это влияет на производительность, что можно сделать для повышения производительности и как это представлено в VBOMesh.

Что внутри. VBO, часть вторая, реализация

В предыдущей части было очень много написано о проблемах, такова уж цена новых технологий.
Теперь самое время поговорить об открывающихся возможностях, и о том, зачем вообще был нужен этот переход от дисплейных списков на VBO.

Что внутри. VBO, часть первая, обзорная

Разрабатывая функционал я старался найти компромисс между производительностью, совместимостью и гибкостью. Иногда приходилось чем-то жертвовать.
Рассмотрим вкратце используемые технологии и подходы. Начнем с самого главного, с чего и задумывался весь этот проект, с VBO, так как это самая простая и в то же время самая проблемная часть.

Выход в свет :)

Решил попытаться создать свой блог, посвященный моим наработках в рамках проекта VBOMesh. В блоге рассматриваются базовые составляющие графического движка а так же различные техники и трюки рендеринга c использованием API OpenGL 2.1+ (с ориентацией на OGL3), реализованные или запланированные в движке. Проводится анализ эффективности некоторых техник, имеется ряд уроков по основополагающим технологиям ну и просто интересная информация или мысли.

Немного о проекте - проект VBOMesh является надстройкой над графическим движком GLScene (glscene.org, glscene.ru), расширяя его возможности за счет использования возможностей VBO и шейдеров.