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

У моего ShaderToy были три основные задачи:

1. Выполнение в реальном времени
2. Простота
3. Физическая корректность (… или типа того)

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

1. Трассировка лучей непрозрачных объектов. Все объекты являются примитивами с простыми пересечениями с лучами (1 плоскость и 3 сферы)
2. Для вычисления освещения используется затенение по Фонгу, а в трёх сферических источниках света применется настраиваемый коэффициент затухания света. Лучи теней не требуются, потому что мы освещаем только плоскость.

Вот как это выглядит:

Наверняка многие из вас хотя бы однажды пользовались хабраконвертером, который официально рекомендован администрацией Хабра — https://shirixae.github.io/habraconverter-v2/. Несколько лет назад его создал хабравчанин meta4, а потом доработал Shirixae. Принцип простой: открываете гуглодок с постом, Ctrl-A, Ctrl-C и вставляете в окно конвертера. Нажимаете кнопку «Конвертировать» и получаете готовый код вёрстки, который можно вставлять в редактор Хабра и публиковать. Только перед этим нужно пройтись и поправить кое-какие мелочи.

И всё бы хорошо, если верстать приходится не слишком часто. Или посты небольшие, несложные. Но если вы верстаете помногу, и в постах есть и картинки, и таблицы, и куски кода, то из раза в раз приходится делать рутину: вставлять нужные пустые строки и убирать лишние, заменять теги <sоurce> на <cоde>, и т.д. и т.п. Мы решили потратить день, чтобы потом долетать за час, и допилили конвертер.

Новая версия лежит тут, а под катом — перечисление доработок.

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

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

Доброго времени суток, Хабр. Мы продолжаем цикл «Галоп Пикселя». Сейчас, находясь на старте 2019 года, можно с уверенностью говорить, что это не только цикл статей, но и многолетняя сага. Пространное повествование о пикселях, их жизни, способе их создания, приёмах и уловках в работе с ними. Мы не будем рассуждать о причинах первоначального «спринта», который затем превратился в многолетний марафон, ибо нет ничего более жизненного, чем сама жизнь. Кому нужны причины отсутствия или пауз, если можно просто вернуться к тому, что мы делали, в чём варились, и в чём, даст бог — будем наблюдаться и далее. В пикселях, конечно же!

Сегодняшняя публикация станет очередной, и возможно даже поворотной вехой в нашем повествовании. Наконец-то мы подошли к созданию полноценной анимации персонажей. Двумя предыдущими главами мы охватили анимацию света и тени, а также анимацию неподвижных персонажей (idle-animation) без ярко выраженных действий. Но сегодня наши персонажи пойдут, а в следующей части даже побегут, завоевав то, что уже давно их по праву рождения. Ещё один плодородный регион. И пройдут ещё одну точку, которая ознаменует окончание базового цикла. Наши пиксели наконец-то станут живыми.

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

Первая часть статьи здесь.

Часть 6. Избегание коллизий

Для правильной навигации NPC часто требуется способность избегать препятствий. В этой части мы рассмотрим steering behavior collision avoidance (избегание коллизий), позволяющее персонажам благополучно уворачиваться от препятствий в окружении.

---

Введение

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

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


Анализируются препятствия перед персонажем и выбирается ближайшее (наиболее угрожающее).

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

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

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

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

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

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

За дело!

Доброго времени суток.
А знаете ли вы, что не все хеш таблицы одинаково полезны? Сейчас я расскажу вам историю, как одна плохая хеш таблица скушала всю производительность, и не поморщилась. И как исправление этой хеш таблицы ускорило код почти в 10 раз.
Конечно, согласно теме — в статье речь пойдет о Delphi, но даже если вы не Delphi разработчик, то все равно советую заглянуть под кат, а после прочтения статьи в исходный код хеш таблиц, которые вы используете. А Delphi разработчикам я советую вообще отказаться от стандартного TDictionary.

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

---

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

Ещё один любопытный эксперимент, в котором участвовало 45 тыс. человек. Заходишь на сайт, тебе показывают статью Дэвида Дойча, британского физика. В статье автор пишет, что сегодня очень трудно внезапно умереть. Например, от инфекционного заболевания или в уличной драке. Лет сто назад это случалось намного чаще. Главный вывод статьи — сейчас мир безопасен как никогда. В среднем, конечно, ведь где-то постоянно идут локальные военные конфликты.

Ольга Базалева, создатель Data Vis и автор блога, написала статью специально для Нетологии о самых важных принципах визуализации. Статья участвует в конкурсе блога.

Хотите выделяться на фоне конкурентов? Чтобы ваши статьи, отчеты, презентации или посты в социальных сетях были профессиональными, интересными и доступными широкой аудитории? Используйте визуализацию данных!

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



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

Недавно у меня появилась возможность выполнить отладку буфера обмена в Windows, и я решил, что хорошо бы поделиться информацией, которую удалось узнать. Буфер обмена — это тот компонент Windows, который многие из нас используют десятки (сотни?) раз в день, особо не размышляя об этом. Прежде чем взяться за это дело, я даже никогда не задумывался, как всё устроено. Как выяснилось, там столько интересного, что вы даже не можете себе представить. Сначала опишу, как приложения хранят разные типы данных в буфере обмена и как извлекают их оттуда, а затем — как приложения могут «прицепиться» к буферу и отслеживать изменения в нём. В обоих случае вы увидите отладочные записи, которые показывают, как получить доступ к данным из отладчика.

