так к чему тут генератор случайных чисел и треугольник малевича?
если в задаче есть определенное условие в полпути, которое уже накладывает некоторые ограничения, по этой логике в в точки абс мы никогда не попадём...
и как бы вам не казалось что кубик это случайность, но кубик нихера не случайность, а так как он кидал это просто забей
хуйня какая-то. вначале он задает вполне конкретное условие - "ставим точку на ПОЛОВИНЕ отрезка...", а потом удивляется что это собирается в узор.
Ему бы еще параллельные линии нарисовать с заданным шагом, а потом с таким же шагом но под 90 градусов - и охуевать , что клеточки в итоге получились!
Не было там условия на половину отрезка.
Просто первая точка нарисовалась примерно там. На илюстрации на 1.09 видно, что она даже на одной прямой с точками A и C не лежит. На 2.50 для другого начального условия процесс изображен. И на 4.48 для точки в окрестности центра треугольника, которая явно не принадлежит получающемуся узору. Результат всегда один.
как это не было? Он на 0:24 так и говорит: "ставим точку на ПОЛ пути" - это и есть "половина отрезка от точки в которой мы сейчас стоим, до той точки в сторону которой мы идем.
*"приближаться на пол пути..."
А, так ты не про начальные условия то есть.
Ну так интерес состоит в том, что откуда бы мы ни начали, мы получаем один и тот же узор. И именно узор, а не равномерную размазню, как следовало бы ожидать от системы, в которой направление движения выбирается случайным образом.
как я понял, там фишка в том, что рандомность то сохраняется, но будучи ограниченная неким условием, она принимает форму этого условия.
Это как если берем горсть песка (более рандомную массу сложно представить) и утрамбовываем ее в формочку, к примеру, в виде звездочки - в итоге, получаем все ту же рандомно перемешанную массу песка, но уже с внешними формами этой звездочки
Да тут все очень просто. Представьте треугольник, поделенный на 4 одинаковых средними линиями. Все точки в центральном треугольнике не могут появится в описанном процессе вообще, потому что они не лежат на пол пути от любой точки треугольника к любой вершине. Потому что от любой точки во всем треугольнике, если взять точку на пол пути к вершине, то она попадет в маленький треугольник у этой вершины.
Вот мы исключили один треугольник.
Продолжая эти рассуждения, можно поделить на 4 более мелких треугольника каждый из трех оставшихся. Там точно так же никогда не будет точки в центральном, потому что второй конец отрезка, серединой которого есть точка в этом треугольнике будет точка в уже ранее исключенном треугольнике.
Это как с приколом про "возьмите любое число от 1 до 10. умножте его на 9, если получилось двузначное число, сложите цифры числа вместе. вычтите 9. у вас получилось 0"
Я конечно не математик, но вполне закономерно, что если задать какие-то строго определённые осмысленные условия, то получишь определённый результат.
Условно говоря, если взять квадрат и обрезать его углы, а затем повторять, то в определённый момент у тебя получится что-то округлое.
Дефакто, тут дорожки проложены условием наличия трёх точек и задачей (двигаться каждый раз на половину дистанции). Рандом играет чисто норминальную роль, ибо очевидно, что рано или поздно при множестве попыток ты побываешь во всех возможных по условию точках. Тот же факт, что при данных условиях выходят очертания треугольников -- чистая физика/матеша. Оно просто так работает ибо так устроена наша вселенная. Могу ещё фокус с бесконечной шоколадкой показать.
>Рандом играет чисто норминальную роль
Рандом нужен, чтобы сделать систему стохастической. Без этого притягивающее множество не может быть фракталом.
>рано или поздно при множестве попыток ты побываешь во всех возможных по условию точках
Ну, во-первых, само условие никак не ограничивает область возможных точек. В любую из них всё равно можно попасть, как минимум взяв желаемую точку в качестве начальной. И об этом было в видео.
Во-вторых, то, что мы здесь видим, на самом деле, это очертания инвариантного множества точек. Это множество бесконечно, поэтому во всех точках система никогда не побывает, даже с учётом всех "рано или поздно". То, что мы видим её очертания является следствием двух фактов:
1) Того, что это множество заодно является притягивающим (аттрактором) из-за того, что фазовый объём системы у нас строго уменьшается (в 2 раза каждый ход).
2) Данная система эргодична. Далеко не все динамические системы обладают этим свойством. Но в данном случае эргодичность за дёшево достигается, поскольку есть заданные из вне случайные числа.
В общем, это реально очень крутая система, чтобы на ней основы теории хаоса изучать. А динамика внутри притяшивающего множества это вообще отдельная тема. Похожий процесс часто моделируют с помощью подковы Смейла и там есть куча радостей в виде бесконечного числа периодических траекторий с любыми наперёд заданными орбитами. А в определённых случаях можно и тьюринг-полноты от них добиться.
В конце видео мне вспомнились креационисты, которые говорят типа, посмотри вокруг, разве могли всякие животные и растения появиться случайным образом, а не по воле Божьей и тут хуяк, папоротник из случайных точек...
ну, там тоже заданы правила и конкретная цель - точность и информативность часов в понимании человека. если трясти коробку с деталями (квадриллионы коробок миллиарды лет), то в некоторых соберутся часы, в других - музыкальные шкатулки, в третьих - прочие разные механические игрушки. так же и с точками - без правил в каком-то из случаев случайными точками можно нарисовать Джоконду, с правилами - будут получаться либо сплошные Джоконды, либо никогда.
Это не конкретная цель, это критерий отбора.
Ты не поверишь, но в природе тоже есть правила взаимодействия чстей и критерии отбора. Только там их еще и больше, поэтому модель куда сложнее.
случайными точками папоротник долго отрисовывать, точки будут попадать одна на другую или вставать очень близко друг к другу, плотность точек будет не равномерная. папоротник из точек будет очень сложно анимировать (например, под действием ветра). так что такое рисуется рекурсией, отрезками листик за листиком. в природе каждая клетка "смотрит" какие клетки её окружают и делится в определённом направлении используя те же формулы.
Хоть и не знал, но как-то не сильно удивило, что с помощью случайных чисел и подобранных формул можно сложные фигуры отрисовывать. Мне вот тут в голову похожи вопрос втемяшился уже какой день дума. Может ли в виртуальном мире, скажем в star citizen, что либо перемещаться быстрее скорости света. Про сам star citizen понятно что локации не связаны жёстко и пространства между ними нет. Но вот если бы было, можно ли мгновенно перемещать объекты?
Вообще то в реальном мире возможны мгновенные перемещения. Скорость света превысить нельзя, а мгновенные перемещения возможны. Такое случается при туннелировании.
Положить, что мы строим наш мир без всей этой релятивистской чепухи, просто однородное евклидово пространство с однородным, глобальным временем. Тогда скорость ничем не ограничена. Вообще ничем, может быть сколь угодно большой.
Отсюда следует, что взаимодействие может быть в пределе мгновенным на сколь угодно больших расстояниях.
Скажем, каждый электрон создает электрический потенциал, который создает кулоновскую силу действующую на абсолютно все объекты с ненулевым зарядом во всей мать его вселенной. Получается, что движение одного конкретного электрона будет иметь мгновенный эффект на все вселенную. Все взаимодействует со всем, мгновенно - такое хрен просимулируешь.
В нашей симуляции, мы хотим скажем обновлять текущие параметры всех объектов не непрерывно, а через определенные, очень малые интервалы времени. Непрерывно просто не получится, ведь процессор может делать только конечное количество вычислений.
Поэтому, каждую итерацию, в момент времени Т мы считаем новые координаты всех объектов для некого момента времени Т + дельта.
Наша дельта это такой шаг по времени. Давай назовем эту дельту квант времени или планковское время.
Поскольку временной шаг конечен (хоть мы и можем сделать его очень малым), мы не сможем симулировать бесконечно быстрые взаимодействия. Придется ввести лимит, на скорость взаимодействия. Как же мы его выберем?
Давай вспомним, что флоатпоинт числа тоже имеют свою точность, они не бесконечно точные. Есть определенная очень малая длина, для оперирования которой не хватит точности. Давай назовем ее планковской длинной. Этакий шаг в пространстве.
Тогда выбор лимита скорости взаимодействия достаточно очевиден. Чтобы симуляция работала корректно, лимит должен быть равен планковской длине деленной на планковское время.
Давай подставим числа, скажем наш шаг по времени равен 5.39е-44 секунд, шаг в пространстве 1.62е-35 метра. Тогда максимальная скорость взаимодействия будет равна: 1.62е-35 / 5.39е-44 что примерно 3.0е8 метра в секунду. Достаточно большая скорость, в принципе должно на все хватить.
Однако есть проблема. А ка мы будем это ограничение на максимальную скорость взаимодействия навязывать?
Если сделать так:
if (скорость > 3.0e8)
{
скорость = 3.0e8
}
То багов будет дофига. Такой хак работать не будет.
Например, я лечу в корабле, который разогнался до скорости 3.0e8, больше не может из за нашего костыля. И тут я вдруг решил пройтись по короблю прогулочным шагом в направлении его движения. Что получится? Моя абсолютная скорость превысит 3.0e8 и этот костыль не даст мне двигаться вперед. Выглядеть это будет очень тупо и забагованно.
В дополнении к этому, получается что некоторые системы отсчета лучше других. В одной я могу идти вперед, в другой (привязанной к кораблю) я не могу. И получается, что есть некая абсолютная система отчета, относительно который мы меряем скорость.
За такое неравноправие систем отсчета сжв закидают говном игру сразу после выхода. Нужно что то делать.
В итоге ТЗ выглядит так:
1. Сделать лимит на скорость взаимодействия
2. Не должно быть никакой абсолютной скорости. Скорость зависит от системы отсчета.
3. Все системы отсчета равноправны
Выглядит бредово, не правда? Какие то взаимоисключающие пункты. Как мы можем ограничить максимальную скорость, если никакой абсолютной скорости нету, и она вообще зависит от системы отсчета?
Т.е. мы по сути хотим сделать так, что в независимости от системы отсчета все скорости были меньше максимальной. Но при этом в каждой системе отсчета мы в принципе можем приближаться к предельной скорости насколько захотим.
Т.е. мы можем разогнать наш корабль до скорости близкой к предельной скорости,
относительно скажем планеты Нибиру. И одновременно с ним, разогнать другой корабль до скорости близкой к предельной относительно планеты Нибиру в противоположном направлении. Но при этом скорость одного корабля относительно другово должна быть меньше предельной скорости.
Как это вообще возможно? ТЗ от нас буквально требует, чтобы:
предельная скорость + предельная скорость = предельная скорость
Заказчик в край ебанулся, и единственный способ как это воплотить в жизнь, это в край извратить то, как работает сложение.
В этом и заключается чудовищный по своей сути хак, мы заменяем простое линейное сложение скоростей на нелинейную операцию таким образом, что чтобы как мы не складывали, мы не получим скорость больше предельной.
Но этот хак создает огромное количество багов, теперь у нас время течет по разному в зависимости от системы отсчета, расстояния зависят от скорости и от системы отсчета, масса тоже зависит от скорости, и т.д.
в виртуальных мирах всегда есть квантование времени, например, 1 тик = 10 мс, что даст 100 fps.
за 1 тик объект можно переместить в любые координаты в любой локации - получается телепортация.
движение - это просто ряд телепортаций, каждый тик смещение координат на определённые значения.
если объект наблюдаем - придётся просчитывать все промежуточные точки каждый тик. если нет - можно вычистить только его конечное положение в конечный момент времени.
можно написать мод, который будет подменять формулу ускорения на классическую (v/t) без учёта скорости света, или любую другую, дающую преимущество кораблям красного цвета, с влиянием кармы пилота и кол-ва открытых ачивок игрока.
охуенный хаос, со всеми заранее заданными условиями. мамка даст тебе пиздов если ты не приберешься в комнате, удивительно, но в комнате сначала становиться чище, потом еще грязнее а потом тееб прилетает пиздов... хаос епта..
для геймдева не оптимально восстанавливать текстуру папаротника по молекулам, проще подгрузить сразу готовую... конечно мы уйдём от килобайтного объёма кода до мегабайтных текстур, но сохраним процессорное время.
процедурные текстуры - крутая вещь. но не рандомными точками, которые будут часто попадать в одни и те же пиксели, а некоторые пиксели вообще ни разу не прокрасятся, т.к. рандом не выпал
Кратко о видео: Возьмем функцию y=sin(x), а теперь рандомно будет брать х и подставлять в формулу и строить график.... Охуеть!!! У нас получается синусоида!!! Это невероятно, из хаотических чисел получается синусоида!!! Это послание нам из мира хаоса!
Мего ироническое видео. "О боже мой взял 3 точки и задав условие движение случайной четвертой точке "пол отрезка" я получил в результата множество треугольников это магия !! " .. Забавно что чем меньше знаний о мире у людей тем больше они ведут себя как впечатлительные дикари.
Почему он математику как магию преподносит? И в конце хуйню несет про генерацию в играх. В играх используют модели и предсгенерированные данные, что бы улучшить производительность игры. Использование памяти в угоду процессора. Другое дело, если памяти мало и генерировать не много, как например в браузерных играх, но сейчас и это не особо проблема.
Это математика.
https://en.wikipedia.org/wiki/Chaos_game