Рисование городских пейзажей.

← →
Unknown user (2003-07-24 18:56) [0]

Из каких соображений исходить, устанавливая параметры вида в OpenGL(glTranslate,glRotate,gluPerspective), если рисуются улицы города, а камера -это глаза идущего по улице человека. Можно ли задавать координаты плоскостей отсечения, например -1,-3 и выводить все в область между плоскостями отсечения? В одной демке я видел, задавали расстояяние от передней до задней плоскости отсечения 4000, не слишком ли много, ведь OpenGL надо всю эту область просчитывать при выводе объектов?

← →
wiz (2003-07-25 11:31) [1]

> Из каких соображений исходить, устанавливая параметры вида
> в OpenGL(glTranslate,glRotate,gluPerspective), если рисуются
> улицы города, а камера -это глаза идущего по улице человека

Ну для начала определись: какой коэф. пропорциональности между метрами и единицами OpenGL (например 1:1). отсюда и плясать можно. тогда translate будет в метрах плюс по z добавь высоту глаз наблюдателя. rotate - направление взгляда (используй только тангаж&рысканье, т.к. человек довольно редко наклоняет голову и при этом мозг все равно воспринимает картинку ненаклонной). perspective - тут главное fov, его можно посчитать из условий: размер экрана (реальный), расстояние до глаз, но выглядит довольно убого, или не долго думая взять у зубров (посмотри какой fov в quake (imho 90)).

Касательно плоскостей отсечения:

> OpenGL надо всю эту область просчитывать при выводе объектов?

Здесь работает алгоритм:
1) RTFM.
2) Если не совсем понятно, как OpenGL обсчитывает треугольники и что такое depth_buffer, то повторить пункт 1.

miniRTFM:

