Сергей Ваткин - DirectX 8. Начинаем работу с DirectX Graphics Страница 4

#define D3DFVF_MYVERTEX (D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1)

D3DFVF_XYZ — вершина задается тремя координатами в пространстве (а может задаваться и четырьмя — при D3DFVF_XYZRHW)

D3DFVF_DIFFUSE — вершина содержит цвет, который влияет на рассеяние света

D3DFVF_TEX1 -—вершина содержит две текстурные координаты

Т.к. запись

D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1

интерпретируется компилятором в точности, как и

D3DFVF_XYZ | D3DFVF_TEX1 | D3DFVF_DIFFUSE

значит порядок расположения данных в памяти в этом месте программы не задается. На программиста накладываются обязательства следовать схеме расположения данных, приведенной в руководстве D3D8 (раздел "About Vertex Formats").

Ну, надеюсь с этим все ясно. Теперь нужно занести вершины всех полигонов пирамиды в память. Для этого создаем массив из вершин и заполняем его данными:

MYVERTEX Vertices[] = {

 vertS, vertA, vertD,

 vertS, vertB, vertA,

 vertS, vertC, vertB,

 vertS, vertD, vertC,

};

Следующий шаг — нужно создать буфер вершин (VB) требуемого размера и формата. Пирамида будет отображена на экране так, что ее нижнего основания не будет видно, значит можно обойтись лишь 4-мя полигонами вместо 6-ти. Здесь я следовал правилу, которое прочитал в руководстве DX: "Remember, the fastest polygons are the ones you don't draw" (что в переводе означает: "Помни, наиболее быстрые полигоны — это те, которые ты не рисуешь"). Создание VB производится функцией CreateVertexBuffer:

HRESULT CreateVertexBuffer(UINT Length, DWORD Usage, DWORD FVF, D3DPOOL Pool, IDirect3DVertexBuffer8** ppVertexBuffer);

Length — длина VB в байтах

Usage — дополнительная информация о VB, которую D3D использует для создания оптимального VB

FVF — формат вершин, которые будут храниться в VB

Pool — в какой памяти создавать VB (можно создать его как в видеопамяти, так и в RAM)

ppVertexBuffer — адрес переменной, которая будет содержать указатель на созданный VB

Всего для хранения полигонов пирамиды используется 4*3*sizeof(MYVERTEX) байт (4 полигона, по 3 вершины в каждом).

if (FAILED(g_pD3DDevice->CreateVertexBuffer(4*3*sizeof(MYVERTEX), 0, D3DFVF_MYVERTEX, D3DPOOL_DEFAULT, &g_pVB))) {

 return FALSE;

}

Остается заполнить буфер вершинами. Для операций заполнения в DX (не только в D3D) используется пара команд Lock() и Unlock(). Команда Lock() возвращает адрес памяти, по которому расположен первый байт буфера. При этом вся память, отведенная под буфер как бы "запирается", и становится недоступной для других приложений. Операция "отпирания" памяти производится командой Unlock(). После запирания памяти, скопируем данные с помощью Си'шной функции memcpy().

VOID* pVertices;

if (FAILED(g_pVB->Lock(0, sizeof(Vertices), (BYTE**)&pVertices, 0))) return FALSE;

memcpy(pVertices, Vertices, sizeof(Vertices));

g_pVB->Unlock();

Я считаю, что это — самая сложная для понимания функция. Разговор о матрицах выходит за формат данной статьи, т.к. это очень обширная тема. Советую почитать статьи JM'а по этому поводу (скажу по секрету — он фанат матриц ;o)). Но вкратце, я все равно расскажу о матрицах :-)

У нас есть трехмерное пространство сцены, которое содержит вершины всех объектов, есть камера - глаз, с помощью которого мы видим это пространство, а также плоскость экрана монитора, на которую осуществляется проектирование. Все это ("мир", камера, операция проектирования) может быть выражено тремя матрицами: World Matrix (мировая матрица), View Matrix (видовая матрица) и Projection Matrix (проекционная матрица).

Вычислять эти матрицы "вручную" довольно сложно, поэтому воспользуемся функциями D3DX. Для матриц создан специальный тип данных D3DMATRIX. В библиотеке D3DX он расширен до типа данных D3DXMATRIX, в который добавлены арифметические операции с матрицами, и некоторые другие удобные свойства.

• Функция D3DXMatrixIdentity() строит единичную матрицу.

• Функция D3DXMatrixRotationZ() строит матрицу вращения относительно оси Z на заданный угол.

• Функция D3DXMatrixLookAtLH() строит видовую матрицу. Параметры этой функции задают точку, в которую будет смотреть камера. Постфикс -(LH) говорит о том, что матрица будет действительна для левосторонней системы координат (аналогично -(RH) для правосторонней)

• Функция D3DXMatrixPerspectiveFovLH() строит проекционную матрицу.

Для того, чтобы "заставить" устройство рендеринга использовать только что созданные нами матрицы, существует функция SetTransform():

HRESULT SetTransform(D3DTRANSFORMSTATETYPE State, CONST D3DMATRIX* pMatrix);

State — тип матрицы, которую нужно изменить (мировая, видовая, проекционная и т.д.)

pMatrix — указатель на "матрицу-заменитель" :)

Вот что нам требуется от каждой из матриц:

a. Мировая

Сделаем так, чтобы пирамида с течением времени равномерно вращалась вокруг оси Z:

D3DXMATRIX matWorld;

D3DXMatrixIdentity(&matWorld);

