Neptune
кстати, ты же наверняка видел самое последнее видео из инфинити, там где они над планетой летают.
Там у них все вроде так шустро работает и детализация довольно высокая. Ты вообще знаешь как они это сделали? :)
Только накрутить яркость туманностей (Shift-[])
Neptune
кстати, ты же наверняка видел самое последнее видео из инфинити, там где они над планетой летают.
Там у них все вроде так шустро работает и детализация довольно высокая. Ты вообще знаешь как они это сделали? :)
Neptune
> Только накрутить яркость туманностей (Shift-[])
эх... надеюсь в след версии уже будет система навигации (типа того что я пару страниц назад рисовал)
И гигантские космические корабли.... :D :D
koaa310
> кстати, ты же наверняка видел самое последнее видео из инфинити, там где они над планетой летают.
> Там у них все вроде так шустро работает и детализация довольно высокая. Ты вообще знаешь как они это сделали? :)
Видел конечно. Сделано так же как у меня, плюс детальные текстуры, и загрузка в отдельных потоках. Если летать медленно, то и у меня всё успевает подгружаться.
хотелось бы сказать , что когда речь идет об Игре , то в случае с предполагаемым космосимом при MMOG
каждый пользователь сможет генерировать планеты на своей машине ( вот ! ) : которые находятся там где и он ( ГГ ) .
В той же Звездной Системе - вроде бы это и очевидно , но вот только недавно было высказано , что кто-то не знает куда искатель полетит - вроде того , что наперед нельзя нагенерить - потому как планет очень много .
А вот в этом случае нам ведь и не надо ВСЕ - все сгенерятся в нужном количестве - от количества пользователей ,конечно .
Но также и очевидно , что все-таки одна планета будет весить все равно многовато - а их в SS (Star System) может быть далеко не одна , да плюс спутники . С планетами в космосимах все решается через кольца докирования - с привязкой к координатам точек входа - а колец может быть тоже несколько : собственно зная точки входа - можно нагенерить наперед нужное количество данных ( каково же нужное количество данных ? ) от точки входа до космопорта .
То есть , если от кольца докирования спустится перпендикулярно к поверхности планеты - а дальше горизонтальный полет над террейном со всеми красотами - Range нужно-генерируемого террейна от точки спуска до космопорта .
Игрок не будет так быстро передвигаться от звезды к звезде - как при просмотре - и к тому же при наличии Системы Навигации Игрок дополнительно может ставить точки входа ( это вариант уже без колец докирования ) - так сказать заранее ( вот учет погоды или тактики ) - это будет выглядеть как небольшая дополнительная генерация ( желательно контролировать поток , если он компилит заранее - не дать ему поглотить ресурсы - выделить ему там какой-нибудь нужный процент , но что б хватило по времени ) : решаются основные вопросы с двух сторон .
Morphia исчезни со своими кольцами, и незабудь принять прописанные доктором таблетки.
Neptune
Возможно тут есть что то интересное для тебя
http://habrahabr.ru/blogs/algorithm/111538/#habracut
там, кстати в коментариях тоже часто бывает полезная инфа.
Извиняюсь тему не читал. Швы все на планетах видят?
jkot
все
Morphia
koaa310
Короче вы предлагаете кэшировать на диск текстуры тех "мест", где юзер часто летает? У меня была такая идея. Для игры это имеет смысл, когда будут существовать популярные у игроков планеты. Для такой программы, как сейчас, это не имеет особого смысла. К тому же дисковый кэш добавит тормозов к незакэшированным областям - ведь перед генерацией нужно просмотреть 100500 файлов на диске и убедиться, что нужного нет. Можно конечно генерацию и чтение с диска запустить в параллельных потоках, но смысл тогда в этом? Работу шейдера не прервёшь, не скажешь ему "забей генерить текстуру, я её нашёл на диске".
Зато кэшированием можно нагенерить текстур процедурных планет и раздавать нуждающимся для их движков:)
koaa310
> Возможно тут есть что то интересное для тебя
> http://habrahabr.ru/blogs/algorithm/111538/#habracut
> там, кстати в коментариях тоже часто бывает полезная инфа.
Хм, диамант не годится, т.к. у меня нерегулярная сетка. Хотя он по-идее очень быстрый, но вероятно на GPU быстрее на любом уровне генерить все октавы, чем возиться с передачей в шейдер текстур предыдущего уровня. Если как-то вычислять размер треугольника, чтобы корректировать параметр R для алгоритма, возможно его можно будет заюзать. Но как получать рандомное число, из текстуры? Или функцией Перлин нойса?
Вороного (почти Вороного:)) использую для кратеров, надо будет потестить как глобальный ландшафт с ним будет смотреться. Но Вороной очень медленный, все наверно заметили, что планеты с кратерами генерятся существенно медленнее планет без кратеров.
В этой статье не указаны другие методы - очевидный многооктавный Перлин (т.н. fbm), который даёт результат, похожий на диамант (ИМХО). Любимый мной Ridged multifractal - преобразование fbm по формуле pow(1-abs(fbm), 2.0), который даёт реалистично выглядящие вблизи горы (но сверху они смотрятся криво). Зато в конце статьи даны зачётные ссылки:)
По поводу симуляции водной эрозии. Почитал статью, действительно неплохой метод физической симуляции процесса. Но для процедурных планет он не применим по двум причинам.
Во-первых, симуляция требует тысяч проходов по времени, один проход на текстуре 256*256 у них занял миллисекунду, значит 1000 проходов займут целую секунду! А ведь даже этого мало - чем больше шагов по времени, тем больше эрозия и дальше успеют протечь реки. Возможна ситуация, когда реки не успеют достичь океана, т.е. процесс "не устаканится". Реально нужны миллионы шагов - миллионы лет эволюции. Тут вводится зависимость от возраста планеты.
Во-вторых, как быть с переносом воды и осадков от одного патча к другому? А между патчами разных уровней? А от патчей, которые ещё не существуют? Для физической симуляции нужно, чтобы планета была вся сгенерирована. А это возможно только для нескольких верхних уровней. А на таких масштабах не то что реки, но и крупные озёра ещё не видны. Виден только крупномасштабный рельеф, который определяется скорее тектоникой и метеоритами, чем эрозией. И всё равно остаётся проблема производительности - для 4096*4096 пикселей один шаг занимает 90 мс, тысяча - 9 секунд. И надо придумать, как переносить воду между патчами/гранями кубемапы, или как обобщить алгоритм для сферы (лучше первое).
В принципе, можно для верхних уровней посчитать милиионы лет эволюции, а на нижних просто добавлять "детали" - 10-100 проходов. Но всё равно это всё будет очень медленно. Так что подождём пока 5-10 лет, а там видно будет. Может можно будет запросто считать 10000 проходов на лету каждый кадр и сделать реальную машину времени в движке - не только движение планет по орбитам, но и эволюцию поверхности.
Neptune
Можешь поделиться линками на статьи по цифровой симуляции эррозии?
Можно делать это на фоне. Отдельный поток для расчёта изображений планет. Задача же не просчитать ландшафт планеты с научной точностью а сделать текстуру для планеты.
Neptune
я опять со своей офлайн генерацией.
Как насчет нагенерировать всяких разных объектов типа гор/кратеров и т.п. заранее (штук 100-200 вариантов + всякие лоды и т.п.), а во время работы программы создавать площадку скажем "под горы", а сами горы насыпать из готовых. При достаточно большом кол-ве предгенереированных вариантов вариативность будет достаточна что бы каждый участок выглядел уникальным.
Все равно, когда вскоре дело дойдет до деревьев/городов и т.п. сложных сооружений тебе придется использовать такой метод собирания "мозайки". Почему бы не применить его и на горы/озера/кратеры....
Из плюсов возможность использовать довольно сложных/красивых объектов + легкая возможность добавления "уникальных" объектов. Да и по скорости думаю будет быстрее.
Necrys
> Можешь поделиться линками на статьи по цифровой симуляции эррозии?
Дак тут, пролистай в конец статьи: http://habrahabr.ru/blogs/algorithm/111538/#habracut
zlos
> Можно делать это на фоне. Отдельный поток для расчёта изображений планет.
> Задача же не просчитать ландшафт планеты с научной точностью а сделать текстуру
> для планеты.
Да понятно это всё, проблема не в этом.
koaa310
> я опять со своей офлайн генерацией.
> Как насчет нагенерировать всяких разных объектов типа гор/кратеров и т.п.
> заранее (штук 100-200 вариантов + всякие лоды и т.п.), а во время работы
> программы создавать площадку скажем "под горы", а сами горы насыпать из
> готовых.
> Из плюсов возможность использовать довольно сложных/красивых объектов + легкая
> возможность добавления "уникальных" объектов. Да и по скорости думаю будет
> быстрее.
Можно, такой читерский способ сделать горы с эрозией. Но вопрос: как отобразить заранее подготовленную текстуру на генерируемую, сетка которой другая и вообше нерегулярная? Ресэмплирование может оказаться даже медленнее, чем генерация фрактала. И как определить координаты, куда эту гору пихать? Опять генерить разбиение Вороного? Так это и есть основной боттлнек. Генерация профиля кратера - это просто функция от расстояния до центра ячейки, её при желании можно в 1D текстуру загнать.
Если есть желание, можешь подготовить несколько 16-битных карт высот с кратером, горой, вулканом и т.д., а я тогда загоню их в систему. Кстати, в Infinity хотели так сделать.
ЗЫ: сейчас главный боттлнек - это передача карты высот на CPU, без этого шага планеты генерились бы в 5-10 раз быстрее. Воторой момент - нужно починить генерацию в отдельном потоке, тогда тормоза должны стать вообще не заметны.