Вопрос про освещение и материал в DirectX 9

[zuze]

Я к коду с двумя вращающимися кубами добавил материал и освещение и z-буфер.

Только что-то странно, у меня тип света "Параллельный или направленный - он не имеет источника, но светит в заданном направлении", но почему-то, то свет попадает на кубы, то нет. Ведь вроде должны кубы всегда освещаться. А получаеться так как будто фанарь направили на кубы и включают и выключают фанарь через определённый проиежуток времени.

А как сделать чтобы кубы всегда освещались?
И ещё как сделать чтобы они тень оставляли?

Код:

// Функция установки освещения и материалов
void LightMaterial(void)
{
	// Создаём материал
	D3DMATERIAL9 Material;
	// Создаём освещение
	D3DLIGHT9 Light;
	D3DXVECTOR3 VectorDir;

	// Обнуляем память под материал
	ZeroMemory(&Material, sizeof(D3DMATERIAL9));
            // Задаём цвета для диффузного и цвета подсветки
	Material.Diffuse.r = Material.Ambient.r = 0.5f;
	Material.Diffuse.g = Material.Ambient.g = 1.0f;
	Material.Diffuse.b = Material.Ambient.b = 0.0f;
	Material.Diffuse.a = Material.Ambient.a = 1.0f;
	// Устанавливаем материал
	pDirect3DDevice->SetMaterial(&Material);
	// Обнуляем память под освещение
	ZeroMemory(&Light, sizeof(D3DLIGHT9));
            // Тип света
	Light.Type = D3DLIGHT_DIRECTIONAL;
	// Количество красного в свете
	Light.Diffuse.r = 1.0f;
	Light.Diffuse.g = 1.0f;
	Light.Diffuse.b = 1.0f;
	// Максимальное расстояние действия источника света
	Light.Range = 1000.0f;
	// Вектор, задающий направление света
	VectorDir = D3DXVECTOR3(0.0f, 0.0f, 1.0f);
	// Нормализуем вектор VectorDir и записываем в свойства направления Light
	D3DXVec3Normalize((D3DXVECTOR3*)&Light.Direction, &VectorDir);
	// Устанавливаем свет
	pDirect3DDevice->SetLight(0, &Light);
	// Включаем свет с соответсвующим индексом
	pDirect3DDevice->LightEnable(0, TRUE);
	// Устанавливаем параметры рендеринга, включая освещение
	pDirect3DDevice->SetRenderState(D3DRS_LIGHTING, TRUE);
	// Устанавливаем параметры рендеринга, включая окружающее освещение
	pDirect3DDevice->SetRenderState(D3DRS_AMBIENT, 0);
}

Полный код в прикреплённом файле и исполняемый файл в архиве.

[Алексей++]

а зачем ты в каждом рендере вызываешь     LightMaterial(); , достаточно в конце инита один раз сейчас вызвать

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

-----------
хотя нет, не в этом кажись дело, а в том, что источник света тоже почему то вращается

Это хорошо заметно при типе D3DLIGHT_POINT источника

[zuze]

Я ступил я оставил цвет при инициализации вершин, а надо координаты нормали по X, Y, Z для каждой вершины написать было.

[zuze]

1. Изменил вершины кубов доба
2. Добавил координаты нормалей к каждой вершине
3. Изменил точку от куда смотрим
4.  LightMaterial(); перенёс в конец функции инициализации объекта

Всё темно вообще не светит теперь, что же не так?

[zuze]

У меня вот так было, я так понял освещаеться только задние стороны кубов, по этому и кубы тёмные.

Код:

// Вектор, задающий направление света
VectorDir = D3DXVECTOR3(0.0f, 0.0f, 1.0f);

Если сделать так, то нормально освещаються кубы.

Код:

VectorDir = D3DXVECTOR3(1.0f, 0.0f, 0.0f);

Если так сделать, то освещаеться только нижние стороны кубов.

Код:

VectorDir = D3DXVECTOR3(0.0f, 1.0f, 0.0f);

Теперь буду разбираться с тем чтобы кубы оставляли тень.

[zuze]

Хотел спросить:
1. Тени делаються с помощью поверхностей (спрайтов)?
2. Если тени можно сделать иначе раскажите пожалуйста?
3. Если тени можно сделать только с помощью поверхностей (спрайтов) я что должен в уме представлять как тень отбрасываеться, ну с кубами это ещё не так сложно, а если будут сложные объекты, может есть проще способ?

[Алексей++]

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

[zuze]

А где об этом можно почитать?

[Алексей++]

не знаю. Напиши Антону ЛС, пусть расскажет

[zuze]

Я нашёл такое

1. Фейковые тени
   
