HLFX.Ru Forum - Так что же делать - разрезать полигоны или часто менять текстуру?

Так что же делать - разрезать полигоны или часто менять текстуру?

Как известно, для рисования все стараются 1) уменьшить число выводимых полигонов и 2) пореже изменять стейт, чтобы рисовать большими кусками.
К смене стейта приводит, например, переключение текстуры (glBindTexture).
Есть два пути, но они взаимоисключающие.

Решение проблемы 1: использовать тайлинг текстуры на полигоне, т.е. полигон может быть очень большой, а текстура на нем повторится много раз (так сделано в Quake3).

Решение проблемы 2: собрать текстуры в одну большую текстуру (атлас). Тогда не нужно будет переключать текстуры, нужно только задать правильные текстурные координаты. Однако использовать тайлинг мы уже не сможем - следовательно, надо разрезать полигон при повторении текстуры (так сделано в Quake1/Half-Life).

У меня появился вопрос - а что, собственно лучше? Понятно, что для больших текстур (512+) лучше 1, т.к. большой атлас не создашь из-за лимита на макс. размер текстуры. Речь о "нейтральном" случае - когда текстуры небольшие и повторения их на полигонах тоже умеренные, не по 100 раз на грань.

Есть разумеется вариант 3 - GL_EXT_texture_array, но это минимум GeForce8, а я про более общий случай.

Если ID перешли на переключение текстур, значит на то были причины.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

FiEctro там как раз причина в том, что текстуры большие.
А с лайтмапами так и не перешли (но их и тайлить не надо).

XaeroX по моему все это разбиение на полигоны только из-за лайтмап и нужно. Ну и софтверный рендерер это использовал, конечно.
А в ку3 все освещение видели? зато шустро.

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

Возникает вопрос - а как в движке будет определяться видимость полигонов? Если по каждому полигончику индивидуально, как в ку1/хл, то лучше, наверное, не разрезать. А если полигоны группируются в батчи, то уже можно подумать...

Кстати, а вот ку3 - для него какая сортировка приоритетнее - от ближнего к дальнему, или по текстурам?

Дядя Миша писал:
А в ку3 все освещение видели?

__________________
"Злобным гениям не нужна харизма." © Shooter__Andy
"Making stuff for an "old ugly game" can be ten times more fun than grinding on a map for a dull, next-gen title." © Lunaran

BUzer писал:
Кстати, а вот ку3 - для него какая сортировка приоритетнее - от ближнего к дальнему, или по текстурам?

Вспомнил тут, что у атласов есть ещё одна проблема - это мипы. Теперь-бы проголосовал против атласа

BUzer, да вроде нет никаких проблем у атласов с мипами... Ну разумеется, если сначала сгенерить мипы из текстур, а потом из них собрать мип-уровни атласа, а не тупо загонять атлас в gluBuild2DMipmaps

Я думаю, лучше больше полигонов. Опыт у меня пока правда небольшой, но кое с чем я уже сталкивался. Например, при тестировании VBO у меня 50000 квадратных полигонов с одной текстурой рисовались на 200 fps. В тоже время 15000 треугольных полигонов с 3000 переключений текстур рисуются уже на 50 fps.

Это еще и от используемого вершинного шейдера зависит.
Например, у меня в Volatile для некоторых брашей и моделей используется "софтварный вершинный шейдер" (реализация текстурных скриптов по типу ку3), и соответственно динамический VBO. Чем больше байтов в нем обновлять каждый кадр, тем хуже.