Quake (3 стр)

TarasB
> TarasB
Дык, а ты на чем играешь на Celeron 600Mhz? =)

Запускал на днях Quake2 на Flybook с сенсорным экраном 1024x600, надо наверное установить на нормальную машинку и в новогодние праздники поразвлечься! ^_^

SkAT
> Дык, а ты на чем играешь на Celeron 600Mhz? =)
Да, а что, не должно идти?

Давайте поговорим про светокарты в кваке.
Вот есть стенка.
На ней есть текстура материи и текстура света.
Правильно ли я понимаю, что смешивать их на ходу, выполняя при этом размытие текстуры света - это слишком дорого?

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

Ещё остаётся вопрос про монстров. Для них уже кешировать не получится, потому что они движутся. То есть для них уже цвет затеняется на ходу? И вычислять тень по карте уже не получается, то есть весь монстр затеняется одинаково. А как считается, насколько именно надо затенить этого монстра?

TarasB
Текстуры на стены накладываются без фильтрации, но лайтмапы фильтруюца, иначе картинка была бы УГ. Смешивать там ничего не надо, лайтма задаёт, насколько нужно сдвинуть индекс цвета в этой палитре в сторону тёмных оттенков:

Кеширование - не слышал про такое, да и маловероятно это. Не кадры же кешировать?
Освещение монстра берётся из лайтмапы ближайшей поверхности ( наиболее часто, на той, на которой он стоит ).

TarasB
> там заранее вычисляется внешний вид текстур, попавших в кадр
Да, в мультиплеере это происходит за время до первого спавна.

Panzerschrek[CN]
> но лайтмапы фильтруюца

Ну я и спрашиваю - неужели это делается каждый кадр? Это же пипец производительности.

Panzerschrek[CN]
> лайтма задаёт, насколько нужно сдвинуть индекс цвета в этой палитре в сторону
> тёмных оттенков:

А вправо сдвигать или влево? Видно же, что так тупо не проканает.

Не, там явно по таблице берётся. Часто видно, как белая стена становится тёмно-красной вдалеке от лампы, например.

Panzerschrek[CN]
> Кеширование - не слышал про такое, да и маловероятно это. Не кадры же
> кешировать?

Кешировать текстуру стены с наложенной светокартой. Чтобы не накладывать и не фильтровать каждый кадр.

Panzerschrek[CN]
> Освещение монстра берётся из лайтмапы ближайшей поверхности ( наиболее часто,
> на той, на которой он стоит ).

Похоже на то.

TarasB
Стен в кадре может быть много. Ещё, чтобы выглядело нормально, нужно кэшировать в высоком разрешении. Так что это слишком сложно и тяжело, уж проще проинтерполировать значения лайтмапы.
А вообще, поищи обзоры движка\почитай исходники, сразу стане понятно.

TarasB
> Давайте поговорим про светокарты в кваке.
http://www.bluesnews.com/abrash/

Panzerschrek[CN]
> Ещё, чтобы выглядело нормально, нужно кэшировать в высоком разрешении.

Кэшировать надо ровно в разрешении родной текстуры стены.

Panzerschrek[CN]
> Стен в кадре может быть много.

Дело не в числе стен, а в суммарном числе текселей на стенах, попавших в кадр.
Очевидно, что оно меньше, чем число текселей на карте, а ведь для каждых 16 текселей (4х4) в файле карты хранится значение от 0 до 63.
Можно оценить размер требуемой памяти, зная размер карты.

Panzerschrek[CN]
> уж проще проинтерполировать значения лайтмапы.

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

Тётя Зюзя
> между тем, у движка сорцы открыты.
ты их читал? там главный цикл заливки в ассемблере

Лайтмапы накладывались как мультитекстурирование. Без кеширований, да и как кешировать попиксельно, губа завернется. Все кроме стен кстати рисовалось другим алгоритмом, с плохой но быстрой перспективной коррекцией.

Spartan
там английский, у меня мозг сразу закипает
но слово "текстуре кешинг" я успел разглядеть раньше, чем мозг вскипел
хехе, как и предполагалось

=A=L=X=
> Все кроме стен кстати рисовалось другим алгоритмом, с плохой но быстрой
> перспективной коррекцией.
Стены тоже рисуются афинными отрезками. Только длина отрезка для стен 8 пикселей, а для монстра - вся линия.

Именно с этой игры я заинтересовался тем, как это сделано))

TarasB
> но слово "текстуре кешинг" я успел разглядеть раньше, чем мозг вскипел
> хехе, как и предполагалось

Жесть, жесть, вот такого я не предполагал даже, а оно вот оно как.
Если вкратце.
Суть в том что рендер двухпроходный.
1. В первом проходе для каждого видимого полигона строится его активная текстура. Эта текстура характерна тем что в неё запекаются и освещение в том числе и если там идет тайлинг - то происходит "детайлизация" - столько раз сколько оригинальная текстура повторяется она действительно записывается с повторениями в то что там называется "surface".
2. На втором проходе полигоны растеризуются как просто текстурированные полигоны причём текстурами уже служат эти "surface", а не оригинальные текстуры.
Первая оптимизация: если активная текстура (sufrace) у полигона в очереди на отрисовку уже построена то её перестраивать не надо и можно сразу переходить к второму проходу быстро-поносному.
Вторая оптимизация: мипмапы - она собственно и делает это всё возможным, т.к. суммарный размер активных текстур не должен быть сильно больше чем размер фреймбуфера экрана собственно, иначе смысл затеи исчезающе мал.
Неявная, но важная оптимизация: т.к. построитель активных текстур и растеризатор разделились и стали очень простыми, они очень хорошо пролезли в регистровые оптимизации.
Подводная оптимизация: декали стало проще реализовывать как этап откинутый в построитель активных текстур и по сути декали вообще не несут пенальти растеризатору если полигон не выходит из кадра.

=A=L=X=
Вот!
И это намного лучше, чем в реальном времени заниматься интерполяциями.
На интерполяциях такой ФПС получить невозможно вообще в принципе.
Про то, что строится только текущий мип - это я не додумался, да.

Интересно, а какой у него аллокатор для сюрфейсов?

TarasB
> Ещё остаётся вопрос про монстров.
Абраш пишет про http://ru.wikipedia.org/wiki/Метод_тонирования_Гуро