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

На кордоне - десять тысяч кусочков моделей. Я в этой карте собрал около трёх тысяч.

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

1	int SelectPartition( tree_t tree, node_t node, bface_t *list )

3	if( tree->blocksize > 0 )

5	dvec3 halfSize = dvec3( node->bounds[1] - node->bounds[0] ) * 0.5;

6	dvec3 normal;

7	double dist;

#if 0

9	if( halfSize.x > tree->blocksize \|\| halfSize.y > tree->blocksize \|\| halfSize.z > tree->blocksize )

      int	axis;

13	if( halfSize.x >= halfSize.y && halfSize.x >= halfSize.z )

14	axis = PLANE_X;

15	else if( halfSize.y >= halfSize.x && halfSize.y >= halfSize.z )

16	axis = PLANE_Y;

17	else axis = PLANE_Z;

19	normal = dvec3( 0.0 );

20	normal[axis] = 1.0;

21	dist = ( node->bounds[1][axis] + node->bounds[0][axis] ) * 0.5;

23	return FindHashPlane( dplane( normal, dist ));

#else

26	// if it is crossing a 1k block boundary, force a split

27	for( int i = 0; i < tree->blockdimensions; i++ )

29	if( halfSize[i] > tree->blocksize )

30	dist = tree->blocksize * ( floor( ( node->bounds[0][i] + halfSize[i] ) / tree->blocksize ) + 1.0 );

31	else dist = tree->blocksize * ( floor( node->bounds[0][i] / tree->blocksize ) + 1.0 );

33	if( dist > ( node->bounds[0][i] + 1.0 ) && dist < ( node->bounds[1][i] - 1.0 ))

35	normal = dvec3( 0.0 );

36	normal[i] = 1.0;

37	return FindHashPlane( dplane( normal, dist ));

#endif

43	if( tree->optimized )

44	return SelectPartitionVL( node, list );

45	return SelectPartitionQ3( node, list );

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

У меня такой же вопрос. В ксаше я обратил внимание, что если поставить 30 солдат модельками как env_static, фпс не проседает, а если 30 реальных - то сильно падает. Это из-за их кода или бсп-дерева? Не совсем понимаю, как это работает.

KorteZZ лимитов в новом ксаше особо нету. Лимиты только в аппаратном обеспечении.

Дядя Миша
Есть планы по выносу AI в отдельный поток?

Есть планы по оптимизации, а не по выносу.

Добавлено 03-11-2020 в 16:04:

Мне сейчас надо определиться с типом коллизии, вот оно что.
Представлять каждый треугольник в виде плоскости со скосами, довольно эффективно в плане скорости работы, но занимает чудовищно много места.
На какой-нибудь ЧАЭС легко может быть 10-15 миллионов плоскостей.
А ведь она по современным меркам довольно таки лоу-поли.

Впрочем там вылезает еще одна проблемка. У видеокарт оказывается, существует лимит на максимальный размер VBO - обычно миллион вертексов.
Самое поганое, что и на индексы точно такой же лимит - 1 миллион.
Это немного нелогично, к тому же превышение лимита далеко не всегда приводит к каким-то последствиям, на моих карточках.
Так что придётся еще и геометрию разбивать на небольшие батчи.
Наверное сделаю куски по 65 киловертексов с локальными оффсетами, чёб индексы хранить в 16-битном диапазоне.

Но повторюсь, главная задача, это определиться с коллизией. Коллизия будет по треугольникам, но надо решить с какими фигурами. Можно сделать просто triangle vs bbox. Можно как в третьем дууме - набирать произвольные простенькие фигуры из конечного числа вертексов - обычно 32-64. В том же физиксе лимит на активное тело - 256 вертексов, но как правило это даже избыточно.

А в сталкере разве нет упрощенной модели геометрии для коллизии? Может строить/подгружать из 3д пакета её в компиляторе моделей, как это делает сорс?

Так почему бы не использовать сталкеровские методы обработки коллизии для сталкеровских моделей? Они тоже медленные?

Да нет никаких "сталкеровских" методов.

Загрузил недостающие части ландшафта. Обратите внимание на поликаунт.

На машинках почему-то текстуры съехали, на всех. Но я пока не разбирался.

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

Добавлено 05-11-2020 в 18:35:

По сути с этой сценой даже мой компилятор не справляется - ему не хватает памяти, выручает только ключ /3Gb в boot.ini
Предвидя советы "ну почему бы не сделать как в сталкере", напоминаю, что новый движок должен уметь как активно использовать полностью брашевые карты, так и полностью полигональные. Т.е. задачка несколько сложнее, чем представляется на первый взгляд.
Нет, не в оптимизации, конечно дело. А в выборе наилучших методов.
А чтобы что-то выбрать, надо многое протестить. Это время.

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

Почему коллизия по треугольникам? Ты хочешь строить какую-то единую структуру для всей карты со всеми елками?