Показать все 60 сообщений этой темы на одной странице
|
Страницы (4): « 1 2 3 [4] Показать все 60 сообщений этой темы на одной странице |
HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- XashXT (https://hlfx.ru/forum/forumdisplay.php?forumid=30)
-- Hardware Skinning (обсуждение и troubleshooting) (https://hlfx.ru/forum/showthread.php?threadid=4279)
, особенно когда лайтмапы в Xash'е такие:
Да, сталкера и метро тоже будем на ксаше делать
Добавлено 06-02-2014 в 23:20:
И возвращаясь к теме хардварного скиннинга. Я начитался всяких статей по оптимизации и решил изучить это дело подробно. В частности, например утверждается, что стрипы работают быстрее фанов.
Ну это понятно почему происходит - стрипы более эффективно используют место, в результате в вертексный кэш влезает больше вертексов, а значит и скорость их обработки выше - за счёт того, что нам не надо трансформировать дважды (а то и трижды) уже оттрансформированные треугольники. Реализаций построения strip-sequence существует две штуки: NvTriStrip и TriStripper. Я не говорю, что нету каких-то других реализаций, просто на гей-деве рекомендует именно эти. Про них упоминается в лекции по повышению производительности, про них же упоминается в подсказках.
Три-стрип я качать не стал, поскольку это оффлайн-тулза, работает как и все тулзы от нвидии крайне неторопливо (я помню как nvdxt жевала текстуры по 20 секунд). Поэтому я сразу перешёл к проверке Tri STripper.
Тулза написана отвратительно. Во первых в качестве стандартных аргументов она принимает исключительно std::vector. Я мигом догадался, что её писали мудаки, после чего уже не рассчитывал на какие-либо прорывы. Так и оказалось 
. Эта зараза трудилась над многими моделями порядка 40-50 секунд, но на некоторых модельках проскакивала за тысячные доли секунды. Никакого прироста она мне так же не дала.
Тогда я подумал, что стрипы - это не самоцель, а всего лишь один из методов оптимизации вертексного кэша, что и являлось моей конечной целью. Тогда я скачал простейшую программку vcacheopt, реализованную в одном-единственном хидере. Программка тоже мудацкая, тоже хочет std::vector на вход. Ну да ладно. И вот какие интересные результаты она мне показала: 1 промах кэша на меш любого размера. Понимаете?
Ведь халфовские модели изначально содержат фан-стрип секвенции, для максимального увеличения производительности. Не стоит однако думать, что это изобретение самой вальвы. Код этот был написан Кармаком еще для первого квейка. Тем не менее меня полученный результат вполне удивил, поскольку еденичный промах кэша на моделях любого размера - это просто идеальный результат, вполне возможно я где-то ошибся при инициализации программы. Я еще раз всё перепроверил и отрисовал модельку с уже изменёнными индексами - модель не покорёжилась, фпс не изменился. Тогда я подумал, что возможно сам код неочень корректный и скачал Одну из версий реализации кода Linear-Speed Vertex Cache
Optimization от Tom Forsyth. Я честно игрался с размером вертексного кэша, но ни в одном случае не получил ни прироста ни падения фпс.
На основании проведённых исследований считаю возможным сделать заявление: халфовские модели достаточно неплохо оптимизированы для минимизации промахов вертексного кэша и любые сторонние оптимизации здесь излишни.
Впрочем, моё исследование нельзя признать совсем уж объективным - ведь я проводил его только на одной видеокарте. Ну чтож, давайте еще немного потестируем - я выложил в соседней теме очередное обновление бенчмарка.
Правила тестирования таковы:
1. запускаем бенчмарк, замеряем FPS в Hardware Mode.
2. выходим из программы (именно так! никаких рестартов и перезагрузок карты), открываем config.cfg и находим строчку vcache_size. По умолчанию она равна 32. Допустимые значения 10 - 64. Попробуйте подставить в переменную следующие значения: 10, 16, 24, 32, 48, 64. После каждого изменения следует сохранить config.cfg, запустить бенчмарк и замерить FPS в Hardware mode.
3. Если вы обнаружите серъезные отличия в FPS, ну например у вас было 100 фпс при vcache_size 32 и вдруг стало 180 FPS при vcache_size 10, то обязательно отпишитесь об этом. Если же при любых изменениях vcache_size результат колеблется в пределах 5-10 фпс, то сообщать об этом не следует, т.к. это укладывается в пределы погрешности.
Сразу предупреждаю - с большой долей вероятности никаких изменений большинство из вас не заметит. С меньшей долей вероятности могу сказать, что изменений не будет ни у кого, поскольку, повторюсь, студиомодельки изначально имеют оптимальный порядок следования вертексов и индексов, который не нуждается ни в каких дополнительных оптимизациях. При этом остаётся открытым вопрос, каким же образом ребята с гей-дева таки получали ощутимый прирост, который заметен не на словах, а вполне на деле (есть демка в соответствующей теме, её можно скачать и убедиться самому). Но тут у меня два дополняющих варианта. Во первых все эти изыскания по производительности проводились в 2005-2006 годах и как следствие ситуация могла в чём-то измениться. А во вторых, тамошний народ обожает юзать текстовые некомпилированные модели, например формата OBJ. Это просто такой дамп треугольников, навроде SMD. Кстати SMD они тоже любят грузить самостоятельно. Я ни разу не видел, чтобы кто-то где-то юзал mdl, но зато есть статьи посвящённые загрузке SMD движком. Откуда такая любовь к сырью - понимать отказываюсь. Возможно это doom головного мозга.
Ну так вот - возвращаясь к проблеме, модели такого типа, естественно не имеют ровным счётом никаких оптимизаций, это просто накиданные как попало треугольники и после прогонки этой кучи через оптимизатор, получение положительных результатов становится вполне реальным.
Чего не скажешь о халфовских студиомоделях.
Ну вроде всё сказал, тестируем, отписываемся, в случае получения каких-либо положительных результатов.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Индексы в OBJ пишутся? Или самому надо генерить?
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
__________________
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
__________________
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
__________________
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Да, вам что ни говори - серавно по своему сделаете 
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
| Временная зона GMT. Текущее время 23:11. | Страницы (4): « 1 2 3 [4] Показать все 60 сообщений этой темы на одной странице |
На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024