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

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

В настоящее время в моей игре Dragons Abound есть пара простых способов отрисовки границ. Она может отрисовывать одинарную или двойную линию по периметру карты и добавлять простые элементы в углах, как на этих рисунках:



Также игра может добавлять поле в нижней части границы для названия карты. В Dragons Abound есть несколько вариаций этого поля, в том числе такие сложные элементы, как фальшивые головки винтов:


В этих полях названий присутствует вариативность, но все они созданы вручную.

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

Прошлой осенью компания АО «Нанософт» представила новейшую версию вертикального приложения nanoCAD СПДС Металлоконструкции 1.2, созданную для разработки двухмерных чертежей металлических конструкций марки «КМ». Подробно познакомиться с функционалом можно в описании продукта nanoCAD СПДС Металлоконструкции либо в статье «nanoCAD СПДС Металлоконструкции. Полноценная работа по созданию 2D чертежей марки КМ». Предмет настоящей статьи – новый функционал nanoCAD СПДС Металлоконструкции версии 1.2. При разработке новой версии особое внимание уделялось рекомендациям и пожеланиям пользователей – по их просьбам были сделаны изменения в работе инструментов программы. В динамике рабочего процесса также сделаны значительные усовершенствования – это новая графическая платформа nanoCAD Plus 10 с новым видеодрайвером и новый ленточный интерфейс. Как результат в новой версии пользователи попробуют современные и удобные инструменты программы, ощутят заметный прирост скорости обработки чертежей, насыщенных параметрическими объектами, текстами, блоками и другими сложными примитивами.

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

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

Но как реализовать идею и превратить ее в готовый проект? С этим нам поможет справиться специализированное программное обеспечение СПДС Металлоконструкции. Это вертикальное приложение, которое устанавливается на такие платформы как AutoCAD и nanoCAD (СПДС Металлоконструкции и nanoCAD СПДС Металлоконструкции). СПДС Металлоконструкции — это универсальная программа, которая создана для разработки двухмерных чертежей металлических конструкций марок КМ и АС.

Во время разработки meshoptimizer частенько возникает вопрос: «А может этому алгоритму использовать SIMD?»

Библиотека ориентирована на производительность, но SIMD не всегда обеспечивает значительные преимущества по скорости. К сожалению, SIMD может сделать код менее переносимым и менее ремонтопригодным. Поэтому в каждом конкретном случае приходится искать компромисс. Когда первостепенное значение имеет производительность, приходится разрабатывать и поддерживать отдельные реализации SIMD для наборов инструкций SSE и NEON. В других случаях нужно понять, каков эффект от применения SIMD. Сегодня мы попытаемся ускорить меш-рационализатор (sloppy mesh simplifier) — новый алгоритм, недавно добавленный в библиотеку — используя наборы инструкций SSEn/AVXn.

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


Рисунок 1. Новый прямой метод построения открытой (бесконечной) квазислучайной последовательности с низким расхождением в треугольнике произвольной формы и размера. На рисунке показаны распределения точек в пятнадцати случайных треугольниках для первых 150 точек.

Краткий обзор

Последовательности с низким расхождением (low discrepancy), равномерно сэмплирующие/заполняющие квадрат, активно изучались почти сотню лет. БОльшую часть этих квазислучайных последовательностей можно расширить до прямоугольников простым растягиванием, не сильно повредив при этом расхождению.

Однако в этом посте мы рассмотрим интересное и важное расширение последовательностей с низким расхождением на произвольный треугольник.

Наверно худшее, что случилось в области процедурной генерации контента (если считать, что это действительно область процедурной генерации контента, в чём я уверен не полностью) — это шум Перлина. Шум Перлина невероятно хорошо подходит (по крайней мере, если не приглядываться слишком внимательно) для генерации интересных ландшафтов. В сабреддите /r/proceduralgeneration недели не проходит без того, чтобы кто-нибудь не опубликовал «систему процедурной генерации», которая оказывается визуализированным разными цветами шумом Перлина. (За время написания этой статьи появилось два таких поста!)


