Войти
ПроектыФорумОцените

Planet_E (3 стр)

Страницы: 1 2 3 4 510 Следующая »
#30
13:41, 8 сен. 2010

Viaceslav(C)
на той планете разумная жизнь еще не зародилась, только микробы )


#31
13:51, 8 сен. 2010

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

#32
14:09, 8 сен. 2010

Aslan
> я понял, пятиугольники вокруг вершин исходного икосаэдра
> ничего тут не сделаешь
Да, именно так, но они особо не мешают. Может пригодится тебе: я использую такую систему - каждому номеру узла соответсвуют заданные шесть номеров окружающих его треугольников. Например, узлу N соответствует треугольники K0, K1, K2, K3, K4, K5. Если К4!=K5, то это шестиугольник. Если нет, то пятиугольник и K5  в рассмотрении не участвует. Так программа определяет, где шестиугольник, а где пятиугольник ;)

Aslan
> я тоже сейчас пишу рендер планеты треугольниками, поверхность рельефная и
> детализация пропорциональна расстоянию до наблюдателя
Интересно-интересно, ссылочку дашь? :)

#33
14:29, 8 сен. 2010

подпишусь. Классные наработки, уважаю. Непременно продолжай и развивай!

#34
14:40, 8 сен. 2010

ссылки
http://aslan7470.narod.ru/Planet/exe.zip - бинарник и данные для работы
http://aslan7470.narod.ru/Planet/src.zip - исходник, C++Builder 6.0, неполные, только сама планета

мне кажется так: ты же берешь соседей некоторой вершины и строишь шести- или пяти-угольник по ним
вершины с пятиугольниками заранее известны

правка
сечас заметил:
если на последней стадии бить треугольники не на 2, а на 3
тогда вершины шести- и пяти- угольников (со стороной=1/3 стороны треугольника) будут в центрах и вершинах треугольников

многоугольники - красиво, но неуверен что они будут плоскими
и с ними не сделаешь ЛОД

#35
15:09, 8 сен. 2010

Aslan
> ссылки
> http://aslan7470.narod.ru/Planet/exe.zip - бинарник и данные для работы
> http://aslan7470.narod.ru/Planet/src.zip - исходник, C++Builder 6.0, неполные,
> только сама планета
ок, спасибо, изучу ;)

Aslan
> вершины с пятиугольниками заранее известны
Так оно и есть. Создана специальная, так сказать, "промапеная", база, с помощью которой получается взаимноодназначное соотвествие между узлами и треугольниками. Проще можно сказать: треугольник видит свои узлы, узел видит свои треугольники.

В частности здесь:
> Например, узлу N соответствует треугольники K0, K1, K2, K3, K4, K5.
и используется эта база.

А записывается она по такому принципу. Пусть N - какой-то узел. Последовательно перебираю все треугольники и записываю их таким образом:
K0, K0, K0, K0, K0, K0
K0, K1, K1, K1, K1, K1
K0, K1, K2, K2, K2, K2
K0, K1, K2, K3, K3, K3
K0, K1, K2, K3, K4, K4

и тут внимание: если фигура - пятиугольник, так и останется. Если шестиугольник, то перезапишется:
K0, K1, K2, K3, K4, K5

Aslan
> многоугольники - красиво, но неуверен что они будут плоскими
Да, кстати, подумал, это очень вероятно.

#36
17:14, 8 сен. 2010

registr

если на последней стадии бить треугольники не на 2, а на 3
тогда вершины шести- и пяти- угольников (со стороной=1/3 стороны треугольника)
будут в центрах и вершинах треугольников

и без предварительных расчетов!

#37
19:30, 8 сен. 2010

Что-то я не понимаю, зачем нужны все эти шестиугольники. Это типа такая система координат, обозначение регионов планеты? Если да, то какого они размера? И зачем, если юниты ходят как захотят, не по клеточкам? Или это разбиение для рендера? Если так, то для получения адекватной детализации нужно 15-20 уровней рекурсии. И всё это на ЦПУ... Боюсь будет либо тормозно, либо мало деталей...

#38
21:42, 8 сен. 2010

