у меня успешно получилось не отрисововать те кубики поторые закрыты соседними, тоесть от полностью заполненого чанка остаются только крайние стенки ( внутренности не отрисовываются)
но и этого не достаточно. слышал о алгоритмах которые могут обьединять соседние кубики, которые находятся на одном уровне в один цельный полигон, таким образом плоскость кубиков например 32х32 можно обьединить всего в один полигон.
очень бы хотелось понять как работает такой алгоритм, чтобы его написать, я чесно не нашел ни одной статьи по данному вопросу.
прошу знающих ребят помоч теоретически или практически помоч с таким алгоритмом.
кто заинтересовался пишите свои соображения.
я видел тут на форуме несколько тем по построению такого ландшафта, но и у них оптимизация довольно слабенькая ( как и у меня ), давайте вместе разберемся c данной темой, думаю многим станет полезно
stupid bot
тут где-то рядом есть тема про рендер майнкрафта
Не имеет смысла для игры типа Minecraft, с динамически изменяемой геометрией. Там по 50 чанков в секунду перестраивается, и оптимизация геометрии будет только всё замедлять. Лучше добавить LODы чанков, чтобы вдалеке их можно было больше отрисовать.
Ещё ведь могут быть проблемы с текстурой, надо чтобы все объединяемые квадраты имели одну текстуру и общий базис текстурных координат.
Не взлетит. Только если одинаковые текстурные координаты.
Да и всё равно много поликов не понадобится - в кадр много чанков не влезает + много чанков в памяти не подержишь, тяжело.
ArchiDevil
в кадр может очень много чанков влезть если смотреть с какой-то горы. конечно если предел видимости не ограничивается радиусом в 5-10 чанков.
а чанк можно оптимизировать для памяти, хранить только видимые кубики. в виде проиндексированого массива. в теории
все это для увеличения фпс.
Panzerschrek[CN]
а если чанк оптимизируется еще во время его генерации?
да и всеравно, я же так или иначе его оптимизирую
тоесть отсекаю невидимые кубики, остаются только стенки, в середине чанк пустой. - проверяю наличие 6 соседей, и добавляю полигон если соседа нету.
тоесть разве есть разница каким алгоритмом оптимизировать, крутым или моим простым?
а LOD - само собой, только я до этого еще не дошел )
п.с.
пока что все только на ЦПУ.
есть ли смысл пытатся генерить чанк на ГПУ? (думаю что лучше пока не поднимать этот вопрос )
ну полигоны сами по себе при майнкрафт-детализации очень мало будут жрать.
а вот невидимые кубики надо отсекать/сортировать от ближних чтобы предотвратить овердро.
stupid bot
Мне в голову ничего не приходит, кроме как отсортировать полученные при генерации квадраты по плоскостям, а это уже сложность n*Log(n). Говорю, смысла оптимизировать нет, видеокарта справляется с рендерингом.
stupid bot
> хранить только видимые кубики. в виде проиндексированого массива. в теории
Ну пойди придумай алгоритм для выделения видимых кубиков и содержания их в памяти, в массивах нефиксированного размера, я посмотрю как ты справишься. Лучше LOD систему сделай нормальную, а не занимайся извращениями.
stupid bot
> но и этого не достаточно. слышал о алгоритмах которые могут обьединять соседние
> кубики, которые находятся на одном уровне в один цельный полигон, таким образом
> плоскость кубиков например 32х32 можно обьединить всего в один полигон
Можно обходить октри на CPU. Но тут проблема с нормальной аппаратной реализацией - не сможешь эффективно использовать ресурсы GPU.
Можно попробовать использовать тесселятор для генерации кубиков в блоке относительно небольшого размера - например 16*16*16 .
FROL
> Можно обходить октри
WAT? У вас octree? Зачем?
> Можно попробовать использовать тесселятор для генерации кубиков
Пример шейдера в студию.
тоесть вы мне советуете не заниматся такой оптимизацией ?
тогда вопрос "почему?" сам напрашивается.
какие существенные и не существенные минусы имеет такая оптимизацие?
п.с.
я тут прикинул, что может пострадать расчет освещения (для каждого кубика ) как в МК. из-за больших полигонов, хотя могу ошибатся
Panzerschrek[CN]
> WAT? У вас octree? Зачем?
У меня нет) Но если бы я делал майнкрафт я бы делал октри)
Ещё один минус, и довольно существенный:
> я тут прикинул, что может пострадать расчет освещения (для каждого кубика )
Короче, овчинка выделки не стоит, нефиг заниматься преждевременной оптимизацией.
FROL
> У меня нет) Но если бы я делал майнкрафт я бы делал октри)
А я делал свой майнкрафт, и поверь, там octree не нужен. Его можно применять разве что для сжатия чанков перед сохранением на диск, да и то, обычное сжатие с помощью zlib работает нормально.
алгоритм называется greedy meshing, как-то так. судя по этому http://0fps.net/2012/07/07/meshing-minecraft-part-2/ побыстрее наивного подхода. Но пиксельный шойдер посложнее будет, если один атлас для всех типов блоков использовать.
Тема в архиве.