Атмосфера (2)
alex_bobkov

Продолжаю атмосферную тематику. Как я уже писал, для создания правдоподобной атмосферы для глобуса удобно использовать алгоритм О’Нила. В osgEarth уже есть класс, который на основе этого алгоритма рендерит атмосферу. Но реализована только половина алгоритма - для расчета цвета околоземного пространства. К цвету рельефа (виртуального глобуса) алгоритм не применяется. Вот как это выглядит:

Исправить это недоразумение достаточно просто. Однако есть свои тонкости. Мы не можем “в лоб” применить шейдер О’Нила к рельфу, т.к. osgEarth УЖЕ использует шейдер для рендеринга рельефа. Например, для смешивания разных текстурных слоёв.

В osgEarth есть механизм, который позволяет нам встраивать куски шейдерного кода внутрь основного шейдера. В общем виде этот механизм описан здесь. Коротко рассмотрю основные шаги применительно к атмосфере:

1) Создать экземпляр osgEarth::VirtualProgram и присоединить к стейтсету osgEarth::MapNode:
osgEarth::VirtualProgram* vp = new osgEarth::VirtualProgram;
mapNode->getOrCreateStateSet()->setAttributeAndModes(vp);

2) Оформить наш шейдерный код в виде отдельных функций и поместить их в текстовые переменные:
std::string vertShader, fragShader;
//read from file

3) Прикрепить их к VirtualProgram. При этом указывается имя шейдерной функции, которую нужно вызвать, и место в основном шейдере, куда вставлять вызов нашей функции:
vp->setFunction("setup_ground", vertShader, osgEarth::ShaderComp::LOCATION_VERTEX_POST_LIGHTING);
vp->setFunction("apply_ground", fragShader, osgEarth::ShaderComp::LOCATION_FRAGMENT_POST_LIGHTING);

4) Далее, конкретно для работы атмосферы нужно задать несколько uniform-”переменных”.
ss->getOrCreateUniform( "atmos_v3LightPos", osg::Uniform::FLOAT_VEC3 )->set( osg::Vec3(0.0, 1.0, 0.0) );
ss->getOrCreateUniform( "atmos_v3InvWavelength", osg::Uniform::FLOAT_VEC3 )->set( RGB_wl );
ss->getOrCreateUniform( "atmos_fInnerRadius", osg::Uniform::FLOAT )->set( _innerRadius );
ss->getOrCreateUniform( "atmos_fInnerRadius2", osg::Uniform::FLOAT )->set( _innerRadius * _innerRadius );
ss->getOrCreateUniform( "atmos_fOuterRadius", osg::Uniform::FLOAT )->set( _outerRadius );
ss->getOrCreateUniform( "atmos_fOuterRadius2", osg::Uniform::FLOAT )->set( _outerRadius * _outerRadius );
ss->getOrCreateUniform( "atmos_fKrESun", osg::Uniform::FLOAT )->set( Kr * ESun );
ss->getOrCreateUniform( "atmos_fKmESun", osg::Uniform::FLOAT )->set( Km * ESun );
ss->getOrCreateUniform( "atmos_fKr4PI", osg::Uniform::FLOAT )->set( Kr4PI );
ss->getOrCreateUniform( "atmos_fKm4PI", osg::Uniform::FLOAT )->set( Km4PI );
ss->getOrCreateUniform( "atmos_fScale", osg::Uniform::FLOAT )->set( Scale );
ss->getOrCreateUniform( "atmos_fScaleDepth", osg::Uniform::FLOAT )->set( RayleighScaleDepth );
ss->getOrCreateUniform( "atmos_fScaleOverScaleDepth", osg::Uniform::FLOAT )->set( Scale / RayleighScaleDepth );
ss->getOrCreateUniform( "atmos_g", osg::Uniform::FLOAT )->set( MPhase );
ss->getOrCreateUniform( "atmos_g2", osg::Uniform::FLOAT )->set( MPhase * MPhase );
ss->getOrCreateUniform( "atmos_nSamples", osg::Uniform::INT )->set( Samples );
ss->getOrCreateUniform( "atmos_fSamples", osg::Uniform::FLOAT )->set( (float)Samples );
ss->getOrCreateUniform( "atmos_fWeather", osg::Uniform::FLOAT )->set( Weather );

