Для меня эти две модели очень похожи, однако у них нет очевидных характеристик, по которым можно было бы измерить их сходство. У этих моделей разное количество вершин, рёбер и полигонов, они разного размера, к тому же по-разному повёрнуты в пространстве, и у обеих одинаковые трансформации (Положение = [0,0,0], Вращение в радианах = [0,0,0], Масштаб = [1,1,1]). Как определить их подобие?

Привет, Хабр! Представляю вашему вниманию перевод статьи «5 Reasons Motion Graphics Help You Connect With People» автора Katy French.



Оригинал статьи: Katy French | Перевод статьи сделал моушн дизайнер Игорь Царёв

Мы большие поклонники моушн дизайна. Это не потому, что он красивый или имеет классную анимацию. Это потому, что моушн дизайн – это уникальный способ общения. Он сочетает в себе всё лучшее, что есть в визуальной коммуникации, сторителлинге в движении и звуке с целью создания привлекательного контента, помогающего брендам делиться своей историей.

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

Хорошо, но что такое моушн дизайн?

Касательного этого формата может возникнуть некоторая путаница. Это что, видео? Это что, мультики? В основном, моушн дизайн – это термин нашей индустрии для анимированного видео. Это могут быть 2D-анимации, 3D-рендеринги или GIF-файлы.

Задача

При разработке нашей игры The Unliving, мы поставили перед собой задачу по отображению различных сообщений, таких, как нанесенный урон, нехватка здоровья или энергии, величина награды, количество восстановленных очков здоровья и т.д., с помощью Particle System. Это было решено сделать для того, чтобы получить больше возможностей для кастомизации эффектов появления и дальнейшего поведения таких сообщений, что проблематично при использовании стандартных элементов UI-системы Unity.

Кроме того, данный подход подразумевает использование всего лишь одного инстанса Particle System для каждого типа сообщений, что дает огромный прирост в производительности по сравнению с выводом этих же сообщений с помощью Unity UI.

Всем привет! Я — тимлид команды по разработке десктопных приложений в компании Роджии Европа. Мы разрабатываем программные решения для нефтегазовой отрасли.

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

Обходя вопросы наследия кодовой базы — о нём я упомяну в статье — был один фундаментальный вопрос — с помощью какой технологии делать? Однозначно нам был нужен OpenGL — который уже применяется в MapView и 3d view на базе OpenSceneGraph — но очевидно, что не голый, и с элементами графического интерфейса. OSG отвалился =(. Технологию, удовлетворяющую двум требованиям — граф сцены и GUI на OpenGL — я знал только одну — Qt QML/Quick. О том, что же у нас получилось и чем нам есть поделиться — внутри.

Не одними волосами едины. Теперь перьевые персонажи доступны не только в синематеках! Да-да, не плашки, а натуральные динамические перья! 26 ноября 2019 года на официальном сайте Peregrine Labs объявили о том, что их продукт, плагин Yeti версии 3.5.4, состоит в официальных “отношениях” с Unreal Engine версии 4.24.

Я очень долго думал, нужно ли писать статью на столь банальную тему. Но так сложилось в жизни, что за очень короткое время мне попадалось быть участником настоящих холи варов на эту тему. Как я понимаю тема больная, по большой части из-за горького опыта работы с псевдо “специалистами” и глобального непонимания комьюнити роли ПМа на проекте.

Я уже представляю толпы людей, которые закидают меня тапками, ведь и так понятно “менеджер зло”, “убийца креатива” и вообще ненужное звено в процессе… Но это статья о том, как менялось мое воспринимание менеджерского состава на проекте, как я учился различать “свой-чужой” и главное, как я дорос до понимания роли Project manager.

Всем привет! Меня зовут Дядиченко Григорий, и я основатель и CTO студии Foxsys. Сегодня мы поговорим про вершинные шейдеры. В статье будет разбираться практика с точки зрения Unity, очень простые примеры, а также приведено множество ссылок для изучения информации про шейдеры в Unity. Если вы разбираетесь в написании шейдеров, то вы не найдёте для себя ничего нового. Всем же кто хочет начать писать шейдеры в Unity, добро пожаловать под кат.

Всем привет! Меня зовут Дядиченко Григорий, и я основатель и CTO студии Foxsys. Сегодня хочется поговорить про шейдеры. Умение писать шейдеры (и в целом работать с рендером) очень важно при разработке под мобильные платформы или AR/VR, если хочется добиться крутой графики. Многие разработчики считают, что шейдеры — это магия. Что по ним мало хорошей информации, и что чтобы их писать нужно иметь, как мимимум, звание кандидата наук. Да, разработка шейдеров по своим принципам сильно отличается от клиентской разработки. Но основное понимать базовые принципы работы шейдеров, а так же знать их суть, чтобы в этом не было ничего магического и поиск информации по этой теме был простой задачей. Данная серия статей рассчитана на новичков, так что если вы разбираетесь в программировании шейдеров, данная серия вам не будет интересна. Всем же кто хочет разобраться в этой теме — добро пожаловать под кат!

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

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

Недавно я столкнулся лицом к лицу с таким зверем как Autodesk Maya. За плечами у меня не было опыта в работе с 3Д моделированием и пришлось в экстренном порядке прокачиваться, начиная с основ, а также ознакомится с функциональностью данного ПО, чтобы проверить работу плагина (QA), который экспортил всё содержимое сцены в определенный формат. Эта статья рассчитана на людей без опыта либо с минимальным в Autodesk Maya и призвана познакомить вас с полезными функциями и редакторах, которые можно в ней найти. Если же вы не нашли функцию/редактор, который считаете полезным, то либо я с ним еще не работал, либо он не пригодился для моих нужд. Расскажите о них и о реальных случаях их применения в комментариях :-)

Статья разделена на секции, каждая из которых относится к одному из аспектов 3Д модели:

1. Общие инструменты
2. Работа с геометрией (полигональной сеткой)
3. Работа с текстурами
4. Работа с анимацией
5. Shelf Editor, Shelves и немного о MEL (Maya Embedded Language)

Всем хорошего настроения и температуры за окном пониже. Как и обещал, публикую продолжение статьи по супер-пупер современному OpenGL. Кто не читал первую часть — Суперсовременный OpenGL. Часть 1.

Возможно повезет и я смогу весь оставшийся материал впихнуть в эту статью, это не точно…

Всем привет. Все кто хоть немного разбирался в теме OpenGL знают, что существует большое количество статей и курсов по этой теме, но многие не затрагивают современный API, а часть из них вообще рассказывают про glBegin и glEnd. Я постараюсь охватить некоторые нюансы нового API начиная с 4-й версии. Ссылка на вторую часть статьи

Введение

С одной стороны движок 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 строчек кода?