О кроликах вроде все. Давайте слегка углубимся в историю. Были далёкие 70е. Все дрыгались под ритмы диско и живали джусифрут. Можно считать, что эти годы явились родоначальниками компьютерной графики. Большинство алгоритмов современной нынешней графики были придуманы именно в конце 70х √ 80х годах. Это BumpMapping, свет, закраска по Фонгу/Гуро, Z-буффер, разные там сглаживания и даже никому не известные (по названию) алгоритмы Брезенхейма (рисования линий, кругов и т.д.), но которыми все пользуются, были придуманы до любимого паскаля. Кому интересно есть книга Роджерса ⌠Алгоритмические основы компьютерной графики■ 1989г.

Наступили менее далёкие 90е. 3Д графика начала переходить из разряда на-супер-калькуляторе-у-неизвестного-матиматика в категорию а-у-меня-это-есть-на-компе. С трудом перевалив через середину, 90е породили на свет общедоступные так называемые ⌠3Д акселераторы■, и про то, что раньше всё рисовали исключительно ЦПУ, все забыли - теперь треугольнички рисовали ГПУ типа Voodoo (Glide-рулёз), а после в игру вступила nVidia и ATi. Когда же 90е вышли на финальную прямую, народ сообразил, что считать матрицы ЦПУ не должен. Даже знаменитый ММХ не стоит грузить на столько грязной работой, и тут же родилась фигня, которую назвали ⌠Блок T&L■ (кто не знает √ это transforming & lighting). И на пару лет все успокоились.

И всё было бы хорошо, если бы не один грешок этого самого T&L √ он выполнял последовательно один и тот же набор операций, как нужных, так и не нужных (это умножение на 3 матрицы трансформации, расчёт света и всё в таком вот духе). А если мне надо сначала расчитать свет ╧1, затем помножить на матрицу ╧1, потом рассчитать свет ╧2 и помножить на матрицы ╧3 и ╧2? ⌠Делать нечего, бояре┘■, придётся подключать в работу ЦПУ. Плохо. Осознав это, собрался народ со всех уголков трёхмерного мира, nVidia сказала всё, что думает об ATi, ATi тоже в накладе не осталась, а там и вся остальная Силиконавая долина поделилась своим мнением. Чуть успокоившись, они подумали и додумались до не безызвестных шейдеров. Были придуманы и вертексные и пиксельные шейдеры.

На рисунке чётко видно, на какой стадии используется vertex shader, а где pixel shader:

Схема Pipeline (взято с www.gamedev.net)

op dest, src0,src1,src2 где

Картинка (для наших маленьких читателей J ):

Допустим вы рендируете модель с помощью DrawIndexPrimitive. Модель состоит из n-ого числа вертексов. Если вы рендируете с помощью обычных средств, то сначала надо задать по отдельности матрицу вида, проекции и мировую, затем задать свет и теперь рендировать. Обработка каждой вершины пойдёт по заранее запланированной программе. Теперь давайте посмотрим, как пойдёт дело при использовании ВШ.

Теперь что где что значит:

v0 √ первоначальный вертекс (вектор {x,y,z,w}). Входной регистр.

c4 - константный регистр. Цвет.

Давайте, штоль, попробуем что-то сделать? Я, пожалую, не буду изощряться, и придумывать что-то новое, а возьму пример из www.Gamedev.net . В этом примере будем крутить выпуклый квадрат, и там ещё будет анизотропное освещение.

Чтоб упростить задачу предлагаю использовать Микрософтный прибамбас для таких вещей, именуемый как класс CD3Dapplication. Для тех, кто не знаком с этим достижением мысли инженеров известной конторы, поясню. Это, так сказать, базовый набор функций для любого приложения (нечто типа MFC для создания приложений типа компьютерных игр). Этот класс создаёт главное окно, реализует обработку виндоусовских мессаг, и вызывает необходимый набор функций, в которые входят:

• OneTimeSceneInit() √ инициализация приложения(вызывается единожды в самом начале).
• InitDeviceObjects() √ инициализация 3Д объектов(загрузка текстур и т.д.).
• FrameMove() √ анимация, вызывается перед рендерингом, в качестве 2х входных параметров используется время, прошедшее с начала запуска программы и время, прошедшее с последнего запуска этой процедуры(всё в сек., тип √ float).
• Render() √ без комментариев.
• DeleteDeviceObjects() - To cleanup the 3D scene objects.
• FinalCleanup() √ финальный cleanup, вызывается при выходе из программы.
• MsgProc() √ виндоусные мессаги, думаю объяснять не надо.

Чтоб включить эту машину смерти, достаточно в main создать наш класс и вызвать функцию Run этого класса:

Теперь всю грязную работу выполнит CD3Dapplication, ну а нам остаётся только реализовать пару функций.