“Переменные” - в кавычках, потому что на самом деле это всё просто константы, которые не меняются во время работы приложения. Настоящих переменных только 2: одна – для задания положения камеры (которая здесь не описана) и другая - atmos_v3LightPos – для задания направления источника света.

Пару слов про задание положения камеры. В коде вершинного шейдера необходимо вычислять координаты вершин рельефа в мировой системе координат. Для этого нужна обратная матрица вида. Она передаётся через встроенную в OSG uniform-переменную:
uniform mat4 osg_ViewMatrixInverse;

Вот как она применяется для вычисления положения вершин  в мировой системе координат.
vec3 v3Pos = (osg_ViewMatrixInverse * gl_ModelViewMatrix * gl_Vertex).xyz;

Эту же самую матрицу удобно применять для вычисления положения камеры:
vec3 v3Cam = osg_ViewMatrixInverse[3].xyz; 

С этой матрицей связан один глюк, про который я ещё напишу.

Прозрачная Земля

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

1) Полусфера, которая использовалась для показа околоземного пространства, стала просвечивать сквозь глобус:

Решение пришло сразу: нужно сначала отрендерить глобус, а потом уже полусферу. Тогда часть полусферы за глобусом не пройдет тест глубины и не будет нарисована. Это можно сделать, например, поместив рельеф в RenderBin с сильно отрицательным номером:
mapNode->getOrCreateStateSet()->setRenderBinDetails(-15, "SORT_FRONT_TO_BACK");

При этом атмосфера находится в рендербине с номером -8.

Примечание: рендербины рендерятся в порядке возрастания номеров. Изменяя номер рендербина можно контролировать порядок отрисовки объектов.

2) Однако это очевидное решение привело к новым проблемам. Часть полусферы стала наезжать на рельеф каким-то совершенно фантастическим образом. Такое ощущение, как будто дальняя плоскость отсечения скачет.

После изучения кода класса osgEarth::Util::SkyNode всё стало ясно. При рендеринге полусферы с атмосферой была отключена запись в буфер глубины, а также использовались свои собственные ближняя и дальняя плоскости отсечения. Такая схема позволила вычислять ближнюю и дальнюю плоскости отсечения для рельефа без учёта атмосферы.

После того, как я стал рендерить атмосферу после рельефа, это привело к следующему эффекту: при выполнении теста глубины для атмосферы значение глубины в буфере (полученное из рельефа) и значение глубины пикселя атмосферы соответствовали разным значениям z-расстояния до камеры. Глубина меньше - а расстояние до камеры больше. (Значение глубины приведена к диапазону [0;1] от ближней до дальней плоскости отсечения). Поэтому успешное прохождение теста глубины привело к тому, что части атмосферы рисовались поверх рельефа.

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

Проблема была решена. Но вскоре был обнаружен новый глюк: атмосфера некорректно отображалась в стереорежиме. Но об это в следующем посте.


3Dconnexion + OpenSceneGraph под Виндой
alex_bobkov

Под Виндой не всё гладко с использованием джойстиков 3Dconnexion в своих приложениях. Официального SDK нет. Точнее он устарел, и разработчики как временное решение предлагают использовать DirectInput. Но и здесь подстава: FTP-сервер с примерами не работает.

Однако, на одном китайском сайте мне удалось найти нужный исходник примера. На базе него я сделал манипулятор для управления камерой в приложении на базе OSG. Демку выложил сюда здесь. Она ещё сыровата. Пока что это proof of concept. Далее буду развивать по мере использования в реальных приложениях.

