forum.boolean.name - Пишем 3D движок

forum.boolean.name (http://forum.boolean.name/index.php)

- Xors3D (http://forum.boolean.name/forumdisplay.php?f=126)

- - Пишем 3D движок - замену Xors3D (http://forum.boolean.name/showthread.php?t=18971)

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

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

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

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

Цитата:

Сообщение от bugway (Сообщение 278081)

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

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

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

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

Цитата:

Сообщение от bugway (Сообщение 278133)

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

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

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

PHP код:




// псевдокод
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;
}

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

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

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

Цитата:

Сообщение от bugway (Сообщение 278302)

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

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

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

Цитата:

Сообщение от Arton (Сообщение 278303)

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

DP - DrawPrimitive
DIP - DrawIndexedPrimitive

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

Post T&L cache.

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

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

Сообщение от HolyDel (Сообщение 278333)

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