Sidebar

Новые компиляторы уровней для Xash3D

ncuxonaT

Well-known member
May 5, 2013
1,136
37
48
Но искать надо именно в том месте где всё ломается. Логично?
Но ведь ломается в любой программе, читающей мап. В том числе в компиляторе.
 

Ku2zoff

New member
Aug 12, 2010
312
34
5
0
Дядя Миша said:
Чем больше размер карты - тем грубее эпсилон. Чем больше сфера - тем меньше вероятность, что она съедет.
Ого, а я оказывается не зря пошёл в сторону уменьшения объектов, а не увеличения размера карты :) Сферы я конечно делать не буду, зачем они нужны брашевые? А вот всякие холмики и кочки уже пытался. Весьма неприятно, когда джек сразу записывает такие структуры в инвалидные. Ну эт я давно учебники не читал, есть определённые правила для создания таких штукенций. У меня есть одна старая карта без сорцев, там одни кочки, да деревья на них. Она даже на новом железе тормозит :D Ох, как же мне тогда не хватало площади, чтобы сделать участок леса.
Дядь Миш, как у тебя продвигаются дела с компиляторами? Ясно, что дискуссия о том, что и где съезжает - это здорово. Как насчёт экономии лимитов? Будет ли существенный прогресс по сравнению с китайцем?
 

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
Вот вам две картинк, для понимания сути процесса.
Первая это VHLT, вторая QBSP2. Точнее разница между ними только в одной функции ChoosePlaneFromList. Немного теории о том, как строится дерево. Слишком большие узлы (например на начальном этапе - вся карта), разрубаются тупо посередине, в противном случае дерево разбалансируется. Это уменьшит число нодов и лифов, но увеличит глубину рекурсии и среднее время доступа по дереву. Дальше, когда больших узлов уже не осталось (узел для простоты понимания - ббокс, коробка), мы выбираем секущую плоскость при помощи этой функции.
Для минимизации увеличения числа полигонов (после того, как секущая ноды их разделит), логично выбирать плоскость, которая сделает как можно меньше разрезов. Причём плоскость выбирается не произвольная, а из тех, что уже прилинкованы к данной ноде. Для удобства они сформированы в цепочки, каждая из которых относится к определённой плоскости. Т.е. surface_t - это цепочка face_t, у которых общая плоскость. Кол-во surface_t зависит от размера ноды, к концу построения BSP она всё меньше и меньше. Задача заключается в том, чтобы при помощи одного surface_t разрубить последовательно фейсы всех остальных surface_t и подсчитать кол-во разрубов. Чем их меньше - тем соответственно лучше. Второй критерий - предпочтение отдается аксиальным плоскостям, по вполне понятной причине - на квадратных фейсах легче лайтмапу контролировать, да и места она меньше занимает. Ну и вообще доступ к дереву быстрее. Поскольку идёт проверка NxN, задача требует весьма много времени, единственная оптимизация которой заключается в том, что вместо реального разрезания используется прикидка, что получится и применить к фейсу секущую. Ну видели вероятно функцию WindingOnPlaneSide. Она выдаёт варианты - плоскость сзади фейса, плоскость спереди фейса, плоскость рассекла фейс. Последний случай как раз и есть деление. На небольших картах халфы, даже безо всяких оптимизаций BSP работает быстро.
Но вы попробуйте тот же grass_test и будете очень удивлены, он и по три минуты может считать. Китайцу это не понравилось и он решил это дело ускорить. Для ускорения он построил простейшее BSP дерево из входных плоскостей (но без разрубания, а то бы получилось падение скорости), просто отсортировав их по принципу эти сзади, эти спереди.
Ну вообщем приблизительно. Прирост эта замута действительно даёт, по словам китайца до 90%. Заодно он же вывел формулу баланса дерева.
Всё бы ничего, но результат применения дерева вы видите на первом скриншоте. Если не сравнивать его со вторым, то можно смело сказать, что освещение в порядке. Но после сравнения, становится понятно, что на первом дикая грязь и артефакты. Это вот как раз результат применения китайских оптимизаций к построению BSP. К слову оно и виз замедляет (с 14 секунд до 40). Хотя лифов и нодов становится ощутимо меньше и глубина рекурсии тоже падает. Китайское дерево в этом плане очень неоднозначное, например оно хорошо экономит вертексы, что повышает фпс. Вообщем ставлю пока эксперименты.
Для тех кто считает, что грязь на первом скриншоте - норма, специально сообщаю, что это максимум что мне удалось вытянуть, малейшие изменения в SelectPartition и освещение мгновенно превращается в дикую грязь и несёт явные следы перехода. Пример - на третьем скриншоте. Тогда как классическая функция выбора плоскости абсолютно устойчива к различным параметрам и любым попыткам дебалансировки дерева - грязи нет. Меня эта грязь бесит еще со времён ZHLT, но там она была черезчур заметной, а китаец её просто загнал вглубь и она иногда лезет в виде мелких артефактов на ровном месте. А чтобы не так палевно было - взял и разблурил.
 

Attachments

Raid

VIP
Jul 11, 2006
8,308
33
220
0
CSM-чат
Гигантская как распилы бюджетов просьба: раз и навсегда выкинуть это хтоническое говно с остановкой компиляции в случае недостающих вадов (да и вообще манеру останавливать компил в случае недостающего чего-то там, или некритичных по сути ошибок). Нету - значит и не надо. Наоборот команду сделать -wadincluded или типа того, которая завязывает карту на наличие вадов. По дефолту пусть будет независимо от вадов.
 

