Я большой поклонник всего, что делает Фабьен Санглард, мне нравится его блог, и я прочитал обе его книги от корки до корки (о них рассказывали в недавнем подкасте Hansleminutes).

Недавно Фабьен написал отличный пост, где расшифровал крошечный рейтрейсер, деобфусцировав код и фантастически красиво объяснив математику. Я действительно рекомендую найти время, чтобы прочитать это!

Но это заставило меня задуматься, можно ли перенести этот код C++ на C#? Поскольку на основной работе мне в последнее время приходится довольно много писать на C++, я подумал, что могу попробовать.

Но что более важно, я хотел получить лучшее представление о том, является ли C# языком низкого уровня?

Введение

fBM расшифровывается как Fractional Brownian Motion (дробное броуновское движение). Но прежде чем начать говорить о природе, фракталах и процедурных рельефах, давайте на минуту углубимся в теорию.

Броуновское движение (Brownian Motion, BM), просто, без «дробности» — это движение, при котором положение объекта с течением времени меняется со случайными инкрементами (представьте последовательность position+=white_noise();). С формальной точки зрения BM является интегралом белого шума. Эти движения задают пути, которые являются случайными, но (статистически) самоподобными, т.е. приближенное изображение пути напоминает весь путь. Fractional Brownian Motion — это схожий процесс, в котором инкременты не полностью независимы друг от друга, а в этом процессе существует некая память. Если память имеет положительную корреляцию, то изменения в заданном направлении будут иметь тенденцию к будущим изменениям в том же направлении, и путь при этом будет плавнее, чем при обычном BM. Если память имеет отрицательную корреляцию, то за изменением в положительную сторону с большой вероятностью последует изменение в отрицательную, и путь окажется гораздо более случайным. Параметр, управляющий поведением памяти или интегрированием, а значит и самоподобием, её размерностью фрактала и спектром мощности, называется показателем Хёрста и обычно сокращается до H. С математической точки зрения H позволяет нам интегрировать белый шум только частично (допустим, выполнить только 1/3 интегрирования, отсюда и «дробность» в названии) для создания fBM под любые нужные нам характеристики памяти и внешний вид. H принимает значения в интервале от 0 до 1, которые описывают, соответственно, грубое и плавное fBM, а обычное BM получается при H=1/2.


Здесь функция fBM() использована для генерации рельефа, облаков, распределения деревьев, вариаций их цветов и деталей крон. «Rainforest», 2016: https://www.shadertoy.com/view/4ttSWf

В процессе поисков наилучшей реализации термального шейдера я наткнулся на matcap-шейдер, опубликованный пользователем bgolus в форумах Unity — неплохая отправная точка.

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


Будем двигаться по порядку, сначала вершинная функция:

В этой статье ведущий UI/UX художник Никита Кандыбин и технический UI художник Ольга Кинчак поделятся эффективными базовыми практиками по оптимизации Unity UI, которые используются в компании Banzai Games при создании игровых интерфейсов, а также укажут на подводные камни тех или иных решений в дизайне и верстке. Практически во всех перечисленных ниже пунктах можно обойтись без кода, настраивая компоненты непосредственно в редакторе, а что-то даже предусматривая заранее на стадии проектирования макетов интерфейса.

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

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

Наблюдение за изменением состояния в базе данных, мониторинг размера очередей, телеметрия с удаленных серверов, запуск деплой скриптов и получение нотификации по завершению — конфигурируется за минуту простым YAML файлом.

Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

Заглянуть «под капот» кода или посмотреть на внутреннее устройство CLR можно с помощью множества инструментов. Этот пост родился из твита, и я должен поблагодарить всех, кто помог составить список подходящих инструментов. Если я пропустил какие-то из них, напишите в комментариях.

Во-первых, я должен упомянуть, что хороший отладчик уже присутствует в Visual Studio и VSCode. Также существует множество хороших (коммерческих) профилировщиков .NET и инструментов мониторинга приложений, на которые стоит взглянуть. Например, недавно я попробовал поработать с Codetrack и был впечатлён его возможностями.

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

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

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

Статья описывает поэтапный процесс написания шейдера травы в Unity. Шейдер получает входящий меш, и из каждой вершины меша генерирует при помощи геометрического шейдера травинку. Ради интереса и реализма травинки будут иметь рандомизированные размеры и поворот, а ещё на них будет влиять ветер. Чтобы управлять плотностью травы, мы используем тесселяцию для разделения входящего меша. Трава сможет и отбрасывать, и получать тени.

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

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

FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и  масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее.

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


Рисунок 1. Сравнение различных квазислучайных последовательностей с низким расхождением. Заметьте, что предлагаемая мной $$-последовательность создаёт более равномерно распределённые точки, чем все остальные методы. Более того, все остальные методы требуют тщательного подбора базовых параметров, а в случае неправильного подбора приводят к вырожденности (например справа вверху)

Рассматриваемые в статье темы

• Последовательности с низким расхождением в одном измерении
• Методы с низким расхождением в двух измерениях
• Расстояние упаковки
• Множества с многоклассовым низким расхождением
• Квазислучайные последовательности на поверхности сферы
• Квазипериодический тайлинг плоскости
• Маски дизеринга в компьютерной графике

Какое-то время назад этот пост был выложен на главной странице Hacker News. Можете прочитать там его обсуждение.

Это — подборка статей из нашего блога «Мир Hi-Fi». Здесь есть материалы, которые помогут вам собрать достойный домашний кинотеатр и подготовить для него помещение. Под катом — немного о телевизорах, советы по акустической коррекции и правила расстановки колонок.

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

Часть 6. Sharpen

В этой части мы подробнее рассмотрим ещё один эффект постобработки из The Witcher 3 — Sharpen.

Sharpening делает изображение на выходе немного чётче. Этот эффект известен нам по Photoshop и другим графическим редакторам.

В The Witcher 3 у sharpening есть две опции: low и high. О разнице между ними я расскажу ниже, а пока давайте взглянем на скриншоты:


Опция «Low» — до


Опция «Low» — после

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

• сравнивая с одним псевдослучайным числом (которое тоже можно получать по разному [1]);
• сравнивая с наибольшим или наименьшим из двух псевдослучайных чисел;
• сравнивая среднее из двух и более случайных чисел (среднее тоже можно считать по разному).

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

Точно также по разному можно рассчитывать наносимый урон, особенно на основе дайсов (кубиков).

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

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

TL;DR

Я создал демо, показывающее, как реализовать прогнозирование на стороне клиента физического движения игрока в Unity — GitHub.

Введение

В начале 2012 года я написал пост о как-бы-реализации прогнозирования на стороне клиента физического движения игрока в Unity. Благодаря Physics.Simulate() тот неуклюжий обходной способ, который я описал, больше не нужен. Старый пост до сих пор является одним из самых популярных в моём блоге, но для современного Unity эта информация уже неверна. Поэтому я выпускаю версию 2018 года.

Что-что на стороне клиента?

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

От переводчика: ровно 175 лет и 3 дня назад были изобретены кватернионы. В честь этой круглой даты я решил подобрать материал, объясняющий эту концепцию понятным языком.

Концепция кватернионов была придумана ирландским математиком сэром Уильямом Роуэном Гамильтоном в понедельник 16 октября 1843 года в Дублине, Ирландия. Гамильтон со своей женой шёл в Ирландскую королевскую академию, и переходя через Королевский канал по мосту Брум Бридж, он сделал потрясающее открытие, которое сразу же нацарапал на камне моста.

$$

Памятная табличка на мосту Брум Бридж через Королевский канал в честь открытия фундаментальной формулы умножения кватернионов.

В этой статье я постараюсь объяснить концепцию кватернионов простым для понимания образом. Я объясню, как можно визуализировать кватернион, а также расскажу о разных операциях, которые можно выполнять с кватернионами. Кроме того, я сравню использование матриц, углов Эйлера и кватернионов, а затем попытаюсь объяснить, когда стоит использовать кватернионы вместо углов Эйлера или матриц, а когда этого делать не нужно.

Карта

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

Вам нужно автоматизировать огромное количество фотограмметрических сканов? Тогда у меня для вас хорошие новости.


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

Но меня интересует полная автоматизация. Если у вас есть сканирующая установка, на которой вы делаете по 100 и больше сканов в день, то необходимо полностью автоматизированное решение для пакетной обработки этих файлов. Данный пост является руководством и/или туториалом по решению этой задачи.

Недавно я начал разбираться с рендерингом «Ведьмака 3». В этой игре есть потрясающие приёмы рендеринга. Кроме того, она великолепна с точки зрения сюжета/музыки/геймплея.



В этой статье я расскажу о решениях, использованных для рендеринга The Witcher 3. Она не будет такой всеобъемлющей, как анализ графики GTA V Адриана Корреже, по крайней мере, пока.

Мы начнём с реверс-инжиниринга тональной коррекции.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Facial Surface and Texture Synthesis via GAN».

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