#Введение

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

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

#24.11.2019

Источник: уже удалённый канал.

Друзья, наконец этот момент настал! Я публикую видео, где показываю результат работы над проектом, который последние два года скрывал от всех и называл "секретным проектом". Чем же оказался этот секретный проект? Смотрите в видео.

Приятного просмотра.

#24.02.2020

Источник: tg/62, tg/63, tg/64.

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

Для начала, очевидно, что рейтрейсинг надо реализовывать на шейдерах.

Поэтому я зашёл на shadertoy.com и взял первые попавшиеся шейдеры, которые это делают. Затем я засунул эти шейдеры в библиотеку, которую я до этого использовал для графики в браузере: miniquad

В итоге получилось это:

#²Довольно быстрый рейтрейсинг трёх сфер

(код) (шейдер) (веб-демка)

#²Очень медленный, но очень красивый рейтрейсинг цветных облаков

(код) (шейдер) (веб-демка)

#²Заключение

Ни первый, ни тем более второй пример не запускаются у меня на телефоне, Firefox тупо крашится. На айфоне первый пример летает. Второй работает, но заметно медленней.

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

(спойлер из далёкого будущего: судьба, я ошибался)

#31.01.2021

Источник: tg/298 (7 💬), tg/299 (80 💬).

#²Введение

Как известно, я решил задачу "что будет если поместить портал в портал". Я написал программу, которая проводит вычисление этого, и срендерил результат.

По этому поводу я опубликовал маленькое видео на ютубе, а затем запостил это видео на реддите, и оно там не взлетело, набрав 29 лайков.

Сейчас, спустя год, я решил предпринять попытку №2, и залил видео, чтобы оно было просматриваемо через встроенный в реддит плеер, и сразу переместил указатель начала видео к сути, параллельно ускорив его. Надеюсь это увеличит эффект.

Вот ссылка на новый пост в реддите. Прошу оценить.

#²Выводы

Спасибо всем за поддержку, пост набрал 2.8к апвоутов и остановился в подъёме. А теперь немного размышлений по поводу реддита.

Я опубликовал данный пост в r/Portal, где находится 98к подписчиков, и где за всё время самый успешный пост набрал 5к апвоутов. Это означает, что насколько бы хорош мой пост ни был, он вряд ли наберёт больше 5к, потому что на это влияет не только качество поста, но ещё и много других критериев, которые должны сойтись вместе одновременно. А я видел, что обычно всякие крутые вещи на реддите набирают >40к апвоутов, и рассчитывал примерно на это. Я думал, что у реддита есть аналог трендов, и что любой пост может взлететь до небес, если он хорош. А оказывается, нет, и если хочется взлететь до небес, нужно публиковаться в изначально популярном сабреддите.

Ещё пост набрал 2.8к апвоутов, и 70 комментариев, в то время, как тот же самый пост на пикабу набрал 2.4к апвоутов, но 469 комментариев. Плюс на пикабу я опубликовал это с предысторией и приложил видео на ютубе, в котором до момента входа ждать наверное секунд 30. Но, тем не менее, его оценило много людей, и посмотрело много людей. Отсюда можно сделать вывод что пикабу является хорошей площадкой с лояльной и активной аудиторией.

Ещё один вариант как можно увеличить охват на реддите - это кросс-посты. Как я выяснил, нельзя кросс-постить в самые релевантные для моего поста сабреддиты: r/gifs, r/gaming, r/interestingasfuck, r/nextfuckinglevel. Туда можно постить только "оригинальный" контент.

Но можно кросс-постить в менее поулярные сабреддиты, и я постнул в r/DrosteEffect, и какой-то чувак кросс-постнул в r/Recursion.

Теперь я обнаруживаю, что мою гифку перезалили, и опубликовали в r/interestingasfuck, и там пост набрал 4.3к апвоутов.

Я принял правильное решение, что разместил ватермарку посередине картинки, потому что учитывая масштабы копипасты постов, это единственный способ как можно найти оригинал. В будущем думаю сразу размещать ссылку на этот телеграм-канал, написав: t.me/optozorax_dev. Раньше у меня ватермарка была слабо видно, и она была в левом углу картинки, благодаря этому какое-то сообщество в вк, обрезало мою анимацию квадратом, и моей ватермарки как и не бывало.

Так же я принял правильное решение, что в гифке сразу перешёл к делу и показываю процесс входа через 1 секунду от старта, а весь нужный контекст предоставляю в заголовке. Так часто делают, и это работает. В этом плане мою ютубовское видео просто ужасно, потому что оно повторяет заголовок, вводит много ненужной информации в начале, и вообще там всё медленно происходит. Весь процесс можно ускорить в 1.5 раза, и ничего плохого не случится. Так же, если бы я сделал видео максимально коротким, то на ютубе шансов завируситься было бы намного больше, потому что люди на ютубе всегда пишут: "If this video less than a minute, and YouTube recommends it to me, I definitely watch it.".

Будущие посты-гифки по этой теме я планирую публиковать в r/gaming, или r/nextfuckinglevel, и уже потом кросс-постить это в r/Portal (туда кросс-пост разрешён).

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

#²Статистика

#9.02.2021

Источник: tg/310 (115 💬).

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

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

Справа показано как треугольник обрезается при входе в данный портал.

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

А ещё, поверхностные порталы можно покрутить в моей программке.

#14.02.2021

Источник: tg/312, tg/313, tg/314, tg/315, tg/316, tg/317 (3 💬), tg/318, tg/319, tg/320, tg/322 (1 💬), tg/323 (19 💬).

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

Я не хотел создавать скучный портал в форме ленты Мёбиуса, который телепортирует из одного места в другое, я хотел создать такой портал, который будет телепортировать в свою какую-то часть, то есть сделать эту ленту такой, чтобы она была порталом, состоящим из одной стороны.

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

Чтобы лучше понять что я имею ввиду, давайте взглянем на эту гифку.

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

Если смотреть на него так, что луч пересекает его два раза, то всё выглядит как обычно (зеркало + зеркало = нормально). Тут важно заметить, что в начале гифки мы видим синий пол через него. Но если смотреть на него так, чтобы луч пересекал поверхность один раз, то мы на месте пола увидим белый потолок. В этом и заключается суть зеркалирования. Представьте что то же самое делается и в ленте Мёбиуса.

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

Более формально, если взглянуть на параметрическое представление ленты Мёбиуса, то мне нужно найти в какой точке (u, v) что-то касается этой ленты, затем просто умножить v на -1: (u, -v), и преобразовать эти координаты обратно к (x, y, z).

Итак, теперь на основе чего это можно сделать? Недолго думав я пришёл к тому, что реализовать такое рейтрейсингом будет проще всего. Окей, делать рейтрейсинг через шейдеры я умею (или могу загуглить на shadertoy.com как это делают), так что тут никаких проблем. Но как мне найти пересечение луча и поверхность Мёбиуса?

