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

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

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

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

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

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

Посмотрите на сцену из игры 2010 года Mass Effect 2 с раздевающимся Джейкобом. На первый взгляд кажется, что он стянул рубашку, как это сделал бы любой человек, демонстрируя невидимому оператору заработанные в боях кубики пресса. А теперь приглядитесь внимательно: к моменту, когда его руки движутся по телу, «снимая» рубашку, её уже нет. Игра переключилась с одетой на раздетую модель с помощью иллюзии, заставляющей игрока подумать, что он снимает рубашку.

Мы пообщались с потрясающими разработчиками Atomontage, пытаясь разобраться, смогут ли воксели вернуться и победить пиксели.

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

Естественные паттерны

Системы Линденмайера придумал венгерский биолог Аристид Линденмайер, изучая рост водорослей. Он разработал L-системы как способ описания процесса роста водорослей и простых растений. Результатом стал своего рода язык, на котором можно было выразить свойства рекурсивности и самоподобия роста организма. И в самом деле, L-системы можно использовать для генерирования естественных паттернов; кроме того, хорошо известные математические паттерны тоже можно записать в виде L-системы. В этой статье я расскажу о различных типах L-систем и продемонстрирую их с помощью отрисовки «черепашьей графикой» двухмерных и трёхмерных систем Линденмейера.

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

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

Но всегда можно посмотреть под другим углом.

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

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

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

Тогда как это удаётся играм?

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

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

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

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

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

Как заставить песок делать то, чего мы от него хотим?

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

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

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

Процесс создания in-game модели персонажа от эскиза до релиза.



Доброго времени суток. Меня зовут Ivan. Сегодня я поделюсь с вами деталями разработки игр, а именно расскажу о полном цикле создания персонажа. Итак, поехали!

Привет, Хабр! Предлагаю вашему вниманию перевод статьи WorldMachine + UE4: Full Workflow.

Руслан Назиров показал, как можно создавать красивые ландшафты в World Machine и импортировать их в Unreal Engine 4. Руслан начал работать с Unreal Engine всего год назад, но уже сейчас демонстрирует удивительные результаты.

Процесс создания ландшафта для UE4

1. Создание нужного ландшафта в World Machine. Я использую библиотеку макросов GeoGlyph для ускорения процесса создания ландшафта.

Введение

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

По этой теме тоже довольно много разного рода публикаций в сети. Однако, многие из них опираются на использование платных приложений или расширений для Unity. Существуют описания и «дешевых» методов, но основная масса их ориентирована на получение так называемых heightmap — черно-белых квадратных изображений местности, где градациями серого определяется относительных уровень высот в данной точке. Существует ряд способов генерации подобных карт высот с использованием например инструментария GDAL. И такой подход не лишен недостатков, связанных с достаточной громоздкостью процедуры создания карты высот и последующей привязкой к полученной местности. Поэтому, в данной статье будет изложен некий альтернативный подход и интересующиеся приглашаются под кат.

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

Введение

В 2017 году большинство популярных веб-игр типа agar.io использует для передачи данных WebSockets через TCP. Если бы в браузерах был встроенный UDP-аналог WebSockets, то это бы сильно улучшило работу с сетями в этих играх.

Вводная информация

Работа веб-браузеров основана на протоколе HTTP (протоколе запросов и ответов без сохранения состояния). Первоначально он был предназначен для обслуживания статичных веб-страниц. HTTP работает поверх TCP, низкоуровневого протокола, гарантирующего надёжную доставку и правильный порядок передаваемых по Интернету данных.

Всё это отлично работало многие годы, но недавно веб-сайты стали более интерактивными и перестали отвечать парадигме «запрос-ответ» протокола HTTP. Для решения этой проблемы изобретены современные веб-протоколы, такие как WebSockets, WebRTC, HTTP 2.0 и QUIC, имеющие потенциал значительного улучшения интерактивности сети.

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

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

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов

Вот уже несколько месяцев специально для JavaRush мы переводим и озвучиваем самый популярный в мире университетский курс о CS50 — «Основы компьютерных наук и искусства программирования» (трейлер). Его уже много лет очно читают для студентов Гарварда и для воспитанников Йельского университета, а в последнее время ещё и заочно для многомиллионной аудитории интернета.
Это перевод самой новой версии курса, который стартовал осенью 2015 года. В курсе 24 лекции и постепенно мы переведём их все. Намедни мы перевели 15-ю лекцию, её вы найдёте под катом в списке всех переведённых на сегодняшний день лекций.

Что вы узнаете, прослушав этот курс:

• Основы компьютерных наук и программирования;
• Концепции алгоритмов и алгоритмичности мышления. Какие задачи можно решать с помощью программирования и каким образом;
• Концепции абстракции, структуры данных, инкапсуляции, управления памятью. Основы компьютерной безопасности. Процесс разработки ПО и веб-разработка;
• Основы языка программирования C и Scratch;
• Основы баз данных и SQL;
• Веб-разработка: основы CSS, HTML, JavaScript и PHP;
• Основы подготовки презентации проектов по программированию.

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

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

Некоторые из вас наверно знакомы с канвой бизнес-модели — инструментом из инструментария L.E.A.N. для стартапов. Инструмент представляет собой лист бумаги с полями для заполнения. В поля с аккуратными пометками заносятся различные аспекты планируемой компании. Смысл канвы в том, что она широко охватывает все основные аспекты. Она также позволяет заранее принимать решения в процессе планирования с учётом их ограничений. Туда заносятся потоки поступления дохода, например, канва вынуждает вас выбрать между скачиваемым продуктом, коробочным продуктом и покупками внутри приложения (In-App Purchases, IAP). Даже если вы впишете туда десять источников дохода, то просто видя несоответствие потоков поступления дохода (например, с вашей командой или маркетинговыми каналами), вы быстро осознаете, что не сможете запустить настолько сложный бизнес. Цель канвы бизнес-модели — помочь вам определиться с приоритетами и масштабом. Кроме того, она позволяет начать думать о каждой составной части компании.

В статье в общих чертах дан анализ двух типов информации – простой и субъективной, рассмотрено различие понятий интеллекта и воспринимающего сознания. Описаны некоторые логические функциональные особенности сознания. Предложен подход технического получения субъективной информации за счет изменения временной степени свободы сигнала на пространственную. С целью получения функции «наблюдателя» в системе, и проявляемых относительно него информационных сигналов, выполняющих роль субъективных ощущений. Решение данной проблемы может дать новый подход к конструированию сильного искусственного интеллекта и пролить свет на трудную проблему сознания.

Тема написания своего ЯПа не дает мне покоя уже около полугода. Я не ставил перед собой цель "убить" CoffeeScript, TypeScript, ELM, тысячи их, я просто хотел понять кухню и как они вообще пишутся.

К моему неприятному удивлению, большинство из этих языков используют Jison (Bison для JavaScript), а это не совсем попадало под мою задачу — "понять", так как по сути дела Jison делает все за вас, собирает AST по заданным вами правилам (Jison как таковой отличный инструмент, который делает за вас львиную долю работы, но сейчас не о нем).

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

Стоит заметить, что данное руководство не привязано к JavaScript, он выбран исключительно из соображений скорости разработки и читаемости, так что вы можете написать свой "лисп"/"питон"/"ваш абсолютно новый синтаксис" на любом знакомом вам языке.

Также до момента написании компилятора (в нашем случае транслятора), процесс написания языка не отличается от процессов создания языков компилируемых в ASM/JVM bitcode/LLVM bitcode/etc, а это значит, что данное руководство не ограничивается созданием языка трансляцируемого в JavaScript.

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