Для начала создадим Win32 проект. Опишем класс CMyD3DApplication:

class CMyD3DApplication : public CD3DApplication

protected:

public:

Здесь надо сразу оговорится про одну интересную фичу из набора DX SDK √ класс CD3DArcBall. Он делает работу по расчету матрицы поворота и перемещения, которые осуществляются с помощью мыши (в симплах от SDK, где что-то можно вращать мышью, используется именно этот класс). Вращение выглядит как перемещение ⌠точки глаза■ по шару, описанному вокруг определённой точки. Чтоб его использовать, достаточно задать параметр √ радиус, и передавать классу мессаги, относительно мыши.

struct VERTEX

FLOAT x, y, z; // The untransformed position for the vertex

FLOAT nx, ny, nz; // the normal

#define D3DFVF_VERTEX (D3DFVF_XYZ|D3DFVF_NORMAL|D3DFVF_TEX1)

Поехали описывать функции:

Вроде всё интуитивно понятно. OneTimeSceneInit нам не понадобится пока, как, впрочем и InvalidateDeviceObjects:

return S_OK;

return S_OK;

Где BasicVertexShader √ массив, в котором храниться шейдерная программа, про dwDec1 чуть дальше.

Путь номер два. Во-первых надо откомпилить шейдерную программу (ШП). Я использовал для этого nvasm.exe. Чем хорош VisualC++ это тем, что избавляет программиста от многих лишних нажатий на кнопки. Так что если вы используете именно его, то достаточно включить файл с ШП в ваш проект, зайти в его (файла) свойства, найти поле ⌠Command line■ и в нём написать ⌠nvasm myfile.vsh■, где myfile.vsh √ ваш файл с ШП. А поле ⌠Outputs■ заполнить страшной строкой ⌠$(InputName).pso■. Думаю если кто об этом не знал, всё понял.

HRESULT CMyD3DApplication::InitDeviceObjects()

// loads a *.vso binary file, already compiled with NVASM and

// creates a vertex shader

if (FAILED(CreateVSFromCompiledFile (m_pd3dDevice, dwDecl, "test1.vso", &m_dwVertexShader)))

return E_FAIL;

return S_OK;

char szBuffer[128]; // debug output

DWORD* dwpVS; // pointer to address space of the calling process

HANDLE hFile, hMap; // handle file and handle mapped file

TCHAR tempVSPath[512]; // temporary file path

HRESULT hr; // error

if( FAILED( hr = DXUtil_FindMediaFile( tempVSPath, strVSPath ) ) )

return D3DAPPERR_MEDIANOTFOUND;

if(hFile != INVALID_HANDLE_VALUE)

if(GetFileSize(hFile,0) > 0)

else

return E_FAIL;

else

return E_FAIL;

// maps a view of a file into the address space of the calling process

// Create the vertex shader

if ( FAILED(hr) )

D3DXGetErrorStringA(hr,szBuffer,sizeof(szBuffer));

return hr;

return S_OK;

Теперь скажу про dwDec1. Как известно, в ШП есть входные регистры, и именно какой регистр что описывает и показывает dwDec1:

D3DVSD_REG(0, D3DVSDT_FLOAT3 ), // position in space

D3DVSD_REG(3, D3DVSDT_FLOAT3 ), // normals

D3DVSD_REG(7, D3DVSDT_FLOAT2), // tex coord

Т.о. во входном регистре v0 будут координаты точки, в регистре v3 √ нормали, а в v7 просто координаты текстуры (в соответствии со структурой VERTEX). Функцию CreateVSFromCompiledFile описывать не буду √ кто захочет, разберётся.

Всё остальное по загрузке я сунул в RestoreDeviceObjects. Предлагаю разобраться, что там к чему.

Во-первых, создаём фигуру (что будем рисовать). Это будет сетка размерности NxM секторов на куске плоскости XY (-1, -1; 1, 1) (т.е. квадрат). В качестве высоты каждого узла сетки будем использовать функцию:

F(x,y) = sin(x)* sin (y), где x,yО[0;p ]

#define WIDTH 30

#define HEIGHT 30

#define TO_RAD(x) (x*3.14/180)

float GetHeight(float x, float y)

return sin(TO_RAD(x*180./WIDTH))*sin(TO_RAD(y*180./HEIGHT));

float kx = 2./WIDTH;

float ky = 2./HEIGHT;

float ktx = 1./WIDTH;

float kty = 1./HEIGHT;

for(int x=0;x<WIDTH+1;x++)

for(int y=0;y<HEIGHT+1;y++)

// position in space

// normal

// tex coord

m_dwSizeofVertices = sizeof (Vertices);

WORD wIndices[WIDTH*HEIGHT*6], *ind;//={0, 1, 2, 0, 2, 3};