В рейтрейсинге луч обычно представляется в виде o + d*t, где o(origin), d(direction) - это вектора, а t - скаляр, который необходимо найти.

И если посмотреть на параметрическое представление, то оно выглядит очень плохо, аналитически найти пересечение луча и точку на поверхности Мёбиуса у нас не получится.

Но, это получается уравнение с тремя неизвестными (t, u, v) и тремя уравнениями. Значит решение можно найти численно! Благо на 3 курсе у нас были лабы на написание многомерного метода Ньютона (узнать который я мечтал ещё со школы), так что как я его понял, сразу оформил это в виде математической статьи, чтобы кто угодно (понимающий математику), тоже мог им воспользоваться, вот ссылка на эту статью, там же рядом лежит pdf'ка.

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

Я думал что всё потеряно, что вот он мой конец. Но через какое-то время мне пришла идея, что можно свести многомерный поиск к одномерному. Если внимательно посмотреть на параметрическое уравнение ленты Мёбиуса, то можно заметить следующее: при фиксированном u оно превращается в уравнение прямой! А ещё можно заметить, что если зафиксировать v = 0, то у нас получится уравнение окружности!

На данной картинке можно увидеть что лента Мёбиуса действительно состоит из прямых отрезков:

Раз лента Мёбиуса при фиксированном u превращается в уравнение прямой, значит можно аналитическим образом найти расстояние между двумя прямыми. А это расстояние можно использовать в одномерном методе Ньютона, чтобы его минимизировать, и найти такое u, при котором это расстояние равно нулю, то есть луч пересекает прямую с поверхности, то есть саму поверхность!

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

Ещё тут важно обратить внимание на то, что u передаётся только в периодические функции, а значит оно должно быть в пределах [0; 2π), и в таком случае лучше обрезать эту переменную по этим границам, когда к ней прибавляется Δu, иначе решение будет сходиться очень плохо (проверено на практике).

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

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

Итак, я теперь наконец умею рисовать ленту Мёбиуса рейтрейсингом, и при этом для каждого луча я умею получать в каких (u, v) на ленте он находится. Вот как это выглядит на поверхности.

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

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

Итак, теперь момент истины! Как же выглядит портальная лента Мёбиуса???

Она выглядит вот так:

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

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

Но это вполне очевидно что данный «портал» всё искривляет. Если посмотреть на визуализацию (u, v) на прошлой картинке, то можно видеть, что там квадратик снизу не таких же размеров как и вверху, а у нас как раз меняются местами верх и низ.

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

Думаю надо немного снизить планку и постараться сделать портал в форме ленты Мёбиуса, который состоит из двух частей. Похоже, такой должен сохранять целостность :)

Кстати, код лежит тут.

#15.02.2021

Источник: tg/324 (14 💬).

Сегодня я сделал портал Мёбиуса, состоящий из двух частей, и он работает и выглядит нормально!

Тут всё как с цилиндром в 14.02.2021: если луч проходит через портал два раза, то он возвращается в прежнюю вселенную. Поэтому лента Мёбиуса выглядит так интересно с некоторых ракурсов, где луч проходит дважды.

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

Ещё что мне нравится, наблюдая в синий портал, можно видеть обратную сторону его границы — оранжевую.

Так же видно, что если поставить эти порталы друг напротив друга, то они, как и обычные порталы, создают коридор.

Затем, в середине видео, я перевернул один портал на 180°, нажав A. Я это сделал для того, чтобы легче было видеть где луч проходит один раз, а где два.

По мне, получилось очень красиво и интересно, стоило всех приложенных трудов :)

Код.

#15.02.2021

Источник: tg/325 (57 💬).

Я сделал веб демку для портала Мёбиуса!!!

Заходите, крутите наздоровье. Управление: мышь + кнопки написаны слева вверху. Если сильно лагает и маленький ФПС, то уменьшите размер браузера, должно стать получше.

Не открывать с телефона, ибо он может просто зависнуть. Здесь шейдеры виноваты, телефон такое не выдержит.

https://optozorax.github.io/mobius_portal/

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

#20.02.2021

Источник: tg/326 (6 💬), tg/327, tg/328, tg/329, tg/330 (15 💬).

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

В то время как в реддите меня забанили с формулировкой «this is not next fucking level», и там в принципе набрало мало лайков, даже в сабреддите /r/Portal. Поэтому думаю что дальше, помимо этого канала, лучше развивать твиттер, это более благодарная площадка, и там сидят крутые математики и крутые программисты.

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

И оказывается что концепцию портала Мёбиуса из двух частей (order-2) уже рассматривали 😔. Мало того, ещё там есть тройной портал Мёбиуса! И ещё есть такие мозговыносящие порталы, которые я до сих пор не могу осмыслить, например Trefoli Partial.

Мне кажется этим всем визуализациям немного не хватает графония в виде телепортации света и возможности увидеть другую сцену сквозь них, либо поставить их друг напротив друга.

Ну а следующее о чём мне рассказали — это «KnotPortal». На самом деле подобный тип портала уже показывался в более старой программе «Polycut», но тут уже визуализация значительно лучше, и тут самое интересное — это Trefoli Knot, который является одним непрерывным порталом, но при этом может телепортировать в 4 (или больше) различных вселенных!

Кстати, непрерывный портал, который может переносить не только в одну вселенную, а сразу во множество — это очень малоизвестная концепция. Я называю такие порталы тройными/четверными итд, и в своё время самостоятельно открыл тройной портал, а на основании идеи о нём и любой N-портал. То есть такие порталы могут существовать N равноценными частями. И соответственно, каждую из этих частей мы можем поместить в различные вселенные, чтобы связывать их друг с другом.

Так что многомировые порталы существовали и до меня, но не в таком виде, как я их придумал! Так что мои предстоящие визуализации будут чем-то новым и необычным.

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

Вот как в «Polycut» визуализировали портал Мёбиуса:

А вот так выглядит портал под названием «Trefoli partial» 🤯.

А вот так выглядит Trefoli Knot, который телепортирует в 4 (или больше) различных вселенных. Его можно посмотреть на этом видео.

Точно, совсем забыл! Пока я пилю визуализации, вот вам загадки!

У меня есть две очень крутые вещи: тройной портал и одиночный портал (монопортал). Если понять концепцию тройного портала, то можно легко соорудить четверной, пятерной итд, но не одиночный.

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

Теперь вот вам зададки: придумайте порталы, которые равноценно существуют тремя частями (тройной портал), и одной (монопортал).

Может быть вы придумаете что-то, что ни мне, ни кому-либо ещё ранее не было известно! В любом случае если вы постараетесь решить эти загадки, то потом будет гораздо интересней увидеть решение.

#2.03.2021

Источник: tg/331 (1 💬), tg/332, tg/333 (2 💬), tg/334, tg/335, tg/336, tg/337 (2 💬).

Вместо того чтобы делать то что обещал или хотел, я снова занимался тем, что изображено на аватарке этого канала.

