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

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

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

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

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

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

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

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

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

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

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

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

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

НО!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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