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

Создание огромного LOD ландшафта

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 322 23 Следующая »
#0
23:05, 18 окт. 2010

Terrain Simplification Simplified: A General Framework for View-Dependent Out-of-Core Visualization (2002)

АХТУНГ - ВОДА (С) slava_mib > нервным просьба читать начиная с отчеркивания
{

Перечитал уже множество бумаг по ландшафту, некоторые алгоритмы довольно забавные, однако все они очень простые, оно и понятно: GCM, GMM и Chunked LOD достаточно бональные вещи, которые любой технарь варящийся в этой теме за пару недель сможет имплементировать и оформить в виде заумной (короткой!) бумажки, а затем кинуть в инет. Поэтому, бумажки в ~10 страничек на описание таких алгоритмов вполне хватает, чтобы понять идею и за несколько дней написать не глядя не в чьи сурсы.

Теперь по сабжу: лично я считаю, что название приведенной бумаги - это просто стеб, т. к. ничего простого я в этом не увидел, однако это сугубо мое личное мнение. ~20 страниц явно не достаточно, чтобы понять в чем соль, а от такого поверхностного объяснения просто пропадает желание читать в середине, т. к. просто теряешь нить повествования. Кроме того, совершенно отвратительный и дикий псевдо-код, где они тока такого стайла понабрались, IEEE все-таки :( Хотя подход, описанный там - довольно интересный...
}

-----------------------------------------------------------------------------------------------------


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

1. Out-of-Core - это просто понт в названии, его там и быть не может, такое биение на треугольники можно провернуть тока на монолитном куске ланшафта (2^(n/2) + 1) x (2^(n/2) + 1), где 0...n - число LOD
2. Из 1 следует, что невозможно на данном алгоритме реализовать большой ландшафт
3. Эти психи собираются в каждом фрейме делать пересчет этого биения в зависимости от положения камеры, а если это целый ландшафт, то это просто нереально
4. Однако надо отдать должное у этого биения - априори не может быть крэков
5. По поводу того, чтобы завернуть все это в TStrip: ну да, красавчики, однако я все равно не понял как они это делают (снова из-за трогладитского уровня объяснений)

Ясное дело, что IEEE никому ничего не должен, понятно что им плевать, но все же такие серьезные работы нельзя описывать в 20 страницах...

Друзья мои, теперь обращаюсь ко всем кто по локти был в теме с ландшафтами: снова мои тезисы по Chunked LOD и ваши комментарии:

1. Сделал вывод, что Chunked LOD самый оптимальный вариант среди всех
2. Он замечательно подходит для Out-of-Core стриминга
3. Ландшафт может быть только (2^(n) + 1) x (2^(n) + 1) размера
4. См. картинку...


Вопрос | Создание огромного LOD ландшафта


5. Видимо понадобится морфинг? Если да, то я понятия не имею как это лучше реализовать :(
6. Как быть с нормалями? Хранить в файле вместе с соответствующими вершинами очередного квадрата?
7. Как делать тени соответственно, чтобы была нормальная четкость? Хочу динамический Lighting
8. Текстуру брать сразу большую и тоже на QuadTree порубить? Если да, то что - текстурные координаты тоже в файле вместе с соответствующими вершинами очередного квадрата? Другой способ текстурирования есть?
9. Возможно ли всю эту красоту по максимуму перегнать на GPU? Если да, то такие пункты и как (хотя бы в общих чертах)?
10. Кстати есть что-то кроме юбчонок, чтобы при этом сохранить TStrip?
11. На каждый очередной квадрат свой вертекс и индекс буферы (учитывая подход со стримингом из файла в котором уже все на QuadTree разбито)?

Для особо сговорчивых и продвинутых - вопрос на засыпку: на картинке ниже я отчетливо вижу, как мне кажется, КОМБИНАЦИЮ 2-х подходов, а именно отвратительно изложенного IEEE (а может это что-то другое? имеются ввиду разбивка крест-накрест по гипотенузе) и собственно Chunked LOD, есть ли у кого идеи по реализации такого подхода? Т. к. насколько я понимаю разбивка крест-накрест в основном используется для ослабления детализации бесконечно плоских (компланарных) областей ландшафта, в то время как более неровные участки хорошо детализируются, все это соответственно делается на статику, т. е. 1 раз! Ну а для динамики и стриминга накидывается Chunked LOD... Звучит аппетитно :) Хотелось бы почитать ваши ремарки на этот счет господа (и дамы?) :P


2 | Создание огромного LOD ландшафта


З. Ы.
Огромная просьба не оставлять ответы с односложным предложением или шутками и т. п. (я понимаю, что возможно прошу слишком много), хочется почитать занятный конструктив и аргументацию по этому поводу, также буду рад рекламе других алгоритмов, кроме Chunked LOD, если вы в доступной форме мне изложите их преимущества. Благодарю!


#1
23:15, 19 окт. 2010

Всем впадлу или никто не знает? А то уже сутки прошли... :)

