1: я не могу понять, в какой точке конвейера LOD Chunked сетка разбивается на куски. Это во время начальной генерации сетки, или есть отдельный алгоритм, который делает это.
Это неважно. Например, вы можете интегрировать блок в свой алгоритм генерации сетки. Вы можете даже сделать это динамически, так что более низкие уровни добавляются динамически (например, когда игрок приближается), используя подобный плазме алгоритм уточнения. Вы также можете сгенерировать сетку высокого разрешения из входных данных художника или данных измерений высоты и объединить их во все фрагменты LOD во время завершения актива. Или вы можете смешивать и сочетать. Это действительно зависит от вашего приложения.
2: Я понимаю, что структура данных Quadtree используется для хранения данных Chunked LOD, я думаю, что я немного упускаю точку, но хранит ли quadtree данные вершин и треугольников для каждого уровня подразделения?
Не обязательно. Дерево просто хранит информацию о геометрии и способах ее визуализации. Это может означать наличие списка вершин / граней на каждом узле дерева. Более реалистично в наше время, вы бы сохраняли дескрипторы мешей / экземпляров в памяти GPU.
3a: Как обычно рассчитывается расстояние до камеры? Когда вы читаете о квадри, очень часто упоминаются ограничивающие прямоугольники Оси. В этом случае у каждого куска будет ограничивающий прямоугольник столкновения, чтобы обнаружить камеру, или игрок поблизости? или есть лучший способ сделать это? (Raycast может быть?)
Очень дешевый и простой вариант - использовать расстояние до центральной точки куска, а затем исправить его. Вы знаете, что это расстояние всегда недооценивается: если центральная точка находится на расстоянии Z, это означает, что половина фрагмента ближе, чем эта. Однако мы не знаем, что такое ориентация. Если мы видим фрагмент шириной по wкраям, ближайший фрагмент будет на расстоянии Z-w. Однако, если мы просматриваем угол чанка первым, ближайший бит будет на расстоянии Z-sqrt(2)*w. Если вы можете жить с этой неопределенностью (вы почти всегда можете), все готово. Обратите внимание, что вы также можете исправить угол обзора, используя базовую тригонометрию.
Я предпочитаю рассчитывать абсолютное минимальное расстояние от камеры до порции, чтобы минимизировать артефакты. На практике это означает проведение дистанционно-точечного теста . Это немного больше, чем вычисление расстояний до центральных точек, но не то, чтобы вы делали миллион таких кадров в каждом кадре.
Если вы можете использовать свой физический движок для этого, то непременно сделайте это, но вы действительно хотите думать об этом больше с точки зрения «расстояния запроса», чем «столкновения».
3b: Части сами рассчитывают расстояние до камеры?
Это действительно зависит от дизайна вашего двигателя. Я бы порекомендовал держать листья относительно легкими, хотя. В зависимости от вашей платформы, только издержки вызова из-за того, что несколько тысяч участков ландшафта выполняют свое собственное обновление, каждый кадр может серьезно повлиять на производительность.
4: у каждого блока есть то же самое "разрешение". например, на верхнем уровне меш будет 32x32, каждый разделенный узел также будет 32x32.
Они не должны, но это удобно, если все куски занимают одинаковое количество места. Затем вы можете осуществлять управление памятью (GPU) в единицах «кусков». Также легче удалить / скрыть швы между двумя кусками разных размеров, если одно разрешение кратно другому, потому что они имеют больше вершин. (например, 32x32 и 64x64 легче управлять, чем 32x32 и 57x57) (спасибо Guiber!). Если у вас есть веская причина изменить размер геометрии куска, обязательно сделайте это.
