Вот кстати говоря насчёт TBN на моделях. В параное сглаживание происходило только в рамках одного меша. Если кто-то не знает структуру студиомодели, поясню. Вся модель делится на Body Parts - это таблица индексов, к которой прилинкованы субмодели. Через параметр pev->body мы можем указывать рендереру какие именно части тела рендерить. Хитрость этой таблички в том, что мы уже при компиляции можем задать любые сочетания из имеющихся у нас субмоделей и привязать их к определённому номеру body. Допустим солдат-негр с дробовиков содержит в табличке 3 субмодели - тело солдата, голова негра и дробовик. Эти три меша будут отрисованы. Субмодели делятся на мешы, но при этом вертексы-нормали общие для всей субмодели. Один меш отличается от другого только текстурой. Так вот всё дело в том, что чаще всего нормали сглажены только для отдельно взятого меша, а не для всей субмодели. Проверить это утверждение очень легко - достаточно попробовать нарисовать Glow Shell, используя те нормали, которые уже есть в модели. Ну вы все знаете, как делается Glow Shell:
В квейках глоушеллы сделаны аналогично, но поскольку там всегда одна текстура на модель, то проблем не возникает. А тут приходится строить новую табличку. Надо сказать, что в Valve в целях ускорения, к этому отнеслись довольно наплевательски. Ну они просто пособирали все нормали с субмодели, которые попались первыми. Примерно в 70% случаев это конает. То что Glow Shell имеет разрывы - незаметно. Да я напомню, что это в основном использовалось на айтемах, ну и может на игроках. Ну как что сложнее - уже видны артефакты. Но в то же время есть еще один кейс где сглаженные нормали сквозь весь меш крайне критичны - это радионовская фича True Form, которая пыталась тесселировать модели в те далёкие времена, я помню её Ксерокс еще пытался заюзать в HLFX и у него бочки так смешно надувались
Тем не менее на ютубе есть ролики, где показано что это даже неплохо работало. А как строятся такие нормали? Там area weights для смежных треугольников субмодели. Я сделал аналогично и через dot сравнил нормали в модели с теми что у меня получились. И вот в 90% случаев dot выдал результат около 0.99, т.е. почти идентичные. Но кое-где было 0.1, а где-то даже -1. Это вот как раз те разрывные места между двумя мешами. У меня тут небольшой бардак с ресурсами, толком проверить пока не могу, но я оставлю эту фичу на будущее - пригодится.
По хорошему TBN надо сохранять в модель, но тогда придётся разработать новый формат, уже с нормальной индексацией треугольников, снять лимит на длину анимации в 64 килобайта, итд.
Добавлено 07-11-2019 в 11:59:
Модели худо-бедно рисуются, анимируются, теперь надо спрайтесы подключить. Старый вариант, где на каждый кадр грузилась отдельная текстурка никуда не годится. Я их сохраню в один большой атлас. А вертексы в VBO и спрайты теперь тоже будут рисоваться через шейдер.
Все равно их мягкими делать. Soft-Particles.
nemyax писал: В каком смысле с нормальной? Сейчас плохая?
Сейчас там raw-поток gl-комманд, к которому нет произвольного доступа, это дичайше неудобно, его приходится каждый раз весь проматывать.
Нормальная индексация, я имею в виду завести структурку triangle и там a,b,c индексы.
Подзагрузил спрайто-кадры в атласы, ну пока не очень плотно. Но для начала сойдет.
Не знаю пока насчёт обрезалки. Я тут в коде упаковщика картинок от Кармака баг нашёл. Сначала понять не мог, да что за дерьмо такое, ну вот ситуация. Допустим у нас в спрайте всего 1 кадр 16х16. Размер атласа аналогично 16х16. У меня там перед загрузкой еще код пытается определить потенциальные размеры атласа, чтобы потуже упаковать кадры.
Вполне естественно что для одного кадра он покажет именно его размеры.
А упаковщик - посылает. А всё почему?
C++ Source Code:
1
for( i = 0; i < blockWidth - w; i++ )
2
{
3
best2 = 0;
4
5
for( j = 0; j < w; j++ )
6
{
7
if( allocated[i+j] >= best )
8
break;
9
if( allocated[i+j] > best2 )
10
best2 = allocated[i+j];
11
}
12
13
if( j == w )
14
{
15
// this is a valid spot
16
x = i;
17
y = best = best2;
18
}
19
}
Видите условие для цикла?
Если blockWidth == w, цикл ни разу не прогонится. Отсюда идиотская ситуация, что мы не можем поместить в атлас картинку, которая точно совпадает по его размерам, но это ладно, это только полдела. Оно из-за этого еще и пакует хуже процентов на 15. То есть я подбирал оптимальные размеры атласа, куда по моим прикидкам должны были влезать все кадры. А упаковщик - хрена. 2-3 последних кадра не влезало. Как повизёт. Да что такое? Увеличил высоту еще на один шаг - влезло.
Странно. Начал разбираться. И вот такое.
Правильнное условие выглядит так
C++ Source Code:
for( i = 0; i <= blockWidth - w; i++ )
вот так всё прекрасно влезает на заданный размер.
Добавлено 07-11-2019 в 18:25:
Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.
Добавлено 07-11-2019 в 18:28:
Particle Trimmer, хех. В принципе такую штуку несложно и самому написать, этож 2д обрезалка. Если парт-системы сделать через инстансинг, то смысл безусловно есть. Впрочем там и лучи надо через него же рисовать, но с лучами попроще - их и так не надо обрезать.
Дядя Миша писал: Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.
Странная логика, казалось бы как раз поэтому и нужно делать.
Да не, от еденичных спрайтов подряд оно не спасёт. Это для облака партиклей в первую очередь полезно. Вот там да, овердрав, который можно сильно уменьшить.
Добавлено 07-11-2019 в 19:19:
Кстати насчёт того исправления о котором я написал выше. Залез в код ку3 - а там уже исправлено Причём тем же способом.
Та я уже почти никуда не лажу. А если и лажу, то не за кодом, а посмотреть архитектурное решение.
Добавлено 07-11-2019 в 20:36:
Чтоб не мелочиться, загрузил вообще все спрайты, которые были. Прикольно выглядит.
Добавлено 07-11-2019 в 20:44:
Барон Ада из дуума занял текстуру 1024х768.
Добавлено 07-11-2019 в 20:46:
Вообще в NT я планирую сжать эти спрайты в DXT1\DXT5, это и будет "новый" формат.
Добавлено 07-11-2019 в 23:20:
Возвращаясь к теме убитых нормалей, то что я писал утром. Вспомнил, что у меня есть моделька, конверченная из ку3 с помощью этой японской программы, название которой я уже забыл. Ну вообщем нормали там вообще никакие. Я не знаю почему. Собсно слева - нормали в модели, а справа seamless normals by area weighting про которые я говорил.
Это конечно искуственный случай, ну просто чтобы было понятнее о чём речь.
Добавлено 07-11-2019 в 23:52:
Да, возвращаясь к вашей самой любимой теме, о том как можно текстуры с разных моделей совершенно не грузить, как дубликаты. В NT это вполне себе реализуемо. Правда с той оговоркой, что компиляторы пытаются подрезать текстуру на разных моделях ($cliptotexcoords), из-за чего одна и та же текстура может менять свой размер на разных моделях. Поэтому для таких текстур будет сделан дубликат. Но их не очень много.
Немного статистики для c1a0d.
Все текстуры уникальные - 653 штуки.
С дубликатами для одинаковых имён и разных размеров - 695 штук
Уникальные текстуры для каждой модели - 790 штук.
Для халфовских моделек вся экономия - 2 мегабайта памяти.
Дядя Миша взвешенное сглаживание нормалей планируешь опциональным делать? Потому что если модель будет с запеченной нормалмапой, то из-за изменений нормалей нормалмапа пойдет по одному месту.
Crystallize ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр. А я ответил, что толку от антиалиасинга не будет, потому что при увеличении даже сглаженной текстуры всё равно полезут пиксели. Так вот, оказалось, что я был неправ, и можно заморочиться, чтоб лайтмапа была более-менее гладкая. Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим. Но видеокарта в него не умеет, поэтому придётся городить огород в шейдере, и фпс немного упадёт, конечно.
Вот вроде бы самый быстрый способ: http://www.java-gaming.org/index.php?topic=35123.0
Ожидаемый результат примерно такой:
Может, ДМа заинтересует.
05-11-2019 13:44