#2
23:26, 19 окт. 2010

Я лично прочитал первые два абзатца, там одна вода, и дальше читать пост было уже впадлу.
Как остальным - не знаю.

#3
17:17, 20 окт. 2010

slava_mib
> Как остальным - не знаю.
аналогично

#4
17:31, 20 окт. 2010

влом всё читать - отвечу по возможности на вопросы

Haroogan
> 1. Сделал вывод, что Chunked LOD самый оптимальный вариант среди всех
х.з.


Haroogan
> 4. См. картинку...
у меня НЕТ дублирующихся вершин. генерируется сетка (точнее нужные данные  а не сама сетка) и потом рендерится, используя различные индексные буферы для лодов

Haroogan
> 5. Видимо понадобится морфинг? Если да, то я понятия не имею как это лучше
> реализовать :(
Надо? - делай. Мне лично не надо

Haroogan
самое качественное - хранить нормали в текстуре нормалей. Тогда любой лод будет одинаково освещаться. Ну или же в геометрии хранить

Haroogan
> 7. Как делать тени соответственно, чтобы была нормальная четкость? Хочу
> динамический Lighting
у меня  PSSM. Правда он мало геометрии захватывает (только ту, что видна в кадре) Так что приёдтся раз в несколько сотен/тысяч кадров генерить карту самозатенения.  Как - х.з.  я бы сделал трассировку вершин ландшафта. Тоесть каждый "квадратик" сетки это пиксель. Пускаем луч из источника света в этот квадрат и если он пересекается с какойнить геометрией то в текстуру заносим цвет тени (или что хочешь) можно увеличить точностиь карты затенения и разбить "ячаеки" сетки ландшафта на более мелкие ячейки - как твоей душе угодно.  Вообще я такое не делало - лишь моё предположение. Уверен есть более крутой способ

Haroogan
> 8. Текстуру брать сразу большую и тоже на QuadTree порубить? Если да, то что -
> текстурные координаты тоже в файле вместе с соответствующими вершинами
> очередного квадрата? Другой способ текстурирования есть?
WTF?  Текстурные координаты всегда одни и теже

Haroogan
> 9. Возможно ли всю эту красоту по максимуму перегнать на GPU? Если да, то такие
> пункты и как (хотя бы в общих чертах)?
понятней изъясняйся.  Хочешь чисто на GPU делать ландшафт ? - юзай DX10 + GS + вершинные текстуры

Haroogan
> 10. Кстати есть что-то кроме юбчонок, чтобы при этом сохранить TStrip?
юбки ни когда неделал. У меня индексные буферы просто правильно генерятся для соединения лодов и всё.


Haroogan
> 11. На каждый очередной квадрат свой вертекс и индекс буферы (учитывая подход
> со стримингом из файла в котором уже все на QuadTree разбито)?
ну если стримминг то да.  Если без него, то 1 общий вершинный буфер и нужжные индексные для разных лодов

#5
0:48, 21 окт. 2010

L а у тебя ландшафт то большой? Я планирую 20Kx20K где-то там то уж точно нужен стриминг а значит без дублежа никак...?
Кстати насчет крэков, ты говоришь у тебя индексы подстраиваются, т.е. я так понимаю у тебя на более детализированной убираются лишние вершины, а ты учел что соседи могут различаться не на 1 ЛОД а на 2 например, т. е. когда нужно будет уже не по одной вершине убирать, а целых 3!?
Юзаю GL btw.
Как же ты без морфинга, всплесков нету?
Можешь поподробней рассказать про нормали?
Про GPU я имел ввиду какие операции при работе с данным подходом можно по возможности загнать в шейдер (и надо ли)?
А вот еще вопрос, а ты Strip'ом орудуеш (и вообще твои соображение на счет strip vs list)?


Вот я вчера уже по быстрому нашмалял базис:

Смотри-ка я красным выделил блоки, на которые как я считаю должен быть наложен кусок текстуры разного разрешения, причем именно тот кусок который предназначается конкретному блоку, иначе просто на большом блоке текстура будет смотреться размыто, а на маленьком наоборот будет излишняя детализация... Ну сам прикинь если у тебя ландшафт 20Кх20К и есть соответственно текстура  20Кх20К  на весь ландшафт, и предположим ты отлетел так далеко, что рендерится тока корень квадтри, ты че будешь накладывать вот эту большую текстуру (на допустим 129х129 вершин, которыми у тебя представлен корень)? По моему грамотней заранее сделать что-то вроде MIP mapping'а этой текстуры, т.е. каждому кваду в дереве в зависимости от его ЛОДА сопоставить кусок оригинальной текстуры с нужной детализацией. Например в случае, описанном выше придется взять ту же самую текстуру, но тока не 20Кх20К, а 1024х1024 (ужать ее) и назначить ее корню дерева, этого будет вполне достаточно. Все эти действия производить при формировании файла ландшафта и писать в него, а потом в приложении из него стримить. Таким образом у каждого квада будет заготовлены и буфера и строго его текстура, которая будет относительно не большая в сравнении с той целой. Иными словами при создании файла я не только карту высот бью на квадтри, но и текстуру эту огромную, чтобы больше с ней вообще не связываться.

Ну а синим я тебе отметил и нарисовал разъяснение моего вопроса по поводу крэков...

Жду )

