Pull to refresh
55.5
Karma
0
Rating
Денис Кильчичаков @augur

User

  • Followers 21
  • Following 7

Процедурная генерация планет

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

Процедурная генерация планет

Мне тоже очень понравилась статья, поэтому и решил вкатиться переводчиком.

Процедурная генерация планет

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

Процедурная генерация планет

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

Процедурная генерация планет

Надеюсь, оригинальный сайт не ляжет под Хабраэффектом...

Процедурная генерация планет

Благодарю! Как видите, и сама статья, и сайт достаточно древние — почти 5 лет для веба — не шутки. Возможно какие-то нюансы настройки.

Процедурная генерация планет

Сей генератор формально тоже велосипед, но выделяется некоторым изяществом.

Один бит сломал, другой потерял: задачка по передаче данных

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

Один бит сломал, другой потерял: задачка по передаче данных

Обновил до версии 0.1.4, добавил свой вариант решения. Не ахти что по оверхеду — в среднем 520% для больших данных. Однако целостность поддерживается надежно, BER примерно 3e-7.

Один бит сломал, другой потерял: задачка по передаче данных

Подскази для "правильных" решений, могут быть например, здесь: https://habrahabr.ru/post/332134/#comment_10295162 Я могу лишь показать "своё", и то, не раньше чем вернусь домой и допишу :)


Десять раз слать бит с повторением — это, извините, тупо. Плюс не решает проблемы с пропущенным битом (вы ждете получения 10).

Б-же упаси, этот пример здесь только как аналог сортировки пузырьком — показать, что задачу выполняет, но максимально неэффективным способом.
И проблем со считыванием нет — this.read возвращает весь накопленный буфер, если его длина меньше запрашиваемой. А на стороне передающей машины стоит ограничитель интенсивности отправки, чтобы кадры не слеплялись.


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

Один бит сломал, другой потерял: задачка по передаче данных

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

Один бит сломал, другой потерял: задачка по передаче данных

Теоретически возможно даже полное исчезновение сообщения

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

Один бит сломал, другой потерял: задачка по передаче данных

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

Один бит сломал, другой потерял: задачка по передаче данных

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

Один бит сломал, другой потерял: задачка по передаче данных

Я забыл упомянуть, как генерируются ошибки, там всё примитивно — два независимых случайных события для каждого бита, 5% потерять, 5% сломать.
Вообще, кажется, это и вправду слишком много. Надо было в исходной задаче сделать 1% и 1%. Хотя можно и самому регулировать эти значения на интерфейсе.

Один бит сломал, другой потерял: задачка по передаче данных

Напишете с оверхедом 500%, возьмут в Яндекс без собеседований, будет уже круто :)
Ночью создавал решение, выходило где-то на 600%, но не дооформил до конца, ушел спать.

Один бит сломал, другой потерял: задачка по передаче данных

Спасибо за развернутый анализ! По моим прикидкам тоже получается, что оверхед ниже 400-500% при таком канале обеспечить не получится.


В этом случае исходный блок будет иметь размер 175 бит и до 25 бит могут быть вставлены в произвольные места.

Тут можно поподробнее, каким способом это достигается?

Один бит сломал, другой потерял: задачка по передаче данных

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

Один бит сломал, другой потерял: задачка по передаче данных

Совершенно верно! Сейчас уточню это в описании.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity