Дядя Миша как сложно с вашим радом. Тогда да, наверное, способ со хранением прямоугольников проще. Еще можно было бы искать по соприкасающимся ребрам на развертке. В таком случае лайтгруппы могли бы быть невыпуклыми. В смысле не надо было бы под лайтгруппу отдавать целый прямоугольник.
Переделал концепцию, как описано выше. Стало на порядок удобнее.
Во первых, реконструкция групп - очень быстрая, пару секунд буквально.
Во вторых, с учётом сделанных изменений, лайтмаппер вообще не модифицирует BSP, ему это просто не нужно. Только сами лайтмапы.
Правда остаётся еще вопрос с повертексным освещением, но прежде чем его решить, надо придумать что делать с дубликатами. Как им накладывать лайтмапу, как повертексное. Причём этот момент вообще самый сложный, надо очень многое продумать. Как это всё рисовать, как выполнять коллизию.
Добавлено 05-12-2020 в 13:37:
Единственное, с чем я лажанулся в своей концепции - исходил из того, что в атласе не может быть более 65к кусочков. А тут лайтмапы.
Не, ну для шрифтов и картинок худа это условие полностью выполнялось.
Хидер менять - это заново все шрифты и худ пересобирать. Ох, блин.
Добавлено 05-12-2020 в 13:37:
Ну да ладно, пособираю статистику, как часто происходит это превышение.
Добавлено 05-12-2020 в 14:25:
Что еще любопытно - я полагал что уменьшение размера вертекса хорошо уменьшит конечный размер BSP-файла. Но по факту снижение произошло всего на 1/6. Все эти дубликаты дают такой чудовищный размер.
Впрочем я неплохо оптимизировал компилятор по потреблению памяти и даже с таким негативным сценарием он отлично справляется, среднее потребление всего 700 мегабайт на сталкеровских картах.
Так я уже и лост-альфовские пробую.
Дядя Миша писал: Так я уже и лост-альфовские пробую.
А они сильно более детализированные, или только из-за размера сложнее? Я вот сейчас всё-таки прохожу 1.4007, и порой возникает желание дать по морде тому, кто некоторые из них так удлиннил. Кордон на севере, Свалка и Металлургическая Фабрика на юге имеют просто бесполезные кишки по 200-300 метров, где ничего нет. Локации в целом классные, если их поурезать и выбросить незанятое место, будет отлично.
Добавлено 05-12-2020 в 18:37:
Ах да, ещё Тёмная Лошина. Именно лошина (по состоянию души автора), потому что нормальному человеку не придёт в голову делать локацию-кишку, на которой всего несколько мест для посещения и дебильный километровый жд тоннель.
ncuxonaT кстати ты был частично прав, действительно запись кусков в лайтмапу занимает часть времени от построения атласа. 56 страниц 1024х1024 писались почти 2 минуты.
Добавлено 06-12-2020 в 11:16:
И да, я ради интереса перекроил этот механизм, выделил память под ноды одним большим куском. Сразу под все ноды. Кусок лайтмапы с бордюром занимает 3х3 пикселя, страница 1024х1024, значит выделяем (width / 3)* (height / 3) + 1 (корневая нода), около 17 мегабайт. Ну не фатально.
И время построения вообще не поменялось. Как было пару минут так и осталось. Значит рекурсия всё убивает.
Разобрался как в сталкере устроено освещение. Вообщем для солнца лайтмапа в явном виде не хранится. Оно и понятно, нужна смена времени суток. Хранится hemisperical lighting и теневая карта. Hemispherical годится для любого времени суток, а вот теневая карта, увы только для одного направления. Впрочем, я думаю, можно рассчитать тени для всех положений солнца. Освещение по полусфере получается от виртуальных hemi-источников. В q3map2 была настройка q3map_skyLight, вот это оно и есть.
Просто генерятся лайты с равномерным распределением в несколько сторон, по окружности, симулируя непрямой свет. Если на ландшафте, допустим стоял какой-нибудь столб, то на лайтмапе прямо видно эти нечёткие тени от разных направлений и их можно посчитать. Чем больше равномерно распределённых таких источников, тем более качественной получается hemi-лайтмапа. Ну и в шейдере всё это смешивается - цвет от солнца (деномический), умножить на теневую карт плюс индирект + амбиент.
Для точечных лайтов хранится просто RGB-мапа с запечённым индиректом.
Этот же подход объясняет как при такой угробищной схеме построения атласа практически не видно швов. Индирект равномерный и его переходы не видны. Прямой свет накладывается попиксельно. А тени редко попадают в стрёмные места. Остаётся еще свет в помещениях, но там во первых VPLS для радиосити, а во вторых, в большинстве помещений - пусто. Голые стены и немного предметов. Так что заметить швы нереально. Но мне конечно такой способ построения атласа не годится. У Микрософта есть UVAtlas какой-то, он раньше был частью DXSDK, но они апублековали сорцы. И вот все кто юзал DX с незапамятных времен его использовали для генерации. Помоему это одна из первых имплементаций LSCM (статья от 2002-го года). Конечно это занимает порядочно времени, но с другой стороны - это всё равно сохранится в статик-мешах моего формата. Так что пофиг. Один раз посчитать и всё.
А для брашей можно и мои hashed LM axis юзать, они хорошо спровляются.
ncuxonaT напомни как твоя затиралка швов работает.
Всю тему пересмотрел - не могу найти упоминания.
Единственное что нашёл, это про какой-то уровень качества, по дефолту равный 100.
ncuxonaT я делал немного по другому. Просто находил соседние эджы и биинтерполировал их люксели. А эджы находил вообще перебором, но поскольку меш индексированный, это было достаточно быстро. Но есть большая проблема. Для брашей это работает плохо из-за T-Junc.
А градиенты вообще можно применять изолировано.
Но использовать Conjugate Gradient Solver мне как-то в голову не пришло.
Да дело вообще не в солверах, я уверен. Дело в том, что я вероятно не понимаю истинной природы швов этих. К тому жы там как минимум два варианта может быть - несовпадение цветов люкселей и несовпадение их оригинов. И вторая проблема куда серъезнее. Вот у нас допустим пятно света. Переходит на два полигона. И на втором люксели сдвинуты относительно первых на половинку. Ну и всё - пятно со швом. И это уже никакими градиентами не поправишь.
Кстати, непомню кто, но кто-то авторитетный говорил - пофиг на повороты лайтмапы, главное чтобы не было швов. То есть, если у нас лайтмапа повернута даже на 45 градусов, то это ок. Но я не согласен. Повернутые люксели тоже выглядят как говно.
Цитата:
thambs писал: Эти сталкеровские карты как-то делятся (на сектора?) или это всё один огромный кусок геометрии?
Делятся, но без фанатизма. В отличие от BSP, который явно стремится нарезать геометрию по секущей плоскости, здесь просто идёт пространственная группировка для того чтобы отрисовать сразу побольше полигонов, если они оказались в одном месте. Ничего не режется, просто делится на группы. В группе от 64 до 4096 треугольников обычно. Потом, когда лайтмапа построена, их можно дополнительно смержить.
Добавлено 08-12-2020 в 09:18:
Цитата:
Дядя Миша писал: Для брашей это работает плохо из-за T-Junc.
Кстати первоначальный вариант нахождения групп искал не смежные рёбра, а просто коллинеарные. Надо наверное вернуть это повидение для брашей. Ну или второй вариант - построить T-Junc и они свяжут эти сурфейсы через себя. Заодно по швам на лайтмапе можно будет проверять качество их удаления.
Добавлено 08-12-2020 в 09:22:
А, да. Я жы всё-таки вчера опробовал LSCM. Линейный солверов в сети до чёрта, но они обычно идут в составе какой-то гигантской библиотеки, типа Eigen или OpenNL, и достать оттуда только то что надо, проблематично.
Но я нашёл старенькую OpenNL еще с реализацией солверов на шаблонах и подключил их. Ну что сказать? Наверное лыжы не едут.
Механихм рабочий, но качество разбивки отвратительное. Причём исходные значения текскордов солвер вообще мало волнуют. Я довольно много разных параметров там крутил и получал стабильно отвратительный результат.
Обычно вполне хорошую поверхность разрывает на 2-3 по случайному принципу. Не знаю, что ему надо. Надо будет еще попробовать нвидиевскую релизацию из Thekla_Atlas.
Добавлено 08-12-2020 в 09:29:
А, насчёт градиентов. В сталкере используется эффективный метод их применения и в тоже время очень простой. Там каждый люксель помечен маркером - было ли в него попадание. Даже не света или трассы, а просто - попал ли этот люксель в треугольник или хотя бы на его ребро. Ну а дальше Average Occluded Samples, по типу как в ку3 у Кармака, но хитрее.
Там задаётся уровень значений этого маркера. Если люксель строго попадает внутри геометрии, то у маркера значение 255. А у остальных градиентов - 254 и так далее по убывающей. То есть по сути это тоже СЛАУ, но весьма быстрое. Оно каждый раз ищет сумму люкселей с маркером выше чем у текущего, заглядывая в 8 соседей.
Этот эффект можно увидеть на лайтмапах в сталкере. Некоторые места этих лайтмап выглядят как нисходящий градиент в прямой угол. Я правда хз, надо ли было так заморачиваться, ведь достаточно одного сторожевого люкселя.
Добавлено 08-12-2020 в 11:22:
Вот к примеру львиная голова из кутри. Ну что это такое?
Технически это мало чем отличается от исходных текстурных координат.
Добавлено 08-12-2020 в 12:39:
У LSCM есть одна очень мерзкая особенность. Он на вход принимает уже готовую параметризацию и растягивает квадраты. Но если параметризация была выполнена с разбивкой на раздельные фейсы то адекватного результата дождаться не получится.
Вот с примером этого льва. Там на половинки текстура отзеркалена.
Результат соответствующий. Я могу конечно нагенерить абстрактные координаты, но вертексы от этого не станут смежными, поскольку текскорды не дают им это сделать.
Есть вариант с другой разбивкой, хранить текскорды в фейсе, а точки - отдельно, но это опять гонять объемы данных.
Вложение: lm_0006.bmp (48.1 кб)
Этот файл был скачан 41 раз.
Хех, ну чтож я оказался прав. Солверу критически важны входные данные.
Иными словами, если подать ему на вход уже существующую параметризацию в виду текстурных координат, то и на выходе мы получим ну примерно такие же текстурные координаты, только в профиль.
То есть впустую потратим время. Решение заключается в том, чтобы убрать из вертексов текстурные и лайтмапные координаты и перенести их в структуру фейса. Тогда мы сможем абсолютно точно подсчитать кол-во уникальных вертексов, сгенерить абстрактную проекцию в качестве начальной параметризации (просто выберем какой-нибудь произвольный угол или короткую сторону ббокс, это вообще плевать, солвер сам растянет квадраты правильно), и подать это на вход. И вот тогда у нас получится что-то нормальное. Вот такой симпатичный лёва у меня тепреь получился.
Вложение: lm_0007.bmp (48.1 кб)
Этот файл был скачан 47 раз.
Дядя Миша писал: И на втором люксели сдвинуты относительно первых на половинку. Ну и всё - пятно со швом. И это уже никакими градиентами не поправишь.
Поправишь. Градиенты замажут так, что видно не будет.
Цитата:
Дядя Миша писал: Кстати первоначальный вариант нахождения групп искал не смежные рёбра, а просто коллинеарные.
Я именно так и делаю. Тжунки не учитываю вообще.
Цитата:
Дядя Миша писал: А, насчёт градиентов. В сталкере используется эффективный метод их применения и в тоже время очень простой. Там каждый люксель помечен маркером - было ли в него попадание. Даже не света или трассы, а просто - попал ли этот люксель в треугольник или хотя бы на его ребро.
В методе с сопряженными градиентами это тоже учитывается. Люксели внутри треугольника имеют больший вес, чем наружние.
Цитата:
Дядя Миша писал: Вот такой симпатичный лёва у меня тепреь получился.
А что у симпатичного лёвы с искажениями и равномерностью?
| IP: 
03-12-2020 17:16
Вложение: 