А именно я захотел оптимизировать рендеринг ленты Мёбиуса.

Напоминаю, что лента Мёбиуса задаётся параметрически довольно сложным уравнением, а рендерю я её через ray-tracing. Соответственно для каждого пикселя надо искать пересечение луча с этой лентой. Я искал пересечение через одномерный метод Ньютона.

Bottleneck'ом этих вычислений было то, что для метода Ньютона требовалось очень много начальных приближений, а именно 10, иначе картинка получалась очень плохой. Если ставить 20-30, то картинка уже идеальная и абсолютно без артефактов, но вычисляется такое невозможно долго. И если бы я мог сократить это число хотя бы до 1 или 2, то я бы очень сильно улучшил производительность рендеринга.

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

Самое первое что я сделал — это откопал в дебрях shadertoy демку где через ray-marching рендерится лента Мёбиуса, может быть мне получится использовать эту информацию.

Затем я выкинул из неё всё лишнее и постарался использовать так, чтобы вычислять начальное приближение из положения на пересечении. В итоге начальное приближение действительно хорошо находилось, и даже слишком хорошо, но из-за особенностей рей-марчинга вокруг ленты Мёбиуса было свечение, и оно очень плохо находило пересечение телепортированного луча, который дважды проходит через ленту, особенно в местах, где эти оба места близки. Я к сожалению не очень понимаю как реймарчинг в данной демке работает, каким магическим образом этот ротор так делает, так что я не смог уменьшить радиус этого свечения. И этот вариант пришлось откинуть в пользу других, потенциально сработающих.

Для дальнейшего повествования следует сказать, что, очевидно, ленту Мёбиуса можно обернуть в сферу так, чтобы она её полностью покрывала. Эта сфера как минимум с радиусом 1.55.

Теперь эту информацию можно использовать. Можно представить любой луч, который потенциально может пересечь ленту Мёбиуса, двумя точками на этой сфере. Первая точка показывает origin, а вторая direction. Итого любой луч мы можем закодировать 4 числами — этими углами на сфере. Тогда результат для этих 4 чисел должен быть — n чисел, обозначающих точки пересечения этого луча с фигурой внутри сферы. Для ленты Мёбиуса по идее должно получаться всегда 2 числа, ибо это довольно простая фигура.

Но на самом деле можно даже не кодировать 2 числа для одного луча, можно всегда кодировать 1 число - ближайшую точку пересечения. А чтобы получить дальнюю точку (в случае, если наш луч лежит не вне сферы, а внутри неё), то мы можем просто поменять местами точки на сфере и получить обратный результат.

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

Чтобы оценить качество любого решения, можно воспользоваться следующими данными. Я перебрал количество начальных приближений для метода Ньютона от 0 до 10 и посчитал насколько хорошо предсказывается истинный результат с 1000 начальными приближениями:

0 — 9.9  
1 — 0.47  
2 — 0.12  
3 — 0.04  
5 — 0.02  
10 — 0.007

Далее по ним мы будем исследовать насколько каждый предложенный метод адекватен.

Итак, основа есть что дальше?

Первое что пришло в мою больную голову — нужно использовать машинное обучение. То есть нужно рассчитать кучу кучу лучей, а затем сделать какую-то нейросетку чтобы она по 4 числам находила другое одно число. Так как простые нейросетки — это просто перемножение матриц, то мы можем в шейдерах перемножать только максимум матрицы 4×4, поэтому надо делать нейросетки из 4 и менее нейронов (напоминаю, что мы делаем рейтрейсинг для каждого пикселя, поэтому использовать перемножение больших матриц мы не можем, уж дешевле будет метод Ньютона 10 раз запустить). Моя больная голова предположила что этого может быть достаточно, и что это даже может сработать.

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

Затем я ушёл на питон + keras, и начал обучать нейронку там. Вот данные, если вдруг кто-то захочет попробовать сделать лучше. Итого у меня самый лучший результат получлися с 3 слоями по 4 нейрона и функцией активации elu. А результат этот 20.0. Намного хуже чем 0 начальных приближений (WAT? у меня в коде где-то явно ошибка, но нейронка точно правильно работает в коде на расте, это я проверял). Если же к ней добавить метод Ньютона после предсказания, то получается 0.31451 (≈π/10, WAT?), что чуть-чуть лучше, чем 1 начальное приближение, но всё ещё очень плохо. Может быть там нейросетка просто нашла среднее число, из которого хорошо сходится в максимальное число других чисел, и всё.

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

Параллельно с нейросетками, в процессе подготовки данных, я вдруг понял, что вообще-то можно просто перебрать все эти 4 числа с каким-то шагом и сохранить результат в текстуру. Если перебирать с шагом 50, то текстура в итоге будет 50²×50² = 2500×2500, что не так и много, особенно учитывая что очень много лучей просто будут чёрными, и что будет оптимизация от png. Ну максимум десяток мегабайт получится.

Вот так выглядит текстура на сфере.

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

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

А вот так выглядит сама текстура (нарисовна в радужном градиенте для простоты восприятия).

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

В итоге кстати, мне удалось добиться 60 фпс на 4к фулскрине, но это выяснилось в процессе. Первое что я сделал — это поставил if, в котором чекаю если луч пересекает сферу которая покрывает ленту Мёбиуса, то только в этом случае считаем дорогой метод Ньютона, иначе не считаем. Следующая оптимизация заключалась в том, что я для вычисления двух ближайших точек у скрещивающихся прямых стал использовать не обращение матрицы 3×3, а более простые формулы с википедии с использованием скалярного и векторного произведения векторов.

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

#6.03.2021

Источник: tg/338, tg/339 (3 💬), tg/340, tg/341.

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

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

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

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

Но сейчас мне пришла идея о том что это можно сделать по-другому: можно делить всё пополам при помощи прямой. А чтобы проверить по какую сторону от прямой находится данная точка, нужно сделать очень мало очень простых арифметических действий, благодаря чему такой код, по идее, должен быть очень быстрым.

Как мы знаем, уравнение прямой задаётся в виде: y = k * x + b. Иногда проблема с этим уравнением возникает, если k → ∞, то есть если прямая горизональная. Эту проблему можно легко обойти если использовать уравнение прямой x = k * y + b, ведь здесь k_y → 0 когда k_x → ∞, в итоге если мы будем выбирать наименьший из них, то наш k всегда будет меньше единицы по модулю.

Я решил поступать следующим образом:

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

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

А это уже много сгенерировать просто в кучу if'ов в код на шейдерах.

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

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

Что интересно, если для метрики «лучшей прямой» выбирать такую прямую, которая делит площади с одной стороны и с другой как можно ближе к «пополам», то итоговый алгоритм работает очень плохо.

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

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

А по поводу библиотеки для пересечения полигонов, тут всё довольно просто. Для Rust существуют биндинги к C++-ной библиотеке clipper, это я и заюзал.

В общем я заставил это работать, и вот пример сложного полигона, для которого это работает.

