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

Страницы (255): « Первая ... « 121 122 123 124 [125] 126 127 128 129 » ... Последняя »
Показать все 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)

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

Ну я уже выше писал, что да, там довольно небыстрый рейтрейсер.
Раз в 40-50 медленней моего. Там где мой за 30 секунд управляется, оригинальный может считать минут 8.

Добавлено 23-11-2020 в 18:40:

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено Crystallize 24-11-2020 в 18:31:

Цитата:

Дядя Миша писал:
При таком подходе плотность люкселей должна быть заранее посчитана на этапе компиляции BSP. То есть чтобы изменить разрешение лайтмапы придётся заново пересчитывать всю карту. Одним только светом не отделаешься.

А в Сорсе так же? Я ему выставляю другое разрешение но эффекта нет.

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

Помоему да, там лайтматрица формируется в bsp.

Добавлено 24-11-2020 в 22:15:

Ну как-то так. Это testers_mp_factory. Проблема остаётся - здесь 76 тысяч сурфейсов - по кол-ву лайтмапгруп. Когда лайтмапа посчитана - они уже не нужны и можно эти группы объеденить обратно. Но компилятор света такими полномочиями не обладает. А даже если бы обладал - свет можно было бы посчитать только один раз, после чего требовалась бы полная перекомпиляция уровня. Не думаю что это кого-то обрадует.

Проблема конечно решаемая, но я пока думаю как лучше сделать.
Можно эти группы сохранить прямо в вертексы. Размер карты конечно вырастет. Можно попробовать сразу выделить место в атласе, но это проблемно - как потом считать плотность в юнитах, как реконструировать группы из атласа. Не факт что это вообще возможно. Буду думать.

__________________
My Projects: download page

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

Цитата:

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

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

что такое лайтмапгруппа?

Отправлено Дядя Миша 24-11-2020 в 20:26:

группа треугольников, которую можно спроецировать на плоскость.
К примеру террайн = 1 лайтмапгруппа.

__________________
My Projects: download page

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

Цитата:

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

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

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

Там по идее на границе шва надо просто сделать билинейку и всё.

Добавлено 26-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'

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

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

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено KiQ 28-11-2020 в 10:47:

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

__________________
-Brain is dead-

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

Я сделаю бинарный промежуточный формат для хранения моделей.
И может быть я ему даже дам расширение .csm

Cached Static Mesh.

Добавлено 28-11-2020 в 14:00:

Цитата:

KiQ писал:
Например в индоре - более мелкое, а для ландшафтов, соответственно мягкое крупное

на ландшафтах тени от деревьев, нельзя там более крупное. Не слишком хорошая идея.

Добавлено 28-11-2020 в 14:06:

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено Ku2zoff 28-11-2020 в 17:29:

А вот кстати вопрос. В сталкере на статике тени меняются в зависимости от положения солнца? В лост альфе 1.4007 утром смешно видеть тени от деревьев в противоположную от солнца сторону.

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

Дык можно же распаковать ресурсы и посмотреть на лайтмапы.
Лайтмапа там запечена только для одного направления солнца.
Кто-то говорил, что можно запечь для произвольного кол-ва направлений, но я насчёт этого пока не интерисовался.

__________________
My Projects: download page

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

Цитата:

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

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

В сталкере, если вы изучали его лайтмапы, должны были отметить одну забавную особенность. Очень много кусков лайтмап повернуты под произвольным углом, отличным от 90 градусов. Это не касается механизма упаковки в атлас, это результат работы Orbitrary Ortho-Projection (оригинальный камент из кода XRay). Там в чём суть - полигоны группируются по нормали, следя, чтобы сумма этих нормалей не превысила некоторый угол, обычно 89 градусов. Результирующая нормаль частенько получается под произвольным углом, а вместе с нею и лайтмапа. Я отказался от этой схемы довольно быстро, использую своё изобретение, которое я назвал hashed lightmap axis. Идея в том, что для любого полигона можно найти максимально близкую аксиальную нормаль. Всего таких нормалей может быть шесть шутк - по сторонам куба. Это же автоматически повышает и плотность упаковки и исключает ситуации, с цилиндрической проекцией, например для колонны или цилиндра будет создано четыре лайтгруппы.
Правда между ними останутся швы, но при сталкеровском подходе они ведь тоже никуда не денутся. Еще и лайтмапу перекосит на какой-то угол.

Добавлено 30-11-2020 в 12:24:

ncuxonaT ты своим упаковщиком "уголком" когда-нибудь пробывал упаковать достаточно большие атласы? Ну скажем 1024х1024?
И не один, а штук 10. И сколько времени это у тебя заняло.
Потому что моя реализация какая-то адски медленная получилась.
Начиная с размера 512х512 она может маслать несколько минут.
До смешного доходит - освещение считается быстрее, чем упаковка в лайтмапу. Но если страница менее 512, то всё быстро.

Добавлено 30-11-2020 в 12:25:

Да вот пример

C++ Source Code:

1	DirectLighting:

2	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (833.86 secs)

3	173028152 total traces casted, 8122516 luxels illuminated

4	total lightmap pages 20

5	CreateLightmapPages: 817.050387 secs

6	writing maps\testers_mp_railroad.bsp

Упаковщик работал сопоставимо с рассчётом освещения. Кармаковский алгоритм таким не страдает, но и пакует ощутимо хуже.

Добавлено 30-11-2020 в 12:39:

Свежие скриншоты:

Фпс низкий, потому что в сурфейсы разбиты по лайтгруппам на 140 тысяч.
Такое кол-во даже просто отправить на рендеринг очень затратно.
Надо мержить обратно, по страницам лайтмапы, но тогда будут проблемы с множественным рассчётом освещения уже готовой карты. Иными словами, осветить карту можно будет только один раз, а потом заново пересобирать с нуля. Впрочем я этой проблемой пока еще не занимался вплотную.
Потом вместе решим как лучше сделать. В идеале тут должно быть 5-7 тысяч сурфейсов.

Добавлено 30-11-2020 в 12:41:

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

Добавлено 30-11-2020 в 12:42:

Деревья не освещены, т.к. подготовлены для повертексного, а его еще нет.
Впрочем это будет опционально, мне сперва надо сделать концепцию MU-моделей. Вот собсно, это и есть две самые главные задачи по компиляторам.

__________________
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 в 09:49:

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

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

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

Дядя Миша скорость наверное зависит от количества элементов, а не от разрешения. Проверил, мой изначальный алгоритм уголком уложил 25к элементов в атлас 4096х4096 за 6 секунд. Оптимизированная более уродская версия алгоритма справилась за 1 секунду.

У тебя точно упаковка медленная? В CreateLightmapPages помимо неё ничего не входит? Может, не атлас долго составляется, а освещение в него долго записывается?

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

25 тысяч элементов и у меня быстро. А вот когда 130 тысяч - уже долго.

Добавлено 30-11-2020 в 17:52:

Цитата:

thambs писал:
На последнем шоте странные потемнения по краям полигонов, так и должно быть?

абведи.

__________________
My Projects: download page

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

Цитата:

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

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

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