nemyax писал: Сравнивать у вершин сразу x, y, z, u, v.
Индексацией вертексов занимается BSP, который оперирует двойной точностью, лайтмаппер одинарной. Мне нет нужды сравнивать их координаты, я сравниваю сразу их индексы.
Цитата:
nemyax писал: Можно перегнать треугольники в структуру данных, которая оперирует смежностью
да я просто построил bordering-матрицу для смежных рёбер, рекурсивно.
Это очень просто и быстро. Чем-то виз напоминает
Добавлено 04-07-2020 в 17:18:
Лайтмаппер к слову полностью самописный, на тех принципах, на которых я его делаю, мне просто неоткуда взять код, такого нигде нет.
Добавлено 04-07-2020 в 19:23:
Давайте расскажу вам принцип работы лайтмаппера на CPU. Ничего особенного сложного в целом там нет, дьявол кроется в деталях реализации.
И если реализация делает что-то не то - полезут швы. Швы это неизбежное зло лайтмаппинга, потому что освещение низкого разрешения, как правило. Если считать в полном, то швов практически не бывает, но это слишком долго, там смысл теряется. Лайтмапы-то размытые, приятные глазу.
Для выделенного сурфейса делается проекция в 2д, эта проекция у нас будет соответствовать нашей лайтмапе. Разумеется. предпочитительнее делать квадрат или прямоугольник, чтобы не было швов на стыке треугольников, да и экономнее во всех смыслах. Далее, для этой плоскости выделяются два массива векторов. Первый массив - это точки, второй - цвета лайтмапы. Можно еще и третий - делюкс-векторы или еще какую-нибудь инфу, типа теней. Принцип понятен. Самое главное зло лайтмап - это вот эти точки. Это как бы переходное пространство из 3д в 2д. Позиции точки в массиве соответствует точно такой же пиксель яркости лайтмапы.
Сами точки должны быть спроецированы на плоскость в 3д. Собственно на этом этапе и начинается всякая чертовищна. Почему она происходит?
1. полигон неаксиальный, из-за конечной точности флоата, часть точек может оказаться за полигоном. И трасса естественно туда не достанет и пиксель станет чёрным. Это бы конечно не проблема, если бы лайтмапы считались в полном разрешении, но точки-то гигантские! Вот эта чернота и залезет на соседа, появится шов-не шов, но пятно, переходящее в черноту.
2. полигон сложной формы, опять таки часть точек на него не попадает, но те, которые заденут хоть краешком - здрасти приехали. С подобными вещами хорошо бороться консервативной растеризацией, насколько это понятие вообще применимо к лайтмаппингу. Или взять срнедневзвешенные значения с девяти соседей (так ку3 поступает).
3. полигон размером меньше одного люкселя! В q3map2 додумались такие полики аппроксимировать повертексным освещением, ну кстати неплохое решение, вполне.
4. швы в основном вылазят, если считать лайтмапу не в родном разрешении. Почему так происходит? Благие намерения. Сделаем разрешение в 2-4 раза больше, чтобы точки на поверхность легли более точно. И посчитаем для них лайтмапу. Прекрасно. Теперь начинается самая чертовщина - мы скейлим нашу лайтмапу обратно вниз. Так вот можете себе представить, что алгоритмов, которые бы эффективно и средневзвешенно это сделали таким образом, чтобы пограничные света у соседних полигонов совпали - в приоде не существует. Причём, дело похоже даже совсем не в алгоритме, просто ресемпл идёт изолоировано для каждого полигона, но при этом учитывает яркость своих соседей. Вот на соседнем полигоне в центре темнее, а на первом - светлее. Лайтмапу с обоих полигонов ресемплили. И так получилось, что края, где они соприкасаются - тоже получились разной яркости. Причём разница там может быть порядка нескольких едениц. ну скажем 233 233 233 и 240 240 240. Выглядит это именно как шов. Хотя если эти картинки показать вам по отдельности, каждый скажет, что на них одинаковый оттенок.
Психопат рассказывал про какой-то алгоритм, который эти швы замазывает, но помоему он сам домазался до того, что убил всё освещение своими замазками. Впрочем и китаец делал нечто подобное с похожим результатом.
5. теоретически швы могут вылезать еще из-за особенностей билинейной фильтрации, но тут я пока не готов рассказать как это происходит и надеюсь, мне не придётся с этим столкнуться. Главное не скейлить полигоны с лайтмапами, поидее получится тоже самое что и с буквами, если нет охранного бордюра.
Ну вот, теперь когда мы разобрались с точками, дальше мы получаем прямой свет. Это очень просто - по стандартной формуле освещения, получаем освещённость нашей точки, перебирая все лампочки, которые наставил дизайнер. Это очень быстрый способ лайтмаппинга и на геймдеве его даже используют для рассчётов при старте приложения. Ну потому что очень быстро. Но, как вы наверное уже догадались, нам будет кое-чего нехватать. А именно теней. За тени у нас отвечает быстрая трасса. Пускаем трассу между лампочкой и нашей точкой, если прошла без помех - собираем свет от этой лампочки. Вроде почти так же просто, если не углубляться в дебри того как работает трасса Но мы и не будем.
Повертексное освещение устроено аналогично, только вместо на лайтмапе точек - сразу вертексы. Аналогично устроен и лайтгрид\лайтпробы. Единственное, нам нужно придумать как именно располагать наши пробы - регулярная сетка, нерегулярная, ну вообщем тут фантазия неограничена, равно как и то, что мы туда будем записывать.
Про индирект расскажу в другой раз, когда до него доберусь. А пока что моя задача - вот как раз генерация этих долбаных точек. К слову, при разработке NT я активно юзаю визуальную отладку, прямо почти для всего. Вот и сейчас, планирую, столь масштабную задачку, как генерацию этих точек визуализировать в pts-файл. Правда рисовать их буду не партиклями, а через VBO, а то чёт тормозно.
Добавлено 04-07-2020 в 21:50:
Визуализировал точки для простейшего случая.
Но есть группы, в которых якобы одна общая нормаль,а на самом деле это террейн. Там придётся искать пересечение с реальной поверхностью.
ну это уже потом, теперь надо атлас построить.
Дядя Миша писал: Психопат рассказывал про какой-то алгоритм, который эти швы замазывает, но помоему он сам домазался до того, что убил всё освещение своими замазками.
-seam_quality n - Качество удаления швов. Больше - лучше. По умолчанию n = 100.
Zopa! Это чтожы для каждой карты вручную подбирать параметр?
Добавлено 05-07-2020 в 13:44:
А вот как выглядят точки для Non-planar поверхности. Понятное дело, что так их использовать нельзя - надо сделать локальную трассу по средневзвешенной нормали и найти пересечение с ближайшей плоскостью.
thambs это у которой полигоны лежат не на одной плоскости.
Ну вот эти горы на картинке фактически - один меш, рисуются за один вызов, все треугольник пошарены друг с другом. Реально наложить одну лайтмапу на все разом. Это наилучшее решение проблемы швов и пятен.
Добавлено 05-07-2020 в 18:39:
Да, грасс_тест поидее тоже превратится в одну сплошную поверхность, но я его давно уже не собирал, надо будет проверить.
Дядя Миша писал:
Надеюсь вам всё это интересно, а то пишу-пишу, никто не камментит.
Никто не пони-мает о чем речь рискну предположить. А это чо, ландшафты какие были в играх вот старых? Полигонов не видать.
Добавлено 06-07-2020 в 09:31:
А вообще вон total tris. Ну, раз такие пироги то и вопрос: помнится была игра такая - Z.A.R. Называется. Там вот как раз пиксельные ландшафты были. А если им например разрешение увеличить и сглаживание по горизонту добавить, чо будет? Но там, правда, и монстры и оружие спрайтовые были.
Почему на скринах оно полосатое? И планируется ли решить вопрос бензиновых разводов на лайтмапах?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!