Aslan
> если на последней стадии бить треугольники не на 2, а на 3
> тогда вершины шести- и пяти- угольников (со стороной=1/3 стороны треугольника)
> будут в центрах и вершинах треугольников
Да, действительно, спасибо за заметку. Можно использовать разные комбинации разбивки.

Neptune
> Что-то я не понимаю, зачем нужны все эти шестиугольники.
Ну тут идет обсуждение всех возможных вариантов. Хотя для меня это непринципиально - чтобы сфера состояла из шести-пяти-угольников. А интересно мне то, что можно использовать разные комбинации разбивки, чтобы получать разные детализации карты.

Neptune
> Если так, то для получения адекватной детализации нужно 15-20 уровней рекурсии.
> И всё это на ЦПУ... Боюсь будет либо тормозно, либо мало деталей...
Если все тайлы сферы грузить в память, то да (хотя кто знает, какая завтра будет память). Логично было бы, как заметил Aslan, использовать детализацию в зависимости от масштаба (что-то вроде гуглмапа). А вообще надо все продумать и взвесить, чтобы получилось наиболее оптимально, пока что это просто бета беты ;).

#39
21:43, 8 сен. 2010

Neptune
ЛОД решает. Близко много деталей, далеко мало. Рекурсивное разбиение
И конечно строится на CPU

Твои демки видел, все классно, но кажется нет приближения до поверхности планеты, т.е. детализация ограниченная?

#40
21:47, 8 сен. 2010

registr
Мою демку смотрел? ЛОД решает проблему, все это давно придумано, давно была игра Eve с виртуальной вселенной
По этой теме есть статьи,  поищи Bourke "planet rendering". У меня сделано даже проще

#41
22:04, 8 сен. 2010

Aslan
> Мою демку смотрел?
Инет дома барахлит, нифига не пашет, завтра с работы загружу. Интересно посмотреть, что там и как ;)

Aslan
> Твои демки видел, все классно, но кажется нет приближения до поверхности
> планеты, т.е. детализация ограниченная?
Ну да, так и есть. Там есть две карты, 4 и 5 итерация от деления икосаэдра 1 к 4. Все тайлы сразу грузятся в память, что не есть хорошо. Поэтому и детализация ограничена.

#42
22:34, 8 сен. 2010

registr
Это я Нептуну писал, у него планеты и звезды, целая галактика, посмотри его тему
У меня тоже берется икосаэдр и каждый треугольник делится на 4, но лишь при условии что длина max стороны / расстояние от наблюдателя > нек.порог (скажем 0.1) - угол зрения. Т.о. получается ЛОД, чем дальше, тем треугольники крупнее (и их нужно меньше), вся планета в пределах ~ 10K триков
Еще сделан рельеф, при делении стороны пополам к точке добавляется псевдо-случайное смещение от центра планеты (каждая вершина хранит seed для srand(), в новой вершине seed получается через сумму концов ребра), с каждым уровнем разбиения смещение уменьшается.
Нерешенная проблема-ограниченный диапазон буффера глубины, нужно от метров до миллионов км (1-10^9), точности float не хватает
Есть идея, как сортировать сферы(планеты) при выводе нескольких, выводить в порядке убывания расстояния по касательной (т.е. Distance^2-Radius^2), это правильно разрешает перекрытия

#43
0:29, 9 сен. 2010

