Войти
ПрограммированиеФорумГрафика

Simplicity. Ландшафты без quadtree и octree. (Комментарии к статье)

#0
19:53, 3 авг. 2004

Комментарий к Статье Simplicity. Ландшафты без quadtree и octree

Вашему вниманию предоставляется описание очень простого в реализации способа работы с ландшафтами. Возможно, его основная особенность — это минимальное использование вычислений на FPU. На сегодняшний день, кажется, у каждого есть видеокарта с названием GeForce или Radeon, и мы можем себе немножко позволить разгрузить CPU за счет нагрузки на GPU. Речь идет об оптимизации, и о том, как можно отказаться от вычислительно емких методов, таких как Quadtree или Octree.


#1
19:53, 3 авг. 2004

Чего только люди не придумают, лишь бы ROAM не делать...

#2
20:51, 3 авг. 2004

ChP
а на фиг этот ROAM нужен? Только памяти много жрет, а толку - 0.

#3
21:20, 3 авг. 2004

chunked lod. рулит 8))

#4
23:56, 3 авг. 2004

Всем привет. Автор статьи - я.

СhP,
"Чего только люди не придумают, лишь бы ROAM не делать..."

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

#5
18:39, 7 авг. 2004

Неужели можно в каждом кадре генерировать новый VBO для 70.000 полигонов? Имхо тормозить будет. Даже если делать writeable буфер, то тогда у него будет фиксированная длина, и смысл метода теряется. Если же создавать новый произвольной длины в каждом кадре, то FPS снизится на порядок, если не больше...
Может быть я ошибаюсь? Поясните пожалуйста...

#6
1:55, 8 авг. 2004

nikita,
"Неужели можно в каждом кадре генерировать новый VBO для 70.000 полигонов? Имхо тормозить будет."

О! как раз задумывался. Может быть это все так, но...
Нужно тока понять какую конфигурацию PC будем считать среднестатистической.

Здесь несколько решений:

1. Я рассматривал 4096x4096. В огромном количестве игр используется размер 2048x2048.
Т.е. для карты 4096x4096 на маске: 8*8*2*1100= 140800 полигонов ->  около 70.000  (примерно 50% от 140.800),
а для карты 2048x2048 на маске: 4*4*2*1100= 35200 полигонов ->  около 17.600 .

2. Я немного внизу статьи сказал про уровни детализации (LOD) на маске, что
для 3ех уровней в 4096x4096:
(70000/3)+ ((70000/3)/2)+((70000/3)/4)=40833 полигонов (примерно: без учета переходов с уровня на уровень)
для 2048x2048: около 10.000

3. Генерировать новый VB в каждом кадре не обязательно.
Для первого fps генерируем, а для последующих нужно фиксировать изменение на маске. новые области попадают в поле видимости, старые выпадает. writeable буфер имеет значение с фиксированной длиной, т.к предел известен.
Сортировки там не надо. на место старых патчей (8x8x2= 32 полигона) ставим новые. Ведем таблицу флагов. Проверяем что ушло, а что осталось. Следим за изменением кол-ва патчей.
Минус: резкий разворот на угол больший чем FOV приведет к ситуации, когда лучше просто генерить в каждом кадре 70.000

Как-то читал DX 8.1 SDK FAQ на MS cайте.
Там говорится о том, что не всегда стоит верить, что видеокарта поддерживает >65535 полигонов на буфер.
Связано это иногда с драйверами. Это как "эхо войны", какой-нибудь пользователь не качает новые драйвера и может натолкнуться на эту проблему.
Т.е. я бы не спешил использовать hmap 4096x4096 или делил бы этот буфер на несколько. Хотя это может быть и не имеет смысла.
Если идти в ногу со временем, то по идее разработчики должны делать игры под DirectX 9.0c и для систем типа (к примеру)Intel P4 или AMD Athlon XP + nVidia GF3 или ATI Radeon 9600.
Но это теоретически, практика иногда требует другого подхода.

Мое глубоко-личное мнение: генерировать такой буфер можно.  высокая, низкая детализация сцены... Это нормальная практика, когда уровень деталей выбирает пользователь в соответсвии со своим hardware. пусть будет low details - 2048x2048 и high details - 4096x4096.
В начале статьи я сказал, что засчет blur и bicubic scaling восстанавливаю hmap из 2048x2048 до 4096x4096 - это лишь делает более гладкой поверхность, а необходимость в этом... спорно.

Если же подвергать критике о чем написано, то спорить я не стану. Я пересматривал недавно неплохо оптимизированный quadtree (исходники показать не могу и не имею права), который, кстати, тоже можно в пух и прах критиковать. Скажу банально... нужно всё познавать, сравнивать и применять то, что подходит к поставленной задаче.

Прошло более 8 месяцев
#7
14:55, 15 апр. 2005

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

Прошло более 1 года
#8
19:12, 12 авг. 2006

А меня смутило обьединение текстур ... начем так изголяться если можно перет рендижом отсортировать по текстурам и переключений будет стока скока текстур использовано  так действительно резче получается ... вот когда я обьединил тормазнуло...

#9
19:54, 12 авг. 2006

>Если идти в ногу со временем, то по идее разработчики должны делать игры под DirectX >9.0c и для систем типа (к примеру)Intel P4 или AMD Athlon XP + nVidia GF3 или ATI Radeon >9600.
>Но это теоретически, практика иногда требует другого подхода.

ГФ3 :)) а ведь всего два года прошло:) тока я чет туплю или как, разве 9.0с в 2004 году был уже?

#10
23:05, 12 авг. 2006

AcMan
Насколько я помню уже был GF6, поэтому и DX9c был...

ПрограммированиеФорумГрафика

Тема в архиве.