Рендер тени в Vice City

[xanser]

Shaggy, опробовать освещение объектов из object.dat можно записав 0x75 в адрес 0x4C9D5A, это переключает условие на противоположное (интересно, а для каких тогда объектов оно работало до этого).
Неплохо получилось с деревьями, если сделать их динамическими.



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

[DK]

xanser, заметьте, что этого можно добиться и запеканием освещения в цвета вершин. Ну да, тут оно вроде как динамическое, но это всё равно повершинное освещение.
Поменять функции для CBuilding достаточно просто.

Код: C++

1. #include "additional\Patch.h"
2. #include "game_vc\common.lighting.h"
3.  
4. class MyViceCityPlugin {
5.     static bool __fastcall BuildingSetupLighting(class CEntity *) {
6.         ActivateDirectional();
7.         SetAmbientColoursForPedsCarsAndObjects();
8.         return true;
9.     }
10.  
11.     static void __fastcall BuildingRemoveLighting(class CEntity *, int, bool) {
12.         SetAmbientColours();
13.         DeActivateDirectional();
14.     }
15.  
16. public:
17.     MyViceCityPlugin() {
18.         // подменяем функции в виртуальной таблице методов CBuilding
19.         plugin::patch::SetPointer(0x6865C4, BuildingSetupLighting);
20.         plugin::patch::SetPointer(0x6865C8, BuildingRemoveLighting);
21.     }
22. } vcplugin;

Вот только для проверки результата нужен ещё обьект с нормалями.

Проект во вложениях.

[xanser]

Вот спасибо, действительно просто. Все отлично работает на статических и динамических объектах, можно экспортировать в игру сразу из zmodeler без прелайта и скриптов Кама. Проверял на своих моделях, на стандартной карте вроде как ничего не изменилось. Включение света у статических происходит на расстоянии 300.0, у динамических на 80.0, осталось их подравнять для красоты, лоды тоже нормально освещает, попробую переделать свою карту теперь. Еще конечно нужен будет потом спец по настройке timecyc.dat для уж совсем красивого освещения.

DK, можешь еще откомпилировать проект, чтобы остальные могли попробовать? Можно даже добавить в твой графический мод ViceMips_byDK.asi. Я у себя проверял, отдельно не вытащу.

[Shagg_E]

Это...просто...восхитительно!
Объекты освещаются практически так же, как если бы "запекались" в максе: вот статическое "запеченное" освещение, а вот - динамическое!(освещение почти такое же, из-за того, что я в своё время просчитывал положение игрового солнца, чтобы запечь освещение, и при другом времени освещение другое: раз и два)
Конечно, пока не хватает затенения объектов, так что лично мне пока больше подойдет метод xanser-а, чтобы можно было ставить динамическое освещение лишь для "избранных" объектов. Правда, я подозреваю, что там будут какие-то проблемы, раз

это переключает условие на противоположное

Т.е. что-то другое при этом должно по-идее отключаться, что не есть гуд...

Еще конечно нужен будет потом спец по настройке timecyc.dat

Такой спец есть - Lego(подробный разбор каждого параметра timecyc)! Он там не разобрал лишь параметры Amb_bl(то же, что и Amb, но во время включения Blur), Amb_Obj_bl(то же, что и Amb_Obj, но во время включения Blur) и BlurRGB(цвет Blur).

Согласен насчет компиляции отдельного проекта, ибо мне это не под силам(я смог добавить в свою asi, но у меня большие проблемы с созданием отдельных asi, ибо я криворук и MS VS у меня глючит). Единственное - в случае интеграции с тем же ViceMips - я бы очень хотел возможность отключения освещения в ini(для различных тестов), тем более, когда в ViceMips уже есть рабочий ini.

Теперь бы еще шедоу маппинг и порт нормалмап с SA, и можно было бы создавать просто божественный визуал!

P.S. xanser, научи делать гифки из 2х изображений 

UPD: Еще одна мысль. Поскольку дин. освещение работает лишь днем, а ближе к ночи плавно меняется на прелайт - можно на моделях сразу запекать ночное освещение, а днем будет работать динамическое. Шик!

[xanser]