Изображение
#6
1:57, 21 окт. 2010

Так часто подымаются темы с этими ландшафтами, интересно, когда уже кто-нибудь сделает нормальную демку, с огромным ландшафтом, да так, чтобы можно было летать над ним хоть в одном метре от него, хоть на 10 илометрах, и расскажет детально как делал и выложит демку с исходниками, и все потом сказали, о да, этот ландшафт совершенен, именно так и надо делать?

Мое мнение следущее:
1. Морфинг нужен обязательно. (передавать в шейдер две высоты, h1 - с текущего лода, h2 - с предыдущего, + морффактор, в вершином шейдере их смешивать h = h1*morph + h2*(1-morph)).
Все виды индексных буфферов можно просчитать заранее (и с оптимизировать для стрипов), грузить на видеокарту можно только изменившееся высоты.
2. Стриминг нужен обязательно (грузить все в отденом потоке, отдавать ассинхроно запросы на загрузку новых данных, менять детализацию по мере их загрузки, не допускать тем самым никаких лагов и ожиданий при прорисовке).
3. Нормали нужно накладывать так же как и другие текстуры на ландшафте.
4. Данные на диске надо бы как-то сжимать, а то занимают слишком много места (для 4к*4к - 32 Мб высоты и 64 Мб нормали). Тут же надо подумать, как потом огранизовать легкую модификацию ландшафта кисточкой, имея в памяти лишь только его часть.
5. при стыковки блоков обязательно необходимо, чтобы все треугольники сходились друг с другом в вершинах, если вершина какого-то треугольника будет лежать на ребре другого, то могут образоваться однопиксельные просветы, которые будут неприятно мигать при повороте камеры. Хотя кто-то может сказать, что это не важно, и если конечную картинку заблюрить, их видно не будет. Или делать юбку, как самый простой, но не очень элегантный вариант.

