HLFX.Ru Forum Страницы (255): « Первая ... « 122 123 124 125 [126] 127 128 129 130 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)


Отправлено ncuxonaT 30-11-2020 в 15:19:

130 тысяч на страницу атласа 1024х1024? 3х3 пикселя куски? Из которых 8 пикселей - это бордюр? Такая себя развертка.
150к в атлас 8к у меня упаковались за 5 минут обычным и 45 секунд оптимизированным.


Отправлено Дядя Миша 30-11-2020 в 15:42:

Цитата:
ncuxonaT писал:
130 тысяч на страницу атласа 1024х1024?

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

Цитата:
ncuxonaT писал:
150к в атлас 8к у меня упаковались за 5 минут обычным и 45 секунд оптимизированным.

А что ты там оптимизировал? Я подозреваю больше всего времени отнимает выделение памяти.

__________________
My Projects: download page

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

Цитата:

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


Отправлено thambs 30-11-2020 в 15:52:

Дядя Миша

__________________
http://www.moddb.com/mods/monorail-quest


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

Я рёбра не рендерю, чёб быстрее было. Так-то оно уберётся.

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

Добавлено 30-11-2020 в 19:04:

Спровидливозти ради, это на работе, тут комп древний, кора дуба.

Добавлено 30-11-2020 в 19: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 30-11-2020 в 17:29:

Дядя Миша в одну большую страницу будет собираться быстрее или медленнее, чем в несколько маленьких?

Цитата:
Дядя Миша писал:
А что ты там оптимизировал? Я подозреваю больше всего времени отнимает выделение памяти.

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


Отправлено Дядя Миша 30-11-2020 в 17:51:

Цитата:
ncuxonaT писал:
в одну большую страницу будет собираться быстрее или медленнее, чем в несколько маленьких?

в одну большую дольше.

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

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

__________________
My Projects: download page

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

Цитата:

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


Отправлено Дядя Миша 02-12-2020 в 07:53:

Нравится это кому-нибудь или нет, но я таки запилил простейший промежуточный бинарный формат для хранения вертексов-треугольников и назвал его CSM, что можно расшифровать как Computed Static Mesh, Compiled Static Mesh или Cached Static Mesh. Но любители конспирологии должны увидеть здесь отслыку к cs-mapping. Не будем им мешать.

И сегодня я наконец-то понял, как же мне смержить сурфейсы обратно в большие куски, не растеряв связи с группами. Причём информации придётся сохранить минимально. Нам не надо хранить информацию для каждого вертекса, нам не надо хранить информацию для каждого треугольника, нам не надо хранить информацию для каждой рендер-группы. Всё что надо сделать - это просто сохранить информацию о ректангле в специальный файлик описания шрифтов, формат которого я разработал этой весной.
Я предполагал, что мне это пригодится, поэтому формат заранее включает в себя разные типы данных: шрифты (описание букв), спрайты (центровка кадра) именованные кадры (для худ-картинок) и наконец лайтмапы.
Там можно сохранить ректангл и размер в world-units. Сами ректанглы записываются в особый файлик сопровождения шрифтов - по одному файлу на каждую лайтмапу. Каждый ректангл - это лайтгруппа. То есть когда мы грузим треугольники геометрии - мы просто напросто ищем в какой из ректанглов попал этот треугольник. Пересечение bbox и tri. В двухмерном пространстве. Задачка решается простым перебором, но здорово ускоряется при помощи AABB дерева. Или двухмерного хэша, но по памяти дерево тут быстрее. И вот таким вот образом нам не надо хранить эту информацию больше нигде. Треугольники обратно собираются в группы, используя минимум информации. Записывать координаты в лайтмапу обратно не нужно - это делается уже в BSP.
Единственный минус подхода - плотность лайтмапы можно будет отрегулировать только в BSP. Впрочем оно почти везде так. И в кутри и в сорсе. А для террейна плотность автоматически считается.
К тому же, пользователь всегда может удалить эти описания шрифтов, сделав перекомпиляцию света невозможной.

__________________
My Projects: download page

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

Цитата:

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


Отправлено nemyax 02-12-2020 в 10:01:

Цитата:
Дядя Миша писал:
я таки запилил простейший промежуточный бинарный формат для хранения вертексов-треугольников и назвал его CSM

Дашь нам криворуким моделистам заголовочник, чёб мы нормали портили?


Отправлено Дядя Миша 02-12-2020 в 14:03:

Да их бесполезно портить, компилятор их всё равно игнорит.
Дам конечно. Там оч. простой формат, вертексы, фейсы и всё.

Добавлено 02-12-2020 в 14:13:

Лиманск из Чистого Неба


И конечно машина времени, в оригинале я её так и не нашёл.


4 часа освещение считалось. Наверное из-за того, что домов слишком много. У луча много препятствий.

Добавлено 02-12-2020 в 14:16:

Следует особо отметить, что в данный момент компилятор работает по максимально негативному сценарию - каждое деревце, каждый пропс копируется и вставляется в карту заново. Из-за чего Лост-Альфовские карты, например, могут занимать до полугигабайта по размерам. Но для меня главное, что сам компилятор это выдерживает и прекрасно укладывается в 32-х битные лимиты по памяти. Уж если он такое издевательство выносит, то без дубликатов - тем более. Но это всё потом. У меня итеративная разработка.

Добавлено 02-12-2020 в 16:56:

Остались у меня две самые сложные задачи.

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

2. сделать мульти-референс модели, чтобы не дублировать геометрию. Очень много мелочей придётся учесть, это утомляет.

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

Добавлено 02-12-2020 в 17:03:

Во, я вспомнил в чём цымес. В BSP будет введён ключ -onlylights, чтобы можно было обновлять только лампочки.

__________________
My Projects: download page

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

Цитата:

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


Отправлено ncuxonaT 02-12-2020 в 16:03:

Тебе не кажется, что ты переусложняешь?


Отправлено Дядя Миша 02-12-2020 в 16:22:

ncuxonaT переусложняю что именно?

Добавлено 02-12-2020 в 19:22:

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

__________________
My Projects: download page

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

Цитата:

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


Отправлено ncuxonaT 02-12-2020 в 17:33:

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


Отправлено Дядя Миша 02-12-2020 в 18:07:

Цитата:
ncuxonaT писал:
Я не очень понял, что с чем объединяется

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

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

Цитата:
ncuxonaT писал:
Вся геометрия разбивается на лайтгруппы, которым соответствуют отдельные куски на лайтмапе, так?

да.

Цитата:
ncuxonaT писал:
Потом эти лайтгруппы объединяются в большие куски, чтобы рендерить их одним дипом?

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

Цитата:
ncuxonaT писал:
Почему нельзя хранить эти куски как субмеши с указанием номера страницы лайтмапы?

Ну во первых оно жы там как-то разбивается на куски, чтобы в одном сабмеше было не более 65 киловертексов. А уж сколько лайтгрупп в этот меш попадёт не учитывается. При таком подходе найти какие там вертексы какой лайтгруппе соответствуют и тем более выделить эти сабмешы - достаточно ресурсоёмкая задача. Т.е. сортировка и группировка в первую очередь должны полагаться на максимально дружелюбную дату для рендинга. А не искать компромиссы, чтобы их лайтмаппер хорошо видел. Это ничем хорошим не закончится. Да и там слишком много мест, где всё это перетасовывается, я не смогу их все отследить. Можно сделать тупо - для каждого треугольника завести структурку
C++ Source Code:
1
// 16 bytes here
2
struct ref_lightgroup
3
{
4
  uint32_t	container;	// gcontainer index
5
  uint32_t	firstelem;	// gcontainer->firstelem + firstelem
6
  uint32_t	numelems;		// for( uint32_t i = gcontainer[container].firstelem + firstelem; i < numelems; i++ )
7
  int32_t	lightGroup;
8
};
9
 
10
// 4 bytes here
11
struct ref_group_bounds
12
{
13
  hvec2	bounds;		// изначальные баундсы для каждой лайтгруппы, чтобы можно было восстановить истинный
14
  // размер. Места в атласе выделяются в makebsp
15
};

Это то, что мне в голову пришло в первую очередь. Но когда в сцене 4-5 миллионов сурфейсов подобные сервисные структуры могут весить до 50 мегабайт. Zhopa. Вторая мысль была озвучена выше - сохраняем для каждой страницы атласа информацию о ректанглах. А затем просто пропускаем каждый треугольник сквозь этот ректангл и находим, где он попал внутрь. Если попал - этот треугольник принадлежит этой лайтгруппе. Для ускорения процесса я построю двухмерное AABB-tree.
Полагаю это будет самый оптимальный вариант.
Есть у такого подхода и минус - невозможно сжимать в 1 пиксель совсем чёрные лайтмапы, например. Но это в целом некритично. А для лайтстилей - даже вредно.

__________________
My Projects: download page

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

Цитата:

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


Отправлено Raid 03-12-2020 в 15:23:

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


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

__________________
Ты себя ведёшь как маленький ребёнок, который на улице увидел говно и обрадовался - говно-говно, смотрите кто-то насрал, ну и дела! © Дядя Миша

лиса.забирать.сыр.кусочек = ворона.уронить.сыр.кусочек( 1шт ); © FiEctro


Отправлено ncuxonaT 03-12-2020 в 16:57:

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

Raid скрипты slide normal thief или noors normal thief для 3дмакса проецируют и переносят нормали с одного объекта на другой. Создаешь вокруг дерева сферу или полусферу, выбираешь её как источник нормалей, крону дерева выбираешь как таргет и переносишь.
https://gamebanana.com/tuts/12231


Временная зона GMT. Текущее время 18:27. Страницы (255): « Первая ... « 122 123 124 125 [126] 127 128 129 130 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

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