Войти
ПроектыФорумУтилиты

Космический симулятор SpaceEngine (166 стр)

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

Страницы: 1165 166 167 168214 Следующая »
#2475
19:22, 10 мая 2012

Избавился от передачи сгенерированной текстуры высот на CPU для построения меша - это был серьёзный боттлнек при генерации рельефа. Вместо этого теперь патчи рельефа рендерится "плоскими" мешами, вершины которых смещаются в вершинном шейдере, используя обращение к текстуре высот. FPS вроде даже не просел, зато скорость генерации возросла в десятки раз (!). Но теперь появилась проблема с рассчётом error metric, т.е. условия, когда нод должен делиться. У меня это был просто размер BBox-а нода на экране, т.е. если BBox больше стольких-то пикселей, нод делится. Раньше я просто строил максимально маленький BBox, описанный вокруг куска рельефа, т.к. меш строился на CPU и я мог найти крайние точки (максимальную и минимальную высоту рельефа в данном меше). Теперь же я не знаю, какие там высоты получаются - всё остаётся на GPU. Поэтому BBox приходится строить максимально большим (учитывать максимальный перепад высот на планете).

Для верхних уровней ничего особо не меняется:

scr00023 | Космический симулятор SpaceEngine
scr00024 | Космический симулятор SpaceEngine

Но для нижних уровней BBox-ы получаются очень длинными, ведь перепад высот на планете достигает десятков километров, а горизонтельный размер нода уменьшается до сотни метров:

scr00025 | Космический симулятор SpaceEngine

Поэтому нижние уровни начинают черезчур активно делиться (что совершенно не нужно), и движок захлёбывается ими. Попробовал считать эррор метрику как размер патча в проекции на сферу (т.е. убрал вертикальную компоненту) - уже лучше, но тоже есть проблема. Центр BBox-а всё ещё на уровне моря, хотя реальная поверхность может быть на 5 км выше или ниже, поэтому эррор метрика опять не правильная - движок считает, что нод далеко, и не делит его, хотя камера может быть на самой поверхности.

Что делать? Находить максимальную и минимальную выоту на GPU и передавать на CPU для построения нормального BBox-а? Этого хочется избежать - опять будут тормоза из-за синхронизаций. Или всё-таки считывать карту высот, но не для каждого уровня, а через 3-4, и использовать её для приблизительного построения BBox-а?


#2476
20:56, 10 мая 2012

Neptune
Аналогичная проблема: вершины смещаю в шейдере по значениям пирамиды текстур, но эти самые текстуры загружаются постепенно с диска (из кеша в памяти, если они там есть). Поэтому размер бокса ноды приходится считать по максимальной высоте на планете. Хотя мне немного проще - условием разбиения я считаю расстояние до бокса, а вот верхней границей бокса я грубо счиатю высоту рельефа под камерой. Иначе да, полная лажа.

#2477
1:04, 11 мая 2012

serpinf
А высота рельефа под камерой как считается? Это ж надо опять же перекидывать данные на CPU... И как быть с другими нодами, которые не под камерой?

#2478
8:48, 11 мая 2012

Neptune
Ну я же и говорю - мне проще, у меня данные всё-таки с диска, а значит они у меня есть на CPU... В твоём случае, когда рельеф полностью процедурный, можно читать на CPU немного данных, только под камерой, не каждый кадр и не с полной детальностью (ну или дублировать генратор для одной точки - не знаю возможно ли это). А у других нод я считаю высоту такой же, это очень грубое приближение, но работает. Ошибки можно заметить вблизи крутых обрывов только, а по большей части рельеф не так уж резко изменяется, чтобы это заметить.
Но я сам ищу метод получше.

#2479
9:54, 11 мая 2012

Neptune
> Это ж надо опять же перекидывать данные на CPU

А можно какую-то часть вычислений не передавать на CPU, а дублировать на нем же? К сожалению, не представляю алгоритма генерации высот, но мысль такая, что можно пользуясь тем же алгоритмом, на CPU вычислить высоты в только в 4х углах площадки, а GPU пусть полностью все считает.