P.S. Сейчас снова зашел на сайт 3dconnexion, и вроде они почти закончили работу на новым SDK.


OpenSceneGraph Cookbook
alex_bobkov

Двое китайцев Rui Wang и Xuelei Qian написал замечательную книгу по OSG: OpenSceneGraph 3.0: Beginner's Guide. Я даже купил себе бумажный вариант. Теперь они готовят продолжение: книгу рецептов OpenSceneGraph 3.0 Cookbook. Там собрано около 100 небольших примеров, иллюстрирующих разные возможности как самого OSG, так и взаимодействия с другими библиотеками. В частности:

  • Создание меню с помощью библиотеки CEGUI
  • Управление приложением с помощью джойстика через DirectInput
  • Интеграция с физическим движком PhysX
  • Создание плагина для браузера с помощь FireBreath

Книга появится в продаже 31го марта. Пока она доступна для предзаказа. А исходные тексты большинства примеров уже сейчас свободно доступны на гитхабе.


Интересное с форума OSG
alex_bobkov

(1) Чел пишет демку на OSG для визуализации движения толпы. Моделирование толпы производится с помощью библиотеки RVO2. Вот канал на ютюбе, где можно посмотреть результаты моделирования. Библиотека RVO2 бесплатна для некоммерческого использования.

 

(2) Австралийцы моделирует наводнения в проекте ANUGA. Клиент для визуализации написан на OSG. Источник.

(3) Некий студент написал библиотеку osgRiver для рендеринга рек на базе osgOcean. Вот постер с описанием алгоритма. Вот видео. Исходники, к сожалению, сейчас не доступны. С глобусом эта библиотека не совместима, как и osgOcean.

(4) Adrian Egli выложил интересную демку с собственной реализацией эффекта Ambient Occlusion.


Атмосфера
alex_bobkov

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

Задача ставится так: необходимо в каждой точке рассчитать цвет околоземного пространства или земной поверхности. Физика атмосферы известна давно. Свет от Солнца рассеивается на молекулах воздуха и аэрозолей в атмосфере и рано или поздно попадает на сетчатку глаза. Свет разных длин волн рассеивается по-разному. Синий - рассеивается сильнее, поэтому небо нам кажется синим.

Необходимо вычислить, какая часть изначального пучка света от Солнца рассеялась, а какая осталась и попала в глаз. Это определяется уравнением рассеяния. В это уравнение входит громоздкий интеграл, который аналитически не берется, а численное интегрирование довольно сложное. Проведение этих расчётов в реальном времени долго было недостижимой задачей. Использовались приближенные алгоритмы для 2х отдельных случаев: вид с поверхности и вид из космоса. В случае вида из космоса достаточно было просто нарисовать красивый ореол вокруг глобуса. А вот примеры алгоритмов для вида с поверхности:

  • osgEphemeris
  • steps3D - я применял его для Виртуального Физтеха

В начале 2000х годов с появлением графических процессоров и возможности их программирования с помощью языков шейдеров начались разработки по расчёту цвета атмосферы в реальном времени. Одна из первых работ в этой области принадлежит Шону О’Нилу, которая даже была опубликована в GPU Gems 2. На эту работу ссылаются многие другие авторы. О’Нил разработал алгоритм для бесшовного рендеринга атмосферы для любого положения камеры от поверхности до дальнего космоса и любого вектора направления на Солнце.

Сам алгоритм сравнительно прост. Уравнение рассеяния максимально упрощено. Все вычисления происходят в вершинным шейдере БЕЗ использования дополнительных текстур с предрассчитанными значениями (lookup tables). И тем не менее, алгоритм выдает правдоподобный результат. Рассчитывается не только цвет околоземного пространства, но и цвет самой поверхности Земли, т.к. луч света в любом случае проходит через атмосферу и рассеивается. Благодаря этому на горизонте цвет поверхности становится более синим и сливается с небом. Сравните картинки с расчётом цвета поверхности и без:

О’Нил выложил все исходники у себя на сайте: как основное приложение, так и GLSL-шейдеры.

Дальнейшие исследования в этой области усовершенствовали алгоритм О’Нила. Нужно отметить алгоритм Брунетона, который также выложил все исходники. Один чел из Питера даже интегрировал их в свой космический движок (вот подробное описание). Брунетон по сравнению с О’Нилом добавил учёт неровностей рельефа и учёт множественного рассеяния.

В проекте “Виртуальная Земля” я использовал алгоритм О’Нила. После отказа от Аванго и перехода на osgEarth обнаружилось, что в osgEarth уже есть класс для рендеринга атмосфера также на основе алгоритма О’Нила. Но почему-то этот класс рендерил только околоземное пространство. Поэтому Земля выглядит как на 2й картинке выше.

Я без проблем перенёс свой старый код для рендеринга поверхности с учётом атмосферы. Однако, когда встала задача сделать Землю прозрачной и показать подземные объекты (гипоцентры землетрясений), то возникла проблема. Об этом - в следующем посте.


Виртуальная Земля
alex_bobkov

Последние года два я занимался визуализацией данных на базе виртуального глобуса. Все наработки воплощались в жизнь в виде приложения под кодовым названием “Виртуальная Земля”, которое дальше использовалось в разных проектах: виртуальная модель Долины гейзеров, прототип тренажера для сотрудников Ленинградской АЭС, виртуальное Протвино, визуализация полёта корабля Восток, визуализация сейсмических данных.

Исторически сложилось, что за основу приложения был взят фреймворк AVANGO NG, который является надстройкой над графическим инструментарием OpenSceneGraph. Для создания самого виртуального глобуса использовался VirtualPlanetBuilder, а позже – osgEarth.