Начнём с обсуждения форматов буфера обмена. Такие форматы используются для описания, какие типы данные можно поместить в буфер. Там есть некоторое количество предопределённых стандартных форматов, которые может использовать приложение, вроде битового массива, текста ANSI, текста в Юникоде и TIFF. Windows также позволяет приложению установить собственный формат. Например, текстовый процессор может зарегистрировать формат, включающий в себя текст, форматирование и картинки. Конечно, это ведёт к определённой проблеме: что произойдёт, если вы скопируете данные из текстового редактора и вставите их в «Блокнот», который не понимает всего этого форматирования и не отображает картинки?

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

С задачей вызова неуправляемого кода из управляемого мы сталкиваемся довольно часто, и эта задача имеет простое решение в виде одного атрибута [DllImport] и небольшого набора дополнительных правил, которые хорошо изложены в MSDN. Обратная же задача встречается гораздо реже. В данной статье мы и рассмотрим небольшой пример, как это можно сделать. Его не стоит рассматривать как исчерпывающий, скорее лишь, как направление хода мыслей и концепцию. Итак, начнем.

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


Серия будет состоять из следующих частей:

• Часть 1. Введение в процедурную анимацию
• Часть 2. Математика прямой кинематики
• Часть 3. Реализация прямой кинематики
• Часть 4. Введение в градиентный спуск
• Часть 5. Инверсная кинематика для робота-манипулятора
• Часть 6. Инверсная кинематика щупалец
• Часть 7. Инверсная кинематика лап паука

Часть 4. Введение в градиентный спуск

Эта часть представляет собой теоретическое введение в инверсную кинематику и содержит программное решение, основанное на градиентном спуске (gradient descent). Эта статья не будет всеобъемлющим руководством по этой теме, это всего лишь общее введение. В следующей части мы покажем настоящую реализацию этого алгоритма на C# в Unity.

Серия состоит из следующих частей (части 1-3 представлены в предыдущем посте):

• Часть 1. Введение в процедурную анимацию
• Часть 2. Математика прямой кинематики
• Часть 3. Реализация прямой кинематики
• Часть 4. Введение в градиентный спуск
• Часть 5. Инверсная кинематика для робота-манипулятора
• Часть 6. Инверсная кинематика щупалец
• Часть 7. Инверсная кинематика лап паука

Основные задачи художников визуальных эффектов

Если говорить только о визуальных эффектах, то их можно разделить на два основных типа задач: геймплейные эффекты и природные эффекты (или эффекты окружений). Принцип их разделения зависит от конкретного проекта. Например в такой игре, как Castlevania (жанра hack'n'slash), 90% визуальных эффектов состояло в умениях персонажа и магии, сильно влиявших на геймплей. Такие задачи требуют серьёзного понимания механик игры и постоянного общения с командой дизайнеров, с которой нужно постоянно договариваться. Для примера давайте возьмём огнемёт. Дизайнеры геймплея подбирают область урона атаки, а затем вам необходимо создать эффект поверх отладочного цилиндра. Постепенно уменьшающийся огонь не полностью соответствует области урона, и дизайнеры начинают на это жаловаться. Вот один из примеров «конфликтов» между двумя дисциплинами, потому что если придерживаться строгих правил, огонь не будет похож на огонь. Поэтому приходится искать альтернативы и убеждать дизайнеров, что игрок не заметит, что небольшой исчезающий огонь не нанёс никакого урона.

Среди прочих жанров, геймплейные эффекты более «важны» в файтингах и RPG.

Существуют и другие игровые жанры, например, шутеры (в особенности это касается реалистичных), в которых природные эффекты так же важны, как и геймплейные. В этом случае художник, ответственный за природные эффекты, становится практически художником по окружениям и в основном сотрудничает с этой командой. Примерами природных эффектов являются водопады, туман, дождь и т.д. Больше всего природных эффектов я создал в Gears of War 4, где мы работали над многопользовательскими картами и должны были заботиться о влиянии эффектов на производительность, потому что от игры требовалось работать в 1080p при 60 fps.

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

А давайте отвлечёмся немного и напишем игру в google play? И не такую огромную и неподъёмную фигню, про которую я обычно пишу статьи, а что-нибудь простое и милое сердцу?

На самом деле, всё очень просто: я наконец-то зарегистрировал аккаунт разработчика и очень хочу его опробовать. На момент написания этих строк у меня нет ни одного написанного класса и ни одного нарисованного пикселя. По сути, эта статья — самый настоящий devlog.

Здравствуйте, уважаемые читатели! Продолжаю серию дилетантских статей о математике.

• Первая часть
• Вторая часть

Сегодня предлагаю поразмышлять над некоторой интересной математической задачкой.
А именно, давайте-ка для разминки решим следующее линейной уравнение:

$$

«Чего сложного?» — спросите вы. Действительно, лишь одно уравнение и целых четыре неизвестных. Следовательно, три переменных есть свободные, а последняя зависит от оных. Так давайте выразим скорее! Например, через переменную $$, тогда множество решений следующее:

$$

где $$ — множество любых действительных чисел.

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

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

$$

где $$ — множество целых чисел.

Теперь решение, полученное в начале статьи, «не проканает», так как мы рискуем получить $$ как рациональное (дробное) число. Так как же решить это уравнение исключительно в целых числах?

Заинтересовавшихся решением данной задачи прошу под кат.

Это продолжение публикации. Первую часть можно посмотреть тут

Содержание:

Циклы
When
Делегаты
Object и companion object
lateinit свойства
coroutines
Выводы