Пля, ты от Crystallize штоле заразился?
Портал - это окно, дырка в стене. Дырка может быть ориентирована?
Как часто ты ориентируешь дырки?
Цитата:
KiQ писал: а то что-то я так до конца так и не въехал в их концепцию
Вот очень хорошая картинка с сайта Фабиана
Проёмы - это порталы. Порталы принадлежат той или иной области. Если не виден портал, значит не видна и вся область. Разумеется область должна быть герметично закупорена, т.е. любой выход из нее должен быть закрыт порталом. Но если это не так, портал флоу просто затечёт обратно и область не будет разбита на две. Технически это даже не ошибка, хотя наверное имеет смысл выдавать предупреждение.
Цитата:
thambs писал: Скажи, а портал может только в одну сторону просматриваться в целях оптимизации?
Порталы и так смотрят в одну сторону, их обычно по две штуки ставят, один туда, другой обратно.
Добавлено 08-05-2020 в 20:40:
Кстати говоря, в Сорсе тоже баловались с такими порталами, но без разрезания всей геометрии, толку от того немного.
Дядя Миша писал: Портал - это окно, дырка в стене. Дырка может быть ориентирована?
Как часто ты ориентируешь дырки?
Цитата:
Дядя Миша писал: Порталы и так смотрят в одну сторону, их обычно по две штуки ставят, один туда, другой обратно.
Неловко вышло.
Если у стенки была некая нормаль и мы проделали дырку в стенке, то у дырки будет та же самая нормаль, так?
Я к чем у заговорил про возможность ориентации порталов, я-то их по твоим скриншотам представлял как браш, и соответственно поэтому сначала предложил пускать из них трейсы вперёд и назад для детекции ниш. Но в связи с твоим недоумением я подумал-а мало ли что, может быть к порталу не применимы термины вперёд и назад, может быть у него и ориентации-то не бывает и нельзя различить перед и бок?
Crystallize писал: то у дырки будет та же самая нормаль, так?
Нормаль, у дырки? Здоров ли ты сегодня?
Вообще говоря нам достаточно ректангла в 2д. Вся эта замута с нормалями - это другой способ оптимизации, оно необязательное, их так просто легче контролировать.
Цитата:
Crystallize писал: представлял как браш
портал - одна из сторон браша. ну как хинт-браш, у которого остальные стороны покрыты скипом. С точки зрения дизайнера.
Продолжим. Здесь пожалуй уместно сделать небольшое историческое отступление. Так любопытно получилось, что в первом дууме и в третьем - по одному компиляторы и принципы построения уровня в чём-то схожи. Там - секторы, тут арии. И там и там они могут быть какой угодно формы, неконвексные. Это же свойство активно используется для распространения звуковых волн в игре. Правда на этом сходство как бы и кончается.
В первом дууме секторы - это геометрия с одинаковой высотой пола и потолка. Любой алгоритм ведь строится на допущениях, как только они перестают отвечать нашим требованиям - всё рушится. Естествено что в квейке мы уже не могли разделять пространство на секторы с разной высотой пола, можете себе представить сколько было бы секторов в таком случае. В принципе надо признать, что PVS, он изначально делался именно под уровни первого квейка и именно в контексте этих зловещих колидоров он работал оптимально. Уже в ку2 с этим начались проблемы, в ку3 пришлось довольно многое поменять, а в д3 и вовсе отказаться от такого подхода. Итак, в д3 фактически произошёл возврат к секторам, но на качественно новом уровне. Сектор\ария это выделенный пользователем кусок уровня, который рисуется за один раз. Ничего страшного при этом не происходит - невидимые части отсекаются на видеокарте. С одной стороны такой подход может резко влиять на фпс при смене секторов (вспомним недавние жалобы на Волатилу, что открытие дверей резко роняет фпс), с другой стороны - это целиком и полностью контролируется пользователем, в отличие от тех же хинтбрашей, которые лишь подсказки доброй воли. Т.е. пользователь может поделить уровень на куски таким образом, чтобы каждый новый кусок попавший в видимость не слишком сильно ронял фпс. Опять таки на открытом пространстве не придётся ждать бесполезную работу по обсчёту видимости.
Как же устроены эти арии? В сущности они уже были во втором квейке, да. Но! Всё это время они использовались как надстройка над обычным PVS. Сам виз их игнорировал кстати. Это был просто еще один слой абстракции - такой толстый-претолстый пвс, который мог выключить разом из видимости целую область. По команде от закрытой двери. Но обычный PVS работал классическим образом - всё так же отсекая по одному-два полигончика где-нибудь там. То есть херово работал, если честно. Виз очень сильно завязан на разбиение деревом, а дерево строится не учитывая вообще никакой виз, его больше волнует конвексность пространства. Можно сортировать плоскости по аксиальности, делать эти разрубы каждые 1024 юнита, но факт остается фактом - добавление нового маленького брашика, может полностью перебалансировать вашу систему виз. Но из-за высокой дискретности разбиения пространства это в сущности мало кто замечал. Чтобы добится большей предиктабельности вот как раз и ввели эти хинты. Только они все равно не гарантируют ничего по сути. Фактически они работают как виз порталы с негарантированным результатом. Может станет лучше, а может и не станет. Вообщем на сегодняшний день это действительно несеръезно. Но повторюсь, PVS как концепция дико удобен, от него очень нехочется отказываться.
Чтоже было сделано в D3. Простая и в то же время гениальная вещь. Как я говорил, у нас было три слоя абстракции - сперва видимость считалась по лифам. Потом по кластерам и наконец по ариям. В ку1 были только лифы. В ку2 добавились кластеры для игнорирования детайл-брашей (но при этом детайл-брашы не были детальными - они не текли (т.е. из них можно было делать уровень), они разбивали другие браши) и арии для выключения дверей. В ку3 концепцию еще более углубили - теперь ареапорталы стали такими же брашами и появилась возможность их расставлять для блокирования видимости. Ну или хотя бы просто для группировки объектах в разных ариях. Но не было сделано самого главного - видимые сурфейсы никак не были привязаны к этим самым ариям. Связь была очень условная, особено в ку3 где полигоны могли одновременно принадлежать нескольким лифам, а лифы в свою очередь - разным ариям. То есть не было вот этой чёткости, когда мы могли рисовать одну арию и точно знать, что всё, что к ней относится - больше ни к чему не принадлежит. Что же для этого надо сделать? Ну очевидно покромсать геометрию по кромкам самой арии? А как это сделать, ария это больше виртуальное понятие - номер в ноде. Плюс у нас геометрия и так уже покромсана BSP-деревом.
И вот тут начинается самое любопытное. Во первых, дерево, где ноды принадлежат разным ариям позволяет очень точно раскромсать уровень на арии ПРОИЗВОЛЬНОЙ ФОРМЫ. Причём эта самая форма задается лишь расставленными порталами. Не надо, как в иных движках заключать её в браши-объемы, достаточно лишь ограничить порталами. К тому же FloodAreas отследит, было ли реальное разделение на несколько арий, ну если вы к примеру поставили ареапортал в чистом поле. Но важный момент - геометрия кромсается вся, не только брашы, но и патчи и тримодели. Впрочем это можно запретить (в том же D3 флаг discrete например для автоспрайтов или зеркал). После того как всё покромсано соответствующими нодами - начинается самое любопытное. Геометрия начинает склеиваться обратно в большие батчи по типу материала.
Таким образом, каждая ария у нас представляет некоторый аналог студиомодели с точки зрения отрисовки - удалены лишние треугольники, всё стрипифицировано и сгруппировано по материалам, а поскольку в одной арии возможно не так уж и много материалов, то и соответственно батчей тоже немного. Правда сам механизм определения видимости чуть тяжелее, чем классический кушный. Но это компенсируется лёгкостью отрисовки. Есть и еще один неочевидный плюс такого подхода. Теперь при помощи таких порталов очень легко задавать туманные области. Ограничиваем вход-выход, их может быть сколько угодно. Если это небольшое углубление - ставим портал, вот вам и вода с туманчегом. Ну или просто вода. Сам виз в его классическом представлении тоже остается, но строится он уже на учете пользовательских ареапорталов и арий. А поскольку их смешное кол-во (в тоже д3 в среднем штук 40-50), считается такой виз от силы 5-10 милисекунд. Становится возможным включить его прямо внутри BSP (а в д3 оно вообще при загрузки карты считалось каждый раз, но это глупость конечно).
Вообщем это весьма перспективный и не утративший своей актуальности подход. Он ведь позволяет эффективно рассчитать и течение света сквозь порталы в реалтайме. И решить эту проклятую проблему с солнцем, которую кстати не решили в сталкере и не факт что решили в метро. Вот возьмем сталкеровский НИИ Агпропром. Там есть такой спуск потземлю. В оригинале его сделали отдельным уровне. В LostAlpha сделали частью общей карты, но когда ты спускаешься вниз, то прямо видно как гаснет солнце. Очевидно они не смогли эффективно отделить верх от низа. С системой порталов это вообще не представляет никакой проблемы. На входе в подземелье ставим один портал, на выходе - другой. Между порталами - шахта с лестницей. Дальше солнце просто определяет видимость - оно может осветить условно арию 0 (аутдор), немного арию 1 (шахту с лестницей) ну и собственно всё - до подземелья лучи уже не добивают. К тому же мы можем эффективно оптимизировать и аутдоры тоже, причём в автоматическом режиме - здесь нам на помощь приходит то самое авторазбиение на квадраты в BSP. Лепим эти арии, каждые 1024 юнита. Ну и дальше ограничиваем видимость либо туманом либо классически по фрустуму.
(продолжение следует)
Добавлено 09-05-2020 в 15:34:
Цитата:
Дядя Миша писал: Становится возможным включить его прямо внутри BSP
Возможно кто-то это истрактует неправильно, я имел в виду, что код рассчёта видимости можно объеденить с компилятором BSP, нет больше смысла выносить в отдельную тулзу.
Добавлено 09-05-2020 в 15:36:
Кстати еще любопытный момент (но это неточно), склееная геометрия с удалёнными лишними вертексами и шареными ребёрами скорее всего позволит более эффективно накладывать лайтмапы. Т.е. разом на развертку, вместо того чтобы выделять куски под каждый полигончик.
thambs типа того. Но насчёт лайтмаппера я пока не знаю, он вероятно будет необязательным. Сделать его надо просто для референса, чтобы сравнивать запечённое освещение с реалтаймом.
Добавлено 09-05-2020 в 18:48:
Вообще BSP компилятор будет очень эпичным. Вероятно ни в одном движке больше не будет такого тяжёлого препроцессинга геометрии как у меня.
CSG по брашам, CSG по сурфейсам, разрезание по дереву, разрезание по ариям, склеивание всего обратно с выкидыванием лишних ребёр, глобальный т-джунк. Но при всём при этом, вероятность выпадения полигонов будет минимальной или вовсе отсутствовать.
Давайте всё же в порядке очерёдности. Сейчас надо получить максимальный прирост производительности даже без PVS. У меня прогресс шёл следующим образом:
1. Новый движок с халфовским форматом (3%..5%) просто из-за отсутствия всякого мусора совместимости и видоизменённому игровому циклу.
2. Построение оптимизирующего виз-три для халфовского формата (10%..%400) к производительности.
3. переход на кутришный формат (200%..%600) к производительности.
Теперь вот финальная стадия оптимизации. Ну посмотрим. Старые форматы никуда не делись, будет с чем сравнивать.
Опробовал дуумтришные оптимизации-триаунгуляции. Ну что можно сказать?
Навскидку - очень неплохо. На том же сипульчере 180 тысяч полигонов собралось в 2500 сурфейсов. Фпс даже безо всякого виза - порядка 250.
И это при том, что там сейчас переходной период, я вообще себе смутно представляю что там рендерится, а что отсекается, я просто отправил эти батчи как MST_TRIANGLE. С другой стороны нельзя прямо сказать, что этот код показывает чудеса оптимизации. Ну что-то там удаляет конечно, факт.
Но всё равно имхо многовато треугольников остается. Зато здесь т-джунктион с хэшем - быстро работает. Сипульчер компилился 5-минут.
Вообще там код с явными ляпами, к примеру идёт прямое сравнение флоатов. Из-за чего постоянно лезут тучи варнингов. Заменил на эпсилоны - почти все ошибки исчезли. Странно это всё, как они с таким кодом вообще свой дуум собирали. Ну да ладно, смысл есть, а это главное.
Конечно там еще весьма много возни предстоит, как это всё запеределать и увязать с текущим форматом.