Я по возможности использовал встроенные возможности OSG, osgEarth, Avango и интегрировал их между собой. Дополнительно было добавлено следующее:

  • Визуализация данных из KML-файлов
    • Метки, линии, контуры и их описания
    • 3д-модели
    • Фотопанорамы (PhotoOverlay)
    • Наложения (ScreenOverlay и GroundOverlay)
    • Путешествия (Tour)
    • Меню для включения/выключения частей KML-файлов.
  • Контекстное меню для меток
    • Показ (стерео-)видео, привязанного к метке
    • Проигрывание аудиофайла, привязанного к метке
  • Визуализация атмосферы, солнца и звёздного неба
  • Покадровая запись видео с приложения
  • Управление камерой с помощью мыши, клавиатуры и джойстика 3dconnexion
  • Режим прогулки
  • Анимация движения космических аппаратов на орбите
  • Освещение зданий и космических аппаратов в зависимости от времени суток
  • Рендеринг дорог с разметкой и лесов
    • на основе данных из KML-файлов
    • на основе данных OpenStreetMap
  • Моделирование дорожного трафика
  • Визуализация природных явлений
    • Схема работы геотермальной системы Долины гейзеров (магматический очаг, линии тока воды, флюиды
    • Схема работы гейзера (надземная и подземная части)
    • Дождь
    • Пожар

Однако, со временем стало ясно, что Аванго создаёт больше трудностей, чем решает. Изначально предполагалось, что Аванго ускорит разработку приложения, благодаря использованию языка Питон. Аванго обеспечивает привязку к Питону основных классов OSG. И действительно, простые задачи на Аванго решаются очень просто. Но чем сложнее задача, тем чаще оказывается, что на уровне Питона нет нужного функционала. Приходится спускаться на уровень C++, где потом возникает необходимость писать большой объём рутинного кода только для того, чтобы привязать свои наработки к Питону.

Другая “фича” Аванго – граф потоков данных. Предполагается, что приложение должно состоять из набора изолированных сущностей – “полевых контейнеров”, которые связываются между собой потоками данных. При изменении данных у одного полевого контейнера с одного конца связи они автоматически пересылаются на другой конец связи другому полевому контейнеру. Идея на первый взгляд здравая, но:

  1. На Питоне создавать новые полевые контейнеры просто. Их становится очень много и может возникнуть путаница. Сложно держать в голове все связи. К тому же обработка полевых контейнеров на Питоне сильно замедляет работу приложения.
  2. На C++ создавать новые полевые контейнеры – это ад. Требуется огромное количество дополнительного кода для поддержки работы потоков.

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

Также при визуализации данных на глобусе жизненно важным является использование типа данных double и соответственно вектора osg::Vec3d. Точности типа float не хватает, и поэтому, например, при движении камеры возникает дерганье. Однако, в Аванго тип osg::Vec3d не экспортирован на уровень Питона. Только osg::Vec3f. Мне пришлось добавлять поддержку osg::Vec3d самостоятельно.

Для хранения всех моих изменений в коде Аванго я сделал форк.

Ну, и пара слов про кроссплатформенность. Аванго изначально разрабатывался под Линуксом. И здесь у него наилучшая поддержка. Под Виндой не работают модуль связи с джойстиками и модуль аудио. Под Маком Аванго не работает. Про Андроид и айОС я вообще молчу.

Поэтому я решил отказаться от использования Аванго и полностью перейти на OSG и osgEarth. Кодовое название нового приложения - “Виртуальная Земля 2.0”. Часть кода из старого приложения, которая была написана на C++, будет перенести не сложно. Часть функционала уже реализована в osgEarth, например, базовая поддержка KML.

Для создания меню в приложении решил использовать библиотеку CEGUI. За основу взял пример, выложенный в рассылке OSG. Правда, неожиданно обнаружилось, что CEGUI не поддерживает пассивное стерео. Но я разберусь с этим.

В последующих постах будет описание процесса разработки.


VirtualPlanetBuilder
alex_bobkov

VirtualPlanetBuilder (VPB) – приложение с открытым исходным кодом для генерации 3д-модели рельефа на основе разнообразных геопространственных изображений (спутниковых снимков) и высотных данных. Рельеф создается в виде множества тайлов с разными уровнями детализации в формате библиотеки OpenSceneGraph. Рельеф оптимизирован для использования в интерактивных приложениях. В зависимости от исходных данных поддерживается создание рельефов разных размеров - до нескольких терабайт, размещенных на кластере компьютеров. Рельеф может быть либо “плоским”, либо геоцентрическим.

VPB разработан Робертом Осфилдом, который также является разработчиком библиотеки OpenSceneGraph.

VPB понимает большое количество форматов геопространственных изображений и высотных данных. Для этого внутри VPB использует библиотеку GDAL (Geospatial Data Abstraction Library). GDAL – библиотека для работы с растровыми географическими форматами файлов данных. Помимо этого в состав GDAL входит набор вспомогательных программ, вызываемых из командной строки, для преобразования и обработки данных.

Подготовка исходных данных

Обычные изображения в форматах jpg, png не могут быть использованы напрямую для генерации рельефа. Для этого нужно осуществить их геопривязку – указать долготу и широту границ изображения. Это можно сделать  с помощью программы gdal_translate, входящей в состав GDAL:

gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr ulx uly lrx lry input.jpg output.tif

где вместо ulx, uly, lrx, lry нужно подставить долготу и широту в градусах верхнего левого и правого нижнего углов изображения. На выходе получится файл output.tif в формате GeoTIFF.

Например, для геопривязки изображений NASA Blue Marble Next Generation нужно использовать следующие команды:

gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr -180 90 -90 0 world.topo.bathy.200407.3x21600x21600.A1.jpg A1.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr -90 90 0 0 world.topo.bathy.200407.3x21600x21600.B1.jpg B1.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr 0 90 90 0 world.topo.bathy.200407.3x21600x21600.C1.jpg C1.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr 90 90 180 0 world.topo.bathy.200407.3x21600x21600.D1.jpg D1.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr -180 0 -90 -90 world.topo.bathy.200407.3x21600x21600.A2.jpg A2.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr -90 0 0 -90 world.topo.bathy.200407.3x21600x21600.B2.jpg B2.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr 0 0 90 -90 world.topo.bathy.200407.3x21600x21600.C2.jpg C2.tif
gdal_translate -of GTiff -a_srs "+proj=latlong +datum=WGS84" -a_ullr 90 0 180 -90 world.topo.bathy.200407.3x21600x21600.D2.jpg D2.tif

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

Разные изображения могут храниться в разных картографических проекциях и могут иметь разные датумы. Поэтому их нужно привести к единой системе координат и единому датуму. Для построения геоцентрического рельефа (виртуального глобуса) обычно используют географическую систему координат (долгота, широта и высота) и датум WGS84. Для преобразования изображения можно использовать утилиту gdalwarp, которая входит в состав GDAL. Вот пример вызова этой утилиты:

gdalwarp -t_srs epsg:4326 input.tif output.tif

Для более быстрого доступа к отдельным частям очень больших файлов имеет смысл хранить данные внутри файла в виде набора тайлов:

gdal_translate -of GTiff -co "TILED=YES" intput.tif output.tif

Также для очень больших файлов удобно заранее сгенерировать уменьшенные варианты изображений, которые бы использовались для низких уровней детализации. Для этого можно использовать утилиту gdaladdo, которая входит в состав GDAL:

gdaladdo -r average file.tif 2 4 8 16 32

Компиляция приложения

Получить исходники приложения можно можно из SVN-репозитория:
http://www.openscenegraph.org/svn/VirtualPlanetBuilder/trunk

Необходимые зависимости: OpenSceneGraph и GDAL. Для генерации проектов Visual Studio используется CMake.

Генерация рельефа

В состав VPB входит несколько утилит. Основная – osgdem. Через аргументы командной строки на вход передаются имена файлов с геопространственными изображениями и другие параметры, описывающие характеристики рельефа. На выходе получается множество файлов с формате ive.

Утилита vpbmaster – более развитый аналог osgdem. Она умеет дополнительно распараллеливать процесс генерации базы данных, используя все ядра процессора, а также другие компьютеры, входящие в кластер. Также эта утилита может возобновлять прерванный процесс генерации и добавлять наложения к уже существующим рельефам.

У osgdem и vpbmaster большая часть аргументов командной строки одинаковая. Вот самые основные:

  • -d <filename> файл с высотными данными
  • -t <filename> файл с изображением
  • --geocentric геоцентрический рельеф
  • -l <numOfLevels> число уровней детализации

Пример построения глобуса на основе данных NASA Blue Marble Next Generation:

osgdem –geocentric -t A1.tif -t B1.tif -t C1.tif -t D1.tif -t A2.tif -t B2.tif -t C2.tif -t D2.tif -o earth.ive

Структура получившихся файлов

На выходе получается множество файлов, каждый из которых содержит тайл рельефа с определенным уровнем детализации. Все файлы соединены ссылками и образуют дерево. На рисунке изображена структура корневого файла и одного обычного регулярного файла. Каждый TerrainTile содержит текстуру в формате dds и высотные данные в виде osg::HeightField.


Обзор OpenSceneGraph
alex_bobkov

28го июня вышла третья версия ОпенСценГрафа. К этому долгожданному событию написал краткий обзор ОСГ в целом.

OpenSceneGraph - кроссплатформенный инструментарий для разработки интерактивных 3д-приложений. Его области применения: симуляторы, научная визуализация, виртуальная реальность, игры. OpenSceneGraph основывается на OpenGL. Он написан на C++, активно использует STL и паттерны объектно-ориентированного проектирования. ОпенСценГраф поддерживает операционные системы: Windows, Linux, Mac OS X, Android, iOS и другие. Лицензия — OpenSceneGraph Public License (OSGPL) — позволяет использовать ОпенСценГраф в том числе в проприетарных приложениях.

Разработка ОпенСценГрафа началась в 1997м году Доном Бёрнсом. Идеологически он опирался на OpenGL Performer, движок компании Silicon Graphics Inc. Позже к проекту присоединился Роберт Осфилд и принял на себя лидерство в разработке. Версия 2.0 вышла в 2007м году, а версия 3.0 - в июне 2011го года. В настоящее время ОпенСценГраф - один из лучших свободных движков общего назначения на основе OpenGL.

ОпенСценГраф - является не игровым, а графическим движком. ОСГ отвечает только за вывод графики. Существует расширение, которое добавляет возможность вывода звука. Есть возможность подключения физических движков. На базе ОСГ существует также игровой движок Delta3D.

ОпенСценГраф обеспечивает следующие базовые возможности:

  • управление 3д-моделями и группами моделей с помощью структуры данных “граф сцены”
  • загрузка 3д-моделей и текстур множества стандартных форматов
  • отсечение невидимых объектов
  • минимизация переключения состояния OpenGL
  • рендеринг текста

Расширенные возможности, которые входят в состав ОпенСценГрафа:

  • osgParticle — работат с системами частиц
  • osgShadow — создание теней разными методами
  • osgVolume — объёмный рендеринг
  • osgAnimation — скелетная анимация
  • osgGA — управление камерой разными способами
  • osgWidget — графический интерфейс
  • osgViewer — поддержка нескольких видеокарт, нескольких экранов, вывода в несколько окон одновременно

Отдельные расширения:

  • VirtualPlanetBuilder — генерация рельефа
  • osgEarth — динамическая генерация рельефа
  • osgOcean — рендеринг поверхности океана
  • osgPPU — постпроцессинг
  • osgEphemeris — рендеринг неба в разное время суток с поверхности земли

Плагин для 3ds max для экспорта моделей в форматах ive и osg, родных форматах ОпенСценГрафа: OSGExp.
Порт ОпенСценГрафа под WebGL: osgjs.

Литература по ОпенСценГрафу:


Теория омега-точки
alex_bobkov

Недавно посмотрел фильм “Начало” Нолана. Очень понравился. И у меня сразу возникли ассоциации с книгой Дэвида Дойча “Структура реальности”. В последней главе он рассматривает сценарий “Конца света”, т.е. Большого Сжатия, который был предложен Фрэнком Типлером.

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

В частности, они смогут построить Универсальный генератор виртуальной реальности. Этот Генератор будет использовать энергию колебаний пространства-времени, работать с очень большой скоростью и манипулировать почти неограниченными ресурсами. Люди будущего могут запустить в этом Генераторе моделирование развития нашей вселенной, начиная с Большого взрыва. За секунды времени в реальном мире могут пройти миллионы лет внутри Генератора виртуальной реальности.

Если начальные условия будут подобраны правильно, то рано или поздно внутри Генератора появится Солнце, Земля, разовьется человеческая цивилизация и мы с вами.

Дальше Дойч и Типлер начинают фантазировать о моральных установках людей будущего. Возможно для них будет аморально позволить нам умереть. Поэтому они могут создать внутри Генератора отдельную изолированную область, в которую будет попадать наш разум после “смерти”. Эту область можно назвать “рай”.

Так что, нужно верить в наших далёких потомков, и “рай” нам "обеспечен" :)


