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)

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

Добавлено 10-05-2020 в 22:26:

Полностью заткнул все ошибки и предупреждения. Что для этого потребовалось сделать?
1. переключиться в режим одинарной точности (перекомпилить)
2. поскольку оптимизация происходит в 2D и использует построение ортогонального базиса - надо непременно юзать ту функцию, которую использовали в D3. MakeNormalVectors. Они все "типа правильные", но код потом намертво привязывается к конкретной реализации и глючит с другой.
3. мало этого - в MakeNormalVectors пришлось еще и заюзать табличный InvSqrt. И вот только тогда все ошибки исчезли. Ну что можно сказать? Зашибись! Отличный оптимизатор.

Добавлено 10-05-2020 в 22:31:

В D3 вообще много такой табличной математики для флоатов. Неудивительно что они не боялись их сравнивать напрямую кое-где.

Добавлено 10-05-2020 в 23:36:

На домашнем компе сепульчер сразу стартанул под 650 фпс
напомню что предидущий рекорд был 420. И это еще на толком не отстроенной системе, я чёрт знает что там рисуется сейчас. Виз-то старый.

Добавлено 10-05-2020 в 23:41:

Вон он, весь сепульчер в кадре. ~350 тысяч полигонов. Я ж говорил, что это должно быть быстро.

Добавлено 10-05-2020 в 23:43:

Так это еще индексы по шине качаются.

__________________
My Projects: download page

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

Тут выяснился один недостаток нового подхода, я думаю вы уже догадались в чём он заключается. В ку3 детайлы не карвились по границам дерева, они просто добавлялись в карту в любом случае. И были видны из какого-то лифа. Здесь же идёт строгое обрезание по секущей плоскости ноды. Иногда (не часто), маппер намеренно располагает детайл ЗА ограничивающим брашем (ну например этот браш невидимый). В ку3 этот детайл бы добавился в уровень в любом случае, а здесь получается, так что невидимая геометрия BSP попросту отрезает его, сама карта при этом, естественно собирается без утечек, но визуально на месте этих патчей-моделей остаются дыры, причём, поскольку мапперы еще и любят их точно совмещать, их отрезание сильно зависит например от режима точности. В одинарном режиме отсекает практически всё, в двойном - ну кое-что.
Т.е. добавление просто считает, что детайл попал в солидную ноду.

Взять вот карту Сока для примера, Focal Point. У него там солидные структуры по бокам лестниц и прямо на них же положены планарные детальные ромбовидные патчи. Патчи там очевидно потому, что брашы такие формы проблематично текстурировать, в радианте не было таких инструментов вроде. И вот оно лежит точно на ноде и отсекается.

Надо подумать как лучше разрешать подобные ситуации.

Добавлено 13-05-2020 в 14:26:

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

Добавлено 13-05-2020 в 14:36:

1

if( keepon && !counts[SIDE_FRONT] && !counts[SIDE_BACK] )

2

{

3

  if( fnormal )

4

  {

5

    // put front face in front node, and back face in back node.

6

    if( DotProduct( fnormal, normal ) > NORMAL_EPSILON ) // usually near 1.0 or -1.0

7

      *front = in;

8

    else *back = in;

9

  }

10

  else

11

  {

12

    vec_t sum = 0.0;

13

    for( i = 0; i < in->numpoints; i++)

14

    {

15

      dot = DotProduct( in->p[i], normal );

16

      dot -= dist;

17

      sum += dot;

18

    }

19

20

    if( sum > NORMAL_EPSILON )

21

      *front = in;

22

    else *back = in;

23

  }

24

  return;

25

}

__________________
My Projects: download page

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

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

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

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

Добавлено 13-05-2020 в 14:49:

Вот скрины

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

Добавлено 13-05-2020 в 15:00:

ЗЫ. У Кармака в D3 более изящное решение - проверить куда смотрит нормаль секущей и сравнить с текущим виндингом. И уже в зависимости от этого положить спереди или сзади. Здесь в чём плюс - мы уже не завязаны на точность. Смотрим только на знак дотпродукта.

Добавлено 13-05-2020 в 15:13:

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

1

vec_t sum = 0.0;

2

for( i = 0; i < in->numpoints; i++)

3

{

4

  dot = DotProduct( in->p[i], normal );

5

  dot -= dist;

__________________
My Projects: download page

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

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

Так что теперь основная задача: финализация формата уровней.
Потом можно будет заняться освещением.

__________________
My Projects: download page

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

__________________
My Projects: download page

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

Слева оптимизированная сетка, справа неоптимизированная.

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

__________________
My Projects: download page

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

Дядя Миша

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

thambs очевидно они не склеились.

__________________
My Projects: download page

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

__________________
My Projects: download page

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

Дядя Миша, а сработает ли такой вариант: в коде кастомного рендера XashXT сделать копию бсп дерева конкретно для отрисовки, а потом его оптимизировать тем подходом какой ты использовал, еще когда только начинал работу над рендерером в XashNT? Ведь поскольку код рендерера целиком можно менять, то вроде бы как не обязательно придерживаться именно бинарной совместимости, и можно немножко доугой вариант дерева впихнуть, с которым оптимизации будут работать. Возможно ли такое реализовать, или же все таки есть какие-то фундаментальные различия, которыми нельзя пренебречь?

__________________
SNMetamorph's Personal Blog
Xash3D Modding Discord

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

__________________
My Projects: download page

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

__________________
SNMetamorph's Personal Blog
Xash3D Modding Discord

__________________
My Projects: download page

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