Фейковая тень - это всего лишь полигон с изображением полупрозрачного кружочка или еще какой глупости, который "кладется" на землю прямо под моделью.

2. Метод проекции вершин
   
Суть метода состоит в том в том, что мы проецируем каждый полигон модели на плоскую землю, а точнее горизонтальную плоскость. Вполне очевидно, что такая тень не будет падать на посторонние объекты сцены и будет верна только для абсолютно ровного пола, типа того, что мы можем наблюдать в спортивных игрушках от EA Sports.

3. stencil-теней
   
1. Рисуем всю сцену без теней.   
2. Запрещаем запись в z-буфер и в буфер кадра.   
3. Рисуем обратные, т.е. невидимые грани конуса тени, при этом увеличивая на единицу значения в stencil-буфере для тех точек, которые лежат ближе выводимых граней.   
4. Рисуем передние, т.е. видимые грани конуса тени и уменьшаем на единицу значения stencil-буфера для точек, которые лежат ближе выводимых граней. Теперь в stencil-буфере мы имеем маску для тех точек, которые попали в область конуса тени.   
5. Рисуем серый полупрозрачный прямоугольник на весь экран, разрешая закраску только тех пикселей, для которых значения stencil-буфера остались увеличенными на единицу.

4. Карты затенения
   
1. Переместить камеру в точку, в которой расположен источник света, и ориентировать ее так, чтобы был виден объект, тень которого мы хотим построить. Очевидно, что из такого положения тень отбрасываемая объектом не будет видна вообще, т.к. она загорожена самим объектом.
2. Затем мы рисуем наш объект, так как он виден из установленной камеры, но только черным цветом на белом фоне, получив, таким образом, картинку - карты затенения, которая является как бы поперечным срезом конуса тени всего объекта.
3. Последнее, что остается сделать, так это наложить полученную карту затенения на другие объекты 3D-сцены. Делается это обычным проецированием полигонов.

5. Метод теневых z-буферов

1. построить два z-буфера: один при рендеринге сцены из обычной камеры (z-буфер камеры), а другой при рендеринге из точки, в которой установлен направленный источник света (z-буфер источника).
2. Потом нужно каждую видимую точку преобразовать из пространства камеры в пространство источника света, чтобы определить x, y координаты точки на картинке, получаемой при рендеринге сцены из положения источника света.
3. И затем мы сравниваем значения z-буфера камеры и z-буфера источника для данной точки, и если значение z-буфера источника оказалось меньше, чем значение z-буфера камеры, то точка лежит в тени.

Чрезвычайно ресурсоёмкий метод.

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

[Алексей++]

хм, если честно, думал, что карты сейчас сами умеют тени рисовать Но, раз такая пьянка, то

3 - получатся однотонные тени, если этого достаточно, то, наверное, это самый лучший метод.

5 - это для быстрого железа и позволяет делать эффекты размытия и наложения теней (теоретически - по расстоянию между z, хотя хз )

4 - наверное, будет работать быстрее, чем 3 , но тоже однотонные тени

[zuze]

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

Маленький вопросик в тему
Я так понял пятый метод используеться в серьёзных играх, а как интересно подобрать правельно железо чтобы использовать этот метод?

[Алексей++]

Я так понял пятый метод используеться в серьёзных играх, а как интересно подобрать правельно железо чтобы использовать этот метод?

А вот не стОит путать понятие "серьёзная игра" и "реалистичная тень" , понятия мало пересекаются (разве что влияние на геймплей, как в The Gift или Splinter Cell) и могут быть в различных сочетаниях

Железо подбирает не разработчик, а конечный пользователь, а разработчик опртимизирует и пишет системные требования

[zuze]

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

Откуда он берёт эти требования к железу?

[Алексей++]

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

Частенько в последнее время давят на графику, а игры скучные при этом. Красивая графика и интересность также редко зависят друг от друга (хотя, бывает) , слишком реалистичная графика даже может помешать интересности (хотя бы за счёт тормозов).

[zuze]

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

Я согласен дело не только в графике, большую роль в игре игает сюжет игры.
Вот напимер игра "Metal Gear solid" сюжет отличные, графика на сегодняшний день не очень, но в эту игру всё равно хочеться играть.

[Алексей++]

MGS мне тоже очень понравилась, графика там (и управление) - приставочные, то есть так себе. Но это, как ты сам заметил, неважно, когда интересно играть. У меня тогда была GeForce2 , на которой Q3 без проблем бегает, а MGS, тем не менее, слегка притормаживал в некоторых местах, особенно был момент такой, когда в лифте напали куча невидимок - вот это был ступор   Но вот тут не обидно было ни капли, потому что - это было не излишество, а элемент игры