Shaggy, попробуй asi-шку во вложении, это уже для любых объектов, причем освещение статических получилось намного стабильнее, чем динамических, те как-то моргают под некоторыми углами обзора, выключаются, надо еще смотреть почему так происходит, если убрать записи в object.dat, то начинают освещаться всегда нормально.

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

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

P.S. Gif-ки я делаю программой ImageReady, если есть Photoshop, в той же папке должна быть, там Import Folder as Frames, настраиваешь время каждого кадра-скриншота, потом Save Optimized As... только размер картинки уменьши.

[DK]

DK, можешь еще откомпилировать проект, чтобы остальные могли попробовать? Можно даже добавить в твой графический мод ViceMips_byDK.asi. Я у себя проверял, отдельно не вытащу.

Там вроде надо только поменять путь к выходной папке (у меня там относительный путь к Vice City/scripts) и запустить сборку, нет?

[DK]

Сделать хорошее динамическое ночное освещение будет трудно.
Если в дневное время можно ограничиться только одним источником света - направленным (солнце), то освещение ночью - это фонари, лампы, и другие локалные источники света ("точечные" источники света).
Точечные источники света в RenderWare выглядят очень плохо, т.к. это всё то же повершинное освещение. Ещё и модели во всех GTA на RenderWare - низкополигональные. Представьте себе дорогу, слеланную двумя треугольниками, и точечный источник где-то посередине дороги. Нужно либо усложнять сетку дороги, так , чтобы в любом месте было довольно большое кол-во вершин, либо делать попиксельное освещение (per-pixel lighting) с подключением шейдеров.
Но тут появляется ещё одна проблема - попиксельное освещение - довольно затратная технология, особенно, если в сцене много источников света.
RenderWare - уже старый движок. Всё там основано на технологии "прямого" рендеринга (forward rendering).
Почти во всех современных играх с открытым миром (где в одном кадре нужно создавать десятки-сотни источников) используется технологии отложенного рендеринга (deferred rendering) и отложенного освещения (deferred lighting).
Реализовать эту технологию в GTA - значит внести внушительные изменения в графический движок. Можно пробовать, конечно 
Да и с forward-овещением можно поиграться, думаю. Всё же его намного проще сделать.

[xanser]

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

[Shagg_E]

xanser>Это древняя проблема Вайса, помимо освещения от 2dfx, портящая также отображение партиклов типа крови на объектах: "отрисовка" этого освещения(и партиклов) идет сверху вниз, а не во все стороны. Т.е. если стену здания наклонить на полградуса - свет на нем отображаться будет(но крайне криво), а на плоскостях, перпендикулярных к горизонту - нет.
DK> Лично я больше жду теней, нежели динамическое ночное освещение, ведь
xanser> ночное освещения можно сильно ослаблить, если изначально ставить модели темный прелайт/освещение(которые днем ни капли не затемняют модель, а делают освещение более контрастным) и в ночных "часах" таймцикла приравнивать значения освещения и тени.

UPD: Короче, я склепаю небольшую демонстрацию, чтобы всё наглядно показать. Одним словом - новое освещение - это бомба! НО для того, чтобы конкурировать с "запеканием" вершин - не хватает теней. НО оно динамическое! НО не хватает теней... НО всё равно шик!

[Eden]

Т.е. прилайт теперь не нужен? Или все таки придется теперь заморачиваться и делать два дома для дня и ночи отдельно с разной освещенностью?

[Shagg_E]

Т.е. прилайт теперь не нужен? Или все таки придется теперь заморачиваться и делать два дома для дня и ночи отдельно с разной освещенностью?

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

[xanser]

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



Мы подменяли функцию CEntity::SetupLighting() в этом адресе 0x6865C4, я также подменил ее еще по 5 ссылкам 0x686614, 0x68B398, 0x68B614, 0x68F6EC, 0x691614.
Поскольку это CEntity, то освещение распространяется на любую сущность, и скорее всего динамические объекты первоначально освещаются хорошо, как и статические, но где-то происходит дополнительная обработка освещения динамических объектов, которая все портит, надо ее найти и отключить.
Я попробовал подменить ссылки на CObject::SetupLighting() в адресах 0x6917D8, 0x691A48, 0x6DBB28 на адрес 0x4C9D90, т.е. на бывший пустой CEntity::SetupLighting(), тем самым отключив стандартное освещение CObject, то же самое сделал и по ссылкам CObject::RemoveLighting() заменив на пустой CEntity::RemoveLighting(), после этого CObject вообще не должен обрабатываться отдельно.
Но где-то эта гадость еще засела, не могу найти никак. Можно конечно убрать все объекты из object.dat и решить проблему, но потеряется возможность делать падающие заборы и т.д.