for(x=0;x<WIDTH;x++)

for(int y=0;y<HEIGHT;y++)

m_dwSizeofIndices = sizeof (wIndices);

Для расчёта нормалей я использовал функцию, которую нагло взял с того же GameDev.net:

m_dwSizeofIndices/sizeof(WORD)/3,

m_dwSizeofVertices/sizeof(VERTEX));

// compute face normals

// for every triangle, take three vertices and cross the edges

pvFaceNormals = new D3DXVECTOR3[dwNumOfTriangles];

for(DWORD i = 0; i < dwNumOfTriangles; ++i)

int e0=pdwIndices[i*3+0];

int e1=pdwIndices[i*3+1];

int e2=pdwIndices[i*3+2];

for(DWORD c = 0; c < dwNumOfVertices; ++c)

int shared=0;

for(DWORD i = 0; i < dwNumOfTriangles; ++i)

int e0=pdwIndices[i*3+0];

int e1=pdwIndices[i*3+1];

int e2=pdwIndices[i*3+2];

/*D3DXVECTOR3 v0 = pvVertices[e0].vPosition;

if(v0==v||v1==v||v2==v)

D3DXVECTOR3 nrml = sum/(float)shared;

Дальше всю эту фигню копируем в буфера (сексуально озабоченных прошу не смеяться сильно с резким выделением слюни на монитор) DX:

if( FAILED( m_pd3dDevice->CreateVertexBuffer( m_dwSizeofVertices,

D3DUSAGE_WRITEONLY , sizeof(VERTEX), D3DPOOL_MANAGED, &m_pVB ) ) )

return E_FAIL;

if( FAILED( m_pVB->Lock( 0, m_dwSizeofVertices, (BYTE**)&pVertices, 0 ) ) )

return E_FAIL;

if(FAILED (m_pd3dDevice->CreateIndexBuffer(m_dwSizeofIndices, 0,

return E_FAIL;

// fill index buffer

if (FAILED(m_pIB->Lock(0, m_dwSizeofIndices, (BYTE **)&pIndices, 0)))

return E_FAIL;

&D3DXVECTOR3( 0.0f, 1.0f,-4.0f ), //from

&D3DXVECTOR3( 0.0f, 0.0f, 0.0f ), //at

&D3DXVECTOR3( 0.0f, 1.0f, 0.0f ));//up

Некоторые другие установки:

Текстура:

Функция SetVertexShaderConstant и служит как раз для задания константных регистров. Первый её параметр √ номер константного регистра (в данном случае задаётся макросом), второй параметр √ указатель, где хранятся значения, которые надо записать в регистры, а последний параметр √ сколько вешать (говорите только точно). Т.о. если нам надо записать вектор (1,2,3,1) в константный регистр ╧4 (zero-base) надо писать:

А если надо занести матрицу mat1 в константные регистры 2, 3, 4 и 5 надо сделать так:

Вообще входные и константные регистры состоят из 4х значений типа FLOAT.

Обычно перед рендерингом обычно осуществляется смена положения объектов в пространстве. Не будем выпендриваться:

static i=0;

// set the clip matrix

return S_OK;

Опять-таки ничего сверхъестественного. Считаем с помощью CD3DXArcBall нужную нам матрицу поворотов и перемещения нашего объекта, задаём инверсированную матрицу вида, а затем делаем вид, что смотрим из точки (0, 0, Z) в точку (0, 0, 0), и, что характерно, центруем ноги перпендикулярно плоскости OXZ (не забыв, что вектор направления нашей головы должен быть (0, 1, 0)).

Тот кто думает, что функция рисования будет огромной будут расстроены / обрадованы (нужное подчеркнуть):

// Clear the viewport

// Begin the scene

if( SUCCEEDED( m_pd3dDevice->BeginScene() ) )

m_pd3dDevice->SetStreamSource(0, m_pVB, sizeof(VERTEX));

// End the scene.

return S_OK;

Чтоб это понять, достаточно только знать, как правильно пишется Direkt3D.

// Pass mouse messages to the ArcBall so it can build internal matrices

switch (msg)

case WM_MOUSEWHEEL:

short sr = HIWORD(wParam);

break;

return CD3DApplication::MsgProc(hWnd, msg, wParam, lParam);

Финальная чистка:

if ( m_dwVertexShader != 0xffffffff )

return S_OK;

return S_OK;

if( (dwBehavior & D3DCREATE_HARDWARE_VERTEXPROCESSING ) ||

if( pCaps->VertexShaderVersion < D3DVS_VERSION(1,1) )

return E_FAIL;

return S_OK;

Подключаемые файлы:

#include <math.h>

#include <D3DX8.h>

#include "D3DApp.h"

#include "D3DFile.h"

#include "D3DFont.h"

#include "D3DUtil.h"

#include "DXUtil.h"

#include "shconst.h"

Макрос для мышиного колеса:

#define WM_MOUSEWHEEL 0x020A

Подключаемые библиотеки:

Файл shconst.h (какие регистры для чего используются):

#define CLIP_MATRIX 0

#define CLIP_MATRIX_1 1

#define CLIP_MATRIX_2 2

#define CLIP_MATRIX_3 3

#define INVERSE_WORLD_MATRIX 4

#define INVERSE_WORLD_MATRIX_1 5

#define INVERSE_WORLD_MATRIX_2 6

#define EYE_VECTOR 10

#define LIGHT_POSITION 11

#define SPEC_POWER 12

#define DIFFUSE_COLOR 14

#define LIGHT_COLOR 15

Строка ⌠vs 1.1■ обозначает то, что программа написана для vertex shader версии 1.1 . Дальше идёт стандартное преобразование точки, т.е. умножение её на мировую, видовую и перспективную матрицу, но по причине того, что эти три матрицы мы помножили заранее (FrameMove), то нам остаётся только помножить нашу точку на полученную ранее матрицу:

mul r0, v0.x, c[CLIP_MATRIX] ; умножение первой строки матрицы на x-компоненту нашей точки, результат записывается во регистр r0

mad r0, v0.y, c[CLIP_MATRIX_1], r0 ; умножение второй строки матрицы на y-компоненту нашей точки, при чём результат прибавляется в уже записанному в r0

mad r0, v0.z, c[CLIP_MATRIX_2], r0 ; тоже самое с третьей строкой матрицы

add oPos, c[CLIP_MATRIX_3], r0 : oPos √ выходной регистр, в который записывается новое положение точки

mul r0, v0.x, c[CLIP_MATRIX] - делает:

mad r0, v0.y, c[CLIP_MATRIX_1], r0 - делает:

mad r0, v0.y, c[CLIP_MATRIX_1], r0 - делает:

c[x][y] √ матрица 4х4. Если кто решит, что я перепутал строки и столбцы, то тот будет почти прав. Дело в том, что в ДХ хранятся матрицы транспонированном виде, вероятно для удобства, т.к. в этом случае проще реализовать умножение. Сами посудите, лучше так (если m √ массив из 4*4 подряд идущих элементов):

чем:

Координаты текстуры заносятся в выходной регистр oT0 (oT1, oT2, ...):

dp3 r1.w, r1, r1 ; в r1.w заносится скалярное произведение вектора r1 на его же самого по трём составляющим, и т.о. получаем квадрат длины вектора (r1.w = L^2 = r1.x*r1.x + r1.y*r1.y + r1.z*r1.z)

rsq r1.w, r1.w ; r1.w = 1/sqrt(r1.w) √ обратный квадратный корень

mul r1, r1, r1.w : умножение составляющих вектора r1 на r1.w

где K √ коэффициент отражения, alpha √ угол между векторами нормали и света, а n √ specular power (величина блика). В нашем случае будем использовать формулу:

где I_r √ интенсивность отражения,

I_d√ интенсивность падающего света.

N √ нормаль

L √ вектор света

R √ вектор отражённого света относительно нормали n

V √ вектор направления взгляда

Как видно, выражение cosⁿ(alpha) мы заменили на эквивалентное (R dot V)ⁿ. Но получить вектор R проблематично, и по этому некий тв. James F. Blinn предложил использовать следующий метод. Берём вектор:

Реализовываем всё сказанное. В регистр r5 вносим вектор направления света (координаты источника, взятые с противоположным знаком √ как будто свет идёт из бесконечно удаленной точки, направлен в нулевую точку и имеет это самое направление)

В r2 записываем сумму векторов направления взгляда и света:

В r0.w записываем n:

Таким образом мы получаем регистр r0 у которого:

И, наконец, сам цвет вычисляется и записывается в выходной регистр цвета oD0. mul r1, c[DIFFUSE_COLOR], r4.y

Есть ещё регистры цвета (oD0, oD1 и т.д.), но почему-то у меня с ними ничего не работало. Вообще, по идеи, последние строки могут выглядеть и так:

Сразу оговорюсь, что пример взят почти полностью с www.gamedev.net, а также при составлении статьи я опирался на неё же. Некоторые выводы я делал сам, и некоторые вещи могут содержать неточности (читать √ ошибки, я всё ж тоже человек), так что если что, сразу приношу свои извинения. Если у кого будут какие комментарии, смело пишите. Похвальные письма тоже можете присылать. Чуть позже я напишу, как сделать почти тоже самое с помощью Cg. Кое-что я взял с http://directxdesign.narod.ru/papers.htm .

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

anatol@sstu.ru