ПрограммированиеФорумГрафика

Посоветуйте оптимизацию сцены

Страницы: 1 2 Следующая »
#0
19:00, 21 фев 2012

Привет всем. В ходе разработки движка возникли известные всем, я думаю, проблемы со скоростью. Опишу вкратце как и что рисую:
Сцена состоит из фейсов, каждый имеет свой материал. Они рисуются по отдельности(знаю что плохо). Когда речь идет о небольшом уровне - все рисуется нормально, когда я его увеличиваю и добавляю геометрию в некоторых местах FPS стал заметно проседать.
Сцена грузится из MAP файла(Vavle Hammer Editor), и по ней строится Octree. Проверка видимости сейчас производится только по Octree. Систему порталов я пока отбрасываю по причине того, что у меня не закрытые пространства. Практически везде в картах нет потолка - скай бокс.
Посоветуйте пожалуйста различные оптимизации для сцены.
Полазил по форуму в поисках информации по Occlusion Culling, как я понял сильного прироста он мне не даст?
Для освещения применяется DS, от количества источников, как Вы понимаете, FPS не зависит, только от геометрии. Возможно ли спасти положение и прикрутить оптимизации для сцены или придется компилировать уровень в CSG, c сортировкой по материалам и объединением по возможности в большие объекты? Какие именно оптимизации стоит вводить?

#1
20:11, 21 фев 2012

Если С++, то можно сделать следующее.

Объявить переменные так

register int xx = 0;
register int yy = 0;
register int kk = 0;
register int tt = 0;

Таким образом переменные помещаются в память процессора или по-другому кеш L2 или L3.

Я думаю что для 2 и 4 переменных всё будет хорошо!

Кеш процессора маленькая, зависит много от того какой процессор попадется.

У некоторых 512 килобайт. 1024 к. 2048 к. 4096к. 8182 к.

Но если кеш будет полон, то это не вызовет ошибки.
Переменные поместятся в кучу, в оперативную память ОЗУ.

Можно выиграть в быстродействии если эти переменные очень часто используются в коде, например в циклах.

#2
20:15, 21 фев 2012

dige
> Таким образом переменные помещаются в память процессора или по-другому кеш L2
> или L3.
да, а мне всегда казалось что компилятор просто будет стараться держать переменные в регистрах, если это возможно.

#3
20:15, 21 фев 2012

DirectXManiac
> Сцена состоит из фейсов, каждый имеет свой материал. Они рисуются по
> отдельности(знаю что плохо).
Фейс это один треугольник? На один треугольник один дип?
Фишка DS в том, что у нас очень часто один пиксельный шейдер. Можно отсортировать по нему. Скошлько треугольников в сцене, сколько дипов?

#4
20:16, 21 фев 2012

dige
Нет, c#. Спасибо все равно за идею, попробую оптимизировать код сначала и ещё возникла мысль правильно рисовать уровни, тогда октри будет точнее отсекать(т.е. не рисовать пол общий для всей карты а дя каждой комнаты свой), должно помочь...
Есть какие-то ещё методы? Occlusion Culling точно не спасет?

#5
20:19, 21 фев 2012

QzR!!!
Нет не треугольник, а грань, от 2 до хз скольки треугольников в зависимости от формы грани, а как подругому если текстуры у всех фейсов будут разные например? Я подумываю о группировке фейсов в один DIP внутри объекта по имени материала...

#6
20:23, 21 фев 2012

Можешь писать библиотеки DLL на С++ и вызывать из С#

#7
20:23, 21 фев 2012

DirectXManiac
> Нет не треугольник, а грань, от 2 до хз скольки треугольников в зависимости от
> формы грани, а как подругому если текстуры у всех фейсов будут разные например?
> Я подумываю о группировке фейсов в один DIP внутри объекта по имени
> материала...
Уже хорошо, а текстуры можно сшить в атлас, если сильно маленькие или часто меняются.
Так всё-таки сколько дипов и треугольников за кадр?

#8
20:27, 21 фев 2012

DirectXManiac
Если карта очень большая, то включаем туман и кулим по дальности.

#9
20:31, 21 фев 2012

Чтобы оптимизировать, надо знать что оптимизировать :)

Правильно были заданы вопросы:
> Фейс это один треугольник? На один треугольник один дип? Сколько треугольников в сцене, сколько дипов?

но ответов на них нет в теме...


> Посоветуйте пожалуйста различные оптимизации для сцены.

Начать стоит с объединения частей с одинаковыми материалами/текстурами, ибо "Сцена состоит из фейсов, каждый имеет свой материал" есть очень плохо.
А вообще, движки Source/Quake из map файлов по традиции создавали bsp дерево. А раз карта из map файла, то и оптимизировать стоит соответствующим образом.

#10
20:31, 21 фев 2012

QzR!!!
> Уже хорошо, а текстуры можно сшить в атлас, если сильно маленькие или часто
> меняются.
Не думаю, что ещё и карты нормалей сшивать и specular maps сшивать? а материалы?

> Так всё-таки сколько дипов и треугольников за кадр?

Если тр-ков 1000, то DIP-ов в среднем 400-500 на карту, это много, очень много... надо сшивать... как минимум...
QzR!!!
> Если карта очень большая, то включаем туман и кулим по дальности.
Ну туман в космосе че то нереальное... хотя... тоже вариант, была мысль

#11
20:33, 21 фев 2012

> Если тр-ков 1000, то DIP-ов в среднем 400-500 на карту,

ох ё маё.... жесть :) ну не 500 же там одинаковых материалов))) наверное и текстур то столько нет =) так что надо группировать в один вершинный буфер и рисовать за один раз =)

#12
20:36, 21 фев 2012

Есть такие планеты, там так горячо, что вся планета окутана газовой пылью!
Дуют ветра с железной пылью.
Раскаленные планеты.

Туман есть! (^_^)

#13
20:42, 21 фев 2012

ASD
А как же Octree отсечение? Если один меш будет содержать пол сцены, как тогда отсечение устроить? В любом случае буду объединять, тока надо ж чтоб отсечение работало...

#14
20:48, 21 фев 2012

DirectXManiac
> Если тр-ков 1000, то DIP-ов в среднем 400-500 на карту, это много, очень
> много... надо сшивать... как минимум...
Платформа? Если это 30% того, что вообще рисуется - тогда проблема, иначе на ПК - нет. Тысячу дипов вполне себе держит. Но как получается 500 дипов при 1000 треугольников - не понятно. Группировать по материалам, сшивать. Кулить тут пока нечего. Если что-то хардкорное под мобильники в стиле quake - то смотри bsp.

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.