Создание RPM-пакетов (на примере Федоры)
alex_bobkov

Под Линуксом удобно устанавливать новые программы в виде RPM (или DEB) пакетов. Вся информация сохраняется в специальную базу данных. Это позволяет без проблем обновлять или удалять программы. К сожалению, разработчики дистрибутивов не торопятся включать в официальные репозитории последние версии программ, а разработчики программ не всегда выкладывают RPM-пакеты собственного изготовления.

Создание RPM-пакетов — дело не сложное, но информации об этом не так много. Существует подробное руководство на английском языке для Федоры, а также цикл статей на русском языке. В первом — слишком много текста для первого знакомства, второй немного устарел, и мне не особо нравится. Здесь я хочу рассмотреть основные идеи в создании RPM-пакетов. Они могут быть полезны тем, кто только задумывается об этом для своей программы.

1. Подготовка инфраструктуры

Необходимо установить пакет rpmdevtools из под рута и выполнить команду rpmdev-setuptree из-под обычного юзера (например, alex). После этого в домашней директории юзера будет созданы директории:
rpmbuild
rpmbuild/BUILD
rpmbuild/BUILDROOT
rpmbuild/RPMS
rpmbuild/SOURCES
rpmbuild/SPECS
rpmbuild/SRPMS

2. Сборка RPM-пакета

