Введение

С одной стороны движок OpenSceneGraph и сам по себе обладает развитой подсистемой управления окнами, обработки событий пользовательского ввода, отправки и приема пользовательских сообщений. Об этом мы довольно подробно поговорили в предыдущих статьях этого цикла. В общем, в сумме с возможностями C++/STL этого вполне достаточно для разработки сколь угодно сложных приложений.

Пример интеграции OSG в приложение, разработанной в QtDesigner. Этот пример будет подробно разобран ниже


С другой стороны, для ускорения разработки на C++ применяются как сторонние библиотеки, расширяющие возможности этого языка (вроде boost), так и целые фреймворки, позволяющие легко и непринужденно разрабатывать кроссплатформенные приложения широкого функционального назначения. Одним из таких фреймворков является ультра популярный Qt. Как бы не ругали Qt за его метаобъектный компилятор и прочие недостатки и неудобства, сила Qt в обширной библиотеке классов, решающей все мыслимые задачи кроссплатформенной разработки, а так же в концепции "сигналы — слоты", реализующей подсистему обмена сообщениями между классами. На сигналах и слотах основаны так же методы взаимодействия приложения с операционной системой, а так же межпроцессное взаимодействие.

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

Пришли очередные выходные, надо написать пару десятков строк кода и нарисовать картинку, да лучше не одну. Итак, на прошлых и позапрошлых выходных я показал, как делать трассировку лучей и даже взрывать всякое. Это многих удивляет, но комьпютерная графика — очень простая вещь, пары сотен строк голого C++ вполне хватает на создание интересных картинок.

Тема сегдоняшнего разговора — бинокулярное зрение, причём сегодня даже до ста строк кода не дотянем. Умея рендерить трёхмерные сцены, было бы глупо пройти мимо стерепар, сегодня будем рисовать примерно вот такое:

Введение

Одной из интереснейших задач, решаемых посредством трехмерной графики является создание «больших миров» — протяженных сцен, содержащих большое число объектов с возможностью неограниченного перемещения по сцене. Решение этой задачи упирается в понятные ограничения, присущие аппаратному обеспечению компьютера.

Типичный пример: «большой мир» при визуализации железной дороги на движке OSG. Не хватает только лангольеров, пожирающих мир за поездом...


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

Введение

Где-то в предыдущих уроках уже говорилось о том, что OSG поддерживает загрузку разного рода ресурсов типа растровых изображений, 3D-моделей различных форматов, или, например, шрифтов через собственную систему плагинов. Плагин OSG является отдельным компонентом, расширяющим функционал движка и обладающий интерфейсом, стандартизированным в пределах OSG. Плагин реализуется как динамическая разделяемая библиотека (dll в Windows, so в Linux и т.д). Имена библиотек плагинов соответствуют определенному соглашению

osgdb_<расширение файла>.dll

то есть в имени плагина всегда присутствует префикс osgdb_. Расширение файла указывает движку какой плагин следует использовать для загрузки файла с данным расширением. Например, когда мы пишем в коде функцию

osg::ref_ptr<osg::Node> model = osgDB::readNodeFile("cessna.osg");

движок видит расширение osg и загружает плагин с именем osgdb_osg.dll (или osgdb_osg.so в случает Linux). Код плагина выполняет всю черную работу, возвращая нам указатель на ноду, описывающую модель цессны. Аналогичным образом, попытка загрузки изображения формата PNG

osg::ref_ptr<osg:Image> image = osgDB::readImageFile("picture.png");

приведет к тому, что будет загружен плагин osgdb_png.dll, в котором реализован алгоритм чтения данных из картинки в формате PNG и помещение этих данных в объект типа osg::Image.

Введение

Одной из особенностей языка C++, за которую его часто критикуют — отсутствие в стандарте механизма обработки событий. Между тем данный механизм это один из основных путей взаимодействия одних программных компонентов с другими программными компонентами и аппаратным обеспечением, и реализуется он на уровне конкретной ОС. Естественно, что каждая из платформ имеет свои нюансы реализации описанного механизма.

В связи со всем вышеперечисленным, при разработке на C++, возникает потребность в реализации обработки событий тем или иным способом, решаемая за счет использования сторонних библиотек и фреймворков. Всем известный фреймворк Qt предоставляет механизм сигналов и слотов, позволяющий организовать взаимодействие классов, наследуемых от QObject. Реализация событий присутствует и в библиотеке boost. И конечно же в движке OpenSceneGraph не обошлось без собственного «велосипеда», о применении которого и пойдет речь в статье.

