ДИПЛОМНЫЙ ПРОЕКТ
Программа
для ландшафтного дизайна
Введение
Какими только возможностями ни обладают сегодня персональные компьютеры при установке на них соответствующих программных средств: они самостоятельно генерируют пароли и шифруют текст, пишут музыку и стихи, создают самые разные изображения и анимацию и даже могут помочь в рисовании вполне реалистических или, наоборот, фантастических пейзажей. Кстати, хранящиеся у многих пользователи обои для рабочего стола и заставки в виде природных пейзажей в большинстве своем не отсняты фотографами, а созданы в профессиональных генераторах ландшафтов.
Генераторы ландшафтов позволяют сравнительно быстро создавать фотореалистические земные или безжизненные, будто бы инопланетные пейзажи, порою по своей красоте и реалистичности неотличимые от настоящих фотоснимков и вполне достойные того, чтобы пополнить любую личную фотоколлекцию или стать фоном для дальнейшей работы в среде графического пакета при создании, например, фотомонтажа или фотоколлажа, а также украсить экран монитора в качестве фонового изображения и т.п.
Искусственные ландшафты могут стать основой для разнообразных 3D-сцен в трехмерных играх, при подготовке телевизионных заставок и клипов. К тому же генераторы ландшафтов - настоящая находка для историков, палеонтологов и географов: первым и вторым они смогут помочь понять, как выглядела наша планета в тот или иной исторический период, а при изучении географии могут быть экстраординарным образовательным инструментом, более интересным, чем обычные учебники. Даже в совершенно далеком от 3D-искусства бизнесе искусственные пейзажи тоже могут оказаться полезными, например для наглядного представления расположения каких-то объектов компании.
Итак, рассмотрим основные принципы, заложенные в фундамент многих
генераторов ландшафтов.
1. Постановка задачі
.1 Проблемная область
Принцип работы генераторов ландшафтов довольно сложен и основан на понимании ими внутренней структуры природного пейзажа и на знании географических данных разнообразных экосистем, а подходы к реализации могут быть разными. Однако большинство генераторов ландшафтов строят рельеф на основе принятой в картографии так называемой карты высот, представляющей собой изображение с концентрическими областями разного цвета, где каждому оттенку соответствует какая-либо высота относительно уровня моря. Такая карта высот может создаваться самой программой (случайным образом) или пользователем (на основании некоей собственной задумки), и тогда пейзаж может оказаться как фотореалистическим, так и фантастическим. Карта высот может быть получена и на базе реальных данных, взятых из базы геоинформационной системы, вследствие чего искусственный ландшафт может стать полной копией какого-то уголка нашей планеты.
Кроме того, почти все генераторы ландшафтов очень тесно интегрированы с
другими 3D пакетами, так что потребуется реализовать поддержку стандартных
форматов.
1.2 Словарь терминов
генератор ландшафт программный пользователь
Если речь идет о трехмерном ландшафте в компьютерной графике, то в первую очередь следует раскрыть такой термин, как «трехмерная графика».
Трёхмерная графика [15] (3D Graphics, Три измерения изображения) - раздел компьютерной графики, совокупность приемов и инструментов (как программных, так и аппаратных), предназначенных для изображения объёмных объектов. Больше всего применяется для создания изображений на плоскости экрана или листа печатной продукции в архитектурной визуализации, кинематографе, телевидении, компьютерных играх, печатной продукции, а также в науке и промышленности.
Трёхмерное изображение на плоскости отличается от двумерного тем, что включает построение геометрической проекции трёхмерной модели сцены на плоскость (например, экран компьютера) с помощью специализированных программ. При этом модель может, как соответствовать объектам из реального мира (автомобили, здания, ураган, астероид), так и быть полностью абстрактной (проекция четырёхмерного фрактала).
Для получения трёхмерного изображения на плоскости требуются следующие шаги:
1. моделирование - создание трёхмерной математической модели сцены и объектов в ней.
Сцена (виртуальное пространство моделирования) включает в себя несколько категорий объектов:
Геометрия (построенная с помощью различных техник модель, например здание)
Материалы (информация о визуальных свойствах модели, например цвет стен и отражающая/преломляющая способность окон)
Источники света (настройки направления, мощности, спектра освещения)
Виртуальные камеры (выбор точки и угла построения проекции)
Силы и воздействия (настройки динамических искажений объектов, применяется в основном в анимации)
Дополнительные эффекты (объекты, имитирующие атмосферные явления: свет в тумане, облака, пламя и пр.)
Задача трёхмерного моделирования - описать эти объекты и разместить их в сцене с помощью геометрических преобразований в соответствии с требованиями к будущему изображению.
2. рендеринг (визуализация) - построение проекции в соответствии с выбранной физической моделью.
На этом этапе математическая (векторная) пространственная модель превращается в плоскую (растровую) картинку. Если требуется создать фильм, то рендерится последовательность таких картинок - кадров. Как структура данных, изображение на экране представлено матрицей точек, где каждая точка определена по крайней мере тремя числами: интенсивностью красного, синего и зелёного цвета. Таким образом рендеринг преобразует трёхмерную векторную структуру данных в плоскую матрицу пикселов. Этот шаг часто требует очень сложных вычислений, особенно если требуется создать иллюзию реальности. Самый простой вид рендеринга - это построить контуры моделей на экране компьютера с помощью проекции, как показано выше. Обычно этого недостаточно и нужно создать иллюзию материалов, из которых изготовлены объекты, а также рассчитать искажения этих объектов за счёт прозрачных сред (например, жидкости в стакане).
3. вывод полученного изображения на устройство вывода - дисплей или принтер.
API (application programming interface) [10] (рус. интерфейс прикладного программирования) - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется программистами для написания всевозможных приложений.
Кадровый буфер (англ. framebuffer) [11] (другие названия: буфер кадра,
видеобуфер, фреймбуфер) - реальное или виртуальное электронное устройство, или
область памяти для кратковременного хранения одного или нескольких кадров в
цифровом виде перед его отправкой на устройство видеовывода.
1.3 Требования к программному средству
Цель данного дипломного проекта является разработка программного продукта, для создания трехмерного ландшафта.
Что при этом должно быть реализовано:
) Легкий в использовании интерфейс программы
) Создание) Создание нового ландшафта) Открытие сохраненного ландшафта
) Изменение высот ландшафта) Создание холмов) Создание равнин) Создание впадин) Выравнивание) Сглаживание
) Работа с текстурами) Возможность загружать и отображать различные текстуры) Создание несколько слоев текстур местности
) Использование фона неба(SkyBox)
) Настройка уровня освещения и теней
) Сохранения ландшафта
в формате для хранения 3D объектов
2. Теория и выбор
.1 Обзор алгоритмов построения ландшафтов
Существует несколько основных принципов представления данных для хранения информации о ландшафтах [14]:
. Первый - использование регулярной сетки высот (или еще другое название Карта Высот - HeightMap).
. Второй - использование иррегулярной сетки вершин и связей, их соединяющих (т.е. хранение простой триангулизированной карты).
. Третий - хранение карты ландшафта, но в данном случае хранятся не конкретные высоты, а информация об использованном блоке. В этом случае создается некоторое количество заранее построенных сегментов, а на карте указываются только индексы этих сегментов.
.1.1 Использование карты высот
Данные представлены в виде
двухмерного массива. Уже заданы две координаты (x, y - по высоте и ширине
массива), и третья координата задается значением в конкретной ячейке, это
высота.
Рисунок 3.1 - Карта высот (слева) и
Полученный ландшафт(справа)
Обычно карту высот хранят в файлах картинок. Это позволяет легко вносить изменения и более-менее наглядно просматривать данные. Тогда двумя координатами будет положение конкретного пикселя на картинке, а третья координата будет представлена цветом (чем выше значение, прямая зависимость от яркости пикселя - тем больше значение высоты для этой точки). Обычно такие картинки содержатся в монохромном варианте, но можно использовать и все цвета радуги. Второй вариант дает нам больше градаций высоты, чем предполагаемые 256 градаций в случае монохромного представления.
С помощью этого способа можно представить достаточно обширные пространства. Но у него есть один существенный недостаток - слишком много описаний для точек, а также, в некоторых случаях, наблюдается избыточность данных (например, когда у вас задается простая плоскость, то, в этом случае, для построения простой плоскости будет использоваться множество точек, хотя можно бы было обойтись тремя). Хотя и эта самая избыточность может пойти нам на пользу, например, при вертексном освещении.
У этого метода существует и несколько плюсов:
а. наглядность, в любой программе просмотра графических файлов можно сразу увидеть всю информацию;
б. простота изменения этих самых данных, так как существует множество программ для работы с растровой графикой;
в. в таких картах можно хранить не только данные о высоте. Например, предположить, что для хранения высоты используется 16 бит, т.е. две цветовые компоненты, это получается 256x256=65536 градаций высоты. Остальные 8 бит могут использоваться для хранения информации о каких-либо особенностях ландшафта, например, расположение зданий, строений, мостов, растительности и так далее.
г. легкость нахождения координат (и высоты) на карте.
е. так как вершинные точки расположены регулярно и достаточно близко, можно более правильно и достаточно аккуратно производить динамическое освещение (зачастую, освещенность вершины напрямую зависит от расстояния от этой вершины до источника освещения). Это и есть та самая польза от избыточности данных.
.1.2 Иррегулярная сетка
Еще один способ представления данных для ландшафтов - иррегулярная сетка вершин и связей их соединяющих. Зачастую такие решения применяются в специализированных пакетах для игр или специальных пакетах для работы с трехмерной графикой (3dMax, Maya). И хранятся в виде трехмерных моделей. Это дает основной выигрыш по сравнению с картами высот: используется значительно меньше информации для построения ландшафта. Необходимо хранить только значения высот каждой вершины и связи эти вершины соединяющие. Это дает выигрыш в скорости при передаче огромных массивов информации по AGP, в процессе визуализации ландшафта.
Но кроме плюсов у этого способа имеется и множество недостатков:
А. алгоритмы построения ландшафтов в основном предназначены для регулярных карт высот. Оптимизация таких алгоритмов под этот способ потребует значительных усилий;
Б. сложности при динамическом освещении - вершины расположены достаточно далеко друг от друга и неравномерно;
В. хранение, просмотр, модификация такого ландшафта также
представляет сложности. При использовании карт высот используются достаточно
простые и "стандартные" средствами пиксельной графики. К примеры,
Paint. Тут же потребуются более специализированные пакеты.
Рисунок 3.2 - Иррегулярная сетка
2.1.3 Посегментная карта высот
В данном способе также используются карты высот. Только вместо высот в ней хранятся индексы ландшафтных сегментов. Они могут быть и регулярными, и иррегулярными (причем можно использовать и те и другие одновременно). Это дает нам следующие преимущества:
а) Возможность представления огромнейших открытых пространств;
в) Возможность создания нескольких вариантов одного и того же сегмента, но при разной степени детализации. В зависимости от скорости или загруженности компьютера можно выбирать более или менее детализованные варианты (так называемые LOD ландшафты - LOD - Level Of Detail).
Минусов у такого способа тоже хватает:
а) проблема стыковки разных сегментов;
б) неочевидность данных. Взглянув на картинку, не возможно моментально представить, как это должно будет выглядеть.
При реализации данного продукта больше подходит первый вариант, это
использование карты высот, т.к. будет потрачено меньше времени на реализацию
создания и изменения ландшафта, и удобство в хранении данных.
3. Выбор средств реализации
.1 OpenGL, DirectX и GDI
В первую очередь нужно выбрать аппаратно-ускоряемую библиотеку(API) для создания компьютерной графики.
На сегодняшний день основных их три - это OpenGL [7], DirectX [9], GDI [8].
Простые приложения, которые не требуют быстрой графики, могут использовать GDI. Однако GDI не обеспечивает качественной анимации, поскольку в нём нет возможности синхронизации с кадровым буфером. Также, в GDI нет растеризации для отрисовки 3D-графики. Современные графические приложения используют DirectX или OpenGL, что даёт программистам доступ к большему количеству аппаратных возможностей.
Отсюда вывод: GDI не подходит для разработки данного программного продукта. Теперь стоит вопрос: “Какой из двух вариантов API выбрать?” DirectX или OpenGL?[13]
Сравним эти две технологии. DirectX построен по объектно-ориентированной схеме, а OpenGL по процедурной. Что лучше? Программа на GL одинаково "хорошо" выглядит и на C++, и на чистом C, чего не скажешь о DX (хотя это надуманное преимущество, сейчас мало кто пишет на C, особенно под Windows). А вот простота архитектуры GL - неоспоримый плюс: GL работает исключительно с примитивами (треугольники, отрезки и точки) и управляется набором булевых переменных, которые позволяют включать или отключать некоторые функции - например, накладывать текстуру или нет, использовать ли освещение и т. д. Код для отображения "первого треугольника" занимает примерно пятьдесят строк. В DX эта цифра куда больше. С одним-то треугольником у GL все хорошо, но как только захочется использовать что-нибудь из современных 3D-эффектов - появляются расширения GL, и еще недавно простой и понятный код тонет в непонятных и ничего не значащих для человека, не посвященного в тайны 3D-графики, строках.
Как ни странно, ведутся споры о производительности. Проверить это проще простого, но зачем? - ведь результат легко предсказуем. Он будет одинаков для обеих библиотек, поскольку сейчас практически все функции реализуются напрямую через аппаратные ускорители. Расхождение результатов может быть только из-за погрешности измерений; сюда относится и оптимизация тестирующего кода, и специфика конкретных драйверов, но в целом для выполнения кода на GL и DX видеокарта должна выполнять одни и те же действия, а значит, и дискуссии о быстродействии беспочвенны. Конечно, можно копать глубже и спорить о качестве шейдерных компиляторов HLSL[High-level Shader Language - С-подобный язык для написания шейдеров в DirectX 9.0] и GLSL[OpenGL Shading Language - аналог HLSL для OpenGL], но лезть в такие дебри не стоит, тем более что оба решения далеки от совершенства.