#2480
20:26, 13 мая 2012

Если делать только под камерой, то соседние ноды всё равно будут коряво работать.
Дублировать на CPU не реально - замахаться можно.

#2481
14:54, 14 мая 2012

Neptune
> Sfighrath
> > Конкуренты не спят :)
> > http://habrahabr.ru/post/142180/
> Вот когда покажут рельеф на планетах и 100 миллиардов процедурных звёзд в
> галактике, тогда можно будет считать их конкурентами :)

На данный момент автор собрал $2251 из необходимых $8000 на окончание проекта (12 часов назад было $1056, так что темп хороший).

Сейчас же уже $12,578 ))))) что уж очень даже поражает )))) это лишь говорит - миру нужны такие движки ))))

p.s.

у кого есть связи на этом сайте с администрацией? )))) кто может мне ник обрезать до просто sibvrv без www.ник.com )))) а то в личном кабинете тут это не реально )))))))))))))

спасибо )))

#2482
21:42, 16 мая 2012

Ну что, есть у кого идеи насчёт павильного построения бибоксов или другого способа правильного деления нодов?

#2483
10:29, 17 мая 2012

Я бы сделал так. В шейдере есть код, генерирующий карту высот по определенным параметрам. Я бы вынес этот код в LoD, сделал бы процедуру, которая знала бы параметры, которые использовались в этой процедуре в шейдере. Эта процедура генерировала бы для меня массив-сетку размером Р на Р высот (параметр можно задавать в настройках), по которой бы можно было оценивать расстояние до нода. Далее можно извращаться немного и подпилить ее для случаев, когда есть сильный перепад высот, например, найти  минимум и максимум и сравнить с данными их сетки - при слишком большой разнице подкорректировать. На мой взгляд это не потребует большого вычеслительного времени, а точность даст весьма разумную.

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

#2484
11:06, 17 мая 2012

Neptune
> Ну что, есть у кого идеи насчёт павильного построения бибоксов или другого
> способа правильного деления нодов?

Т.к. опять же плохо себе представляю алгоритмическую часть, то еще одно решение "влоб":
построить дерево ббоксов заранее (один раз), когда приближаешься к планете. А дальше просто брать готовые ноды. Насколько это затратно по памяти - не берусь судить, но всяко меньше, чем сама сетка рельефа.

#2485
23:01, 19 мая 2012
Что делать? Находить максимальную и минимальную выоту на GPU и передавать на CPU для построения нормального BBox-а? Этого хочется избежать - опять будут тормоза из-за синхронизаций.

Ну а что тут еще поделаешь? Лоды считаются на процессоре, а поверхность в видео карте. Либо возвращать текстуры верхних уровней лода и определять перепад высот по ним, либо считать на процессоре крайние точки(это если нет проблем с одинаковостью работы алгоритма на цпу и гпу) И в том и в другом случае нужен небольшой допуск, ведь точки между крайними могут иметь чуть большую/меньшую высоту.
#2486
19:55, 13 июня 2012

привет,
что то давненько ничего не слышно.
Как продвигается наш любимый космический проект? :)

#2487
10:23, 15 июня 2012

Кстати, вот здесь есть Space exploration/flight simulation проект Noctis IV - насколько я понимаю, по смыслу очень похожий на SpaceEngine в текущем виде.
The Noctis galaxy, Feltyrion, is approximately 90 thousand light-years in radius
И игроки-стардрифтеры должны все это исследовать и занести в каталог :)

#2488
15:54, 15 июня 2012

koaa310
> привет,
> что то давненько ничего не слышно.
> Как продвигается наш любимый космический проект? :)

Вот:

http://spaceengine.org/forum/14-167-1

#2489
18:13, 15 июня 2012

0.96 ... остается только пускать слюни :)

Страницы: 1165 166 167 168214 Следующая »
ПроектыФорумУтилиты