Избавился от передачи сгенерированной текстуры высот на CPU для построения меша - это был серьёзный боттлнек при генерации рельефа. Вместо этого теперь патчи рельефа рендерится "плоскими" мешами, вершины которых смещаются в вершинном шейдере, используя обращение к текстуре высот. FPS вроде даже не просел, зато скорость генерации возросла в десятки раз (!). Но теперь появилась проблема с рассчётом error metric, т.е. условия, когда нод должен делиться. У меня это был просто размер BBox-а нода на экране, т.е. если BBox больше стольких-то пикселей, нод делится. Раньше я просто строил максимально маленький BBox, описанный вокруг куска рельефа, т.к. меш строился на CPU и я мог найти крайние точки (максимальную и минимальную высоту рельефа в данном меше). Теперь же я не знаю, какие там высоты получаются - всё остаётся на GPU. Поэтому BBox приходится строить максимально большим (учитывать максимальный перепад высот на планете).
Для верхних уровней ничего особо не меняется:
Но для нижних уровней BBox-ы получаются очень длинными, ведь перепад высот на планете достигает десятков километров, а горизонтельный размер нода уменьшается до сотни метров:
Поэтому нижние уровни начинают черезчур активно делиться (что совершенно не нужно), и движок захлёбывается ими. Попробовал считать эррор метрику как размер патча в проекции на сферу (т.е. убрал вертикальную компоненту) - уже лучше, но тоже есть проблема. Центр BBox-а всё ещё на уровне моря, хотя реальная поверхность может быть на 5 км выше или ниже, поэтому эррор метрика опять не правильная - движок считает, что нод далеко, и не делит его, хотя камера может быть на самой поверхности.
Что делать? Находить максимальную и минимальную выоту на GPU и передавать на CPU для построения нормального BBox-а? Этого хочется избежать - опять будут тормоза из-за синхронизаций. Или всё-таки считывать карту высот, но не для каждого уровня, а через 3-4, и использовать её для приблизительного построения BBox-а?
Neptune
Аналогичная проблема: вершины смещаю в шейдере по значениям пирамиды текстур, но эти самые текстуры загружаются постепенно с диска (из кеша в памяти, если они там есть). Поэтому размер бокса ноды приходится считать по максимальной высоте на планете. Хотя мне немного проще - условием разбиения я считаю расстояние до бокса, а вот верхней границей бокса я грубо счиатю высоту рельефа под камерой. Иначе да, полная лажа.
serpinf
А высота рельефа под камерой как считается? Это ж надо опять же перекидывать данные на CPU... И как быть с другими нодами, которые не под камерой?
Neptune
Ну я же и говорю - мне проще, у меня данные всё-таки с диска, а значит они у меня есть на CPU... В твоём случае, когда рельеф полностью процедурный, можно читать на CPU немного данных, только под камерой, не каждый кадр и не с полной детальностью (ну или дублировать генратор для одной точки - не знаю возможно ли это). А у других нод я считаю высоту такой же, это очень грубое приближение, но работает. Ошибки можно заметить вблизи крутых обрывов только, а по большей части рельеф не так уж резко изменяется, чтобы это заметить.
Но я сам ищу метод получше.
Neptune
> Это ж надо опять же перекидывать данные на CPU
А можно какую-то часть вычислений не передавать на CPU, а дублировать на нем же? К сожалению, не представляю алгоритма генерации высот, но мысль такая, что можно пользуясь тем же алгоритмом, на CPU вычислить высоты в только в 4х углах площадки, а GPU пусть полностью все считает.
Если делать только под камерой, то соседние ноды всё равно будут коряво работать.
Дублировать на CPU не реально - замахаться можно.
Neptune
> Sfighrath
> > Конкуренты не спят :)
> > http://habrahabr.ru/post/142180/
> Вот когда покажут рельеф на планетах и 100 миллиардов процедурных звёзд в
> галактике, тогда можно будет считать их конкурентами :)
На данный момент автор собрал $2251 из необходимых $8000 на окончание проекта (12 часов назад было $1056, так что темп хороший).
Сейчас же уже $12,578 ))))) что уж очень даже поражает )))) это лишь говорит - миру нужны такие движки ))))
p.s.
у кого есть связи на этом сайте с администрацией? )))) кто может мне ник обрезать до просто sibvrv без www.ник.com )))) а то в личном кабинете тут это не реально )))))))))))))
спасибо )))
Ну что, есть у кого идеи насчёт павильного построения бибоксов или другого способа правильного деления нодов?
Я бы сделал так. В шейдере есть код, генерирующий карту высот по определенным параметрам. Я бы вынес этот код в LoD, сделал бы процедуру, которая знала бы параметры, которые использовались в этой процедуре в шейдере. Эта процедура генерировала бы для меня массив-сетку размером Р на Р высот (параметр можно задавать в настройках), по которой бы можно было оценивать расстояние до нода. Далее можно извращаться немного и подпилить ее для случаев, когда есть сильный перепад высот, например, найти минимум и максимум и сравнить с данными их сетки - при слишком большой разнице подкорректировать. На мой взгляд это не потребует большого вычеслительного времени, а точность даст весьма разумную.
Если рельеф прегенерирован, то, на мой взгляд, наиболее оптимальным будет ручная прегенерация достаточно грубой карты высот заранее с последующим ее сохранением на диск, и потом ее уже анализировать.
Neptune
> Ну что, есть у кого идеи насчёт павильного построения бибоксов или другого
> способа правильного деления нодов?
Т.к. опять же плохо себе представляю алгоритмическую часть, то еще одно решение "влоб":
построить дерево ббоксов заранее (один раз), когда приближаешься к планете. А дальше просто брать готовые ноды. Насколько это затратно по памяти - не берусь судить, но всяко меньше, чем сама сетка рельефа.
Что делать? Находить максимальную и минимальную выоту на GPU и передавать на CPU для построения нормального BBox-а? Этого хочется избежать - опять будут тормоза из-за синхронизаций.
Ну а что тут еще поделаешь? Лоды считаются на процессоре, а поверхность в видео карте. Либо возвращать текстуры верхних уровней лода и определять перепад высот по ним, либо считать на процессоре крайние точки(это если нет проблем с одинаковостью работы алгоритма на цпу и гпу) И в том и в другом случае нужен небольшой допуск, ведь точки между крайними могут иметь чуть большую/меньшую высоту.
привет,
что то давненько ничего не слышно.
Как продвигается наш любимый космический проект? :)
Кстати, вот здесь есть Space exploration/flight simulation проект Noctis IV - насколько я понимаю, по смыслу очень похожий на SpaceEngine в текущем виде.
The Noctis galaxy, Feltyrion, is approximately 90 thousand light-years in radius
И игроки-стардрифтеры должны все это исследовать и занести в каталог :)
koaa310
> привет,
> что то давненько ничего не слышно.
> Как продвигается наш любимый космический проект? :)
Вот:
0.96 ... остается только пускать слюни :)
Тема в архиве.