[ AmberSkyNet VR ]

Возможности движка

Нету шейдеров! Нету shadow volume! И projective shadow тоже нет! Ничего нету, зато исходники открыты и структура простая :)

• Кроссплатформенный движок, собирается под Linux(gcc) и под Win32 (MinGW).
• Хорошая масштабируемость и легкая расширяемость собственными модулями.
• Возможность сборки как в виде одной библиотеки (dll/so), включающей в себя полный функционал движка, так и в виде набора библиотек, используя модули, необходимые для реализации конкретной задачи.

• Загрузка и сохранение сцен в XML-формате.
• Поддержка скриптового языка Lua.
• Отображение с учетом текстур и материалов моделей формата 3ds на сцене.
• Воспроизведение спрайтовой анимации (из графических файлов с кадрами анимации).
• Формирование ландшафта по карте высот (графического файла).
• Формирование ландшафта из raw-файлов формата Second Life.
• Загрузка шрифтов из графических файлов.
• Поддержка шрифтов формата TTF при помощи библиотеки FreeType 2.
• Чтение графических файлов формата BMP, PCX, JPG, PNG и проч., поддерживаемых библиотекой SDL_image.
• Воспроизведение фоновой музыки и звуковых эффектов из файлов формата Waw, Mp3, Ogg и проч., поддерживаемых библиотекой SDL_mixer.
• Чтение ресурсов из zip-архивов. При желании можно добавить собственный плагин чтения из архива другого формата.

Принципы:

• Базовая "универсальная" идея установки переменных в классах через общие функции GetParam/SetParam, GetPtrParam/SetPtrParam
• Простая и, надеюсь, понятная архитектура с минимумом наворотов.

Для сборки движка из исходников вам необходимо:

• для сборки под Win32 требуется компилятор MinGW (в других собирать не пробовал)
  а в качестве среды разработки - Dev-C++ или CodeBlocks (в нем мне нравится возможность полной перекомпиляции всех проектов в workspace, что отсутствует в Dev-C++)
  
• для сборки под Linux - gcc, а так как make-файлы вручную делать влом (а работа с autotools оказалась выше моего понимания), то применяю CMake

В движке используются следующие сторонние библиотеки:

• SDL, SDL_image, SDL_mixer, SDL_net. Если у вас их нет, то можно скачать с официального сайта
• FreeType 2
• tinyXML (включена в исходники движка)
• zlib (включена в исходники движка)
• Lua (включена в исходники движка)

Для разработки так же использовались:

• Система контроля версий SVN (можно установить графический интерфейс Tortoise SVN под Win32 )
• Векторный граф. редактор Dia для рисования поясняющих схем.
• Граф. редактор Gimp для подготовки графических ресурсов.

Метаясь в своих разработках от изометрической РПГ к трехмерному шутеру, а от шутера к сетевой ММОРПГ я заметил, что некоторые части кода можно переносить из одного проекта в другой без особых изменений. Так в голову пришла идея - сделать проект, в котором были бы реализованы некоторые общие части, входящие во все мои изыскания, на основе которых создавать проекты мне было бы легче, чем "с нуля". Раньше склонялся больше к законченному движку, теперь - к фреймворку. Поэтому за один из основных принципов разработки архитектуры данного проекта взял наибольшую автономность составляющих модулей (по мере возможности, конечно), чтобы можно было использовать в других проектах.

Естественно, более высокоуровневые модули (например, модуль реализации узла сцены в виде 3ds-модели, который вызывает для отрисовки функции модуля графики) так использовать не получится. Да, можно сделать чтобы каждый узел сцены рисовал сам себя, используя исключительно вызовы графического API, но мы потеряем время на лишние переключения между материалами и мешами, а также на установку состояний отрисовки. Лучше все отправлять граф. менеджеру, который перед непосредственно отрисовкой должен собирать все вызовы и упорядочить их для минимизации числа изменений параметров между отрисовками разных мешей.

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

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