Его код можно посмотреть здесь.

Всё работало хорошо, но проблемы начались когда я захотел скомпилить это для wasm, C++ в wasm бесплатно не компилился, а гугление и пробование всяких wasm32-unknown-emscripten привели в кроличью нору, и я понял что надо бросить это дело пока не поздно. Другая библиотека под названием geo-booleanop написана на чистом Rust 👍. Но проблема в том, что её исходный код основан на коде на JS, и она у меня падает при любых чуточку сложных, а иногда и при простых полигонах 👎.

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

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

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

А иногда возвращается треугольник, который состоит из 4 точек, и прикол этого треугольника в том, что эта 4 точка находится очень далеко, но то что она образует, имеет практически нулевую площадь. И для такого «треугольника» не находится подходящая разделяющая прямая. В общем одни сложности.

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

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

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

А пока вот ссылка на текущий код.

Что интересно, всё здесь я сделал где-то за 2-3 дня. Я думал что у меня на отлаживание багов уйдёт опять неделя, как это было с ускорением рендеринга ленты Мёбиуса. Но нет, очень часто всё это дело работало с первого раза. Не знаю уж чья тут заслуга — моя, потому что я уже очень много работаю с подобными алгоритмами в личных проектах; или заслуга Rust, потому что его система типов и философия согласной которой организовываются библиотеки, дают такой буст; а может олимпиадки расшатали мозги.

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

#8.03.2021

Источник: tg/342 (26 💬), tg/343.

Монопортал.

Мы привыкли что порталы состоят из двух частей, что они способны соединять вместе два мира. Но что если усомниться в этом основании и придумать портал, который состоит из одной или из трёх частей? Такое вообще возможно?!

Да! И сегодня я покажу портал, котоый состоит из одной части. Я называю его просто Монопортал.

Этот портал работает почти как зеркало, только без отзеркаливания! Видно, что написанный на стенке напротив текст он не зеркалит, и его можно спокойно читать.

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

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

Монопотрал можно покрутить в браузере:

https://optozorax.github.io/portal/?scene=monoportal

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

И это можно называть порталом, а не чем-то зеркало-подобным, потому что в него возможно зайти. Зеркало же нельзя назвать порталом, потому что при входе в него вы будете сталкиваться сами с собой, и его нельзя сконструировать из обычных порталов, не нарушая «физику».

Исходники (код пока что страшноват, скоро приведу его в порядок).

Наслаждайтесь)) А на подходе ещё куча других монопорталов и тройной портал.

Так же этот пост можно поддержать в твиттере.

#13.03.2021

Источник: tg/351 (3 💬), tg/352 (1 💬).

Я сделал интерфейс для визуального редактирования сцены с порталами. Через этот интерфейс можно менять матрицы объектов и они будут меняться риалтайм (сделаны через uniform у шейдеров); а можно менять объекты и код определения чего-то внутри них, код пересечения с ними; тогда изменения произойдут после нажатия кнопки Recompile, потому что нужно перекомпилировать шейдеры. На видео можно наблюдать этот интерфейс. Сцена здесь сделана полностью с помощью этого интерфейса.

Далее будет написано как и почему я это сделал.

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

Данный интерфейс сделан на основе megaui, стандартного гуя юзаемой мною библиотеки (macroquad). Данный интерфейс является так называемым Immediate Mode GUI (далее буду называть imgui, не путать с библиотекой dear imgui), то есть, кратко говоря, он используется следующим образом:

if ui.button("Add").clicked() {  
    array.push(...);  
}

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

Возвращаясь к теме, после монопортала я начал делать сцену тройного портала, но понял что я слишком часто запускаю компиляцию, даже когда мне надо повернуть матрицу на какой-то угол чтобы затестить как она будет выглядеть. И я понял что так продолжаться не может, мне нужен визуальный редактор матриц на основе того что я сделал в просмотре монопортала. И буквально за пару дней я такой визуальный редактор и сделал, и он работал. Я крутил слайдеры, а объекты крутились риалтайм. Риалтайм достигался за счёт того, что матрицы я передавал через униформы.

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

К моменту как я это сделал, я опубликовал твит, где можно посмотреть как это выглядело.

Сейчас я пользуюсь egui для imgui'я, всем советую.

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

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

Сейчас у меня много багов, и код генерации шейдеров не очень хороший, работаю над этим, но уже есть:

• Редактор матриц: обычная матрица, умножение матриц, телепортацию матрицы через две другие матрицы.
• Редактор объектов: (плоский, сложный) × (обычный, портал).
• Редактор материалов: обычный, зеркальный, стекляный (последние 2 не тестировал).

Далее я планирую добавить:

• Редактор униформов

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

Далее я планирую нарисовать сцену монопортала через этот интерфейс, затем через него же сделаю портал Мёбиуса, и начну делать все остальные сцены, и показывать все остальные крутые порталы, которые я открыл. Ждите.

Как видите, я пробую новый формат: сначала говорю что сделал, а затем объясняю всю мотивацию. Как вам?

#14.03.2021

Источник: tg/353 (3 💬).

Я тут немного посидел, пофиксил баги, добавил код, и теперь:

• Даже портал Мёбиуса в этом визуальном редакторе можно задать и конфигурировать.
• Работает материал стекла — сфера посередине. Не знаю зачем мне стекло, просто круто!
• Работает материал зеркала — стена справа.

Ох как хорошо с этим визуальным редактором, скоро великий суп наварю портальные сцены создам.

#18.03.2021

Источник: tg/354, tg/357 (1 💬), tg/358, tg/359, tg/362 (1 💬), tg/364, tg/365 (6 💬).

#²Portal Explorer

Объявляю релиз Portal Explorer v0.1.0!

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

Чего говорить, просто возьмите и зацените веб-демки: (лучше с компа)

#²Монопортал

Монопортал

#²Портал Мёбиуса

Портал Мёбиуса

#²Таймлапс

А вот здесь можно увидеть таймлапс того как я делал сцену с монопорталом через интерфейс. Снимал до того пока у меня не вылетела программа :D, потом уже лень было снимать.

#²Что сделал

Значит, я последние несколько дней фигачил весь этот крутой интерфейс, пилил фичи, и наконец сделал так, чтобы в интерфейсе можно было задавать ВСЁ:

• Свободные переменные типов bool, int, float.
• Вычисляемые переменные. То есть в интерфейсе пишешь формулу, а формула вычисляется в число.
• Матрицы.
• Матрицы через вычисляемые переменные.
• Объекты.
• Материалы.
• Текстуры.
• Пользовательский GLSL код.
• Какие из свободных переменных пользователь может настраивать.
• Этапы анимации (типо как собрать монопортал из дверного проёма и простых порталов).

Ещё раз советую потыкаться в интерфейс, там есть возможность всё это настраивать, посмотрите, лучше тысячи слов.

Про задание объектов и матриц я уже рассказывал, расскажу про новое.

