ну у меня векторы и вершины используют одну структуру основной элемент которой m[3]; Хотя можно и написать для вершин и векторов отдельные классы.

noKEmoH, это значит ты неправильно архитектуру строишь. Всё должно быть логично, ибо программирование - это логика в чистом виде.
Не надо никаких классов вершин. Просто когда ты будешь делать класс модели, заводи указатель на тип float и пиши в память вершины.

Хорошее начинание, годится для написания небольшого трактата на тему "сферический конь в вакууме".

Можно присоединиться?   

Движок "сферический конь в вакууме (СКВВ) для DirectX":
1. СКВВ состоит из основных подсистем: графика, физика, игровая логика (AI если угодно), звук, работа с данными (загрузка-выгрузка ресурсов). Рассматриваем только графику, остальное пока отбросим.

2. Графическая подсистема функционально представляет собой бесконечный цикл, в котором отрисовывается кадр. Структурно это набор классов, где присутствуют следующие основные понятия:

• рендерер - управляет циклом отрисовки, обрабатывает события графического устройства
• 3D объект - всё что нужно для описания одного 3D-объекта в сцене, содержит ссылки на материал, геометрию и параметры (размер, позиция и ориентация в пространстве, др. параметры)
• источник света - подвид 3D объекта, не отрисовывается сам по себе, указывает параметры освещения (диффуз, спекуляр)
• камера - подвид 3D объекта, не отрисовывается сам по себе, указывает точку и направление обзора, FOV и aspect ratio
• сцена - плоский список или иерархия 3D объектов
• материал - описывает, как рендерить 3D объект, хранит список текстур, рендер стейтов и D3DXEffect либо отдельную пару шейдеров
• геометрия - описывает, что рендерить для отрисовки 3D объекта, хранит один и более вершинных буферов, один необязательный индексный буфер, необязательные смещения и размеры в них и тип примитивов

3. Игровой цикл представляет собой следующую последовательность действий. 
Для каждого 3D объекта в сцене рендерер выполняет:

• вычисляет матрицу преобразования в мировые координаты (или пропускает, если она с прошлого раза не менялась)
• вычисляет bounding box объекта по его размерам и/или крайним точкам в вершинном буфере, с учётом мировой матрицы
• проверяет, пересекается или попадает ли bounding box в поле зрения камеры (frustrum culling), если нет то пропускаем этот объект
• определяет какие источники света воздействуют на 3D объект (по расстоянию от объекта до лампочки или конусу spotlight)
• по настройкам материала выставляет рендер стейты, текстуры и шейдеры/эффект на девайс
• по состоянию объекта и параметрам материала настраивает параметры шейдеров/эффекта
• по настройкам геометрии выставляет вершинные и индексный буфер на девайс
• выполняет отрисовку (так называемый DIP - Draw Indexed Primitive или Draw User Primitive или др. вариант метода граф. девайса)

4. От общих понятий перейдём к частным, и рассмотрим самые элементарные но необходимые:

• графический девайс - экземпляр IDirect3DDevice9, это корневой объект граф. подсистемы. Девайс всегда привязан к окну винды (хотя можно рендерить в несколько окон) и предоставляет набор низкоуровневых функций для управления отрисовкой
• рендер стейт - render state, режим отрисовки, например "рисовать с наложением по alpha-каналу" или "отключить буфер глубины" или "включить аппаратный туман" и т.п. Существует около 60 различных рендер стейтов. Для управления фильтрацией и адресацией текстур существуют sampler state-ы
• вершинный буфер - хранит массив вершин в видеопамяти. Вершина состоит из одного и более элемента: позиция, нормаль, текстурные координаты, цвет и др. Вершинный буфер обычно отрисовывается как набор треугольников (полигонов), по 3 вершины на полигон, с возможностью использовать одну вершину в нескольких полигонах (для этого существует индексный буфер). Можно также рисовать линии (пара вершин=отрезок) или точки, этим управляет primitive type в DIP
• шейдер/эффект - программа выполняемая на GPU (Graphics Processing Unit) видеокарты, оформляется файлом .fx или .hlsl (или др. расширение как угодно), содержит две обязательных функции называемых "вершинный шейдер" (vertex shader) и "пиксельный шейдер" (pixel shader) соответственно. Вершинный шейдер получает поток вершин из вершинного буфера и подаёт на выход экранные координаты вершины и доп. данные для пиксельного шейдера. Пиксельный шейдер принимает эти данные (например текстурные координаты) и вычисляет цвет конкретного пиксела для отправки на выход (экран или off-screen surface). Результирующий пиксел проходит ряд тестов (тест глубины и др.) и смешивается с текущим содержимым экрана в соответствии с тек. рендер стейтами

5. Что надо для создания 3D объекта:

• загрузить текстуры и шейдеры из соотв. файлов
• загрузить вершинные и индексные данные из файлов в определённом формате (сильно зависит от движка, но можно юзать готовый ID3DXMesh и формат .x)
• задать позицию, размер и ориентацию в пространстве
• настроить доп. параметры (например настройки материала)

6. Что такое bounding box и frustrum culling: не все 3D объекты попадут в поле зрения камеры в конкретный момент времени. Для сокращения кол-ва отрисовываемых объектов (и повышения FPS), каждый объект представляется в виде охватывающей коробки - bounding box. У камеры в свою очередь есть пирамида видимости (frustrum), где нижняя и верхняя грани - это дальняя и ближняя плоскости (far/near planes) а боковые поверхности соответствуют краям экрана (в 3D они расходятся с увеличением расстояния). Если bounding box 3D объекта попадает целиком или пересекается с frustrum-ом камеры, объект считается полностью или частично видимым, значит его отрисовывать надо. Иначе пропускаем.