Необходимо сделать tar.gz архив с исходниками программы. Название должно следовать шаблону: <name>-<version>.tar.gz (например, myprogram-1.0.tar.gz). Архив нужно поместить в директорию SOURCES.

Необходимо создать spec-файл с именем <name>.spec. Spec-файл содержит метаинформацию о пакете и скрипты для сборки, установки и удаления пакета. Spec-файл нужно поместить в директорию SPECS.

Из директории SPECS вызвать команду rpmbuild -ba <name>.spec

В случае успешного завершения будут созданы 3 RPM-пакета с приблизительно следующими названиями:

  • RPMS/i686/<name>-<version>-1.fc13.i686.rpm — искомый RPM-пакет
  • RPMS/i686/<name>-<version>-debuginfo-1.fc13.i686.rpm — пакет с отладочной информацией
  • SRPMS/i686/<name>-<version>.fc13.src.rpm — пакет с исходниками и spec-файлом

3. Описание spec-файла

Spec-файл состоит из 2х частей: метаинформации о пакете (название, описание, версия, лицензия, URL, название архива с исходниками, зависимости) и набора секций, которые называются %description, %prep, %build, %install, %clean, %files, %changelog.

Сборка программы происходит в директории BUILD, после чего устанавливается в директорию BUILDROOT. Для их удобного обозначения применяются макроопределения %{_builddir} и %{buildroot}.

