PMG

Так сейчас я скачал основу движка с gamedesign.narod.ru мне она понравилась и сейчас я решил на ней писать движок но у меня возникла сложность как организовать менеджер вершин который работал бы с vertexbuffer и indexbuffer - посути тут надо сделать классы для них и общий менеджер. Еще я хотел бы сделать так что бы позволить работу с вершинами и для OpenGL - точнее в будущем по мере надобности что бы легко можно было добавить рендер OpenGL. Скачать версию движка под DirectX 9.0 можно по URL: http://defg.narod.ru/defg.rar - там ничего не выводиться только синий экран - движок в разработке.

1. В чем сложность с менеджером вершин?
2. Что бы обеспечить поддержку и OGL и DX, надо иметь некий общий абстрактный класс.

_________________
С уважением, Сергей

Мне надо помочь !!! - создать этот менеджер вержин. Я бы хотел что бы он поддерживал и DX и OpenGL. А насчет рендера я думаю можно просто сделать некие объекты - например треугольники и еще спецефекты по разному описать в классах для DX и для OpenGL. А класс Render уже будет определять какой выбран рендер и содержать функции для рендера треугольников и специфектов в зависимости от выбора использовать. Так вот как вообще сделать общий менеджер и для OpenGL и DX ????????????? И общий рендер прошу помогать !!!!

Думаю удобно будет хранить в стеки буферы вершин. Надо мне будет написать наверное для него класс - работа со стеком.

_________________
С уважением, Владислав

Ты смотри в суть проблемы! Вершины какими атрибутами заданы: положение, нормали, текстуры, сочленения. Значит класс для хранения этих атрибутов по mesh должен быть один и не зависит от DX,OGL. А так как рендерить их надо по разному, то классы для вывода их должны иметь одного общего виртуального предка, но реализация их должна быть разной. Т.е. класс mesh_render_ogl должен содержать код, который будет рендерить заданную mesh.

_________________
С уважением, Сергей

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

_________________
С уважением, Владислав

Наверное, ты имеешь ввиду, вот что:
1. Есть чистый виртуальный класс:
class Render {
void render() = 0;
}

2. Делаешь два класса:
class Render_OGL : public Render {
void render () { glBegin() .... }
}
class Render_DX : public Render {
void render() { .... }
}

3. Затем как рендерить выбираешь на этапе инициализации:
Render_OGL * r_ogl;
Render_DX * r_dx;
Render * r_ptr; // текущий рендер
...

if ( type_render == RENDER_OGL ) {
r_ogl = new Render_OGL;
r_ptr = (Render *)r_ogl;
}
else {
r_dx = Render_DX;
r_ptr = (Render *)r_dx;
}

...
r_ptr->render(); // зависит от иницализации.

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

_________________
С уважением, Сергей

Хм, интересно, а перед тем как писать движок С++ выучить не пробовал?
Говорят помогает.

Если чесно, то виртуальные функции здесь не выход.
1) Как ты думаешь, для чего придумали разные triangle strip, vertex array и т.д.? Рисовать каждый треугольник вызовом отдельной функции - пустая
трата ресурсов.
2) Вызов виртуальных функций немного медленне обычних функций.

Немного подумай, и выход найдешь. ОБЯЗАТЕЛЬНО

_________________
"I just don't give a f..." Eminem

1) Если есть геометрия, которая готова для vertex array, то ее всегда можно быстро передать GPU, и виртуальные функции хдесь, по-моему, не помеха.
2) Согласен, но если только много, очень много наследований. А делать все через темплеты, тоже не фонтан .

Я тут эспериментировал с OGL, и для себя выяснил, что triangle strip/fan - не катит, медленно и нудно. vertex array - вещь, быстро и совместимо. vertex_buffer_object - медленнее чем просто vertex array.

_________________
С уважением, Сергей

Гм.. по идее VBO должно быть самым быстрым.
VA все равно гоняет через шину, только одним батчем.
А VBO сразу размещает в видеопамяти..

Кстати кто знает, в direct3d ихние VertexBuffer это аналог VA или VBO ?

Не тут-то было . VBO медленнее ... если надо постоянно менять геометрию!Если конечно геометрия статична, загнал ее один раз в память и все, то тогда, конечно VBO быстрее, чем VA. Это все равно, что lock сделал для VA.

Насчет D3D ничего не могу сказать точно, но скорее всего ты прав.

_________________
С уважением, Сергей

Ну, здесь есть 2 возможных варианта:
1) Модель MVC (Model/View/Controller). Суть ее заключается в следующем: у нас есть некий набор обьектов и отдельно существует обьект (например, рендерер), который умеет рисовать остальные обьекты. Т.е. для вывода на экран нужен вызов вида: renderer.draw( robotMesh );
Модель хороша, только есть несколько серьезных недостатков. Например, сильная связность между классами (что не очень хорошо с точки зрения ООП): если один программист изменяет представление мэшей в классе Mesh, тогда другой программист должен изменить класс Renderer. С другой стороны,
класс Renderer может использовать любой API. Для примера взгляните на
движок Борескова (steps3d.narod.ru)
2) Каждый обьект сам умеет себя рисовать. Т.е. будут вызовы в стиле: robotMesh.render(); О достоинствах и недостатках судить можете сами. Только
как в этом случае организовать вывод с помощью нескольких API? Одно решение имеется (наследование + вирт. функции), но очень "некрасивое".

_________________
"I just don't give a f..." Eminem

По второму методу можно предложить такое решение: делаешь виртуальный класс GraphicObject у него метод render, и потом лепишь потомка GraphicObject_Mesh_OGL, или GraphicObject_Mesh_D3D в нем уже соответственно, что тебе надо помещаешь в метод render. Более того при этом методы ты можешь иметь классы типа GraphicObject_Mesh_OGL_Win или GraphicObject_Mesh_OGL_Linux, а иерархию. Объектов рендерить через указатели на GraphicObject.

for ( i=0; i<count_object; i++ ) list_object[i].render();

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

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

_________________
С уважением, Сергей

Так о способе модель/вид/контроллер у меня дома лежит эта очень интересная книга "Графика 3D-игры на OpenGL" A.B.Боресков. Но в этой книге хоть и профессионально относятся к разработке движка, в ней даны не полные коды классов и довольно сложно описанна разработка как я считаю. С VertexBuffer я думаю разбирусь а может и вовсе не буду делать. Как я думаю в движке хватит сделать такие возможности как работа с окном(создание окна, обр. сообщений), камеру, загрузка моделей с анимацией(О анимации я могу узнать из книги "Продвинутая анимация DX") там всякие спрайты и остальное. Я думаю что ко второстепенным можно отнести работу с интерфейсов в окне используя DX там создание кнопок(исп. напр. текстуры) и конечно работа с Terrain,звуком и физикой. Как вы думаете какую систематику классов мне использовать ???. А насчет Terrain как реализовать Quad-деревья - вообще мне кажется что эта технология искажает поверхность ландшафта когда урезает лишние вершины при рендере(деление поверхности на четыре прямоугольник-квада пока они не опишут объект камеру). А как насчет форума для движка - это будет очень интересной разработкой я думаю Кстати урр C++ я знаю как знаю вроде мне хватает

http://gamedesign.narod.ru - посмотрите на этот сайт я оттуда можно сказать взял движок который разместил на сайте. А сам щас делаю новый движок кто не понял. Так помотрите как там сделана структура движка. Выразите своё мнение.

_________________
С уважением, Владислав