Aslan
> Твои демки видел, все классно, но кажется нет приближения до поверхности
> планеты, т.е. детализация ограниченная?
  Нет, не ограниченная. Точнее на видео и в выложенной демке (0.75 beta) ограничена данными, которые есть в наличии в файлах на диске. Рельеф на поверхности есть.
  За основу взят куб, т.к. его грани - квадраты, на них легче всего ложить текстуру. При рендере происходит рекурсивное разбиение граней (динамическое квадро дерево), с подтягиванием вершин на поверхность сферы, плюс данные из карты высот. При чём "элементом", узлом дерева является не вершина, а меш 33*33 вершины, который строится по загружаемой с диска или генерируемой процедурно текстуре - карте высот. На этот меш накладывается текстура цвета (а не раскрашиваются сами вершины), и карта нормалей, которая строится по той же карте высот. Короче как в гугл земле, хотя там не куб в основе. ЛОД получается автоматически - разбиение узла происходит, когда его размер на экране больше предельного. Ну и отсечение невидимой геометрии вью фрустумом и сферой планеты тоже достаточно эффективное из-за иерархичности дерева (если узел вышел за границы экрана, то и все его потомки тоже вышли).
  Приведу числа. Насовская текстура Земли имеет в оригинале разрешение 86400*43200, для моего движка преобразована в 6 граней куба по 32768*32768. Детализация примерно 300 метров на пиксель. Полностью загрузка всех текстур при неподвижной камере на поверхности планеты происходит за 10 секунд, при этом потребляется ~300 Мб видеопамяти. Если использовать сжатие текстур, то можно и в 100 уложиться.
  Сейчас занимаюсь процедурными планетами, т.е. вместо загрузки с диска происходит генерация текстур высоты и цвета, причём на GPU. Приосходит это примерно на порядок быстрее, чем загрузка с диска:) И нет предела детализации, кроме объёма вмдеопамяти и желаемого быстродействия.

Aslan
> давно была игра Eve с виртуальной вселенной
В Eve-online до сих пор нельзя приземляться на пленеты, потому что они плоские:) Или ты не про неё?

Aslan
> Еще сделан рельеф, при делении стороны пополам к точке добавляется
> псевдо-случайное смещение от центра планеты (каждая вершина хранит seed для
> srand(), в новой вершине seed получается через сумму концов ребра), с каждым
> уровнем разбиения смещение уменьшается.
Это diamond-square? Имхо не самый лучший алгоритм, хоте формы красивые получаются. Но мало возможностей для контроля. Тем более он на ЦПУ... Ребята, там, где много вычислений, надо использовать только GPU! :)

Aslan
> Нерешенная проблема-ограниченный диапазон буффера глубины, нужно от метров до
> миллионов км (1-10^9), точности float не хватает
> Есть идея, как сортировать сферы(планеты) при выводе нескольких, выводить в
> порядке убывания расстояния по касательной (т.е. Distance^2-Radius^2), это
> правильно разрешает перекрытия
Правильно, планеты нужно рисовать от дальних к ближним, причём далёкие планеты можно вообще рисовать без z-теста, художником, т.к. издалека рельеф всё равно не различить (исключение - кривые астероиды, планеты с кольцами, облаками, и т.д.). Для остальных использовать z-тест, но при этом очищать z-буффер перед рендером каждой следующей планеты, устанавливать ближнюю и дальнюю плоскости отсечки, чтобы планета была чётко зажата между ними, тогда на каждую планету будет целиком весь z-буффер. С таким приёмом мне хватает 32-битного z-буффера для детализации от 10м до 10-20 тыс. км. (радиус крупной твёрдой планеты). Можно ещё использовать float z-буффер, инверсную функцию z-теста, логарифмирование z-величины в шейдере, не знаю, не пробовал.

#44
8:56, 9 сен. 2010

Neptune
Может не Eve, а по другому называтся, но такая игра была
На youtube множество видео "planet rendering"
diamond-square - не знаю, у меня из треугольников, начинается с икосаэдра
меш 33*33 вершины - ты сделал для удобства вычисления след. уровня на GPU? Используешь шум Перлина?

> где много вычислений, надо использовать только GPU
как сказать, 20K вершин - это много для CPU? А у тебя сколько?

> Правильно, планеты нужно рисовать от дальних к ближним...

Аха, на каждую планету свои установки z-buffer, для достаточно далеких только FACE_CULL
+ отдельный z-buffer для мелких объектов (др.кораблей, астероидов) в пределах видимости и различимости деталей

Точность float - 7 знаков (мантисса 24 бит). Хватило бы на планету (с учетом диапазона min dist - max dist), если бы z-buffer был линейным. Худшая ситуация когда к примеру стоишь на поверхности горы и горизонт за 100 км
В остальном у меня и будет сортировка, звезды вообще рисуются первыми с выкл. z-buffer
Сферы в общем случае надо сортировать по длине касательной, планеты сойдет и по расстоянию до центра, т.к. расстояния между ними много больше их радиусов

Страницы: 1 2 3 4 510 Следующая »
ПроектыФорумОцените

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