Работа с 3D-графикой *

Тест-драйв nanoCAD СПДС Стройплощадка 8

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

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

Что такое портал?

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


Из трёх игр самой известной, вероятно, является Portal, однако лично меня всегда восхищала Prey и именно её я мечтал скопировать. Однажды я попробовал реализовать собственную версию в Unreal Engine 4, но не особо преуспел, потому что в движке не хватало функционала. Тем не менее, мне удалось провести вот такие эксперименты:


Однако только в новых версиях Unreal Engine мне наконец-то удалось добиться нужного эффекта:

Приглашаем вас принять участие в бесплатном вебинаре «Создание металлической фермы в СПДС Металлоконструкции».

ЗАРЕГИСТРИРОВАТЬСЯ



Вебинар состоится 23 апреля в 11:00 по Москве. Программа вебинара включает в себя демонстрацию новых возможностей программного продукта СПДС Металлоконструкции, предназначенного для автоматизации разработки проектно-конструкторской документации марок КМ и АС.

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

Введение

---

«Что получится, если мы заменим числа с плавающей запятой на рациональные числа и попытаемся отрендерить изображение?»

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

Это зародило во мне мысль — если допустить, что все входящие данные рендерера (координаты вершин, 3D-преобразования и т.д.) были бы заданы как рациональные числа, то создавали бы все операции, от создания луча, обхода ускоряющей структуры и до пересечения лучей с треугольниками только рациональные числа? Если это было бы так, то мы бы смогли выполнять проверку копланарности совершенно точно! Возможно, вы зададитесь вопросом, почему 3D-сцена, выраженная в рациональных числах должна давать результаты тоже только в рациональных числах…


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

В прошлой части мы рассказывали о зарождении КОМПАС-3D v18, кое-что о выборе критериев и моделей для тестирования новых функций, а также затронули тему отрисовки в варианте «Базовый».
Продолжим рассказом о варианте отрисовки «Улучшенный».

Искажения, бесшовный шум и как с ними работать.

Генерируем планету

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

• Шум Перлина (Perlin Noise) — самый простой вариант. Шум Перлина был разработан Кеном Перлином в 1983 году, он имеет пару недостатков — визуальные артефакты и довольно низкая по сравнению с другими вариантами скорость при генерации больших изображений.
• Симплекс-шум (Simplex Noise) — разработан Кеном Перлином в 2001 году как попытка устранения недостатков шума Перлина; это вполне достойное и быстрое решение, однако обладающее серьёзным недостатком: использование трёхмерного симплекс-шума защищено патентом, что делает его довольно дорогостоящим.
• Открытый симплекс-шум (Open Simplex Noise) — был разработан KDotJPG с одной простой целью: создать современную и бесплатную версию симплекс-шума, относительно быструю и без искажений.

Из этих трёх лично я предпочитаю Open Simplex Noise, который использую в своих личных проектах. Стоит заметить, что в текущей реализации OpenSimplexNoise для получения простого доступа к масштабу, октавам и порождающим значениям потребуется дополнительная работа. В Интернете есть множество информации о том, что делает каждый из этих элементов, и я крайне рекомендую вам её изучить. Однако в своей статье я буду говорить не об этом.

Тест-драйв nanoCAD СПДС Металлоконструкции 1.2 Часть 2

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

Данная статья является продолжением рассмотра основ GLTF и GLB форматов. Вы можете найти первую часть статьи здесь. В первой части мы рассмотрели с вами зачем изначально планировался формат, а также такие артефакты и их атрибуты GLTF формата как Scene, Node, Buffer, BufferView, Accessor и Mesh. В данной же статье мы рассмотрим Material, Texture, Animations, Skin, Camera, а также закончим формировать минимальный валидный GLTF файл.

Material и Texture

С мешем неразрывно связаны материалы и текстуры. При необходимости меш может быть анимирован. Материал хранит информацию о том, как модель будет отрендерена движком. GLTF определяет материалы, используя общий набор параметров, которые основаны на Physical-Based Rendering (PBR). PBR модель позволяет создавать “физически корректное” отображение объекта в разных световых условиях благодаря тому, что шейдинговая модель должна работать с “физическими” свойствами поверхности. Есть несколько способов описания PBR. Самая распространенная модель — это metallic-roughness model, которая и используется по умолчанию в GLTF. Также можно использовать и specular-glosiness модель, но только при помощи отдельного расширения (extenstion). Основные атрибуты материала следующие:

1. name — имя меша.
2. baseColorFactor/baseColorTexture — хранит инфомрацию о цвете. В случае атрибута Factor информация хранится в числовом значении для RGBA, в случае Texture — хранится ссылка на текстуру в объекте textures.
3. metallicFactor — хранит информцию о Metallic
4. roughnessFactor — хранит информцию об Roughness
5. doubleSided — имеет значение true либо false (значение по умолчанию) и указывает на то, будет ли меш рендериться с обоих сторон или только с "лицевой" стороны.

Что такое GLTF и GLB?

GLTF (GL Transmission Format) — это формат файла для хранения 3Д сцен и моделей, который является крайне простым в понимании (структура записана в стандарте JSON), расширяемым и легко взаимодействующим с современными веб-технологиями. Данный формат хорошо сжимает трёхмерные сцены и минимизирует обработку во время выполнения приложений, использующих WebGL и другие API. GLTF сейчас активно продвигается Khronos Group как JPEG от мира 3D. На сегодняшний день используется GLTF версии 2.0. Существует и бинарная версия данного формата, которая называется GLB, единственное различие которого в том, что все хранится в одном файле с расширением GLB.

Эта статья — 1 часть из 2х. В ней мы с вами рассмотрим такие артефакты формата и их атрибуты, как Scene, Node, Buffer, BufferView, Accessor и Mesh. А во второй статье мы рассмотрим оставшиеся: Material, Texture, Animations, Skin и Camera. Больше общей информации о формате можно найти здесь.
Если в процессе просмотра статьи захочется лично поработать с данным форматом, то можете скачать модели GLTF 2.0 с официального репозитория Khronos на GitHub

Проблематика и её решение

Изначально GLTF формат был задуман Khronos Group как решение для передачи 3D контента по интернету и был призван минимизировать количество импортеров и конвертеров, разные виды которых создаются при работе с графическими API.

На текущий момент GLTF и его бинарный брат GLB используются как унифицированные форматы и в CAD программах (Autodesk Maya, Blender и т. д.), в игровых движках (Unreal Engine, Unity и прочих), AR/VR приложениях, соц. сетях и т.д.

В этой статье мы поговорим про скульптинг, ретопологию и развертку. Но сначала нужно определиться с целью. Что мы будем моделировать, и каким способом?

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

В ходе подготовки к очередному семейному празднику — годовщины родителей решил воплотить в жизнь одну замечательную идею — создание уникального фотосветильника с помощью 3D технологий.



Идея пришла не мне, буду честен, увидел реализацию у моего интернет товарища — Николая Ралкова (за что хочу выразить ему отдельную благодарность за идею и помощь в решение возникающих проблем).

Итак, пробежимся по порядку.

Тест-драйв
nanoCAD СПДС Металлоконструкции 1.2

Уважаемые хабровцы, интересующиеся САПР,
За несколько месяцев ведения блога на Хабре мы получили много вопросов, об основных инструментах программ СПДС Металлоконструкции и СПДС Стройплощадка. Поэтому решили создать и опубликовать материалы тест-драйвов по этим решениям на платформе nanoCAD. Материалы будут публиковаться по частям и помогут всем, кто предпочитает осваивать софт самостоятельно, познакомиться с интерфейсами программ и пройти основные этапы проектирования в них.

Начинаем с nanoCAD СПДС Металлоконструкции. В этой публикации вы узнаете о том, как создавать новый проект, новую сборку, массив осей, научитесь создавать колонны и балки и размещать их на плане.

Представляем третью статью нашего цикла о работе с 3D-моделями в Unity. Предшествующие статьи: «Особенности работы с Mesh в Unity» и «Unity: процедурное редактирование Mesh».

В мире компьютерной графики существует множество форматов представления 3D-моделей. Некоторые из них позиционируются как универсальные, другие — как оптимизированные под конкретные задачи или платформы. В любой сфере мечтают работать с универсальным форматом, но реальность говорит нам «нет». Более того, из-за такого зоопарка получается порочный круг: разработчики «универсальных» инструментов придумывают свои внутренние форматы для обобщения предыдущих, увеличивая популяцию и плодя средства преобразования форматов. Так появляется проблема потери или искажения данных при конвертации. Проблема стара как мир (мир IT, конечно), и она не обошла стороной импорт моделей в Unity.

В этой статье мы расскажем о некоторых трудностях, с которыми приходится сталкиваться при работе с моделями в Unity (особенности функционирования ModelImporter, разница представлений 3D-объектов и др.), а также о том, какие инструменты мы создали, чтобы эти трудности преодолеть.

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


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

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

