HLFX.Ru Forum Страницы (255): « Первая ... « 29 30 31 32 [33] 34 35 36 37 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

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)

Отправлено Дядя Миша 05-11-2019 в 13:44:

В дальнейшем буду. Я предусмотрю такой же конвертор из одного формата в другой, как и для уровней.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-11-2019 в 08:59:

Вот кстати говоря насчёт TBN на моделях. В параное сглаживание происходило только в рамках одного меша. Если кто-то не знает структуру студиомодели, поясню. Вся модель делится на Body Parts - это таблица индексов, к которой прилинкованы субмодели. Через параметр pev->body мы можем указывать рендереру какие именно части тела рендерить. Хитрость этой таблички в том, что мы уже при компиляции можем задать любые сочетания из имеющихся у нас субмоделей и привязать их к определённому номеру body. Допустим солдат-негр с дробовиков содержит в табличке 3 субмодели - тело солдата, голова негра и дробовик. Эти три меша будут отрисованы. Субмодели делятся на мешы, но при этом вертексы-нормали общие для всей субмодели. Один меш отличается от другого только текстурой. Так вот всё дело в том, что чаще всего нормали сглажены только для отдельно взятого меша, а не для всей субмодели. Проверить это утверждение очень легко - достаточно попробовать нарисовать Glow Shell, используя те нормали, которые уже есть в модели. Ну вы все знаете, как делается Glow Shell:

C++ Source Code:
vec3_t vertex = mesh->vertex + mesh->normal * shell_scale;

В квейках глоушеллы сделаны аналогично, но поскольку там всегда одна текстура на модель, то проблем не возникает. А тут приходится строить новую табличку. Надо сказать, что в 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.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 07-11-2019 в 11:31:

Цитата:
Дядя Миша писал:
придётся разработать новый формат, уже с нормальной индексацией треугольников

В каком смысле с нормальной? Сейчас плохая? Или сейчас всё на стрипы завязано?

Отправлено Дядя Миша 07-11-2019 в 12:56:

Цитата:
nemyax писал:
В каком смысле с нормальной? Сейчас плохая?

Сейчас там raw-поток gl-комманд, к которому нет произвольного доступа, это дичайше неудобно, его приходится каждый раз весь проматывать.
Нормальная индексация, я имею в виду завести структурку triangle и там a,b,c индексы.

Подзагрузил спрайто-кадры в атласы, ну пока не очень плотно. Но для начала сойдет.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 13:07:

Дядя Миша будешь делать обрезалку квадов спрайтов, как хумус завещал?
http://www.humus.name/index.php?ID=266

Отправлено Дядя Миша 07-11-2019 в 15:28:

Не знаю пока насчёт обрезалки. Я тут в коде упаковщика картинок от Кармака баг нашёл. Сначала понять не мог, да что за дерьмо такое, ну вот ситуация. Допустим у нас в спрайте всего 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д обрезалка. Если парт-системы сделать через инстансинг, то смысл безусловно есть. Впрочем там и лучи надо через него же рисовать, но с лучами попроще - их и так не надо обрезать.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-11-2019 в 15:41:

Цитата:
Дядя Миша писал:
Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.

Странная логика, казалось бы как раз поэтому и нужно делать.

Отправлено Дядя Миша 07-11-2019 в 16:19:

Да не, от еденичных спрайтов подряд оно не спасёт. Это для облака партиклей в первую очередь полезно. Вот там да, овердрав, который можно сильно уменьшить.

Добавлено 07-11-2019 в 19:19:

Кстати насчёт того исправления о котором я написал выше. Залез в код ку3 - а там уже исправлено Причём тем же способом.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-11-2019 в 17:08:

Цитата:
Дядя Миша писал:
код ку3

А в код Jedi Academy лазишь?

Отправлено Дядя Миша 07-11-2019 в 20:52:

Та я уже почти никуда не лажу. А если и лажу, то не за кодом, а посмотреть архитектурное решение.

Добавлено 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 мегабайта памяти.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 20:58:

Дядя Миша взвешенное сглаживание нормалей планируешь опциональным делать? Потому что если модель будет с запеченной нормалмапой, то из-за изменений нормалей нормалмапа пойдет по одному месту.

Crystallize ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр. А я ответил, что толку от антиалиасинга не будет, потому что при увеличении даже сглаженной текстуры всё равно полезут пиксели. Так вот, оказалось, что я был неправ, и можно заморочиться, чтоб лайтмапа была более-менее гладкая. Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим. Но видеокарта в него не умеет, поэтому придётся городить огород в шейдере, и фпс немного упадёт, конечно.
Вот вроде бы самый быстрый способ:
http://www.java-gaming.org/index.php?topic=35123.0
Ожидаемый результат примерно такой:
https://ndotl.files.wordpress.com/2018/08/bilinearvsbicubic.jpg
Может, ДМа заинтересует.

Отправлено Дядя Миша 07-11-2019 в 21:57:

Цитата:
ncuxonaT писал:
взвешенное сглаживание нормалей планируешь опциональным делать?

пока вообще не знаю что с ним делать.

Цитата:
ncuxonaT писал:
Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим.

бикубик зараза такая активно провоцирует швы. Нельзя просто взять и заменить фильтр. Надо что-то еще делать с лайтмапой.

Добавлено 08-11-2019 в 00:57:

Ну вот примерно так:

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 22:06:

Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?

Отправлено thambs 08-11-2019 в 01:54:

>https://ndotl.files.wordpress.com/2...arvsbicubic.jpg
Красота какая.

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

Отправлено Crystallize 08-11-2019 в 07:12:

Цитата:
ncuxonaT писал:
ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр.

Спасибо, красиво смотрится.

Цитата:
ncuxonaT писал:
Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?

Ну тогда уж смешать "до" и "после" по маске у которой крайние скажем 5 пикселей это градиент.

Добавлено 08-11-2019 в 14:12:

Я не понимаю почему билинейка такая, она же должна быть мутнее по идее.
Временная зона GMT. Текущее время 12:26. Страницы (255): « Первая ... « 29 30 31 32 [33] 34 35 36 37 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024