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

[bugway]

Я пытался сказать, что использование PB10 нисколько меня не ограничивает. Как и в Си те же оконные процедуры, обработка сообщений и т.п. Наличие ассемблера вообще развязывает руки. На результирующую DLL движка использование PB10 негативно не повлияет.

А теперь по существу:

Кто делал фабрику мешей, поделитесь соображениями - как это лучше связать с буфером/буферами вертексов?
Варианты (просто пришедшие в голову):
1. Хранить все меши в едином буфере вертексов. В классе меша реализовать ссылки на определенную область в буфере вертексов.
2. Хранить сами вертексы как часть экземпляра класса меша и использовать отдельный буфер вертексов для каждого меша.

Иначе говоря, сколько статических буферов вертексов принято использовать - один или столько, сколько мешей?

Второй вариант позволит использовать такой стиль:
MyEngine.Mesh(i).Render

Первый вариант (с общим буфером) такой стиль:
MyEngine.Render Mesh(i)

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

[Mr_F_]

Я пытался сказать, что использование PB10 нисколько меня не ограничивает. Как и в Си

Function NvAPI_GetDisplayDriverVersion(ByVal hNvDisplay As Dword, pVersion As NvDisplayDriverVersion) As Long 'CDecl
pVersion.version=Len(pVersion) Or 65536
! push dword pVersion
! push dword ptr hNvDisplay
Call Dword NVfunc(2)
! mov RetVal, eax
Function = RetVal
End Function

Ты ведь в курсе, что чтобы вызывать в С функцию из длл, не надо передавать аргументы асмом? Можно просто подключить хидер и либ и вызывать как обычную. В крайнем случае можно подгрузить динамически, но и там всё проще.
Тьфу, да даже в блицаке можно было юзать деклс и вызывать нормально.

Никто никогда не напишет для повербейсика хидеры. Захотел юзать самый популярный формат моделей FBX? А вот и хер тебе, например, сдк есть только под С++ и Питон.

1. Хранить все меши в едином буфере вертексов. В классе меша реализовать ссылки на определенную область в буфере вертексов.

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

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

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

Второй вариант позволит использовать такой стиль:
MyEngine.Mesh(i).Render

Первый вариант (с общим буфером) такой стиль:
MyEngine.Render Mesh(i)

Первый вариант тоже должен мочь реализовываться вторым кодом, почему нет?
"Каждый объект сам себя рендерит" это не лучшая идея (уже много где обсуждалось). Каждый раз входишь в функцию, кладёшь что-то на стек, плюс она ещё может быть виртуальной (не знаю как в вашем бейсике), мы ждём пока каждая функция выполнит гапи код. Если много объектов - то много оверхеда накапливается.
Намного приятнее имхо и дружелюбнее к железу представлять все объекты как данные. Меш должен содержать только инфу, нужную для его рендера. Дальше ты рендереру посылаешь толстую пачку этих мешей, и он, как на конвеере, их рендерит друг за другом без перерывов, в одном цикле. Также, в таком случае этот конвеер можно крутить в параллельном потоке, например.

[pozitiffcat]

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

Если имеется ввиду неймспейсы как в си, то - нет. Движок должен работать с максимальным количеством различных компиляторов. Поэтому я использую COM DLL с зашитой в нее TLB, чтобы не подключать хидеры.

Пздц.
В си нет неймспейсов, в плюсах есть. Что бы твоя дллка работала везде, нужно пилить extern "C" и __declspec погугли.

И да. Неймспейсы для переносимости не нужны, но на компилятор это никак не влияет ))

[pozitiffcat]

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

Кто делал фабрику мешей, поделитесь соображениями - как это лучше связать с буфером/буферами вертексов?

Мое предложение. Каждый меш хранит один буффер с вершинами и буффер с индексами. Затем Список Поверхностей их индекс начала, конца и указатель на материал.

При отрисовке биндим оба буффера, и циклом бежим по поверхностям рисую диапазоны индексов. Все.

// псевдокод
template <typename T>
class Buffer {
}

struct Surface {
    std::pair<int, int> range;
    Material *material;
}

class Mesh {
public:
    void render() {
        bindVertexBuffer(m_vertexBuffer);
        bindIndexBuffer(m_indicesBuffer);
        bindShader(); // устанавливает настройки меша в шейдер
        for (const Surface &surface : m_surfaces)
            renderSurface(surface); // устанавливает настройки поверхности в шейдер - рисует
    }
private:
    std::vector<Surface> m_surfaces;
    Buffer<Vertex> m_vertexBuffer;
    Buffer<int> m_indexBuffer;
} 


[Samodelkin]

соглашение о вызовах

[bugway]

А с точки зрения материалов? В каждом меше создавать еще подмеши со своим материалом?

А потом в цикле рендера перебирать все подмеши всех мешей с одним материалом, потом с другим материалом, потом с третьим и т.п.? Не убьет ли это производительность?

Т.е. если имеем в кадре 100 различных типов мешей по 10 материалов. Итого нужно 1000 вертексных буферов + столько же индексных?

[Mr_F_]

Т.е. если имеем в кадре 100 различных типов мешей по 10 материалов. Итого нужно 1000 вертексных буферов + столько же индексных?

ну в идеале тебе нужен 1 VB и 10 IB.

в не идеале, хотя бы 1 VB/IB на меш ничто не мешает держать - тогда по 100 тех и тех + для каждого типа материала хранишь оффсет/размер (диапазон короче) в индексбуфере меша.

[pozitiffcat]

Я же все написал выше.
А что бы избегать много объектов, делай класс который сконструирует один меш из 100, сгруппируя по материалам. Это относится к статике. Также можно заюзать текстурный атлас. Можно добиться отрисовки всего за 1 дип.

[bugway]

Занимаюсь оптимизацией. Как каждый из вас относится к идее не использовать DIP в пользу DP ?

Плюсы DP в том, что можно дублировать вертексы в одной позиции с разными текстурными координатами. Из минусов только большое количество самих вертексов (для куба аж 36 вместо 8 при DIP). Но судя по профайлингу DP быстрее DIP на 10-15%. Поэтому вроде больше плюсов у DP, чем у DIP.

Кто как думает?

[Arton]

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

Занимаюсь оптимизацией. Как каждый из вас относится к идее не использовать DIP в пользу DP ? Кто как думает?

Если бы мне кто объяснил что есть что?

[bugway]

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

Если бы мне кто объяснил что есть что?

DP - DrawPrimitive
DIP - DrawIndexedPrimitive

[HolyDel]

Post T&L cache.

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

про post T&L cache - когд вершину обработал вершинный шейдер, результаты ее хранятся в кэше. И если есть треугольники со смежными вершинами - то эти смежные вершины в случае DIP будут считаться только один раз, в случае DP для каждого треугольника всегда считаются три вершины. и неважно, считались они уже или нет.

[Samodelkin]

И я так понимаю, что если рендер имеет сильный перекос в сторону пиксельных шейдеров (perpixel light, deffered shading и т.п.), то возможно DP в некоторых ситуациях будет предпочтительней.

[HolyDel]

по идее в случае сильного перекоса в сторону пиксельных шейдеров будет без разницы. на растеризации будет ботлнек.

для куба аж 36 вместо 8 при DIP

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

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

[Samodelkin]

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

по идее в случае сильного перекоса в сторону пиксельных шейдеров будет без разницы. на растеризации будет ботлнек.

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