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

Страницы (255): « Первая ... « 24 25 26 27 [28] 29 30 31 32 » ... Последняя »
Показать все 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)

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

Это операторы словами:
GL_EQUAL ==
GL_NOTEQUAL !=
GL_GREATER >
GL_LESS <
GL_GEQUAL >=
GL_LEQUAL <=

Добавлено 28-10-2019 в 13:46:

Цитата:

Crystallize писал:
По-моему ты с ума сойдёшь всё это документировать.

наоборот. Достаточно понять общие принципы, а дальше сработает экстраполяция.

__________________
My Projects: download page

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

Цитата:

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

Отправлено Дядя Миша 30-10-2019 в 15:51:

Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.

Добавлено 30-10-2019 в 18:51:

Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.

__________________
My Projects: download page

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

Цитата:

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

Отправлено ncuxonaT 30-10-2019 в 16:18:

Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?

Отправлено XaeroX 30-10-2019 в 16:37:

ncuxonaT
У меня тут одна знакомая дочь офицера говорила по поводу з-препасса, что... ну ты понял.

__________________

Отправлено Crystallize 30-10-2019 в 16:49:

BSP геометрию при загрузке конвертить в модель

Отправлено Дядя Миша 30-10-2019 в 17:09:

Цитата:

ncuxonaT писал:
Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?

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

Цитата:

Crystallize писал:
BSP геометрию при загрузке конвертить в модель

Модели фундаментально отличаются от брашей, если ты еще не понял.
Способом их редактирования. В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру. Для брашей всё строго наоборот, там ты нарисовал кубек и каждую грань покрасил в свою текстуру. Текстура поменялась - стоп конвейер, перезапуск отрисовки.
Текстуры нельзя склеить в атлас, т.к. они с тайлингом. Текстуры нельзя склеить в 2Д массив, т.к. во первых они все разного размера, во вторых 2д массивы довольно таки тормозны, на удивление, на старом железе. А где то их нет вообще.

Добавлено 30-10-2019 в 20:07:

ЗЫ, биндлесс текстур на старом железе нет тем более.

Добавлено 30-10-2019 в 20:09:

Кстати говоря, насчёт отсечения. Возьмем пресловутый сипульчер. Там примерно триста тысяч фанов. С визом и куллингом, средняя видимость - ну тысяч 18, а то и меньшы. Конечно ежели бы этот сипульчер покрыть одной текстурой, будет очень быстро

__________________
My Projects: download page

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

Цитата:

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

Отправлено KiQ 30-10-2019 в 17:17:

Дядя Миша текстуры можно собрать в атлас с GL_NEAR, а фильтрацию делать в шейдере, но это, конечно извращение немножк

__________________
-Brain is dead-

Отправлено nemyax 30-10-2019 в 17:24:

Цитата:

Дядя Миша писал:
В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру

Никто не заставляет в единую. Хочешь натягиваешь несколько по вкусу. Толку-то объединять, если моделек всё равно много и текстуры на них разные.

Отправлено Crystallize 30-10-2019 в 17:24:

Цитата:

Дядя Миша писал:
Текстуры нельзя склеить в атлас, т.к. они с тайлингом.

нифкурил

Отправлено nemyax 30-10-2019 в 17:29:

Crystallize
Если текстурные координаты за пределами единичного квадратика, то на атласе они бы брали чужие текстуры.

Отправлено Crystallize 30-10-2019 в 17:36:

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

Отправлено KiQ 30-10-2019 в 17:41:

Crystallize для каждого атласа заводить texture region по количеству изначальных текстур, которые будут клампить оффсет?

__________________
-Brain is dead-

Отправлено Дядя Миша 30-10-2019 в 17:53:

Crystallize это всё было бы хорошо в теории, если бы не существовало пирамидальной фильтрации, анизотропной фильтрации и других страшных слов.

Добавлено 30-10-2019 в 20:53:

Цитата:

KiQ писал:
а фильтрацию делать в шейдере

пирмаидалку вручную делать? нафиг-нафиг. Сам бы попробовал штоли.

__________________
My Projects: download page

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

Цитата:

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

Отправлено KiQ 30-10-2019 в 18:14:

Ну так а это, сортировать видимые фейсы в текстурные списки?

__________________
-Brain is dead-

Отправлено Дядя Миша 30-10-2019 в 20:42:

Первые эксперименты по оптимизации.
Чёт какой-то COF получился.

Добавлено 30-10-2019 в 22:01:

Цитата:

KiQ писал:
видимые фейсы в текстурные списки?

что такое текстурные списки?

Добавлено 30-10-2019 в 23:34:

Вообще я подозреваю, мне просто нужно что-то из функционала GL посвежее. Я попробовал так же через glDrawArrays рисовать, ему индексов вообще не нужно. Но это deprecated по идее. Да и не всегда оно быстрее.

Добавлено 30-10-2019 в 23:42:

Гм. Похоже всё еще хуже. glDrawArrays просто экономит время, которое я трачу на генерацию индексов на CPU. И при сравнении оказалось, что это весьма незначительная часть процесса. Настолько незначительная, что разница даже в дебаге минимальна. Ну она есть конечно, скажем в релизе там 1100 фпс, а в дебаге 1030 фпс. Но и только.

__________________
My Projects: download page

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

Цитата:

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

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

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