#²Вычисляемые переменные.

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

Так что очень хотелось бы засунуть вычисляемые переменные в шейдеры, но нельзя, надо делать отдельное решение. И я быстро нашёл отличную библиотеку fasteval, которая как раз позволяет парсить строки с формулами и интерпретировать их. Обожаю Rust за то что мне за несколько часов удалось полностью подключить и встроить эту библиотеку в интерфейс.

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

В комбинации с этим я и создаю то что можно наблюдать в демке монопортала.

Вот так выглядят формулы и этапы анимации в интерфейсе:

#²Сообщения об ошибках

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

#²Проекция Панини

Так же я добавил очень хайповую Проекцию Панини. Эта проекция позволяет не очень сильно искривлять картинку (не сильнее, чем Fisheye), но при этом предоставлять очень большой угол обзора, даже больше 180°. Сделана она на основе проекции на сферу, а потом из этой проекции на цилиндр. Хитрая проекция в общем. В веб-демке чтобы её включить, нажмите «Camera Settings» и поставиьте галочку «Panini Projection».

#²Заключение

Теперь я столько сцен наделаю: смещающий монопортал, вращающий на 180° монопортал, тройной портал, МОНОПОРТАЛ МЁБИУСА, угловой монопортал, портальная броня, порталы из замощений, ух.

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

Ещё мне очень нравится egui, он так классно выглядит, и с ним так просто писать интерфейс. Ещё кайфую с того что могу без перекомпиляции менять очень много разных вещей.

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

Ещё я щас думаю что со всем этим гуём я смогу прямо ОЧЕНЬ просто показать как таки построить портал в портале, без всех тех моих зубодробительных алгоритмов над полигонами на C++, думаю через этот гуй можно просто за час решить проблему портала в портале в том виде как она решена в моём видео на ютубе.

Вся эта интерактивность, она очень хороша. Класс.

Кстати, этот пост можно поддержать в твиттере.

#19.03.2021

Источник: tg/366 (5 💬).

Монопортал Мёбиуса.

Этот портал состоит из одной части и обладает одной поверхностью! Всё что в него входит просто телепортируется на другую его часть.

Обязательно заходите в веб демо (с компа), там вся анимация, описание, и там очень много ползунков можно покрутить:

https://optozorax.github.io/portal/?scene=mobius_monoportal

Интересное наблюдение, которое я совершил случайно: если крутить его вокруг локальной оси Y, то картинка не меняется!

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

Кто помнит, в самом начале я как раз мечтал получить именно этот результат, и теперь у меня получилось!

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

#20.03.2021

Источник: tg/368 (11 💬).

Тройной портал.

Я уже усомнялся в том, что порталы могут иметь только две части, и показывал вам портал из одной части, настало время показать портал из трёх частей, портал который может соединить три разных мира!

Веб демка (лучше с ПК)

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

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

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

Кстати, лайфхак: чтобы приблизить можно сделать угол обзора 2°.

Меня можно поддержать в твиттере, реддите, пикабу.

#21.03.2021

Источник: tg/380 (3 💬), tg/386 (2 💬).

Портал в портале.

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

Кажется это самое лучшее что я когда-либо делал в жизни.

https://optozorax.github.io/portal/?scene=portal_in_portal

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

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

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

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

#24.03.2021

Источник: tg/387 (1 💬), tg/388, tg/389 (3 💬).

А я тем временем немного законтрибьютил в опен-сурс. У меня в Portal Explorer'е были разные наработки, улучшалки юзаемых мною библиотек, и я решил вынести их отдельно, чтобы другие тоже могли пользоваться.

#²quad-url

[crates.io] [github] [web demo]

Это библиотека для чтения и изменения текущей ссылки (search параметры, hash) и для открытия ссылок в текущей или новой вкладке.

В моём Portal Explorer'е это используется для считывания сцены из урла: ?scene=triple_portal, и я сейчас сделал так, что когда сцена открывается через меню «Load», то текущая ссылка меняется на имя этой сцены.

Так же с помощью неё я пофиксил открытие ссылок в egui-miniquad, а следовательно и в следующем крейте.

#²egui-macroquad

[crates.io] [github] [web demo]

macroquad славится своей простотой использования, и теперь с такой же простотой можно подключить очень крутую библиотеку для Immediate Mode GUI: egui.

Кстати, все мои последние вещи: Portal Explorer, Monoportal, Mobius Portal написаны с использованием macroquad, так что всем советую.

#13.04.2021

Источник: tg/395 (4 💬).

Новости за последнее время:

1. Мою довольно нетривиальную фичу в egui замерджили. Кратко говоря, данная фича позволяет любому виджету хранить произвольные данные в структуре интерфейса, которая передаётся везде. То есть не надо заводить какой-то свой HashMap, и протаскивать его во все функции. Сделано это при помощи хранения через трейт Any (как TypeMap). Так же важнейшей частью и челленджем этой фичи является решение проблему де/сериализации этой штуки! Это нужно, чтобы после закрытия программы всё состояние интерфейса могло сохраняться и считываться из файла. Сделал это при помощи отложенной десериализации, которая ждёт когда пользователь вызовет .get::<Type>() с тем типом, который ему нужен. Автор egui говорит что мне надо вынести это как отдельный крейт, ибо сериализацию Any вроде так ещё не была решена. Надо будет заняться, но мой перфекционизм требует чтобы я сначала изучил все TypeMap библиотеки, и только потом релизил это как крейт... Эту фичу я сделал, так как интерфейс в Portal Explorer'е выглядел страшно с точки зрения кода, ибо я везде протаскивал свои HashMap'ы. Пока что без новых портальных сцен, потому что там у меня во всю идёт рефакторинг 🚧, ибо мой интерфейс уже не позволяет легко и быстро делать сложные портальные сцены.

2. Я оживил репошку awesome-quads, где собраны ссылки на проекты, которые основаны на либах miniquad/macroquad. По списку игр и прочих штук видно, что macroquad довольно популярен.

3. 🔵🟠 Portal Explorer попал в Rust GameDev ежемесячник! Спасибо Андрею @ozkriff_games за эту возможность и координацию ✊.

#29.04.2021

Источник: tg/396, tg/397, tg/398, tg/399, tg/400 (2 💬), tg/402 (6 💬), tg/403.

#²Portal Explorer 2

Объявляю о релизе Portal Explorer v0.2.0!

Список изменений:

• Отрефакторен интерфейс редактирования сцен.
• Добавлена возможность менять камеру в меню просмотра сцены.
• Появилась кнопка включения русского языка в меню.
• Добавились описания конкретных этапов, у переменных теперь можно задавать человекочитаемые названия и описание вместо «user_a».
• favicon

Для каждой сцены:

• Улучшено описание, добавлено описание на русском.
• Возможность смотреть на портал под призмой того что он соединяет несколько миров.
• В пункте «Explore» можно в один клик перемещать камеру на конкретный портал.

Изменения сцен:

• Тройной портал — красивые комбинации настроек добавлены как отдельные этапы.
• Портал в форме замыкания Хопфа (Цепной портал) — «новая» сцена.
• Портал в портале — показал начало анимации, красивые комбинации настроек и даже анимации добавлены как отдельные этапы.

Веб-демка:

https://optozorax.github.io/portal/?scene=triple_portal

Выбирайте сцены в меню «Load». Даже если вы видели все эти сцены, советую пройтись по ним снова, и снова глянуть описание, ибо там много изменений и улучшений.

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

А ниже будет более подробно.

#²Отрефакторен интерфейс редактированя сцен

Напоминаю, что все сцены я делаю в визуальном редакторе, который сам и написал. Раньше у меня там было всё очень плохо с точки зрения User Experience, потому что:

• Некоторые настройки сцены зависели от положения в массиве. Соответственно если я что-то удаляю или перемещаю, то это может сломаться.
• Другие настройки были завязаны на строковых именах, соответственно нельзя переименовывать некоторые объекты, и вообще это как-то несерьёзно.
• Нельзя было задать анонимный объект «на месте» (inline). Можно писать только имена существующих объектов. Соответственно если я хочу просто сделать минус к существующей переменной, то мне надо создавать новую именованную переменную.
• Все этапы объяснения были сделаны так, что в настройках сцены для конкретной переменной (например, которая управляет цветом порталов — от чёрного к оранжевому/синему) надо ставить switch в виде математической формулы, например swith(stage, 0.0, progress, 1.0, 1.0 - progress, 0.0). Из-за того что разные анимации должны находиться в одной матрице или одной переменной, сложность и когнитивная нагрузка невероятно возрастали.

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

Поэтому я решил ввести две новые фичи:

• Чтобы каждый объект имел свой типизированный айдишник (вместо имени или положения в массиве).
• Чтобы значение любого объекта можно было задавать «на месте», без написания его имени и создания именованного объекта.

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

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

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

В самом верху находится меню «Objects», в нём лежат объекты. Объект требует одну матрицу, чтобы задать место где он будет находиться. Матрицу можно объявить инлайн, здесь это именно так и делается. Но здесь сделана «Param.» (параметрическая) матрица, у которой компоненты можно задавать формулами, которые зависят от каких-то параметров. В данном случае сделано чтобы положение матрицы высчитывалось на основании угла x по траектории окружности, который можно передать пользователю, например. Соответственно данный объект крутится по окружности. Видно что внутри матрицы заданы ещё инлайн формулы.

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

#²Добавлена возможность менять камеру в меню просмотра сцены

Хочется:

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

И я такое реализовал, и это можно видеть подробно на данном видео.

#²Появилась кнопка включения русского языка в меню

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

Сделал я это как минимум потому что мне самому проще сначала написать всю лирику на русском, а потом переводить её на английский. А то когда было только английское описание, было очень сложно формулировать мысли.

Ну и вообще, русский как бы основной язык меня и моих читателей.

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

#²Портал в форме замыкания Хопфа

Знаете же как цепь соединяют? Вот это портал в данной форме. Наверное лучше было бы назвать его «Цепной портал».

Для того чтобы он работал необходимо чтобы два портала, соединённые в цепь, были двухсторонними (имеет телепортирующую поверхность как спереди, так и сзади).

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

Ещё в видео можно увидеть что существует два способа раскраски данного портала, и как раз благодаря одному можно понять куда и когда луч телепортируется.

Идею о таком портале подсказал один математик из твиттера, ему он очень понравился.

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

#²Портал в портале

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

Ну и ещё добавлены анимации и картинки. Хвала новому интерфейсу, добавить их было легче лёгкого!

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

#1.05.2021

Источник: tg/404, tg/405, tg/406, tg/407 (3 💬).

А я вам принёс парочку новых прикольных монопорталов. В ближайшее время вас ждут ещё два (три/четыре?) интересных монопортала.

#²Вращающий монопортал

Вращающий монопортал

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

Результирующий монопортал вращает всё на 180°.

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

Идея: спасибо myotra.

#²N-монопортал

N-монопортал

Это монопортал, который ведёт себя как будто он состоит из N частей, например из трёх, но на самом деле часть всегда одна!

#³Построение

Берём обычный монопортал и просто вращаем его части, чтобы между ними был угол 360°/Count.

#³Обычный монопортал

Он получается при Count = 2, и это довольно очевидно, он выглядит как будто у него есть две части.

Если заменить порталы на зеркала (опция Act as a mirror), то он выглядит как обычное зеркало.

Если отзеркалить одну портальную часть (опция Mirror one part vertically) (это не то же самое что сделать её зеркалом!), то портал выглядит как обычный вращающий монопортал.

#³Тройной монопортал

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

Зеркало здесь ломается посередине.

Отзеркаливание одной части тоже ломается.

#³Четверной монопортал

А тут уже зеркало не ломается. На самом деле зеркало ломается только для нечётных N.

Четвертинка посередине выглядит как обычный монопортал — через неё можно читать текст напротив вас, и это сохраняется даже если включить зеркало! Именно так и сделан предмет под названием «True mirror», он состоит из двух зеркал, стоящих друг напротив друга под 90°.

Аналогично для опции отзеркаливания одной части.

#³Остальные

Остальные монопорталы ничем не выделяются.

#2.05.2021

Источник: tg/408 (5 💬).

⚠️ На улицах Алматы были обнаружены спойлеры к будущим порталам Ильи

#3.05.2021

Источник: tg/409.

#²Смещающий монопортал

Смещающий монопортал

Этот портал работает как обычный монопортал, но дополнительно смещает всё на половину своей высоты.

Он может существовать только благодаря помощи поддерживающих порталов.

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

#³Смещаем одну часть

Берём обычный монопортал и смещаем его часть ровно на половину его высоты.

#³Добавляем поддерживающие порталы и телепортируем эту часть

Под конец этой анимации портал станет непрерывным.

Попробуйте прокрутить эту анимацию с выключенной опцией «Teleport light». Зелёный цвет означает телепортированный портал.

#³Исследование смещения

Портал получается непрерывным только для смещения 0 (обычный монопортал) и 0.5 от высоты портала.

#³Делаем портал больше

Можно видеть что с большим порталом пол и потолок встречаются ровно посередине высоты комнаты.

#5.05.2021

Источник: tg/412, tg/413 (2 💬), tg/414, tg/415, tg/416.

#²Введение

Я закончил все фундаментальные монопорталы!

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

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

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

#²Смещающий монопортал 2

Смещающий монопортал 2

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

#²Масштабирующий монопортал 2

Масштабирующий монопортал 2

Он собран из смещающего монопортала, верхняя часть которого превращена в трапецию и в соответствии с этим изменился масштаб всего что от неё зависело.

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

#²Заключение

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

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

Предварительный ответ — нет, но кто знает)

#6.05.2021

Источник: tg/417, tg/420 (10 💬), tg/421 (13 💬)