7. Что ещё нужно для отрисовки геометрии. Вершина состоит из произвольного (определяемого программистом) набора данных (position, normal и т.п.), можно представлять её себе как массив из разного типа элементов. Например: Vector3 (XYZ вектор из 3х float-ов), Single (один флоат), Vector4, ushort и другие. Для указания формата вершины, вводится понятие vertex declaration - массив описателей формата и семантики каждого элемента вершины. Без установки Vertex declaration на девайс отрисовать вершинный буфер нельзя

8. Как считать мировую матрицу и что это вообще такое. Для преобразования координат вершины в экранные координаты, выполняется трансформация "local->world->view->projection", где "local" - это координаты вершины взятые из вершинного буфера, "world" - координаты после мировой трансформации или мировые координаты. Мировые координаты - это позиция вершины в общем 3D пространстве сцены. Все 3D объекты содержат текущую позицию в мировом пространстве. Матрица трансформации для перевода в мировые координаты расчитывается как произведение трёх матриц: масштабирование, поворот, сдвиг. Первое действие соответствует размеру 3D объекта, второе - ориентации в пространстве, третье - позиции в мировых координатах. Оставшиеся две трансформации "view" и "projection" соответствуют камере и размерам окна на экране.

9. Что делает вершинный шейдер для вычисления экранных координат. В вершинный шейдер попадают данные одной вершины, разбитые на элементы (position, normal и т.п.), взятые из вершинного буфера в соответствии с форматом указанным в vertex declaration. Шейдер получает position (это вектор из 3 или 4 флоатов) и трансформирует с пом. матрицы "local->world->view->projection" (обычно local пропускают и называют эту матрицу worldViewProjection). Матрица worldViewProjection считается способом описанным выше и представляет собой матрицу 4x4 флоатов. Результат трансформации - вектор XYZW, где первые три координаты делённые на четвёртую дают позицию на экране и значение Z для теста глубины. Этот вектор ещё называют однородными координатами или position in clip space или position in homogenous clip space. Матрица worldViewProjection (как и другие данные, на усмотрение программиста) передаётся в шейдер через набор глобальных переменных - из называют константами шейдера.

10. Что делает пиксельный шейдер для вычисления цвета пиксела. Пиксельшейдер принимает доп. данные от вершинного шейдера и имеет в своём распоряжении доступ к текстурам а также константам пиксельшейдера. На основании этого можно к примеру взять пиксел из текстуры по текстурным координатам принятым из вертексшейдера, "осветить" умножением на интенсивность и цвет источника света и вывести в результат.

11. Ну и так далее, рандомные мысли приходящие в голову.

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

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


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


Ни в коем случае не буду мешать, на собственную статью у меня усидчивости не хватит   

P.S. если не в тему влез, могу удалить свой пост   

mr.DUDA, 

уже на это намекалось, как я понял, статья пишется для себя, а не как учебник.

Значит ты предолгаешь строить дом с крыши?  


Невнимательно читал: 1/5 кода я оставляю за читателем, и если он его не напишет сам - то не сможет ничего делать дальше. Копи/паст тут не прокатит. К тому же объяснений принципов и теории люди в яндексе и гугле найти могут. Я конечно велосипедист, но не до такой степени.

С этим согласен, к этому и идём.

В споре рождается истина, мой друг  

Rickert, 
нет, он предлагает начать с понятия "дом", "несущщие стены", "фундамент", а не с понятий "кирпич", "дверная ручка" и "решетка для вентиляции"   

не считаешь что начать с кирпича и бетона логичнее?

Нет, конечно, я считаю для начала "От и ДО" должны ввести понятия "дом", "фундамент". А потом уже переходить к кирпичам и дверным ручкам.

PS Конечно это только мое имхо.

Это сообщение отредактировал(а) AntonN - 6.11.2008, 13:00

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

дом стоят по плану.
не нужно так однобоко смотреть.

ADD В общем, если нет желания понять и пересмотреть свою точку зрения, предлагаю оффтоп прекратить 

Это сообщение отредактировал(а) AntonN - 6.11.2008, 20:05

Смотря для чего, опять же. И для кого объяснять..

Если для строителя-ремесленника, то можно показать что такое кирпич и из чего делается раствор, и как они совмещаются. Ну и дальше как кирпичи укладывать между собой и как стену ложить. Отсюда наверное можно объяснить, как дом строится, но на примере конкретного дома (в котором мы стенку вначале строили из кирпичей), и более-менее понять как там остальные части сделаны и склеены. Но на такой дом уйдёт много времени, т.к. строителю придётся показывать не только как кирпич кладут, а ещё и как провода устроены (электричество провести, розетки поставить), из чего трубы делают (канализацию и водопровод провести), как обои клеить наиболее оптимальным способом, где какую краску и шпаклёвку использовать, какие уголки для плинтусов юзать, как правильно двери навешивать... ну и так далее, улавливаешь идею? Это на годы растянется, и толку - чуть!

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

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

Вообще пусть каждый пишет так, как считает нужным  
Я выбрал такой путь - как мне кажется так дома не строили ещё. А что получится на выходе - увидим.

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