Attachments

Last edited:

Raid

VIP
Jul 11, 2006
8,308
33
220
0
CSM-чат
2 Дядя Миша:
Тогда заранее спасибо :drink:

[ADDED=Raid]1507414014[/ADDED]
Насчёт BSP-растительности - а какова разница по времени каждого компилятора между всеми трёмя скниншотами? Второй очевидно лучше, но надо знать его ресурсную цену, скажем так.
 
Last edited:

mittorn

New member
Apr 22, 2010
1,213
15
0
2 Raid:
А не пробовал сравнивать с линуксовыми сборками компиляторов? Мне интересно, ломаются ли реальные карты от переноса на gcc и от sse/avx векторизации?

[ADDED=mittorn]1507439841[/ADDED]
У меня gcc на одно нехорошее место ругается:
Code:
common/bspfile.cpp: В функции «SwapBSPFile»:
common/bspfile.cpp:329:41: предупреждение: iteration 4 invokes undefined behavior [-Waggressive-loop-optimizations]
    g_texinfo[i].vecs[0][j] = LittleFloat( g_texinfo[i].vecs[0][j] );
                                         ^
common/bspfile.cpp:327:17: замечание: containing loop
   for( j = 0; j < 8; j++ )
 
Last edited:

mittorn

New member
Apr 22, 2010
1,213
15
0
2 Raid:
у меня есть 3 разных версии - от какого-то древнего xashxt ещё до custom build, от свежего xashxt (генерирует корректный deluxemap) и свежий с поддержкой моделей, но без deluxemap. могу под твой проц собрать оптимальный, если покажешь что в /proc/cpuinfo.

[ADDED=mittorn]1507470481[/ADDED]
вообще любая версия после китайца портируется за несколько минут, но насколько она работоспособна - не известно. Я компилировал простые карты, а проблемы csg/bsp могут на них просто не проявиться или я их мог не заметить - ведь освещение заблюрено.

[ADDED=mittorn]1507470540[/ADDED]
ну и я не проверял поддержку моделей вообще
 
Last edited:

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
ведь освещение заблюрено.
-blur 0
Там вообще интересно получается. Китайский комплект этих артефактов не выдаёт явным образом, но это еще ничего не значит - баги могут друг-друга взаимно компенсировать в разных тулзах. Например в одном только раде, сколько исправлений было, а я до него еще недобрался.
 

mittorn

New member
Apr 22, 2010
1,213
15
0
2 Дядя Миша:
Сейчас благодаря твоим комментариям я уже лучше знаю что надо проверять. просто пока не занимался этим.
К тому же у меня есть дампер лайтмапы, которым я подбирал crossfire.rad, с ним можно сравнить лайтмапу попиксельно
 

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
Чтобы отключить китайские навороты, надо запускать компил со следующими параметрами:
-notextures -dscale 2 -vismatrix normal -blur 0
Правда он там еще нормализующий порог крутил, так что будет темнее в целом.
Вот вам новая порцыя скриншотов: qrad, vl28, vl29, vl30, vl31, vl33.
SELECT_FAST_PARTITION с 30-й версии, блур с 31-й.
Между прочим подозреваю, что увеличение потребления памяти радом частично связано с изменением построения дерева. Вторая беда - он в patch_t слишком много всего напихал, в том числе и для ксаша тожы.
 

Attachments

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
2 Raid: я забыл сказать, что артефачит только эта комната. В остальных местах мало что поменялось.
 

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
2 DrTressi: будет геометрия посложнее - сразу полезет чёрт знает что, вон у Тхамбса спроси.
Работа HLRAD_TestLine_EDGE_FIX
Слева оригинал, справа фикс. В равной степени похоже на AO и на грязюку. А вам как больше нравится?
 

Attachments

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
Так, ну я снова со своими глупостями. Я доделал бсп и решил подсунуть ему на выбор VHLT разных версий, ZHLT, ну и родной курад. Результаты на скриншотах.
Расшифровка:
vlXX - VHLT номер версии
zlXX - ZHLT номер.версии
qrad - понятно
_fast - оптимизированное дерево от китайца (отличается меньшей глубиной рекурсии, это видно и на скриншоте из дебаг-инфы)
_norm - классическое построение дерева по Кармаку
_blur0 - отключённый блур
_blur2 - blur 2x
Из скриншотов можно сделать следующие выводы:
1. блур провоцирует лайт-лики на слишком-мелких поликах, сдвигает границы света и тени, что зачастую нереалистично выглядит.
2. то что я ошибочно принял за работу блура в версии 30 и выше, оказалось результатом исправленного (?) сглаживания нормалей. Хотя подобное сглаживание и скрадывает объем в какой-то степени.
3. есть и зависимость от построения дерева и баги в самом раде, это хорошо заметно на скринах с ZHLT, хотя часть багов там исправили.
4. виз не влияет ни на что, только принципы построения самого дерева.
 

Attachments

Qwertyus

New member
Aug 13, 2009
1,339
26
0
Варианты fast наиболее "мягкие" и даже без блура весьма ничего. ZHLT бяка.
 

Game Server

CSM TV

Page QR Code

QR Code

Donate Campaign

Total amount
$0.00
Goal
$25.00

Latest profile posts

TestUser wrote on TRUP@C's profile.
Master?
TestUser wrote on TRUP@C's profile.
Hello Father

Members online

No members online now.

Discord