Дядя Миша вроде бы уверен.
Вот скрины из презентации оптимизатора мешей AMD Tootle. Сортировкой кластеров они здорово понижают овердроу.
У тебя горы не выпуклые, овердроу по-любому присутствует.
Для включённого Z-Test понятия overdraw бессмысленно.
Это если дракончик полупрозрачный и замкнутый, там да. Наблюдатель не будет его наблюдать извнутри. А что ты с горами сделаешь?
Добавлено 25-05-2020 в 00:11:
И вообще у меня к AMD-шным разработкам крайнее недоверие. Я еще не забыл ихний TrueForm.
Дядя Миша писал: Для включённого Z-Test понятия overdraw бессмысленно.
Ты, верно, шутишь? Если порядок треугольников такой, что сначала рисуются дальние, а потом ближние, то одни и те же пиксели каждый раз перерисовываются.
Отремонтировал декали. В декалях ведь главное что? Чтобы они накладывались и на мир и на энтить одновременно. В халфе меня это всегда бесило.
У этих декалей есть еще один плюс - они переживают сейв\рестор. Ну потому что наносятся компилятором. Это скажем так, нечто вроде infodecal, но если без имени для активации - очевидно их может нанести сам компилятор. Ну примерно как лампочки без имени. Тот же принцип.
Алгоритм нанесения совпадает, так что разобрать какие декали нанёс компилятор, а какие движок невозможно.
Добавлено 25-05-2020 в 09:39:
А. Им теперь углы указывать обязательно, в отличие от халфовских. Ну то есть они конечно пытаются найти средневзвешенную нормаль, но на полисупе порой такая ерунда получается.
Добавлено 25-05-2020 в 10:00:
Поглядел я этот AMD Tootle. В комплекте идут замкнутые мешы, ну естественно. Как предлагается отремонтировать уровень, когда игрок находится внутри меша и может смотреть на треугольники в любом порядке? Вот в кваке с софтрендером, там дерево их правильно сортировало с любой точки зрения. Поэтому там был нулевой овердрав.
А сейчас по факту их дешевле одним дроколом нарисовать, чем пытаться отсортировать по кирпичику. Хотя конечно никто не запрещает.
Добавлено 25-05-2020 в 10:01:
А, он еще и с рейтрейсером, ну вообще чудесно. Это сразу втопку. Даже объяснять лень.
Овердрав солидных объектов смысла не имеет. Да ты почитай тему на геймдеве, я создал вчера. Там народ пишет, что давно уже разницы нет.
Есть и более ранние темы с аналогичным выводом.
Я не вижу смысла в этой сортировке в первую очередь потому, что она значительно замедлит компиляцию, практически ничего не дав взамен.
Потому что, если я рисовал скажем 20к, а нарисую 40к - и то фпс почти не просядет, а ты хочешь чтобы от этой оптимизации был эффект?
ncuxonaT писал: Я думал, мы пытаемся понять, почему от стрипов фпс падает, хотя должен расти.
он и растёт, если разбить меш на маленькие кусочки, а потом их стрипифицировать. Само утверждение, что при стрипификации фпс непременно должен вырасти - ложное. Это зависит от железа.
Добавлено 25-05-2020 в 15:28:
Я слишком хорошо помню времена, когда смена поколений железа на корню убивала все оптимизации. Скажем, до восьмого поколения жирафов, подход используемый в ку3 - рисовать понемногу, трансформировать на CPU, был выгоднее. И даже DrawArrays шустро работал. На восьмом жирафе это резко затормозилось. Опять таки раньше GPU были векторные, теперь они скалярные. Я помню когда в середине нулевых все поголовно увлекались mmx_mempcy который работал быстрее кртшного. Вышел Core2Duo и поставил ситуацию с ног на голову. Но даже если и допустить, что от стрипификации по прежнему должна быть польза. Ну вот навскидку:
1. рисовать выгоднее большими батчами, очевидно.
2. большие батчи тристрип обрабатывает очень долго
3. после этой обработки фпс наоборот падает
Что тут дальше проверять? Тебе хорошо, у тебя не стоит никаких глобальных задач, ты можешь и месяц потратить на эти исследования.
Ну так вперёд, если интересно. Потом расскажешь.
С видимой геометрией пока что всё, теперь колоизация.
Какие варианты есть вообще в принципе?
Самый очевидный - коллизия по сурфейсам. Этого я пока что делать не хочу. С одной стороны оно не требует какой-то предварительной подготовки геометрии, с другой подобная коллизия не слишком надёжна и тяжела в рассчётах. Но конечно можно будет потом попробовать и такую коллизию.
Городить какие-то специальные ускоряющие структуры, BVH, BIH или Kd-tree, я пока что тоже не планирую. Обойдемся уже имеющимся BSP. Опять-таки потом можно будет сравнить, благо BSP самый сложный из всех в построении. Остальные деревья можно строить налиту, резать ничего не надо. Ну и в качестве примитивов для коллизии я планирую по прежнему использовать брашы. Тот баг с залипанием у нечётных сторон я успешно исправил, но дело даже не в этом. У брашей есть важные плюсы:
1. конвексные структуры быстры в детектировании пересечений
2. параметрические конвексные структуры не только быстры, но еще и абсолютно надёжны даже при одинарной точности плавающей.
3. пересечение с плоскостью - самый простой, быстрый и надёжный тип проверки столкновения.
4. у брашей, кроме всего прочего есть еще и такой замечательный параметр как объем. Конечно для конвексных тел его можно использовать в любом случае, но это как-то непринято и не всегда быстро. А определение столкновения с брашем автоматически вычисляет подобные вещи, что очень удобно. Опять же брашами легко задавать объемы среды.
То есть мне в данной ситуации надо решить две задачки: построить коллизию для произвольных патчей и для произвольных моделей.
На данный момент есть как специальные, так и общие кейсы. Основная цель - минимизация кол-ва брашей. Способов аппроксимации коллизии брашами существует несколько штук, но об этом - в следующий раз.
| IP: 
24-05-2020 15:49
