Я еще не довел алгоритм до конца, поэтому трудно судить о его минусах)
все зависит от числа треугольников
у меня сейчас около 100 тысяч в кадре, полет нормальный :)
хотя для стратегии вряд ли столько нужно
Можно начинать разбивку не с икосаэдра, сразу с 4-ой разбивки. В ней 5120 треугольников, цикл проходится быстро, примерно половина отсекается. Но если начинать с икосаэдра, то было 20 стало примерно 10, 10*4=40, было 40 стало примерно 30, далее почти без изменений 30*4=120, 120*4=480, 480*4=1920 т.е. получается нужно перебрать 20+40+120+480+1920=2580, а это меньше чем 5120. Когда треугольники начнут заполнять весь экран, там вообще должно быть все просто отлично.
Я так понял, что вы генерите один длинный VBO, и полностью обновляете его при изменении положения/ориентации камеры? И как, fps сильно падают, если всё время двигаться? Вычисления происходят на CPU? Можно посмотреть в сторону геометрических шейдеров и тесселляции.
Neptune
> один длинный VBO
Фишка в том, что он не настолько длинный, как может показаться первоначально. В массив (на самом деле вектор) занесены только те треугольники, которые можно будет увидеть на экране. Теоретически рендериг должен происходить даже быстрее чем у вас в движке, но в то же время дополнительная нагрузка обусловлена расчетом. Пока да, вычисления на CPU, как работает, сказать не могу, потому что не довел до конца.
registr
> В массив (на самом деле вектор) занесены только те треугольники, которые можно
> будет увидеть на экране.
Может есть смысл заносить не только то, что видно на экране, а вообще вокруг камеры и до горизонта? Тогда можно будет крутиться на месте, и ничего не будет подгружаться. А при движении не перестраивать массив, а обновлять - с той стороны, куда движется камера, добавлять треугольники, с противоположной удалять. Хотя если треугольники идут всперемешку, поиск и удаление будет слишком долгими...
Neptune
просто у него ортогональная проекция и во фрустум попадает мало граней
Neptune
> до горизонта
Так там и получается до горизонта сверху, если выбрать правильный угол для наблюдателя.
> Тогда можно будет крутиться на месте, и ничего не будет
> подгружаться.
Вообще говоря, до поры до времени, пока я не выйду в другую область. Но тогда нужно думать о смене областей и прочее
> А при движении не перестраивать массив, а обновлять - с той
> стороны, куда движется камера, добавлять треугольники, с противоположной
> удалять. Хотя если треугольники идут всперемешку, поиск и удаление будет
> слишком долгими...
Наверно проще создать массив заново, чем искать по массиву есть там треугольник или нет, а потом еще его туда вставлять/удалять...
Ломаю голову над такой задачей. Нужно определить, виден ли треугольник на экране. Допустим сфера состоит из N вершин, тогда треугольников будет примерно 2*N. Чтобы определить виден ли треугольник, нужно перебрать все треугольники и для каждого треугольника перебрать 3 его вершины. Очевидно, определение видимых треугольников будет содержать 2*3*N=6*N вычислений. С другой, стороны очевидно также, что вместе с тем будет проделываться лишняя работа, так как вершин всего N. Логичным было бы перебирать не треугольники, а вершины. Но как потом из полученных видимых вершин получить видимые треугольники? По вершине можно определить 6-5 принадлежащих ей треугольников. Но нельзя их бездумно записывать, так как треугольники будут повторяться. Можно было бы создать булевый статический массив треугольников и записывать туда значения 0/1 - виден/невиден. Но тогда нужно выделять много памяти под него, да и перезаписывать его при изменении камеры мягко говоря хлопотно. Тогда можно создать, что-то вроде динамического списка, но тогда непонятно как обращаться к его элементам по индексу, который вообщем неизвестен. Получаем дилемму. Интересно, существуют ли какие-нибудь подобные методы?
мне всё-таки кажется ты не тем занимаешься. Создай сферу где поменьше треугольников. Отрисовывай их втупую для быстроты разработки игры. Сконцентрируйся на геймплее, а не на оптимизации ненаписанного сферического движка.
registr
Рендерь не отдельными треугольниками, а треугольными патчами. Если даже малюсенький кусочек патча виден, рендерь его весь - ничего страшного. Для патча проверяй видимость BBox-a, можешь сделать его какой-нибудь треугольной формы для оптимальности.
Если хочешь всё-таки проверять каждый треугольник, заведи в структуре, описывающей вершину, булево поле - видна/не_видна. Для компактности под него лучше выделить 1 бит. Я обычно собираю все булевы ключи в одну int или short переменную, и работаю с ними через маски. Если других булевых ключей нет, можно позаимствовать старший бит у какой-нибудь int переменной.
Проверяешь все вершины, устанавливая бит. Потом при рендере треугольников считаешь, у скольких вершин ключ = true.
Доделал свой механизм. С динамическими тайлами и уровнями детализации.
Сама прога: http://narod.ru/disk/6266457001/5_2.rar.html
DLL: http://narod.ru/disk/6266553001/dll.rar.html
Определение виден ли треугольник на экране или нет оставляет желать лучшего. Возможно, лучше переделать этот момент через буфер выбора или еще какой-нибудь буфер. Надо подумать.
registr
> Доделал свой механизм. С динамическими тайлами и уровнями детализации.
> Сама прога: http://narod.ru/disk/6266457001/5_2.rar.html
> DLL: http://narod.ru/disk/6266553001/dll.rar.html
Не запускается. Не хватает libgcc_dw2-1.dll, а после неё, я уверен, ещё какой-нибудь, и ещё... Перед тем, как выкладывать демку, не плохо было бы определить все зависимые dll, и положить их в комплект. Могу помочь в этом процессе - присылай по одной dll, а я буду писать, пошло или нет:)
registr
> Определение виден ли треугольник на экране или нет оставляет желать лучшего.
> Возможно, лучше переделать этот момент через буфер выбора или еще какой-нибудь
> буфер. Надо подумать.
О_о Не пугай так... Определение, виден ли объект на экране - это то, с чего должен начинаться движок:) И делается это на ЦПУ, простой векторной математикой, BBox-ами или BSphere-ами. И не больше нескольких сотен таких объектов за кадр. Треугольник - слишком мелкий объект, их же сотни тысяч должны быть. Если треугольником ты называешь кусок ландшафта треугольной формы, тогда гуд:)
Neptune
> Не запускается. Не хватает libgcc_dw2-1.dll, а после неё, я уверен, ещё
> какой-нибудь, и ещё...
Перешел на новую версию qt и mingw, поэтому не учел. Перезалью.
Neptune
> BBox-ами или BSphere-ами.
Как? Я не знаю, что это.
Я уже объяснял свой механизм. Проверяются треугольники икосаэдра, выбираются видимые на экране, делятся, и опять так далее до желаемой разбивки. Рисуется только окончательный массив, после цикла по разбивкам. Другой вопрос, как определить виден ли треугольник на экране оптимально.
Вот требуемый файл libgcc_s_dw2-1
registr
Работает, но отсечка да, корявенькая. Может ты перепутал условие видимости? Треугольник НЕ виден, если все три его вершины НЕ видны. У меня подобное было, долго не мог понять, в чём глюк.
А как повернуть камеру, чтобы посмотреть вдоль горизонта? Такие ощущение, что детализация меняется сразу по всей сфере.
Вот теперь замени треугольник на треугольной формы BBox, в который вписан кусок ландшафта из 1000-2000 полигонов, тогда получится нормальная детализация. Только ИМХО квадратные куски ландшафта всё-таки удобнее...
Тема в архиве.