HLFX.Ru Forum - Блог разработчика

Страницы (23): « Первая ... « 14 15 16 17 [18] 19 20 21 22 » ... Последняя »
Показать все 334 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Paranoia 2:Savior (https://hlfx.ru/forum/forumdisplay.php?forumid=38)
-- Блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5236)

Отправлено ncuxonaT 22-06-2019 в 12:55:

Дядя Миша то есть просто проекция на одну из координатных плоскостей в зависимости от нормали?

Цитата:

Дядя Миша писал:
Ты же говорил, что как в Last Of Us. А это совсем другая статья.

Да то же самое. Только тут с кодом.

Отправлено Дядя Миша 22-06-2019 в 13:21:

Цитата:

ncuxonaT писал:
то есть просто проекция на одну из координатных плоскостей в зависимости от нормали?

ну да. Загляни в код ку3. Кстати там есть в компиляторе реализация радиосити, которую никто никогда не юзал. А я вот сегодня посмотрел и там тоже какая-то убиралка швов присутствует, интересно. Может быть тоже типа той что ты дал, я не углублялся.

Теперь самое интересное. Я могу посчитать радиосити для солнца. Потому что от солнца вторичка считается трассировкой по полусфере. Просто в нормальном режиме этот результат сохраняется в патчи, а я его сразу запишу в лайтмапу. Конечно это это не полноценное радиосити, всего одно переотражение и только от солнца. Но я так рассуждаю. Во первых в сталкере оно всё равно точно так же - одно по полусфере, а во вторых я там не припомню радиосити от остальных источников. Хотя может и были, не присматривался. Но у нас-то всё равно ЧАЭС на открытом воздухе. Так что будет норм. И без глобальных переделок компилятора.

Добавлено 22-06-2019 в 16:21:

Ну а потом подключу ландшафт, рассажу траву и настанет полный рот-фронт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-06-2019 в 05:52:

Психопат всё интерисовался насчёт консвервативной растеризации, отвечаю как я разрешил эту задачку. Правда тут надо учесть что для классического лайтбейкера некоторые вещи неактуальны, но всё же.
Как я уже и говорил, лайтмапа у нас в любом случае квад или прямоугольник, потому что картинка. Размеры вычисляются вписанием треугольника в ббокс. В идеальном случае (брашы) у нас квадратный полигон соответствует квадратной лайтмапе. Но в случае моделей естественно так не получается. Зато каждому трианглу всегда соответствует обратный и мы в принципе можем посчитать лайтмапу для их суммы, но в моём случае это нереализуемо, поскольку лайтмапа хранится не в атласе, а в виде raw-массива. То есть с избыточностью данных придется смириться. Вторая проблема очевидно - для пары трианглов образующих квад с высокой долей вероятности будет выделена идентичная по размерам лайтмапа и свет придется посчитать для каждой. Что автоматически означает двойную бессмысленную работу. Наиболее характерный пример - тот самый вагончик. Если бы я уменьшил лайтмапу в движке до 256х256, то вы бы увидели в атласе (r_showlightmaps), что вот та тень с окошками на полу присутствует в двух экземплярах, для одного и второго триангла пола соответственно. Оно конечно и на большой лайтмапе видно, но там глаза сломаешь. Это конечно не дело. Код подготовки лайтмапы к рассчёту имеет встроенные средства для отсечения лишних точек - массив occluded. То есть неважно по какой причине точка стала невалидной, нам важно что для нее свет не будет считаться. В самой халфе идёт проверка на попадение люкселя в солидный лиф, но как легко догадаться на карте из одних моделей это бессмыленное условие. У моделей нет никаких лифов и вообще нет дерева. Проще всего проверить границы треугольника построением барицентрических координат и проверкой на выход из их границ. Собственно это я и сделал. Второй положительный момент - барицентрические значения можно использовать для лерпинга нормалей и получения сглаженной фонг-нормали. При таком подходе скорость работы вырастает вдвое, однако, поскольку мы отсекаем пиксели по краям треугольника, легко догадаться что эти самые края обведутся чёрной каёмкой. Причём чем меньше разрешение лайтмапы - тем больше эта каёмка. Для борьбы с этим тоже есть два метода. Во первых старый вариант из кутри - найти у occluded-пикселей 9 соседей и взять с них значения по average. Размер фильтра невелик, поэтому оно почти всегда даёт идеальные результаты. Но легкая "тень" от шва всё равно еще может присутствовать. Второе решение - эмпирическое ввести вокруг трианглао охранный бордюр. Барицентрика имеет в виду границы менее ноля и более еденицы. Вот к ним и надо прибавить наш борюдр. Обычно это значения от 0.1 до 0.5. Чем выше значение - тем меньше вероятность артфектов и тем меньше выигрыш по скорости, потому что мы опять начинаем считать потенциально невидимые люксели.
Впрочем даже со значением бордюра 0.5 у нас двухкратный прирост по скорости (а со значением 0.0 - трёхкратный). Если надо, я может потом скриншотами проиллюстрирую.
Так же выяснилось что китайский блур для трианглов абсолютно не годится, он провоцирует на них швы. Его конечно можно заменить на обычный box 4x4, но вы же понимаете, что это придется лайтмапу увеличить вдвое, а значит и время работы возрастёт во столько же. Блур китайский тем и хорош, что там нет линейного увеличения размера от фактора.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-06-2019 в 10:19:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-06-2019 в 16:06:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 23-06-2019 в 16:08:

Дядя Миша я сначала тоже так делал, чтобы значение "occluded" пикселей бралось из соседних, но это не работает, если соседних нет. Какой-нибудь тонкий треугольник вообще не имеет нормальных пикселей, все "occluded", и пока, освещение брать неоткуда.
Вариант с барицентрическими координатами непредсказуемый. Непонятно, с каким коэффициентом их надо пячить, чтобы гарантировано покрыть граничные пиксели.

Сейчас сделал второй вариант отсюда, на первых тестах результат хороший.

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

Отправлено XaeroX 23-06-2019 в 16:28:

Цитата:

Дядя Миша писал:
Элбер смог добавить на карту воду в отстойники, лестницы, Сидоровича и сталкеров.

Ландшафт нормальный давайте делайте. А то пазорище какое-то размытое.

__________________

Отправлено Дядя Миша 23-06-2019 в 17:51:

Цитата:

ncuxonaT писал:
я сначала тоже так делал, чтобы значение "occluded" пикселей бралось из соседних, но это не работает, если соседних нет

Я не знаю, какие там у тебя конкретно проблемы на GPU, но я могу продолжать лайтмапу вовне треугольника на любой размер абсолютно. То есть я могу аллокнуть лайтмапу, в которую вписан треугольник + охранный ряд люкселей. Или два ряда. Потому что люксели считаются просто для определённой точки в пространстве, которые совпадают с плоскостью треугольника. Если я во время этого действа залезу на соседа - отлично. Значит там всё будет гладенько. Поэтому я и говорю, что у меня проблема не стоит на CPU.

Цитата:

ncuxonaT писал:
Какой-нибудь тонкий треугольник вообще не имеет нормальных пикселей, все "occluded"

тонкий в смысле мелкий? А то треугольники все одной толжены.

Цитата:

XaeroX писал:
Ландшафт нормальный давайте делайте.

Вывези ваську

Ты НЕ ВЫВОЗИШ!

Добавлено 23-06-2019 в 20:04:

Цитата:

ncuxonaT писал:
Сейчас сделал второй вариант отсюда, на первых тестах результат хороший.

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

Добавлено 23-06-2019 в 20:51:

Ну вот. Еще не идеал, но показать уже не стыдно:

Время рассчётов: 1 hour, 33 minutes, 14 seconds elapsed
Продолжаю эксперименты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 23-06-2019 в 17:57:

Цитата:

Дядя Миша писал:
Потому что люксели считаются просто для определённой точки в пространстве, которые совпадают с плоскостью треугольника.

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

Цитата:

Дядя Миша писал:
тонкий в смысле мелкий? А то треугольники все одной толжены.

Ну да, мелкий или узкий.

Цитата:

Дядя Миша писал:
Я пока што не могу понять что они там делают в вертексном шейдере.

Я тоже не понял, поэтому предрассчитываю все эти точки на ЦПУ, а потом рендерю как GL_POINTS.

Отправлено Crystallize 23-06-2019 в 18:01:

Цитата:

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

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

Отправлено Дядя Миша 23-06-2019 в 18:13:

Цитата:

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

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

Цитата:

ncuxonaT писал:
Сосед же не обязательно лежит в той же плоскости.

Если в той же - будет отлично. Если в другой - не будет сглаживания.

Цитата:

ncuxonaT писал:
а потом рендерю как GL_POINTS.

А не медленно?

Цитата:

Crystallize писал:
А если обработать модель так же как компилятор обрабатывает исходник карты, т.е. собрать и отвизить внутренности чтобы выяснить какие группы треугольников-соседние, а какие-нет?

Ну вот Ксерокс скоро на Волатиле это и покажет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 23-06-2019 в 18:15:

Цитата:

Дядя Миша писал:
Ну вот Ксерокс скоро на Волатиле это и покажет.

Как я тебе это покажу, если вертексы должны формировать конвексный браш? А в моделях обычно всякая непотребщина творится.

__________________

Отправлено Дядя Миша 23-06-2019 в 18:29:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 23-06-2019 в 19:44:

Цитата:

Дядя Миша писал:
Нет, я же говорю, я от барицентрика оставляю зазор и получается что-то типа консервативной растеризацыы.

Цитата:

Дядя Миша писал:
Если в той же - будет отлично. Если в другой - не будет сглаживания.

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

Цитата:

Дядя Миша писал:
А не медленно?

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

Отправлено Дядя Миша 23-06-2019 в 20:31:

Цитата:

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

второе да.

Ну чтож, досчиталось:

Как вы уже наверное догадались - на этом уже можно было и остановиться, но ничего подобного. Элбер мне докинул недостающие детали этой карты, суммарным весом еще на 700 тысяч полигонов %)

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Временная зона GMT. Текущее время 07:25.

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024