Я не хочу унизить шум Перлина. Это невероятно полезный для процедурной генерации инструмент, ставший точкой входа в эту область для множества людей, в том числе и меня. Но в то же время он очень сбивает с толку, потому что подразумевает, что процедурная генерация намного проще, чем это есть на самом деле. Большинство еженедельных постов о «системах процедурной генерации» в /r/proceduralgeneration исчезают без следа, когда их авторы обнаруживают, что следующий шаг в процедурной генерации гораздо сложнее. Истина в том, что шум Перлина стал своего рода счастливой случайностью. Он отлично подходит для генерации интересных ландшафтов, но на то нет систематических или повторяемых причин.

Теперь, когда мы знаем основы комбинирования функций расстояний со знаком, можно использовать их для создания крутых вещей. В этом туториале мы применим их для рендеринга мягких двухмерных теней. Если вы пока не читали моих предыдущих туториалов о полях расстояний со знаком (signed distance fields, SDF), то крайне рекомендую их изучить, начав с туториала о создании простых фигур.


[В GIF возникли дополнительные артефакты при пересжатии.]

Autodesk Revit (далее – Revit) является одной из программ, осуществляющей автоматизированное проектирование в технологии информационного моделирования зданий (BIM). Вместе с тем, основным результатом проектирования являются плоские чертежи, для оформления которых используются СПДС GraphiCS 2019 и nanoCAD СПДС 10 (далее – СПДС). Совместная работа СПДС и Revit является предметом обсуждения данной статьи.

При работе с полигональными ассетами можно отрисовывать только по одному объекту за раз (если не учитывать такие приёмы, как batching и instancing), но если использовать поля расстояний со знаком (signed distance fields, SDF), то мы не этим не ограничены. Если две позиции имеют одинаковую координату, то функции расстояний со знаком возвратят одинаковое значение, и за одно вычисление мы можем получить несколько фигур. Чтобы понять, как преобразовывать пространство, используемое для генерации полей расстояний со знаком, я рекомендую разобраться, как создавать фигуры с помощью функций расстояний со знаком и комбинировать sdf-фигуры.

Как написано в недавних постах блога, я боролся за то, чтобы получить в своей игре Dragons Abound нужную детализацию береговых линий. Моё разочарование возникло во время реализации барьерных островов. Чтобы создать как можно более узкий остров, я делал их шириной в одну локацию — на рисунке ниже каждая локация является треугольником Делоне:


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

В декабрьских новостях об урагане Флоренс часто упоминались Внешние отмели — ряд барьерных островов на побережье Северной Каролины:


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

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

Чтобы понять, почему это так, давайте взглянем на «ванильную» карту острова:

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

Подготовка

Для визуализации полей расстояний со знаком (signed distance fields, SDF) мы будем использовать одну простую конфигурацию, а затем применим к ней операторы. Для отображения полей расстояний в ней будет использоваться визуализация линий расстояний из первого туториала. Ради упрощения мы будем задавать все параметры за исключением параметров визуализации в коде, но вы можете заменить любое значение свойством, чтобы сделать его настраиваемым.

Хотя меши являются простейшим и наиболее универсальным способом рендеринга, существуют и другие варианты представления фигур в 2d и 3d. Одним из часто используемых способов являются поля расстояний со знаком (signed distance fields, SDF). Поля расстояний со знаком обеспечивают менее затратную трассировку лучей, позволяют разным фигурам плавно перетекать друг в друга и экономить на текстурах низкого разрешения для высококачественных изображений.

Мы начнём с генерации полей расстояний со знаком с помощью функций в двух измерениях, но позже продолжим генерировать их в 3D. Я буду использовать координаты мирового пространства, чтобы у нас была как можно меньшая зависимости от масштабирования и UV-координат, поэтому если вы не понимаете, как это работает, то изучите этот туториал по плоскому наложению, в котором объяснено, что происходит.

Здравствуйте.

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

Вводная

