Пишем 3D движок - замену Xors3D

[moka]

Сообщение от impersonalis

что нужно (?)

jimon всё правильно сказал.

[bugway]

Блин.... как же я ступил с 3D vision... Удивляюсь, почему не работает разделение ракурсов - а ведь банально проглядел, что у меня стояло %D3DCREATE_SOFTWARE_VERTEXPROCESSING
... Поправил на %D3DCREATE_HARDWARE_VERTEXPROCESSING и все стало работать... И ФПС поднялся в 4 раза...

P.S. У кого есть опыт создания игрушек на DX - подскажите - как работали с клавиатурой? Через DirectInput или GetAsyncKeyState WinApi?

[Mr_F_]

P.S. У кого есть опыт создания игрушек на DX - подскажите - как работали с клавиатурой? Через DirectInput или GetAsyncKeyState WinApi?

и так и эдак, по сути разница не велика, но DirectInput не советуют сами MS юзать, т.к. забили на него.
в винапи я только не GetAsyncKeyState юзал, а GetKeyboardState - она возвращает массив со всей клавы где нажато, где нет (раз в кадр вызывал).

[bugway]

Точно. Шапку больше править нельзя...

[bugway]

Имеем: ландшафт и набор моделей с разными материалами и камеру, которая смотрит на часть моделей из набора.

Правильно ли я понимаю следующие вещи: (поправьте, если не прав)

0. Постоянно загружаем в фоне нужную порцию вертексов с диска в память (неважно для чего: ландшафта, моделей и т.п.), проверяя что нужно грузить исходя из положения и направления камеры.
1. Опрашиваем устройства ввода, считаем физику, меняем координаты вертексов и т.п.
2. Сортируем все вертексы по материалам, создаем вертексные буферы для каждого материала и пишем в них только то, что должно быть видно из камеры.
3. Для каждого материала перед рендером соответствующего вертексного буфера на экран устанавливаем вертексный шейдер через SetVertexShader.
4. Рендерим все получившиеся вертексные буферы.
5. Применяем пиксельный шейдер на всю картинку.

НО!

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

[Mr_F_]

0. Постоянно загружаем в фоне нужную порцию вертексов с диска в память (неважно для чего: ландшафта, моделей и т.п.), проверяя что нужно грузить исходя из положения и направления камеры.
1. Опрашиваем устройства ввода, считаем физику, меняем координаты вертексов и т.п.
2. Сортируем все вертексы по материалам, создаем вертексные буферы для каждого материала и пишем в них только то, что должно быть видно из камеры.

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

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

это вообще полный бред, дешевле нарисовать огромный меш не попадающий в камеру, чем дрочить буферами каждый кадр.

3. Для каждого материала перед рендером соответствующего вертексного буфера на экран устанавливаем вертексный шейдер через SetVertexShader.
4. Рендерим все получившиеся вертексные буферы.
5. Применяем пиксельный шейдер на всю картинку.

у тебя каша в голове, на каждый вызов отрисовки необходим как вертексный так и пиксельный шейдер - обязательно, если одного из них нет, то дх9 будет делать его через ффп (что все равно эмулируется шейдерами в драйвере), в дх10-11 ффп вообще нет, и без шейдеров работать нельзя.
применять постпроцессовый шейдер поверх всей картинки в конце можно - но не обязательно.

запомни - закачка чего-то из оперативки в видеопамять (и наоборот) это адово дорогая операция, ничего кроме шейдерных констант ты не должен по-хорошему каждый кадр перезаливать.
нет, бывают исключения, типа когда нам надо на цпу какое-нибудь soft body симулировать, но это единичные случаи, за которыми надо чётко следить и вырубать/лодить их жестоко при первой возможности. в старых играх, бывало фпс у анимаций скиненых персонажей уменьшали вдали, лол, чтобы скинмеши перезаливать реже.
-----

почитай
http://netlib.narod.ru/library/book0032/
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

[bugway]

Я понял так: если геометрия статичная, то действительно - можно сделать один единственный буфер вертексов и один раз залить его в видеопамять. В этом буфере будут все вертексы всех статичных моделей с кадрами анимаций, уровнями детализации и т.п. Естественно там должно быть отсортировано всё по материалам. А рендерить такой буфер необходимо кусками по типу материала. Например: верстекс 1-120 - вертексы одного материала, 121-240 - другой материал, и .т.п. Уменьшить кол-во вызовов DrawPrimitive можно использованием текстурных атласов.

Но как быть с динамической геометрией? Или ее желательно тоже привести к статике? При динамическом ландшафте можно попробовать что-то типа marching triangles, т.е. залить в буфер вертексов все возможные комбинации и рендерить ту комбинацию, которую нужно, предварительно задав матрицу транформации.

Что я имею ввиду. Возьмем к примеру мир Minecraft. Базовый элемент мира - куб. Если использовать идею, которую я описал выше, то нам в буфере вертексов нужен всего один куб (36 вертексов). При рендере куба в нужном месте мы просто задаем матрицу смещения.

Я правильно рассуждаю?

[pax]

В майнкрафте рендерится не кубами, а чанками, каждый чанк это 16х16х128 генерируется отдельно, и там не кубы, а фейсы только те, что видно.

Плюс вспомни прозрачную геометрию, которая должна сортироваться каждый кадр и рисоваться от дальнего к ближнему.

[bugway]

Сообщение от pax

В майнкрафте рендерится не кубами, а чанками, каждый чанк это 16х16х128 генерируется отдельно, и там не кубы, а фейсы только те, что видно.

Но ведь чанки - это по сути динамическая геометрия. Чанк перестраивается, когда ставится или удаляется куб. Т.е. происходит изменение буфера вертексов. Верно?

[pax]

Да, там чанки постоянно перестраиваются.

[bugway]

Сообщение от pax

Да, там чанки постоянно перестраиваются.

Иначе говоря, происходит частая пересылка вертексов из памяти в буфер вертексов. Верно? Понятно, что не каждый кадр, но суть такая?

[pax]

В Unity есть так называемый статик батчинг, который объединяет всю статическую геометрию на старте, но это отключается если не нужно.

Сообщение от bugway

Иначе говоря, происходит частая пересылка вертексов из памяти в буфер вертексов. Верно? Понятно, что не каждый кадр, но суть такая?

Я думаю эта память заранее выделена, и обновляется по необходимости.

[bugway]

Я пытаюсь сказать, что имеется дилемма: либо относительно часто менять буфер вертексов, но рисовать минимальным кол-вом вызовов DrawPrimitive, либо наоборот: не трогать буфер вертексов, но тогда будет огромное число вызовов DrawPrimitive.

[pax]

В универсальных движках всегда так. Когда пишешь движок под конкретный проект ты сможешь все оптимизировать как тебе надо.

[Mr_F_]

Иначе говоря, происходит частая пересылка вертексов из памяти в буфер вертексов. Верно? Понятно, что не каждый кадр, но суть такая?

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