Имеется также много других удобных макроопределений и макрокоманд.

Рассмотрим типичный spec-файл:

Summary: The example program
Name: myprogram
Version: 1.0
Release: 1.%{?dist}
License: GPL
Group: Applications/Multimedia
URL: http://example.com/
Source0: %{_sourcedir}/%{name}-%{version}.tar.gz
BuildRequires: automake
BuildRequires: autoconf
Requires: python

%description
The example program

%prep
%setup

%build
%configure
make

%install
rm -rf %{buildroot}
make DESTDIR=%{buildroot} install

%clean
rm -rf %{buildroot}

%files
%defattr(-, root, root)
%doc
%{_bindir}/*

%changelog
* Tue Jul 13 2010 Alexander Bobkov <alexbobkov@list.ru> 1.0-1

Первая половина файла в особых комментариях не нуждается. Рассмотрим несколько важных секций из второй половины.

  • В секции %prep происходит подготовка исходников. Необходимо их поместить в директорию BUILD. Для удобства используется макрос %setup, который распаковывает архив из директории SOURCES. Если имеются дополнительные файлы, то их можно копировать простой командой cp.
  • Секция %build содержит скрипт для сборки программы. В данном случае скрипт состоит только из двух команд: макрос %configure запускает команду configure, а make делает известно что.
  • Секция %install производит установку программы в директорию BUILDROOT
  • В секции %files указываются файлы из директории BUILDROOT, которые должны быть помещены в RPM-пакет.

Таким образом можно сделать собственный RPM-пакет для своей программы. По сути, spec-файл аккумулирует опыт ручной установки программы. Более подробное описание – в официальном руководстве.

Tags: , ,

?

Log in