HLFX.Ru Forum - XashNT: блог разработчика

Страницы (255): « Первая ... « 97 98 99 100 [101] 102 103 104 105 » ... Последняя »
Показать все 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)

Отправлено KiQ 24-05-2020 в 15:49:

Дядя Миша возможно зависит от итераций обхода вертексов, при стрипе еще операция возвращения в исходный вертекс или типа того

__________________
-Brain is dead-

Отправлено Дядя Миша 24-05-2020 в 16:09:

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

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 24-05-2020 в 17:18:

Дядя Миша на овердроу не проверял? может, nvtristrip делает такие стрипы, что овердроу сильно большой.

Отправлено Дядя Миша 24-05-2020 в 17:50:

ncuxonaT откуда там овердраву взяться? Ты уверен что правильно понимаешь значение этого термина?

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 24-05-2020 в 18:12:

Дядя Миша вроде бы уверен.

Вот скрины из презентации оптимизатора мешей AMD Tootle. Сортировкой кластеров они здорово понижают овердроу.
У тебя горы не выпуклые, овердроу по-любому присутствует.

Отправлено Дядя Миша 24-05-2020 в 21:11:

Для включённого Z-Test понятия overdraw бессмысленно.
Это если дракончик полупрозрачный и замкнутый, там да. Наблюдатель не будет его наблюдать извнутри. А что ты с горами сделаешь?

Добавлено 25-05-2020 в 00:11:

И вообще у меня к AMD-шным разработкам крайнее недоверие. Я еще не забыл ихний TrueForm.

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 24-05-2020 в 21:18:

Цитата:

Дядя Миша писал:
Для включённого Z-Test понятия overdraw бессмысленно.

Ты, верно, шутишь? Если порядок треугольников такой, что сначала рисуются дальние, а потом ближние, то одни и те же пиксели каждый раз перерисовываются.

Отправлено Дядя Миша 25-05-2020 в 05:48:

Цитата:

ncuxonaT писал:
то одни и те же пиксели каждый раз перерисовываются.

Мда

__________________
My Projects: download page

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

Цитата:

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

Отправлено Crystallize 25-05-2020 в 06:37:

Дядя Миша ты бы хоть отвечал так чтобы у вас была дискуссия которую можно читать, а не "ой, всё!", нам же тоже интересно

Отправлено Дядя Миша 25-05-2020 в 07:01:

Отремонтировал декали. В декалях ведь главное что? Чтобы они накладывались и на мир и на энтить одновременно. В халфе меня это всегда бесило.

У этих декалей есть еще один плюс - они переживают сейв\рестор. Ну потому что наносятся компилятором. Это скажем так, нечто вроде infodecal, но если без имени для активации - очевидно их может нанести сам компилятор. Ну примерно как лампочки без имени. Тот же принцип.
Алгоритм нанесения совпадает, так что разобрать какие декали нанёс компилятор, а какие движок невозможно.

Добавлено 25-05-2020 в 09:39:

А. Им теперь углы указывать обязательно, в отличие от халфовских. Ну то есть они конечно пытаются найти средневзвешенную нормаль, но на полисупе порой такая ерунда получается.

Добавлено 25-05-2020 в 10:00:

Поглядел я этот AMD Tootle. В комплекте идут замкнутые мешы, ну естественно. Как предлагается отремонтировать уровень, когда игрок находится внутри меша и может смотреть на треугольники в любом порядке? Вот в кваке с софтрендером, там дерево их правильно сортировало с любой точки зрения. Поэтому там был нулевой овердрав.
А сейчас по факту их дешевле одним дроколом нарисовать, чем пытаться отсортировать по кирпичику. Хотя конечно никто не запрещает.

Добавлено 25-05-2020 в 10:01:

А, он еще и с рейтрейсером, ну вообще чудесно. Это сразу втопку. Даже объяснять лень.

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 25-05-2020 в 10:09:

Цитата:

Дядя Миша писал:
А сейчас по факту их дешевле одним дроколом нарисовать

Так они и рисуют одним, только индексы предварительно сортируют. Короче сравнивать овердроу со стрипами и без них ты отказываешься, так?

Отправлено Дядя Миша 25-05-2020 в 11:19:

Овердрав солидных объектов смысла не имеет. Да ты почитай тему на геймдеве, я создал вчера. Там народ пишет, что давно уже разницы нет.
Есть и более ранние темы с аналогичным выводом.
Я не вижу смысла в этой сортировке в первую очередь потому, что она значительно замедлит компиляцию, практически ничего не дав взамен.
Потому что, если я рисовал скажем 20к, а нарисую 40к - и то фпс почти не просядет, а ты хочешь чтобы от этой оптимизации был эффект?

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 25-05-2020 в 11:49:

Цитата:

Дядя Миша писал:
Овердрав солидных объектов смысла не имеет.

Не понимаю, почему ты так считаешь. Можешь включить блендинг (не выключая тест глубины) и посмотреть, сколько раз одни и те же места перерисовываются.

Цитата:

Дядя Миша писал:
Потому что, если я рисовал скажем 20к, а нарисую 40к - и то фпс почти не просядет

Я думал, мы пытаемся понять, почему от стрипов фпс падает, хотя должен расти.

Отправлено Дядя Миша 25-05-2020 в 12:28:

Цитата:

ncuxonaT писал:
Я думал, мы пытаемся понять, почему от стрипов фпс падает, хотя должен расти.

он и растёт, если разбить меш на маленькие кусочки, а потом их стрипифицировать. Само утверждение, что при стрипификации фпс непременно должен вырасти - ложное. Это зависит от железа.

Добавлено 25-05-2020 в 15:28:

Я слишком хорошо помню времена, когда смена поколений железа на корню убивала все оптимизации. Скажем, до восьмого поколения жирафов, подход используемый в ку3 - рисовать понемногу, трансформировать на CPU, был выгоднее. И даже DrawArrays шустро работал. На восьмом жирафе это резко затормозилось. Опять таки раньше GPU были векторные, теперь они скалярные. Я помню когда в середине нулевых все поголовно увлекались mmx_mempcy который работал быстрее кртшного. Вышел Core2Duo и поставил ситуацию с ног на голову. Но даже если и допустить, что от стрипификации по прежнему должна быть польза. Ну вот навскидку:
1. рисовать выгоднее большими батчами, очевидно.
2. большие батчи тристрип обрабатывает очень долго
3. после этой обработки фпс наоборот падает
Что тут дальше проверять? Тебе хорошо, у тебя не стоит никаких глобальных задач, ты можешь и месяц потратить на эти исследования.
Ну так вперёд, если интересно. Потом расскажешь.

__________________
My Projects: download page

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

Цитата:

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

Отправлено Дядя Миша 25-05-2020 в 18:45:

С видимой геометрией пока что всё, теперь колоизация.
Какие варианты есть вообще в принципе?
Самый очевидный - коллизия по сурфейсам. Этого я пока что делать не хочу. С одной стороны оно не требует какой-то предварительной подготовки геометрии, с другой подобная коллизия не слишком надёжна и тяжела в рассчётах. Но конечно можно будет потом попробовать и такую коллизию.

Городить какие-то специальные ускоряющие структуры, BVH, BIH или Kd-tree, я пока что тоже не планирую. Обойдемся уже имеющимся BSP. Опять-таки потом можно будет сравнить, благо BSP самый сложный из всех в построении. Остальные деревья можно строить налиту, резать ничего не надо. Ну и в качестве примитивов для коллизии я планирую по прежнему использовать брашы. Тот баг с залипанием у нечётных сторон я успешно исправил, но дело даже не в этом. У брашей есть важные плюсы:
1. конвексные структуры быстры в детектировании пересечений
2. параметрические конвексные структуры не только быстры, но еще и абсолютно надёжны даже при одинарной точности плавающей.
3. пересечение с плоскостью - самый простой, быстрый и надёжный тип проверки столкновения.
4. у брашей, кроме всего прочего есть еще и такой замечательный параметр как объем. Конечно для конвексных тел его можно использовать в любом случае, но это как-то непринято и не всегда быстро. А определение столкновения с брашем автоматически вычисляет подобные вещи, что очень удобно. Опять же брашами легко задавать объемы среды.

То есть мне в данной ситуации надо решить две задачки: построить коллизию для произвольных патчей и для произвольных моделей.
На данный момент есть как специальные, так и общие кейсы. Основная цель - минимизация кол-ва брашей. Способов аппроксимации коллизии брашами существует несколько штук, но об этом - в следующий раз.

__________________
My Projects: download page

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

Цитата:

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

Временная зона GMT. Текущее время 00:24.

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