Метод, к которому я в результате пришёл, немного отличается от всего того, что я видел у других, и не использует вообще никаких классов UI (в том числе и Canvas), поэтому я решил задокументировать его для общества. А для тех, кто хочет изучить исходный код, я выложил его на Github.

Предисловие

После выхода последней игры из серии «Метро» я потратил несколько часов на изучение её внутренней работы и решил поделиться тем, что может показаться интересным с технологической точки зрения. Я не буду проводить подробный анализ или изучать дизассемблированный код шейдеров, а покажу высокоуровневые решения, принятые разработчиками в процессе создания игры.

На данный момент разработчики ещё не рассказывали об использованных в игре техниках рендеринга. Единственным официальным источником информации является доклад с GDC, который нельзя больше найти нигде в Интернете. И это досадно, ведь игра работает на очень интересном собственном движке, эволюционировавшем из предыдущих игр серии «Метро». Это одна из первых игр, в которых используется DXR.

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

Первые шаги

На поиск среды, способной работать с этой игрой, у меня ушло несколько дней. Протестировав несколько версий RenderDoc и PIX, я остановился на изучении результатов трассировки лучей с помощью Nvidia NSight. Я хотел изучать рендеринг без функций raytracing, но NSight позволял исследовать подробности и этой функции, поэтому я решил оставить её включённой. Для всего остального рендеринга вполне подошёл PIX. Скриншоты сделаны с помощью обоих приложений.

Вступление

Задача для оружия была сформулирована одновременно с задачей о персонажах. Оружие изготовлено для sci-fi сетевого шутера под VR платформы. Стиль оружия был выбран под впечатлением дизайна 90-х годов, c небольшим уклоном в Retro design. Проект является VR экспериментом и находится в разработке.

Assembler – мой любимый язык, … но жизнь так коротка.

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

Зная себя, я уверен, что игра едва получит своё воплощение, но возможно кого-то из общественности заинтересуют мои наработки на этом тернистом пути. И так приступим.

Персонаж — это личность. Без истории нет индивидуальности. Каждый хороший персонаж начинается с истории, а дизайн персонажа должен рассказать эту историю.

В своей предыдущей статье How To Make Low Poly Look Good я говорил, что главная цель низкополигонального (low poly) дизайна — донести сообщение через наименьшее количество форм.

Это особенно справедливо, когда вы создаёте низкополигонального персонажа. Нужно рассказать историю, использовав как можно меньше форм.

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

---

Я буду работать в Blender. В Maya, Max и других 3D-редакторах есть похожие инструменты, так что не беспокойтесь об этом.

Это вторая статья из серии «3D-карты конца 90-х, на которых работал Quake». В первой части мы рассмотрели Rendition Vérité 1000 конца 1996 года и специальный порт игры для неё под названием vQuake. Rendition удалось победить всех на рынке Quake. На короткий промежуток времени она оставалась единственной платой, способной запускать блокбастер id Software с аппаратным ускорением.

Но всё изменилось в январе 1997 года, когда id Software выпустила новую версию Quake под названием GLQuake. Так как порт был создан с помощью miniGL (подмножества стандарта OpenGL 1.1), любой производитель аппаратных ускорителей мог написать драйвера miniGL и принять участие в гонке 3D-карт. С этого момента возможность конкуренции была открыта каждому. Цель заключалась в генерации как можно большего количества кадров в секунду. Наградой была слава и деньги покупателей. Вкратце изучив историю, можно понять, что два авторитета того времени без сомнений считали царями горы двух производителей.

Пока что в этом нет никаких сомнений: миром Quake правит Voodoo. А так как Quake правит миром игр, то покупка 3Dfx Voodoo почти неизбежна для геймеров.

— Tom's Hardware, 30 ноября 1997 года

3DFX Voodoo 1
— Эталон, по которому меряются все остальные карты.

— Файл .plan Джона Кармака. 12 февраля 1998 года^[2]

Только взглянув на спецификации^[3], в которых заявлялось о скорости заполнения в 50 мегапикселей/с, я сразу же захотел изучить эту карту и понять, что же сделала 3dfx, чтобы создать настолько мощный продукт.

Уже 20 лет прошло с момента выпуска первой 3D-версии КОМПАС — V5.11. За это время мы поняли, что потребности наших пользователей растут пропорционально возможностям КОМПАС-3D, так же как и функциональность КОМПАС расширяется пропорционально запросам пользователей. Только вот одна загвоздка: наращивая долгие годы технологическую часть, мы упирались в проблему производительности при работе со сложными большими проектами. Теперь и этот рубеж преодолен, и мы готовы рассказать, как нам удалось ускорить КОМПАС-3D на более чем 30 базовых операциях.