#²Портал в форме логарифмической спирали

Портал в форме логарифмической спирали

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

#²Опрос

×1.3
png

#²Результат

Всем спасибо за участие, совпало с моим выбором на 3/4, я не ожидал что обычный монопортал вырвется так вперёд)

Опубликовал в твиттере: (заходите по ссылке, там тред)

×1.8
png

В этот раз я попробовал публиковаться по-другому:

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

#11.05.2021

Источник: tg/423, tg/424 (2 💬), tg/425 (1 💬), tg/427 (1 💬), tg/430, tg/431 (2 💬), tg/432, tg/433 (13 💬), tg/434 (17 💬), tg/435, tg/436 (7 💬).

#²Введение

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

#²Основы

Основы

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

Очень часто порталы сравнивают с зеркалами, поэтому имеется опция «Mirror», которая позволяет отключить телепортацию света и объектов и просто превратить порталы в зеркала.

Для нас привычна концепция двери — она позволяет перейти из одной комнаты в другую. Но куда важнее не сама дверь, а дверной проём, потому что именно он соединяет две комнаты, разделённые стенами.

Видимо идея портала была вдохновлена именно им.

В этой сцене показаны две комнаты, соединённые дверным проёмом.

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

Можно сказать что портал — это дверной проём между пространствами.

#²Порталы в одном мире

Интересности начинаются когда мы помещаем порталы в один мир.

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

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

А теперь попробуйте заменить порталы на зеркала. Теперь в каждом зеркале мы видим чередование голубого и оранжевого зеркала; а у изображения треугольника чередуется перед и спина.

Это просто немного другое расположение двух порталов в одном мире:

При Distance = 0 получается 4-монопортал, за подробностями смотрите в сцену N-monoportal.

#²Дверной проём

Из любого дверного проёма можно создать порталы.

Можно сказать как будто мы рвём пространство-время между половинками дверного проёма.

#²Модель скорости

Модель скорости

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

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

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

Если рассмотреть разные точки зрения на движение, то кажется как будто движение портала аналогично движению всего пространства. И в одних случаях пространство и объекты внутри него либо всегда подвижны либо всегда неподвижны до или после телепортации.

#²Одинаковая форма

Одинаковая форма

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

Данный закон пригождается при телепортации портала через другой портал.

#²Портал в портале: две пары

Портал в портале: две пары

Вопрос «Что будет если поместить портал в портал?» можно решить по-другому, не создавая никаких парадоксов, просто взяв на два портала больше.

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

Это можно наблюдать перемещая ползунок «Progress».

А теперь попробуйте сделать это с выключенной опцией «Teleport light».

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

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

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

#²Заключение

Так же по сцене с моделью скорости можно видеть появление новой фичи: автоматические анимации, которые работают за счёт обращения к текущему времени. Я обновил сцену «Портал в портале» в соответствии с этой фичей — это можно посмотреть в этапах «Анимация 1» и «Анимация 2».

На этом всё на сегодня. Кстати, привет всем новым подписчикам, и огромное спасибо ТехноШаману. Такая поддержка очень мотивирует!

#31.05.2021

Источник: tg/439, tg/440, tg/441, tg/442, tg/443 (3 💬), tg/444.

#²Введение

Я всё ещё хочу создать видео где объясняю портал в портале. Сначала расписал довольно подробный план для начала и конца видео. А на середине начались проблемы. До этого я думал что всех имеющихся анимаций и сцен хватит для того чтобы снять подробное и понятное видео, но во время написания плана видео, осознал что нет.

Как раз таки середина и переход от простейших понятий до самого решения задачи поставили меня в ступор. Я думал что бессилен, но потом вышел на ходьбу (я недавно начал ходить каждый день по 8к шагов), и во время ходьбы решил продумать все эти проблемы. Отходил час, придумал и собрал все паззлы в одну единую картину, теперь у меня есть чёткий и понятный план. Почему-то во время ходьбы мне думается намного лучше, чем во время сидения на месте. Может ещё помогает что во время ходьбы на улице не позалипаешь в телефон и не увидишь счётчик уведомлений.

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

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

#²Разрезающая призма

Сцена разрезающая призма.

Это сцена показывает что один портал всегда можно представить как несколько порталов и что порталы обрезают входящие объекты на своей границе.

Понимание данного свойства порталов может быть полезно для понимания того как работает сцена «Портал в портале: две пары».

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

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

Вы можете перемещать положение прямой на портале.

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

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

Главное чтобы сохранялось их относительное положение на входе и на выходе.

Граница двух порталов должна вести себя как нож, который на входе обрезает все объекты, входящие в него. Здесь ножи представлены серым цветом.

Этот нож обязан быть направлен по направлению скорости входящего объекта.

На выходе объект восстанавливается обратно, поэтому его разрезание не меняет ничего.

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

#2.06.2021

Источник: tg/445, tg/446, tg/447 (1 💬), tg/448.

Я продолжаю делать и улучшать сцены для предстоящего видео на ютубе, и сегодня я вносил дополнения в сцену «Портал в портале».

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

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

Здесь объект показан в виде круга, у которого разные цвета на разных сторонах и выделено направление.

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

#2.06.2021 2

Источник: tg/449, tg/450, tg/451 (15 💬), tg/452.

Сцена «Двигающийся дверной проём».

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

В данной сцене показывается эта аксиома с точки зрения движения порталов.

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

Сложности начинаются когда порталы обладают скоростью относительно друг друга. Но это уже было показано ранее в 11.05.2021.

Если дверной проём двигается вокруг неподвижного объекта, то точно так же порталы могут двигаться вокруг объекта не придавая ему скорости.

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

#3.06.2021

Источник: tg/453, tg/454, tg/455, tg/456 (108 💬), tg/457.

По поводу прошлой сцены у читателей возник вопрос по поводу того что если один портал будет двигаться ускоренно (например, вращаться), а другой - нет? Как себя будет вести телепортированный объект? Ибо с неускоренным движением всё понятно, я уже это показывал в 11.05.2021, там объект двигается согласно Первому Закону Ньютона - равномерно и прямолинейно.

У меня есть два варианта развития событий с ускоренными порталами: дальнодействие и не-дальнодействие. Лучше будет понять на анимациях.

Я считаю что не-дальнодействие - правильный вариант, но может у вас есть свои аргументы, приглашаю в комментарии обсудить это!

Ссылка на сцену.

#²Дальнодействие

Дальнодействие. Тут оранжевый портал двигаем мы, но вот объект стоит неподвижно, и портал его поглощает. Если смотреть в оранжевый портал, то объект там так и продолжает стоять на месте, а если смотреть из синего, то объект вращается без действия всяких сил. Дальнодействие!

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

#²Не-дальнодействие

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

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

#²Опрос

×1.2
png

#4.06.2021

Источник: tg/458 (7 💬), tg/459.

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

Ссылка на сцену в веб-демке: https://optozorax.github.io/portal/?scene=cut_plane