Введение

Мы уже говорили о том, что класс osg::Camera управляет связанным с ним графическим контекстом OpenGL. Графический контекст инкапсулирует информацию о том, как и куда происходит отрисовка объектов и какие атрибуты состояния к ним применяются. Под контекстом понимают графическое окно, вернее его клиентскую область, или пиксельный буфер OpenGL, который хранит данные пикселей без передачи их в кадровый буфер.

OSG использует класс osg::GraphicsContext для представления абстрактного графического контекста, и класс osg::GraphicsWindow, для представления абстрактного графического окна. Последний имеет метод getEventQueue() для управления событиями от элементов GUI. Вообще говоря графический контекст есть платформоспецифичное понятие, поэтому большую часть работы по созданию окна и связыванию его контекста с контекстом OpenGL, OSG берет на себя. При вызове метода createGraphicsContext() класса osg::GraphicsContext() требуемый код (а его не мало, поверьте!) будет сгенерирован препроцессором автоматически, в зависимости от платформы. От нас лишь требуется передать этому методу аргумент типа osg::GraphicsContex::Traits, содержащий описание того, какое окно мы хотим получить.

Введение

Говоря о приемах программирования, специфичных для OSG в прошлый раз мы говорили о механизме обратных вызовов (Callback) и его реализации в движке. Настало время посмотреть на то, какие возможности дает нам применение этого механизма для управления содержимым трехмерной сцены.

Если говорить об анимации объектов, то OSG предоставляет разработчику две возможности её реализации:

1. Процедурная анимация, реализуемая программным способом через трансформацию объектов и их атрибутов
2. Экспорт анимации из 3D-редактора и управление ею из кода приложения

Для начала рассмотрим первую возможность, как наиболее очевидную. О второй мы обязательно поговорим чуть позже.

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

Как всегда, в нашем распоряжении только голый компилятор, никаких сторонних библитек использовать нельзя. Я не хочу заморачиваться с оконными менеджерами, обработкой мыши/клавиатуры и тому подобным. Результатом работы нашей программы будет простая картинка, сохранённая на диск. Я совершенно не гонюсь за скоростью/оптимизацией, моя цель — показать основные принципы.

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

Всем привет! Меня зовут Гриша, и я основатель CGDevs. Продолжим говорить про математику что ли. Пожалуй, основное применение математики в геймдеве и компьютерной графики в целом – это VFX. Вот и поговорим про один такой эффект – дождь, а точнее про его основную часть, требующую математики – рябь на поверхности. Последовательно напишем шейдер для ряби на поверхности, и разберём его математику. Если интересно – добро пожаловать под кат. Гитхаб проект прилагается.

Всех с наступающим! Меня зовут Гриша, и я основатель CGDevs. Уже не за горами праздники, кто-то уже нарядил ёлку, поел мандаринов и во всю заряжается новогодним настроением. Но сегодня речь пойдёт не об этом. Сегодня мы поговорим про замечательный формат под названием LDraw и про плагин для Unity, который я реализовал и выложил в OpenSource. Ссылка на проект и исходники к статье, как всегда, прилагаются. Если вы так же, как и я любите лего – добро пожаловать под кат.

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

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

Также я сделал небольшое веб-приложение, где можно потренироваться в создании формул для произвольных фигур и сгенерировать свой файл Excel.

Осторожно: 19 картинок и 3 анимации под катом.

3 года назад художник спросил меня:
— Слушай, а можно в нашу мобильную игру добавить красивые облачка?
— Нет, это абсолютно невозможно, у нас постоянно вращается камера, так что билборды будут смотреться очень фальшиво даже если на них добавить карты нормалей, а другие способы…
*художник погружается в летаргический сон*

Для меня нет большего удовольствия, чем выяснять, что я был неправ.



Про фотореалистичный рендеринг облаков написано много статей, но если хочется рисовать облака на смартфоне, приходится придумывать кучу всяких хаков, упрощений и допущений.
Под катом подробное описание рендеринга облаков на мобильных и много html5 гифок.

Можно было делать очень долгое и интересное введение в тематику антитеррористических мероприятий на объектах критической инфраструктуры, но это не является профильным направлением Хабрхабра, поэтому попытаюсь сделать краткую инъекцию, не отягощенную терминологией.

