Я понял об чём ты говоришь, но повторюсь, используется нормаль от поверхности, которую вернула трасса. Если использовать нормаль от взгляда - получится проекция.
Впрочем код клиппинга декалей возможно будет ещё меняться.
Добавлено 27-08-2023 в 11:30:
Можно ещё сделать что: пробежаться по дереву, собрать все потенциальные сурфейсы, пробежаться по сурфейсам, из каждого треугольника посчитать нормаль, сложить все нормали и получить среднее.
В компиляторе я так и делаю.
Ну да, нетривиальная задача, тут либо растягивать рисунок декали, либо вот такие пропуски, и то и то выглядит так себе. Видимо нужно брать нормаль не от проекции, а высчитывать какую то среднюю нормаль от поверхности. В общем хз.
Дядя Миша
А можешь визуализировать сетку твоих декалей и пофоткать с разных ракурсов? Мне всегда было интересно, как они ложатся.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
В принципе можно заморочиться и уничтожить смежные рёбра там где по смыслу они не нужны, но на скорость отрисовки это не влияет, а время постановки - увеличивает. Смысла нет.
Цитата:
FiEctro писал: а высчитывать какую то среднюю нормаль от поверхности
Ну да, я про это и говорю. Компилятор bsp у меня именно этим и занимается.
В радиусе места постановки декали собирает все поверхности, берёт от них нормаль и вычисляет среднюю. И вот эта нормаль берётся как база для проекции.
Добавлено 27-08-2023 в 13:18:
По срокам и задачам напишу. Что мне ещё осталось сделать:
1. Декали на моделях (пока что только на скелетных)
2. Сохранение декалей в сейв
3. Систему партиклей (сейчас их нет вообще никаких)
4. Полная ревизия и отладка.
И будет демка. Конец септямбря ориентировочно. Но загадывать не буду.
Добавлено 27-08-2023 в 14:21:
Поскольку декали являются частью общей системы материалов, можно делать вот такие вот вещи.
Дядя Миша писал: Вот единичная декаль, тут получше видно.
Спасибо!
Цитата:
Дядя Миша писал: В радиусе места постановки декали собирает все поверхности, берёт от них нормаль и вычисляет среднюю. И вот эта нормаль берётся как база для проекции.
Это замечательно. Сделай ещё слои для объектов и декалей, чтобы на одни объекты они могли накладываться, а на другие нет. Очень полезная штука.
Цитата:
Дядя Миша писал: Компилятор bsp у меня именно этим и занимается.
Кстати, соррян что отхожу от темы, но как у тебя обстоят дела с Т-джунками? Планируется какой нибудь фикс для них?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша писал:
Можно ещё сделать что: пробежаться по дереву, собрать все потенциальные сурфейсы, пробежаться по сурфейсам, из каждого треугольника посчитать нормаль, сложить все нормали и получить среднее.
В компиляторе я так и делаю. [/B]
Вот как раз в этом случае тебе нужна матрица смежности.
Дядя Миша писал: Ну есть флажок nodecals, если ты об этом. А вот так чтобы слоями, ну типа в три слоя декали наложились, а на четвёртый - ну ни в какую, этого нет.
Ну вот в сорсе к примеру в материале можно указать какая декаль будет накладываться, там стекло, дерево или ещё что нибудь. Но по мне это не очень удачный вариант. Надо указывать лучше сам ресурс, а не тип поверхности.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Декали готовы. И на моделях и на брашах. И они сохраняются в сейв.
И да, действительно можно накладывать без ограничений - они никогда не удаляются, только накапливаются. Впрочем потом надо будет сделать более гибкие настройки в этом плане конечно. Иногда декали надо удалять по сюжету.
Перехожу к имплементации клиентских эффектов.
У нас это темпэнтити, лучи, партиклы и трасеры.
С новой архитектурой ксаша никакие дурацкие темп-энтити мне не понадобятся. Буду использовать обычные - это намного удобнее во всех отношениях. С лучами пока всё очень туманно, никакая концепция в голове не вырисовывается. Но к счастью в Кваке таких лучей нету, а значит пока что этот вопрос можно отложить в сторону. А те лучи, которые используются в кваке сделаны из темпэнтить сегментами. Так что тут вопрос закрыт.
А вот партиклы надо сделать обязательно. Какая же игра без партиклов?
Это первый дуум ещё как-то без них мог обходиться. Но сделать партиклы с моей архитектурой движка будет не так-то просто. Рисовать партиклы через глбегин я не могу. Можно сделать через инстансы, но я с ними никогда не работал. К тому же у меня конвейер под них не настроен, а вообще инстансы будут нужны, например для отрисовки инстанс-моделей и я полагаю, эту работу имеет смысл выполнить разом для всего. Поэтому пока что мне представляется следующая схема организации партиклов:
1. как и декали, партиклы будут прикрепляться к модели. Если же прикрепления не предполагается, то будут аттачится к миру.
2. апдейт предполагает обновления всех позиций партиклей, а так же изменения их цвета, т.е. стандартная эвалюация.
3. обновлённые данные заливаются в VBO в конце кадра. Та часть партиклов, которая уже вышла из строя, просто получает нулевую прозрачность. И по этому критерию для нее перестаёт выполняться обновление. Когда все партиклы получат нулевую прозрачность, считается что парт-система выработала свой ресурс и может быть освобождена.
4. технически каждый партикл представлен в виде четырёх вертексов и шести элементов, причём во все четыре вертекса записана текущая позиция партикла, а трансформация поворота к камере выполняется на видеокарте. Да, тут есть избыточность, но во первых в одной партсистеме партиклов обычно не так уж и много (128-256 максимум), а во вторых без инстансов эту проблему всё равно не решить. Зато все партиклы, принадлежащие одному эффекту рисуются за один вызов, что тоже положительно сказывается на оптимизации.
5. Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей. А так же использовать и сами спрайты в качестве партиклей. Аналогично сделано и для декалей - шейдер мировых декалей использует шейдер для отрисовки мира. Меньше уникальных шейдеров - меньше их переключений, выше фпс. Но конечно никто не мешает написать и собственный.
6. Партиклы всегда добавляются в очередь прозрачных полигонов и их возможно отсортировать по дальности. Но только в рамках целой партсистемы,а не каждой частички. Впрочем и это неплохо, т.к. партиклы обычно вообще никто не сортирует.
Пока что так всё это вижу.
Добавлено 30-08-2023 в 16:39:
У прочитавших вышесказанное наверняка возникнет вопрос, мол почему бы и с лучами не поступить так же как с партиклами, хранить сегменты обновлять в шейдере. А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.
Дядя Миша писал: Буду использовать обычные - это намного удобнее во всех отношениях.
Неплохо сделать возможность стаковать несколько энтитей ввиде одного объекта, чтобы не приходилось городить огромные гирлянды из объектов. Ну и конечно добавлять свой скрипт ввиде такой же энтити.
Цитата:
Дядя Миша писал: Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей.
А если я захочу вместо спрайта модельку вставить? Мы кстати для оптимизации делали спрайт именно ввиде треугольника, а не квадрата как результат фпс в 2 раза выше А ведь есть ещё компонент который с помощью скрипта может сам по себе какую угодно фигню из вертексов и полигонов рисовать
Цитата:
Дядя Миша писал: У прочитавших вышесказанное наверняка возникнет вопрос, мол почему бы и с лучами не поступить так же как с партиклами, хранить сегменты обновлять в шейдере. А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.
Сначала ответь на вопрос что такое вообще партикля? Это инстансер объектов (задаёт количество и время), т.е. их спавнер, а дальше ты задаёшь уже поведение этим объектам с помощью генераторов или может даже задания им свойств обычных энтитей, почему нет?
Цитата:
Дядя Миша писал: А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.
Для лучей не нужно 2 точки, у луча есть координата его начала и направление (по желанию ещё длинна и его субдивайд, если мы хотим например его искривлять как молнию). Но если уж точно нужно прицелиться в какой то объект, есть констрейнт LookAt.
Кстати насчёт лучей, добавь ещё нативные безъе пути, это очень удобная штука, которой как правило нет из коробки ни в одном движке. Ну может разве что в волатиле.
Цитата:
Дядя Миша писал: 5. Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей. А так же использовать и сами спрайты в качестве партиклей. Аналогично сделано и для декалей - шейдер мировых декалей использует шейдер для отрисовки мира. Меньше уникальных шейдеров - меньше их переключений, выше фпс. Но конечно никто не мешает написать и собственный.
Так а в чём проблема? Спрайт имеет свой материал, а материал может иметь какой угодно шейдер. Я никогда не понимал нафига хранить 2д графику в разных форматах? Для текстур свой формат, для UI свой, для спрайтов свой формат, для скайбоксов свой, для кого этот изврат?
В Юнити кстати есть GPU Instance для всех одинаковых материалов с одним шейдером в сцене, я не знаю как он работает, но подымает ФПС он очень хорошо, когда много объектов с одним материалом.
Цитата:
Дядя Миша писал: Декали готовы. И на моделях и на брашах. И они сохраняются в сейв.
И да, действительно можно накладывать без ограничений - они никогда не удаляются, только накапливаются. Впрочем потом надо будет сделать более гибкие настройки в этом плане конечно. Иногда декали надо удалять по сюжету.
Круто Не забывай что декалям можно например ещё задавать сортировку, ну например маппер налепил в одном углу кучу декалей, а ему нужно чтобы они ложились в определенном порядке друг на друга.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Я никогда не понимал нафига хранить 2д графику в разных форматах?
Ну вот вальвовцы тоже не понимали - нафига. В результате в халфе худ хранится в самых обычных спрайтах, а ректанглы в них люди должны вручную прописывать, руководствуясь видимо пролетарским чутьём, не иначе. Потому что в прописывании этих ректанглов лажали абсолютно все.
И я в том числе. И их ненавидели прописывать, да. Но зато всё в одном формате, как ты любишь.
Объясняю:
1. Текстура - это просто сборище пикселей и к ним идёт хидер с информацией о сжатии, а так же долготе и широте. Это не трёхмерный объект и не двухмерный объект. Это просто raw-массив.
2. Шрифты (атласы) содержат в себе текстуру и ректанглы, описывающие участки на этой текстуре, которые можно (и нужно) считать отдельными изображениями. Делается это из целей оптимизации - одну текстуру быстрее грузить, одну текстуру быстрее рисовать. А информация о регионах поможет нам быстро ориентироваться. Обычно она ассоциируется либо с индексом буквы (если это обычный шрифт), либо со специальным именем, если это шрифт картинок. Но и лайтмапы можно тоже хранить в таком вот шрифте, конечно.
3. Спрайты (ну по крайней мере в моём случае), это не просто картинка и не просто набор картинок. Это трёхмерная геометрия запечённая в GPU-friendly буфферы, информация о регионах и картинка. Под термином спрайт может скрываться всё что угодно. Там может быть классический спрайт-биллбоард, может быть импостор или моделька кустика травы.
Ну вообщем что-то такое, что имеет кастомную геометрию, но при этом не имеет коллизии. Так же на кадры спрайта можно привязать разную геометрию, по типу как body у моделей. Разница в том что такая геометрия статична лишена разных зависимостей и гораздо более оптимальна для инстансинга. Да и для темп-энтить тоже. В халфе, как ты знаешь, даже для статичной модели обязательно считаются кости, не бывает моделек без костей. Это расточительно. Вот мои спрайты в данном случае замена таким моделькам.
4. Скайбоксы. Скайбокс это кубемапа, т.е. трёхмерная текстура. Лукап в нее осуществляется вектором. Вроде бы и raw-массив, но хитрый. Опять же к геометрии никакого отношения не имеет.
Цитата:
FiEctro писал: Мы кстати для оптимизации делали спрайт именно ввиде треугольника, а не квадрата как результат фпс в 2 раза выше
Страшно подумать, что творится с юнити, если он надорвался рисовать целых два треугольника.
Цитата:
FiEctro писал: Для лучей не нужно 2 точки
Это смотря какие лучи. Если лазер, то да, достаточно одной точки и направления. А есть лучи, которые именно что приаттачены к двум точкам. Причём обе точки могут быть как на одной энтите, так и на разных.
Цитата:
FiEctro писал: GPU Instance для всех одинаковых материалов с одним шейдером в сцене
А ты подумай на минуточку, почему эта штука не включена по умолчанию и навсегда.
Цитата:
FiEctro писал: ну например маппер налепил в одном углу кучу декалей, а ему нужно чтобы они ложились в определенном порядке друг на друга.
Это статичные декали, у меня их компилятор считает и они вкомпиливаются прямо в карту. Ещё не хватало такое в рантайме делать.
Добавлено 30-08-2023 в 23:53:
Цитата:
FiEctro писал: Я никогда не понимал нафига хранить 2д графику в разных форматах?
Так может ты поэтому до сих пор свою игру никак сделать не можешь, что кое-чего не понимаешь?
Ну да ладно. По здравом размышлении понял, что городить огород ради одних только партиклей смысла не имеет. Тут нужна большая клиентская система визуальных эффектов. Выносить это в скриптовой язык не буду - система прекрасно параметризуется, а условий там нету, равно как и каллбэков. Точнее говоря, каллбэков там можно придумать ровно два штуки - по удалении временного эффекта и по его коллизии с геометрией.
И сделать обратную связь на те же визуальные эффекты. Ну то есть мы стреляем такой специальной лучевой пушкой в стену, от нее отваливается сгусток энергии в виде шара, падает на землю, при соударении распадается на множество мелких шариков, которые плавно гаснут. Ну что-то вроде такого. Понятно, что на скриптах такое делать затратно, а каких-то сложных условий тут нет.
В принципе к чему-то аналогичному пришли и в форках кваки, в таких как даркплейс или FTE. Но честно говоря, там описание скриптов мозговзрывающее, приведу характерный пример такого скрипта для Arcane Dimensions.
C++ Source Code:
1
effect TE_GUNSHOT
2
count 1
3
type static// вот это тяжелое наследие из кода кваки. Таких переключателей быть вообще не должно
4
color 0x101010 0x707070 // RGBA упакованный в unsigned long. Симпатично, а главное как удобно!
5
tex 32 36 // вручную предлагается прописывать размер текстуры или я не понял
6
size 1 2 // это начальный и конечный размер, а может быть рандомный диапазон?
7
sizeincrease 2 // а это тогда что?
8
alpha 64 96 48 // альфа с тремя параметрами?
9
velocityjitter 8 8 4 // почему джиттер по трём осям но без диапазона рандомности,
10
gravity 0.01 // слава богу, хоть тут всё логично, это фактор.
Ну и вот такое вот оно там. Хрен победи как его использовать, тем более без визуального редактора.