- =A=L=X=
- Постоялец
Погуглил и главным образом только отсылки к движку Cube 2 бесплатному из того что можно сказать "разговор по существу".
Но пока не хотелось бы с головой уходить в изучение исходников - а так сказать порассуждать над основами.
Из полезного что на форуме нашел - побить пространство на субкубы большенького размера которые уже будут скоплением сравнительно больших мешей для снижения DIP. Октри там какой нибудь наложить для быстроты отсечения фруструма.
Но что то как то и всё? Или кто знает более мощные концепты?
Может задебажить игру в PerfStudio/прочих? Включить вайрфрейм и всех делов :)
А вообще в майнкрафте не такое уж и большое количество видимых кубиков, инстансинг зарулит...
Програмно каждый кубик может быть или открытым(хотябы одна сторона в воздухе) или закрытым. Тоесть обрабатывается некая 3д плоскость, а не все кубики. А тут уже можно заюзать индор техники.
Недавно пробовал рендерить большую территорию, состоящую из кубиков:
40 FPS на GeForce 310M
Здесь порядка 5 миллионов кубиков, которые разделены на чанки (отдельные меши из 64x64x32 32x32x64 кубов). При обновлении чанка генерируется меш, который состоит только из видимых сторон кубов.
там вапще всё разбито по chunk'ам, если не знаете - вроде как весь мир разбивается на 16x16x128 кубиков, чанков. В сети ландшафт загружается чанками.
Che@ter
> А вообще в майнкрафте не такое уж и большое количество видимых кубиков,
> инстансинг зарулит...
А чего там инстансить то? Куб же очень простая фигура, более того в подавляющем большинстве видны только одна-две-три грани. Разве есть смысл "инстансить" грани?
Хорошо, допустим видюхи умеют сотни миллионы маленьких трисов в секунды, в это верится.
А вот как быть с филлрейтом? Довольно легко напридумывать ситуаций когда филлрейт забьёт растеризатору печенку вконец.
Например поле из множества плоских слоёв с пустыми слоями между ними и вот мы в центре композиции смотрим наверх там или вниз.
Очевидно полезно рендерить от ближних чанков к дальним включив z-buffer, но как то поэффективней можно?
=A=L=X=
> но как то поэффективней можно?
Конечно, просто не нужно рисовать то что не видно,
раньше так во всех играх делали, а теперь разленились.
Hybernaculum
> Конечно, просто не нужно рисовать то что не видно,
> раньше так во всех играх делали, а теперь разленились.
Воистину так, это отличный совет. Теперь вопрос - как это реализовать в условиях майнкрафта, когда потенциально любая конфигурация кубов может быть и самое плохое - они могут быть динамически перестроены в рантайме.
Я сколько ни думаю в сторону PVS для такого массива кубов - толкового что то ничего не приходит. Либо чудовищные структуры по размеру превышающие сам лабиринт, непонятно как вычисляемые, особенно для случая рантайма, либо одно из двух.
Если например в том же же сценарии из множества плоскостей что я описал в каждой плоскости сделать дырочку вдоль одной линии - охохо...
думаю, в майнкрафте освещение интересно сделано - свет всегда четко проникает в шахты.
Может поможет http://www.sea-of-memes.com/LetsCode1/LetsCode1.html
Igor'
Зачетная ссылка
Igor'
> http://codeflow.org/entries/2010/dec/09/minecraft-like-rendering-…
> -in-opengl-4/
Да, ссылка зачётная но и большая, вечером подробнее почитаю.
> Может поможет http://www.sea-of-memes.com/LetsCode1/LetsCode1.html
Вот сразу от себя уже странное из выстраданного вижу - тут предлагается батчи составлять по текстурам. Однако вспоминая крохотные и одинаковые размером текстурки майнкрафта сдаётся мне намного более оптимальный способ - сделать атлас из квадратных текстур и батч строить один просто манипулируя текстурными координатами. Разве не? Просто после встречи такого подхода как то сомнение возникает в практичности изложенных вещей.
У меня так:
Собираю меш по чанкам 16x16x256.
Jarro
> 16x16x128
Conductor
> 32x32x64 кубов
ArchiDevil
> меш по чанкам 16x16x256.
Скажите пожалуйста - почему все (и, кстати, единственные "все" кто вообще что-то своё делал) вы удлиняете размер меша в одном каком то пространственном направлении в разы???
В чём профит?
удлиняют так как по Y обычно информации мало.
Тема в архиве.