И всё же, для тех, кто решит пропустить длинное введение, ищите подзаголовок «Что же с виртуальной реальностью?».

Кому интересны только итог и «Best practice», тогда сразу в «Заключение».

Обновление от 18.12.2017: добавлено видео, ускоренное в 4 раза.


Для тех, кто может позволить себе 20 минут отдыха, сcылка на видео со звуком в FB.

Что за проблема такая?

Конкретно в данном случае, мы говорим о специалистах по охране ядерных установок. Глобально десятки или даже сотни тысяч специалистов в ожидании первичного или очередного, обучения, а учебных и тренировочных центров не хватает (более подробно ниже под спойлером).

Привычно читать о проникновении информационных технологий на производство, в финансы, логистику, ритейл и другие сферы. А что если соединить театр и ИТ?

Мне повезло участвовать в таком проекте и следовать не привычному ТЗ, а режиссерскому замыслу, который окончательно формировался на моих глазах. В Московском драматическом театре имени М. Н. Ермоловой мы устанавливали аудиовизуальное оборудование, и пару месяцев я был полноправным участником репетиций – следил за процессом из-за кулис и с балкона, где располагалось рабочее место инженера видеомонтажа, настраивал технику и вносил коррективы.



О наших экспериментах в области театрального искусства, о сложностях и победах я и расскажу. В этом посте также будет много фотографий: театр ведь зрелищное искусство. А для самых нетерпеливых сразу под катом выкладываю видеоспойлер. В этом видеоролике нет технических деталей (в отличие от поста), зато всего за три минуты вы узнаете о совместных проектах ЛАНИТ и Ермоловского театра.

Вы выбрали карьеру дизайнера. Я не могу отговорить вас от этой идеи, не смотря на то что вы уже отдали кучу времени/денег (или того и иного вместе) для того, чтобы стать Новым Великий Дизайнером. Я думаю, через пару лет вы начнёте задавать себе тот же вопрос, что и я: “Почему я не занялся сыроварением?”.

Друзья, хочу поделиться опытом, который приобрел в процессе практического изучения дисциплины, как фотограмметрия. Буду рад, если кто-нибудь из вас выскажет свое мнение, поправит меня или укажет на ошибки, которые допустил. Возможно эта статья по изучению мною фотограмметрии поможет и будет полезна Вам. Моя работа описана на примере фотосъемки природы в городском парке, в Центральной полосе России, в период август–сентябрь 2017 г.

Друзья, 9-10 сентября в московском офисе Mail.Ru Group состоится самый ожидаемый фестиваль компьютерной графики CGSpace#6. Вас ждут два дня полезных и увлекательных лекций, воркшопов, общения и много приятных сюрпризов!

Для того, чтобы каждый смог понаблюдать за процессом создания синематика в игровой компании, мы начинаем серию живых включений прямо из Video Production Department в Plarium Kharkiv.

Себастьян ван Элвердинге рассказывает о своём подходе к созданию потрясающих трёхмерных камней и скал с помощью множества фотографий. Более подробно о нём можно узнать в туториале на gumroad.com/sebvhe.

Введение

Привет, меня зовут Себастьян, я живу в Брюсселе, на родине лучшего картофеля фри, пива и шоколада! Сейчас я работаю художником по окружениям в Starbreeze Studios (Стокгольм). раньше я работал в Playground Games над игрой Forza Horizon 3, которая стала для меня отличной возможностью применения фотограмметрии в игре AAA-класса.



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

Хотя с момента написания мой рабочий процесс немного поменялся, туториал всё равно применим к тому, что собираюсь рассказать. Если вам будет что-то непонятно в этом интервью, то, скорее всего, вы найдёте подробное объяснение в туториале.

Сегодня речь зайдёт о цвете.



Это спектр видимого света, построенный в цветовом пространстве sRGB с помощью прототипа моего колориметрического движка. Внизу подписана длина волны в нанометрах. Именно пространство sRGB является сегодня стандартом для интернета, так как оно поддерживается подавляющим большинством дисплеев. Но по правде, цветовой охват его невелик (всего 36 % от видимых глазом цветов); в нём очень плохо передаются оттенки зелёного. По этой причине на изображённый спектр наложен серый фон, снижающий насыщенность цветов до той, которую можно отобразить на стандартном мониторе. О том же, какие закономерности лежат в основе формирования цвета, и как цвет представлен в цифровой технике, да поведает эта статья.