D3DXMatrixRotationZ(&matWorld, GetTickCount()/1024.0f);

g_pD3DDevice->SetTransform(D3DTS_WORLD, &matWorld);

b. Видовая

Камера должна смотреть на пирамиду сбоку, причем не должно быть видно нижнего основания пирамиды (помнишь, мы выбросили два полигона основания?):

D3DXMATRIX matView;

D3DXMatrixLookAtLH(&matView, &D3DXVECTOR3(5.0f, 5.0f, 6.5f), &D3DXVECTOR3(0.0f, 0.0f, 1.0f), &D3DXVECTOR3(0.0f, 0.0f, 1.0f));

g_pD3DDevice->SetTransform(D3DTS_VIEW, &matView);

c. Проекционная

D3DXMATRIX matProj;

D3DXMatrixPerspectiveFovLH(&matProj, D3DX_PI/3, 1.0f, 1.0f, 100.0f);

g_pD3DDevice->SetTransform(D3DTS_PROJECTION, &matProj);

Здесь D3DX_PI/3 - это поле зрения (field of view) камеры. Попробуй поэкспериментировать с этим параметром.

Собственно, здесь и происходит рендеринг сцены. Как всегда, он начинается с очистки окна и Z-Buffer'а:

g_pD3DDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(100, 100, 100), 1.0f, 0);

Затем, подготавливаем D3D к началу сцены.

g_pD3DDevice->BeginScene();

Пересчитываем матрицы:

DoMatrices();

Теперь настроим текстуру. И вообще, здесь подходящее место для того, чтобы вкратце рассказать о том, что такое текстура и текстурные координаты! Итак… Текстура — это графическая картинка, которая используется для натягивания на трехмерный (и не только) объект, что придает ему реалистичный вид (правда, это зависит от текстуры и от того, кто и на что ее натягивает :)) ). При текстурировании объекта, каждая его вершина должна иметь текстурные координаты, т.е. числа от 0 до 1, задающие привязку к конкретному месту текстуры. Рассмотрим пример, т.е. нашу четырехугольную пирамиду. Она была выбрана не случайно именно четырехугольной! Представь себе квадратный (для простоты), очень эластичный лист резины, на котором изображена каменная стена (текстура). Теперь "схвати" его за центр и тяни вверх (при этом края квадрата должны оставаться на месте). Т.к. лист эластичный, он легко поддастся и начнет растягиваться. Вместе с ним будет растягиваться и изображение стены. Тяни до тех пор, пока лист не превратится в правильную четырехугольную пирамиду без нижнего основания. Заморозь полученный объект, чтобы он не вернулся в первоначальное положение. Все! Еще раз вернемся к месту, где задаются вершины пирамиды:

float a=6.0;

#define vertA {-a/2,  a/2, 0.0f, 0xffffffff,  0.0f, 1.0f,}

#define vertB {-a/2, -a/2, 0.0f, 0xffffffff, 0.0f, 0.0f,}

#define vertC {a/2, -a/2, 0.0f, 0xffffffff,  1.0f, 0.0f,}

#define vertD {a/2, a/2, 0.0f, 0xffffffff,  1.0f, 1.0f,}

#define vertS {0.0f, 0.0f, (float)(a/sqrt(2)), 0xffffffff, 0.5f, 0.5f,}

0xffffffff (белый цвет) — цветовой "вес" вершины. Белый цвет означает, что текстура в данной вершине будет того же цвета и яркости, что и в оригинале. Если заменить цвет на 0x00000000, то вершина будет черной и при рендеринге вокруг нее образуется черное пятно. Попробуй! =)

Последние два числа являются текстурными координатами. Вернемся к мысленному эксперименту с квадратным листом… (до того, как мы его деформировали) Возьмем его левый верхний угол за начало координат. Ось X направим вправо, ось Y — вниз. Тогда правый нижний угол будет иметь координаты (1, 1). Как ты уже догадался, центр квадрата (проекция вершины S пирамиды на плоскость основания) имеет координаты (0.5, 0.5). Вот так задаются текстурные координаты.

Вернемся к программе. У нас будет одноуровневая текстура, первым и единственным уровнем которой будет загруженная ранее g_pTexture:

g_pD3DDevice->SetTexture(0, g_pTexture);

При рендеринге на текстуры могут накладываться фильтры, что сглаживает многие недостатки. Изюминкой программы является то, что тип фильтра можно менять прямо во время исполнения (клавишами F1, F2, F3, F4). Кроме того, как я обещал в начале статьи, используем MipMapping! Но для начала расскажу, что он собой представляет…

MipMap - это цепочка текстур, каждая последующая из которых является менее детализированным вариантом предыдущей. Уменьшение детализации на один уровень достигается путем сокращения длины и ширины текстуры в два раза. Цепочка генерируется до тех пор, пока размер одной из сторон текстуры не становится равным 1. Допустим, что текстурированный объект удаляется от наблюдателя. Сначала на него накладывается текстура с максимальным разрешением, затем, по мере удаления, текстура переключается на свой менее детализированный вариант. Согласись, на далекий объект, который занимает на экране всего один пиксель, глупо натягивать текстуру размером 100 Kb. Таким образом, благодаря некоторым дополнительным затратам памяти на MipMap-текстуры, заметно увеличивается быстродействие рендеринга и, вообще говоря, его качество. Во время переключения между детализациями, визуально может быть заметен скачок. Его можно сгладить, используя фильтрацию, что мы и сделаем (напомню, что текущий тип фильтра хранится в переменной CurrentFilter):