depth_buffer разбивает на нужное количество промежутков заданное расстояние far-near ((по моему) для perspective размеры промежутков - растут как степень двойки). Далее, при обсчете треугольника oGL сравнивает расстояние (в единицах depth_buffer"а) от точки треугольника до глаза с тем что уже записано в depth_buffer"е и если расстояние !меньше!, то выводит на экран новую точку треугольника.

Отсюда вывод, если расстояние (в единицах depth_buffer"а) до новой точки и старой будет равно, то oGL ничего не выведет (Это не совсем так, но для простоты понимания сойдет).

Соответственно: если ты выводишь все свои полигоны в область (1,3) (по расстоянию), а (near,far) = (1,1000000), то на используемую тобой область приходится всего-ничего значений depth-buffer"а и он используется неэффективно (то есть много некрасивостей в виде пилы на краях/пересечениях полигонов).

Правило: устанавливай near/far такой, чтобы как можно лучше покрыть depth_buffer"ом свое используемое пространство, но не жадничай (самый яркий пример: в quake использовался единичный куб на уровень и значение far было 1. Таким образом при запуске созданного открытого уровня максимальным размером игрок из угла этого уровня видел едва-ли половину его).

Вместо PS:

Вопрос: Измениться ли что-нибудь, если всю геометрию oGL сцены умножить на два и (near,far) также умножить на два?
Ответ: Если вы ответили что либо отличное от "нет", то повторите пункт 1 алгоритма.

← →
Unknown user (2003-07-25 13:24) [2]

To wiz. Спасибо за столь подробный ответ и потраченное на меня время. Из всего вышесказанного я сделал вывод, что для улучшения качества лучше задавать расстояние до задней плоскости отсечения побольше. Это значение ведь также должно влиять на перспективу, т.е. на ощущение пространства, что для рисования улиц города очень важно.
А что, имеются исходники Quake 3?

← →
wiz (2003-07-25 16:10) [3]

> Из всего вышесказанного я сделал вывод, что для улучшения
> качества лучше задавать расстояние до задней плоскости отсечения
> побольше

Все-таки поменьше.

> Это значение ведь также должно влиять на перспективу

Никоим образом. Перспективу ты задаешь углом обзора (гориз и верт) (через fov и aspect).

> А что, имеются исходники Quake 3?

Во-первых, это говорилось про Quake 1 (или просто quake ;) ), а во-вторых, это было видно во время игры.

← →
Unknown user (2003-07-25 17:51) [4]

To wiz. А как ты думаешь устроена GTA (игрушка где воссоздан целый город в 3Д)?.

← →
Ev_genus (2003-07-25 18:30) [5]

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

>А как ты думаешь устроена GTA
Вопрос не ко мне, но я отвечу. А в чем проблема? не надо хранить уровень одним куском. Советую почитать о bsp.

← →
Asteroid (2003-07-25 18:32) [6]

> Unknown user © (25.07.03 17:51)
У GTA есть какоая-то далекая задняя плоскость, а остальное - уровень детализации объектов от расстояния (параметр Distance в настройках меняет расстояние до границы максимальной детализации). У края задней плоскости все затуманивается.

← →
Unknown user (2003-07-25 19:18) [7]

To Ev_genus. По моему в этой игрушке город разбивается на совсем небольшое количество кусков, подгрузка их заметна -она вызывает секундную паузу. Так вот как там определяется какие объекты находятся в поле зрении камеры и их надо выводить а какие нет?

← →
wiz (2003-07-26 02:34) [8]

2 Ev_genus
> Пересекающиеся полигоны это бред, зачем такое делать

Пример: обычный кубик. Каждое ребро - практически пересечение полигонов (соприкосновение). Если у тебя характерные размеры сцены - 1000 "метров", а размер куба 0.1 м, то каждое ребро с определенной точки зрения будет выглядеть пилой (победить такое довольно трудно).

2 Unknown user
> По моему в этой игрушке город разбивается на совсем небольшое
> количество кусков, подгрузка их заметна -она вызывает секундную
> паузу

Это загрузка уровня из файла. Файл внутри разбит еще на куски.

(imho) Лучше всего такие уровни хранить блоками + граф, в котором определены связи между блоками.
(2 Ev_genus: если я не ошибаюсь, примерно так и устроен bsp)

2 Unknown user
> Так вот как там определяется какие объекты находятся в поле
> зрении камеры

len: Для каждого объекта вычисляем расстояние до камеры.
angle: Для каждого объекта вычисляем угол между направлением на объект (от камеры) и направлением самой камеры.

если abs(angle)>(fovx/2) (угол обзора горизонтальный), то объект вне камеры.
//конечно на самом деле нужно еще учитывать угловые размеры объекта
если len>len_detail, то вместо полной модели рисуем её упрощенную версию
если len>len_detail2, то рисуем самую упрощенную версию (без текстур, оч. мало полигонов)

Это самый простой алгоритм. Если его нагрузить так, чтобы он обрабатывал не все объекты, а только из соседних узлов графа (соседних с узлом в котором находится камера), то он станет ишо быстрее. А дальше реализуй еще 1024 оптимизаций алгоритма и можешь продавать свой движок (как iD Software) ;).

← →
K.o.Z (2003-08-08 01:25) [9]

уважаемые, подскажите как карту города и объектов хранить (если учесть, что масштаб метров к единицам OpenGL 1:1) ????

← →
wiz (2003-08-08 23:57) [10]

2 K.o.Z: в файле ;)))

А если серьезно, то для начала нужно разобраться:

Если у тебя город поделен на клетки (квадраты, треугольники, гексагоны), то скорее всего надо хранить просто высоту каждого узла.

Если у тебя нет четкой структуры поверхности, то храним список узлов + список полигонов (напр. треугольников) в формате N1, N2, N3 : номера узлов.

Так же и с объектами. Плюс у объектов есть еще координаты в пространстве города.

---
С объектами можно и сложнее. В одном проекте я сделал двойной список объектов:

список A: только геометрия объекта (точки, треугольники). все координаты относительно некоего "центра объекта".

список B: сам объект. В нем: номер в списке A (указатель на геометрию), абсолютные координаты данного объекта, индивидуальные св-ва данного объекта.

Правда в результате программер, который делал user interface проекта долго ломал себе голову, когда попытался понять, что там вообще творится в graph engine. Но с проблемой памяти в случае большого количества однотипных объектов (в моем случае это была "фигурка дома типового") я разобрался насмерть ;)

Рисование городских пейзажей. Найти похожие ветки