Можно определить телепортацию так: всё что полностью вошло в портал, отправляется на другую сторону портала.

Тогда чтобы понять что происходит с объектом, частично вошедшим в портал, необходимо разбить этот процесс на дискретные шаги.

Здесь имеется шаг Δt, за время этого шага часть объекта входит в портал, а часть не входит. Тогда последовательность действий следующая:

• Сначала надо определить где нужно разрезать объект так чтобы одна часть полностью вошла в портал, а другая нет.
• Затем обрезать его
• Затем телепортировать обрезанную часть.
• И далее можно двигать всё до конца шага.
• Повторять итеративно.

#6.06.2021

Источник: tg/460, tg/461, tg/462, tg/463.

Сцена про разрезание объекта порталами была нужна больше для того что будет показано сейчас.

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

Вот так это выглядит в сцене про две пары.

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

Вот так под капотом работает сложная телепортация.

И это важно понимать, ведь когда портал входит в портал, с ним происходит то же самое, но сложнее. На этой картинке красный портал входит одновременно в другой красный и в другой зелёный.

#12.06.2021

Источник: tg/469 (21 💬), tg/471.

Обновил визуальный стиль:

• Шахматная текстура теперь менее контрастная
• По краям порталов теперь есть чёрная обводка, чтобы чтобы они лучше отделялись от фона
• Добавил антиалиазинг, поэтому прога работает в 4 раза медленней, выключить его можно в меню «Rendering options».

Первая картинка - было.

Вторая картина - стало.

#14.07.2021

Источник: tg/473 (48 💬).

Наконец-то я сделал это видео, приятного просмотра!

#22.07.2021

Источник: tg/474, tg/475 (7 💬), tg/476, tg/477 (14 💬).

#²Как я сделал это видео

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

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

Для начала я создал список необходимых объясняющих сцен и сделал их, а потом написал в этот канал с объявлением что я начал работать над видео (11.05.2021). Как я потом понял, я описал эти сцены слишком подробно, ибо в видео я им дам очень мало экранного времени и не смогу их так подробно объяснить.

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

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

Первое время план не пошёл: я очень хорошо расписал начало и конец, а середина не клеилась (я уже писал об этом в 31.05.2021). Пришлось придумать и создать новые сцены.

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

Я начал смотреть кучу видео-уроков про Shotcut, в котором работал поначалу. Я выбрал именно его, потому что он бесплатный, а я весь такой за бесплатный софт. С горем пополам сделал в нём три первые минуты видео и понял что в нём работать отвратительно, что он тормозит и вообще у него ужасный интерфейс. А ещё я понял что из моего видео надо выбросить очень много всего (я выбросил подробное объяснение что такое портал и что он не равен червоточине), и я лучше понял как надо работать с планом, чтобы он подходил под реалии видео, перелопатил его почти полностью, попереносил кучу всего.

Эти три минуты я озвучил на телефон и звук был ужасен. Его обязательно надо было менять, иначе делать видео будет невозможно. Мне нужен хороший микрофон. Onigiri говорил что первые видео он начинал с петлички BOYA M1-BY, которая стоит ~800р. Я последовал его примеру и купил её. И да, это видео было сделано именно на этой петличке. Я вставлял её в телефон и записывал на диктофон, а потом скидывал на комп (напрямую в комп было очень много помех). Звуком я очень доволен, по крайней мере для первого видео это лучше всего. Спасибо Onigiri за такой совет, ибо с этим Виталием Головановым у меня в голове сложилась картинка что работать можно только с аудиокартой и большим микрофоном за много денег.

Я забил на бесплатность, стал взрослым человеком, установил винду и взял Premiere Pro. В нём конечно работать было намного приятнее и заметно эффективней чем в Shotcut.

Далее идёт очень долгий процесс делания видео, после которого я получил 17 минут материала. Лень рассказывать и вспоминать что там было, так что опустим эту часть (хаха, саму эссенцию опустим, молодец илья).

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

Со вторым горем пополам я перезаписал весь звук, перемонтировал всё видео, доснял к нему много нового видео-материала. И видео отправилось на второе ревью к @vsevolodpl, правда после него я ничего делать не стал (уже сдох), да и получил мало критики, так что забил болт.

Теперь настала пора публикации. Я подумал что нельзя так просто публиковаться на русском, я же мечтал ещё на английском языке. Теперь меня блочили ещё английские субтитры. С горем пополам их сделал, а затем прогнал через Grammarly, исправив все возможные ошибки. Кстати, спасибо hirrolot.github.io за помощь в этом деле. Мой английский очень плох, но один англоговорящий чел в твиттере сказал что субтитры ему понравились, так что ладно.

Значит текст был готов, осталось только наложить субтитры на видео. Я раньше уже их накладывал, и в интерфейсе ютуба это, мягко говоря, неудобно, поэтому я погуглил можно ли накладывать субтитры прямо в Premiere Pro, и оказалось что можно.

Сначала я наложил русские субтитры, и это был ад. Чтобы отсубтитрить 10 минут видео, текстом который ты уже имеешь, нужно непрерывно монотонно ЧАС работать и не отвлекаться. Это реально смертельная работа, копипастить этот текст и выравнивать его под аудио. Я боялся того что меня ждало при наложении английских субтитров.

Но тут хвала небесам, я накладывал английские субтитры поверх русских, и этот процесс происходил в 1.7 раз быстрее (я замерял!), потому что не надо слушать аудио. Боюсь представить сколько бы у меня заняло отсубтитрование английских сабов без русских, сколько бы я потратил времени на чтение английского текста и слушание русского войса, чтобы подравнять их нормально.

Ну а потом ещё куча часов рендеринга и 5 часов ожидание загрузки видео итд. Но это несущественно по сравнению со всем остальным.

В общем создание этого видео кратко можно описать так тремя словами: очень много работы.

Кстати, fun fact: чистого наговоренного текста вышло 23к символов, а длина видео 24 минуты, так что вот вам эмпирические данные о том как узнать итоговую длину видео по плану без монтажа.

#²Что я думаю по поводу создания этого видео

Делать видео очень сложно. Теперь я понимаю что видеоблоггерство - не очень простое занятие, и весь этот монтаж, озвучка и куча всего ещё — это невероятный труд. И когда я смотрю как Стас разоблачает Топлеса, я не могу видеть разоблачение, я вижу только 40 минут очень сложного монтажа. Как Стас это делает, я не представляю.

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

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

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

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

#²Психологический эффект

Как я уже говорил, я мечтал сделать именно это видео ещё 2 года назад. И щас я его наконец сделал, казалось бы я закрыл целый гештальт, я должен быть счастлив, но в момент публикации я не почувствовал ничего. И сейчас я не чувствую ничего. Если подумать, то так происходит всегда когда я что-то делаю. От предвкушения получается удовольствия больше, чем от процесса или результата. Может это не нормально и надо прорабатывать с психологом.

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