...

суббота, 21 сентября 2013 г.

[Перевод - recovery mode ] Рендер топологии в WebGL

Часть первая — Введение




В этой серии постов, я буду рассказывать о технологии рендринга тераина в игре «Rally Trigger», базируемой на WebGL.

image

От переводчика: случайно натолкнулся на эту серию статей, которая на данный момент еще только пишется. Нужно сказать — статьи отменные, все отлично разжёвано! Нужно сказать, я не знаю как будет правильно перевести «terrain», поэтому я его так и буду называть — тераин.



Интересная проблемка



Примечание: производительность JavaScript — тема номер один для разработчиков HTML5 игр. В данной статье рассматриваются последние события в мире asm.js.

WebGL делает процесс кодинга еще более занятным, чем он есть. WebGL — это OpenGL для браузера, обеспечивающий доступ к мощностям GPU, но с некоторыми ограничениями. Важно заметить, что CPU-side во главе с JavaScript, обрабатывает данные куда медленнее, чем нативное приложение на OpenGL. Это связано с тем, что при пересылке данных с процессора на GPU происходит множество проверок, цель которых — сделать веб приложения безопасными. Но как только данные попадают на видеокарту, рендринг протекает быстро.


image


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


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


Кроме того, существует ограничение количества треугольников, которых GPU сможет отрендрить real time. Запас (прим. пер.: автор использовал хорошее слово — бюджет) треугольников (для рендера тераина) будет крайне ограниченным, поэтому мы не можем себе позволить большое количество деталей на всей поверхности земли.


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

image

В идеале, было бы не плохо использовать как можно больше треугольников возле камеры и поменьше в отдалении:

image

Но это будет гомняно выглядеть при движущейся камере:

image


Итак, если готовы немного пригрузить CPU — можно использовать один из множества алгоритмов для адаптации детализации местности (LOD) к текущему положению камеры. Алгоритм, по сути, равномерно распределяет работу между процессором и видеокартой.


Решение: Geoclipmapping



(прим. пер.: даже не представляю как правильнее перевести термин)

Итак — как достичь адаптивный LOD имея только статические данные о вершинах? Geoclipmapping и вершинное текстурирование спешат на помощь!


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

image


Во время рендера мы смещаем эту сетку к текущему положению камеры и грузим нужный сегмент текстуры с картой высот в вершинный шейдер.


Звучит просто (прим. пер.: конееечно), но все немного сложнее, так что в следующей статье я расскажу поподробнее о том как это работает и как на WebGL сделать производительный geoclipmapping с морфингом. Ну а после этого похоливарю о картах высот с разным разрешением и накладывании теней на поверхность (при. пер.: ну а как еще перевести surface shading?).


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Комментариев нет:

Отправить комментарий