Начну несколько издалека. Приставлен я к небольшой технологической установке, твердотельному волоконному лазеру Unilaser, произведённому в КНР. Управляется станок специализированным ПО, EzCad2 [Unilaser]. Программа обеспечивает ряд возможностей для отрисовки картинок для нанесения, управление режимами реза. Однако, точно позиционировать текст в ней весьма затруднительно, поэтому используется дополнительный векторный редактор. В качестве такового до последнего времени выступал Corel Draw X8.

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

1. Мы должны иметь возможность рендерить любой шрифт любого размера в реальном времени, чтобы адаптироваться к системным шрифтам и их размерам, выбранным пользователями Windows.
2. Рендеринг шрифтов должен быть очень быстрым, никаких торможений при рендеринге шрифтов не допускается.
3. В нашем UI куча плавных анимаций, поэтому текст должен иметь возможность плавно перемещаться по экрану.
4. Он должен быть читаемым при малых размерах шрифтов.

Не будучи в то время большим специалистом в этом вопросе, я поискал информацию в Интернете и нашёл множество техник, используемых для рендеринга шрифтов. Также я пообщался с техническим директором Guerrilla Games Михилем ван дер Леу. Эта компания экспериментировала со множеством способов рендеринга шрифтов и их движок рендеринга был одним из лучших в мире. Михиль вкратце изложил мне свою идею новой техники рендеринга шрифтов. Хотя нам вполне было бы достаточно уже имевшихся техник, меня эта идея заинтриговала и я приступил к её реализации, не обращая внимания на открывшийся мне чудесный мир рендеринга шрифтов.

Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json

О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.

Слева направо: оригинал, оснащённое поле (frame field) и окончательный результат. На базе зашумлённого растрового изображение в оттенках серого вычисляется оснащённое поле, выровненное по линиям картинки. На острые углы типа X- и T-пересечений накладываются векторы по обоим направлениям. Затем из этого поля извлекается топология чертежа — и производится окончательная генерация векторных кривых

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

Первые алгоритмы векторизации изображений появились в начале 1990-х годов и
использовались в инструментах для редактирования векторной графики, таких как Adobe Illustrator (Live Trace), CorelDRAW (PowerTRACE) и Inkscape. Несмотря на их широкое внедрение в промышленности, эти алгоритмы до сих пор страдают от серьёзных недостатков и находятся в активной разработке. В нескольких индустриях, где векторизация крайне необходима, включая традиционную анимацию и инженерное проектирование, она часто выполняется вручную. Дизайнеры кропотливо обводят отсканированное изображение с помощью инструментов рисования.

Изначально я не планировал делать демо на Chaos Constrictions 2018, однако за 2-3 недели до cc понял, что с пустыми руками идти на демопати никак нельзя, и решил написать небольшую демонстрацию для 386/EGA/DOS.

Скомпилировав в Turbo-C под DOS свою либу AnotherGraphicsLibrary, которая идеально ложиться в битплановую структуру EGA режима, я разочаровался, от тормозов, прежде всего тормозов EGA. Демо в том виде, в котором я хотел бы его видеть, за этот весьма ограниченный срок, сделать было невозможно.

Однако сдаваться и не делать что-либо, я уже не мог. И тут я вспомнил, что давно хотел принять участие в ZX-Spectrum конкурсах демо. А так, как за последний год у меня появилось целых два 48k реала, я мог получить определенное удовольствие от создания демо. К слову — для меня самое главное в написании демо это именно тестирование на реале, эмульгаторы не дают такого наслаждения от процесса, уж очень это замечательное чувство, когда после очередного изменения в коде ты закачиваешь демо на реал, и видишь как настоящая железка тасует байтики в памяти, отрисовывая эффект.

Поскольку из реалов у меня только 48k, то и демо я решил сделать для 48k. А из-за ограниченности сроков и отсутствия каких-либо наработок, выбор пал на создание 1k intro(демо объёмом всего 1 килобайт, или 1024 байта).

Несколько дней назад Хабру исполнилось 12 лет. В честь этого нам в FunCorp захотелось сделать что-то особенное. Мы немного подумали и решили подарить Хабру — Habr.