Так как блоки могут быть разных размеров, и на них действительно желательно класть текстуру разных размеров (фактически кусок накладываемой на блок текстуры будет определяться 4 параметрами, lod - лод блока карты высот, x, y - координаты этого блока в лоде, 0 <= x < 2^lod, 0 <= y < 2^lod, и size - размер куска накладываемой текстуры, равен примерному размеру рисуемого блока на экране в пикселях), и это делать очень сложно и некрасиво. Наиболее оптимальным мне видиться попытаться реализовать sparse virtual texture, и хранить небольшими одинаковых размерыми блоками все куски текстуры накладываемые на ландшафт (например кусками (32+2*brd)*(32+2*brd), brd=4), и эти блоки хранить в текстурном атласе. Высоты также можно хранить в аналогичной текстуре (только разве что без фильтрации или с линейной фильтрацией, тогда h2 будет считаться автоматом, не надо будет на проце его дополнительно средним арифметическим вычислять), тогда можно будет подумать, как увеличить еще детализацию в шейдере процедурным шумом.

#7
11:36, 21 окт. 2010

Haroogan
> а ты учел что соседи могут различаться не на 1 ЛОД а на 2 например, т. е.
> когда нужно будет уже не по одной вершине убирать, а целых 3!?
А зачем так делать? можно проще, соседние лоды отличаются не более чем на 1 уровень. По идее это логично. Раcстояние посчитать по другому для этого и все. Зачем усложнять реализацию? Если отличается больше чем на 1 лод, можно уменьшить размер батча. Если батчей много то ландшафт разбивать на так называемые страницы и грузить динамически.

#8
11:38, 21 окт. 2010

Andrey
> А зачем так делать? можно проще, соседние лоды отличаются не более чем на 1
> уровень. По идее это логично
это зависит от того как подобранна функция что LOD считает
запусти Крайзис и посмотри на террайн под углом близким к 90 и с большого расстояния - узнаешь много интересного

#9
13:28, 21 окт. 2010

>Я планирую 20Kx20K
А ты уже подумал о том, а на*уя тебе такой ландшафт? ;-)

#10
14:55, 21 окт. 2010

может у него авиасим

#11
15:02, 21 окт. 2010

Отпишитесь по нормалям подробно кто-нибуть ) И что насчет бумажки "Terrain Simplification Simplified: A General Framework for View-Dependent Out-of-Core Visualization (2002)", никому не доводилось читать?

#12
15:09, 21 окт. 2010

innuendo
> запусти Крайзис и посмотри на террайн под углом близким к 90 и с большого расстояния - узнаешь много интересного
а чего там будет, словами можно описать?

#13
15:12, 21 окт. 2010

arabesc
> > запусти Крайзис и посмотри на террайн под углом близким к 90 и с большого
> > расстояния - узнаешь много интересного
> а чего там будет, словами можно описать?
таки нет крайзиса под рукой ? могут быть  отличия не в 1 lod между патчами

#14
15:38, 21 окт. 2010

innuendo
> таки нет крайзиса под рукой ?
таки нету...

Haroogan
> Обращаюсь к тем, кому довелось прочитать эту бумагу
бумагу не читал, но делал ROAM, там ситуация похожая

> 1. Out-of-Core - это просто понт в названии, его там и быть не может, такое
> биение на треугольники можно провернуть тока на монолитном куске ланшафта
можно делать расчёт для патча
патчи, конечно, должны обмениваться информацией о разбиении, чтобы избежать разрывов

> 2. Из 1 следует, что невозможно на данном алгоритме реализовать большой ландшафт
ну, подумать можно...
жизнь облегчает то, что дальние патчи, которых много, изменяются много реже, чем ближние, которых мало

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

вот пример
Изображение
тут ландшафт 1025x1025, патчи 33x33, пересчёт синхронный, в основном потоке

Страницы: 1 2 322 23 Следующая »
ПрограммированиеФорумГрафика

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