[DK]

Что-то вообще не то сделал.
CEntity и CPhysical отдельно вообще не существуют, это родительские классы для других.
А обьекты вроде CDummyObject - по идее, вообще не отображаются - dummy ведь (пустышка).
Для наглядности - иерархия классов в ВС
Надо подменять функцию в вирт таблице CObject

Код: [Выделить]

.data:006917D8 20 9D 4C 00                             dd offset _ZN7CObject13SetupLightingEv ; CObject::SetupLighting(void)
.data:006917DC 00 9D 4C 00                             dd offset _ZN7CObject14RemoveLightingEb ; CObject::RemoveLighting(bool)

Код: C++

1. #include "additional\Patch.h"
2. #include "game_vc\common.lighting.h"
3.  
4. class MyViceCityPlugin {
5.     static bool __fastcall DynamicSetupLighting(class CEntity *) {
6.         ActivateDirectional();
7.         SetAmbientColoursForPedsCarsAndObjects();
8.         return true;
9.     }
10.  
11.     static void __fastcall DynamicRemoveLighting(class CEntity *, int, bool) {
12.         SetAmbientColours();
13.         DeActivateDirectional();
14.     }
15.  
16. public:
17.     MyViceCityPlugin() {
18.         // подменяем функции в виртуальной таблице методов CBuilding
19.         plugin::patch::SetPointer(0x6865C4, DynamicSetupLighting);
20.         plugin::patch::SetPointer(0x6865C8, DynamicRemoveLighting);
21.         // подменяем функции в виртуальной таблице методов CObject
22.         plugin::patch::SetPointer(0x6917D8, DynamicSetupLighting);
23.         plugin::patch::SetPointer(0x6917DC, DynamicRemoveLighting);
24.     }
25. } vcplugin;

[xanser]

Я так сделал из-за наследования классов, Entity и Object и Object->Physical.Entity указывают на одно и то же в данном случае, тем более что в функциях SetupLighting нет обращения к полям классов, поэтому, я думаю, их можно менять местами в виртуальной таблице без проблем. Это все работает, только не дает эффекта для решения проблемы.
Дело в том, что оказалось, что это 0x6917D8 освещает динамические объекты, а это 0x6865C4 как динамические так и статические, то есть подменяет не только для CBuilding, а для любых CEntity как родительского класса, возможно даже для машин и педов сработает без их собственных функций освещения, не проверял, поэтому нет смысла дублировать

Код: C++

1. plugin::patch::SetPointer(0x6917D8, DynamicSetupLighting);
2. plugin::patch::SetPointer(0x6917DC, DynamicRemoveLighting);

после

Код: C++

1. plugin::patch::SetPointer(0x6865C4, DynamicSetupLighting);
2. plugin::patch::SetPointer(0x6865C8, DynamicRemoveLighting);

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

[Shagg_E]

xanser, да но в предыдущем варианте, когда было

Код: [Выделить]

    plugin::patch::SetPointer(0x6865C4, DynamicSetupLighting);
    plugin::patch::SetPointer(0x6865C8, DynamicRemoveLighting);без

Код: [Выделить]

    plugin::patch::SetPointer(0x6917D8, DynamicSetupLighting);
    plugin::patch::SetPointer(0x6917DC, DynamicRemoveLighting);лично у меня в этом случае освещение динамических объектов(из object.dat) не менялось, а теперь динамически освещается всё(что с нормалями).
Хотя, конечно, если ты прав и одна из этих функций перекрывает другую, нужно найти правильный консенсус, дабы избежать багов(жаль, тут я бессилен чем-то помочь)...
Проверял новую версию на нескольких сборках вайса - пока нареканий не обнаружил, зато пришла одна безумная мысль(скоро выложу видос)...

P.S. Кстати, я вот не хотел(одно время) принудительное динамическое освещение для всех объектов, т.к. кое-где мне нужно было именно "запеченное" освещение, но, блин, потом дошло - можно же эти объекты всего лишь экспортить без нормалей, и нет проблем