Правильная отрисовка BSP в OpenGL 3.3+ (2 стр)

Maris
Ты занимаешься оптимизацией приложения, скомпиленного В ДЕБАГЕ? О__________о
Чего только не встретишь на любимом форуме..

Ну он же не физику отлаживает, например. Для рендеринга разница не слишком большая, в дебаге только сортировка будет сильно тормозить.
А вообще я бы делал так:
1. копим все видимые сурфейсы в отдельный список
2. сортируем список по материалу\шейдеру, прозрачности итд
3. копим индексы в intermediate buffer (сам уровень в одном статическом VBO)
4. как токо сменился материал\шейдер - рисуем накопленное
Хотя, если честно прирост от накопительства небольшой. В OpenGL кол-во дипов слабо влияет на FPS.

g-cont
> Ну он же не физику отлаживает, например.
Он отлаживает код, переполненный шаблонами и функциями-аксессорами. Ничего, да?
> В OpenGL кол-во дипов слабо влияет на FPS.
Смотря что ты понимаешь под "дипом". Если draw-команду - то да, там же несколько иначе всё организовано, и питфол в glVertexPointer. Не исключено, что драйвер буферизует draw calls.

Вобщем, кое-как поборол эту проблему. Решилась кешированием видимых индексов для N последних кластеров, где были.  Так же перевел из деверда в форваред. Правда, пришлось отказаться от обрезания геометрии по фруструму (пока не ясно, как это прикрутить ее к кешу). Кол-во выводимой геометрии увеличилось с 1000 до 1100 треугольников.

В результате сборка индексов занимает раз в 20 меньше времени в среднем (понятно - берется из кеша). ФПС вырос до 500 и уперся уже в вызов команд OpenGL:

1. Комадны вывода OpenGL выполняются примерно за 1100 мкс.
2. Переключение буффров выполняется за 900 мкс (!). Это как? Всегда думал, что быстрее намного должно быть.

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

Maris
> А критические места, что в дебаге, что в релизе одни и те же будут.
В общем случае это утверждение неверно. Оптимизация делается не с целью ускорить все функции, а с целью ускорить самые медленные. А их надо искать в релизе, а не дебаге.
Приведу всего один пример: оптимизация с использованием SSE-интринсиков в дебаге не даёт вообще никакого прироста, а иногда может привести и к падению производительности. Но стоит собрать проект в релизе - картина меняется кардинально. И то, что раньше было критическим местом, перестаёт им быть.

Maris
> Переключение буффров выполняется за 900 мкс (!). Это как? Всегда думал, что
> быстрее намного должно быть.
glBindBuffer или glBindVertexArray? Первое быстрое, второе медленное, почему - я написал постом выше твоего.

Моласар
Я бы на твоём месте вообще не парился. Сейчас даже на самой хилой видеокарте нарисовать 1 уровень от Quake III почти ничего не стоит. Так что всю непрозрачную статичную геометрию можно за раз рисовать, предварительно отсортировав по материалам.

Panzerschrek[CN]
Я и не парюсь, просто говорю, как есть.
> Так что всю непрозрачную статичную геометрию можно за раз рисовать,
> предварительно отсортировав по материалам.
Но ты же в курсе, да, что в ку3 многослойные материалы с анимациями цветов, текстурных координат, а иногда и вертексов, и для каждого такого материала нужен либо многослойный шейдер, либо делать несколько проходов?
И да, как ты собрался рисовать всё за один раз без переключения текстур, учитывая, что в ку3 сотни текстур без учёта многослойных эффектов? Чему равен MAX_ARRAY_TEXTURE_LAYERS на "самой хилой видеокарте"? 64? 128?

Моласар
> Но ты же в курсе, да, что в ку3 многослойные материалы с анимациями цветов,
> текстурных координат, а иногда и вертексов, и для каждого такого материала
> нужен либо многослойный шейдер, либо делать несколько проходов?
В курсе. Всю многослойность сейчас можно сделать в один проход одним шейдером.
> И да, как ты собрался рисовать всё за один раз без переключения текстур,
> учитывая, что в ку3 сотни текстур без учёта многослойных эффектов?
Я видимо не удачно выразился. Я имел в виду рисовать за один раз все полигоны уровня с заданным материалом, не заморачиваясь с обходом BSP дерева и отсечением по пирамиде видимости. Ну и буфер индексов при этом строить надо один раз - при загрузке уровня.
В MAX_ARRAY_TEXTURE_LAYERS ты не упрёшься, в Quake III нету столько текстур с одинаковым размером, чтобы их можно было в один текстурный массив складывать.

Panzerschrek[CN]
> Я имел в виду рисовать за один раз все полигоны уровня с заданным материалом,
> не заморачиваясь с обходом BSP дерева и отсечением по пирамиде видимости.
Да, прекрасно. А потом кто-нибудь засунет в движок вот эту ку3-карту:
http://www.youtube.com/watch?v=QrRwmvLNFGw#t=54
И всё подохнет даже не на геометрии и не на конском overdraw, а на переключениях текстур, шейдеров и стейтов.

Panzerschrek[CN]
> В курсе. Всю многослойность сейчас можно сделать в один проход одним шейдером.
Я почти уверен, что смогу сделать такой ку3шный эффект (работающий в ку3), который не удастся сделать "в один проход одним шейдером", по крайней мере без грязных хаков. :)

Моласар
> Я почти уверен, что смогу сделать такой ку3шный эффект (работающий в ку3),
> который не удастся сделать "в один проход одним шейдером", по крайней мере без
> грязных хаков.
Код такого q3 шейдера в студию! А я напишу тебе по нему GLSL шейдер.

Panzerschrek[CN]
> Код такого q3 шейдера в студию! А я напишу тебе по нему GLSL шейдер.
Ну допустим, вот:

test
{
  {
    map "map1"
    blendFunc add
  }
  {
    map "map2_with_alpha"
    depthWrite
  }
}

Вполне распространённая задача, между прочим. Нарисовать что-нибудь прозрачненькое, а поверх накрыть решёткой.

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

Panzerschrek[CN]
Конкретно в ку3 есть шейдер "textures/base_wall/glass_frame", который примерно так и реализован. Но тебе, конечно, больше, чем Кармаку, виднее, что корректно, а что нет.
Я прекрасно знаю, что есть такая категория людей, которая будет отмазываться до последнего: "это некорректно", "это не нужно", "это мы скажем дизайнеру так не делать" и так далее.
Самое страшное - когда такие люди начинают учить других.