пиксельшейдер тормоз! [решено] (4 стр)

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

Ты front-to-back рисуешь? early z срабатывает?

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

Mira
Ну тогда вариант - анализ depth complexity и принятие решения о том, делать ли зпасс, отдельно для каждого кластера/узла октрее/что ты там используешь.
Можно вполне посчитать эту информацию на этапе препроцессинга.

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

Овердрав можно относительно легко измерить с помощью стенсил-буфера. Правда, в D3D9 стенсил нельзя прочитать и приходится извращаться с визуализацией, а вот в OpenGL можно прочитать и сохранить в файл/вывести на экран в уголочке. Медленно, но для дебаг-целей годится. Пример можно посмотреть в Q3, поиск по "r_measureOverdraw".

можно и альфаблендингом обычным измерить - рисуешь еле видным цветом всё, в итоге где сильнее видно - там и овердравнее