OGSE: КБ разработчиков

[Murarius 10 533]

"Конструкторское бюро" OGSE.
Все о платформе, разработке, использовании материалов Old Good Stalker Evolution, а также всяческие предложения по дальнейшему развитию.

 

Исходники ogse.dll: https://yadi.sk/d/smv9hMa3gqGf5

Собирать только VS 2005 или VS 2008. В противном случае не взлетит.
Вроде бы внешних зависимостей никаких, необходимые файлы уже включены в проект.

 

Создаете файл с именем level.puddles в папке с нужной локацией. Открываете файл в текстовом редакторе и вносите туда записи вида:

[south_blockpost]
center = -84.61,-34.95,-347.90
max_depth = 0.5
radius = 30

[south_blockpost] - имя. Никакой роли не играет, служит лишь для ориентирования. Должно быть уникальным в пределах одного файла.
center - координаты центра лужи на локации
max_depth - максимальная глубина лужи. Выбирается таким, чтобы актор в самом низком присяде не смог в нее "нырнуть" с головой.
radius - размер лужи.
 
Определение координат для луж несколько заморочено. Связано это с тем, что не в любом месте можно поставить лужу - она может быть лишь в локальном углублении. Для выявления таких углублений предлагаю следующий вариант (именно им пользовался я). Декомпилируете локацию, загружаете в сдк. Удаляете ВСЕ объекты, кроме террейна, далее работаете только с ним. В свойствах террейна увеличиваете его вертикальную координату так, чтобы координатная сетка в сдк была полностью под ним. Затем понемногу "опускайте" террейн обратно. В тех местах, где будет появляться координатная сетка, и будут находиться локальные углубления. Киньте там калаш (или другой объект), узнаете координаты. Для большей заметности помогает сделать сетку "погуще".
Другой способ предложил Deathdoor. Сделайте очень большую плоскость в майке, обтяните заметной текстурой. Потом вставьте ее на локацию в LE под террейн, ну и двигайте потом вверх. Принцип аналогичен вышеописанному - там, где будет проступать плоскость, там локальное углубление.

 

При реализации этих эффектов довольно быстро стало понятно, что далеко не каждый источник света с ними выглядит хорошо. Потому была внедрена система пообъектной настройки фларов и объемного света. Для каждого источника можно включать или выключать эти эффекты отдельно двумя способами:
1) В all.spawn. Найдите секцию лампы, возьмите оттуда light_flags. Объемный свет включается путем выставления в light_flags флага 0x40, флары - флага 0х80. Выключаются эффекты снятием соответствующих флагов. Модифицируете флаг, собираете спавн, начинаете новую игру, наблюдаете появившиеся эффекты. Можно новую игру и не начинать, тогда перепишите нет-пакет лампы скриптом в игре. Для новичков в hex-исчислении: открываете виндовый калькулятор, переключаете в программистский режим, выбираете режим Hex. Выставление флагов производится функцией Or, снятие - функцией Xor.
2) В СДК. Поскольку расставление эффектов является больше дизайнерской задачей, сделал небольшую правку СДК: https://yadi.sk/d/3ZujqzlMgqJ6p. С ней просто запускаете LE, в опциях спавн-объекта лампы появятся флажки Enable Flare и Volumetric.

 

Прежде всего, понадобится утилитка, изготавливающая объемный туман, понимаемый OGSE-модом: https://yadi.sk/d/NXAUhXucgqJfP
Далее:
1) Запилите в 3d редакторе модель тумана и экспортируйте ее в obj. Вот простенькая модель, если кому лень запускать майку: https://yadi.sk/d/jvrU3XDjdSRvw
2) Создайте папку meshes в папке с fvolume_maker;
3) Скиньте модельку туда;
4) Запустите fvolume_maker. Параметры для батника:
-config <string> файл с конфигом объемов. Если не указано - будет fvm_config.ltx
-source <string> файл, куда сохраняем готовые объемы. Если не указано - будет level.fvolumes
-append <true|false> экспериментальная опция, позволяет не переписывать, а дополнять существующий файл *.fvolumes
Про файл конфигов. Он содержит записи вида:
[test]
position = 0.267,2.688, 91.776
rotation = 0.0,0.0,0.0
scale = 1.0,1.0,1.0
 
Все очевидно. Имя секции - имя вашей модельки. Position, rotation - позиция тумана на локации и поворот относительно осей.
Scale - растяжение модельки тумана по осям.
 
5) После окончания работы программы получится файл level.fvolumes. Нужно запихать его в папку с локацией. Для каждой локации такой файл нужен отдельный.
6) Правите конфиг туманов. Это файл config/environment/fog_volumes.ltx. 
Он содержит записи вида:
[test]
color = 1.0,1.0,1.0,1.0
max_density = 0.5
Тут еще очевиднее, чем раньше. Color - цвет тумана, max_density - плотность тумана. 
1 - ничего не видно через 1 метр, 0,5 - ничего не видно через 2 метра, и т.д. Обратная зависимость, короче.
7) Включаете опцию r2_volumetric_fog, загружаете локацию и ищете свой туман на локе.
 
Для удобной настройки есть консольная команда reset_fv. При ее вызове применяются изменения color и max_density.

 

Для создания и редактирования диалогов очень удобно пользоваться редактором диалогов за авторством Mlandrinus: https://yadi.sk/d/qmUaU5VIgqKCh. Кидаете в папку со сталкером, запускаете, дальше все в целом понятно. Конфиги должны быть распакованы.

 

Вид текстур в тепловизоре определяется настройкой material в textures.ltx. Имеется два пресета - для морд/тел/брони и для оружия. По сути, различие между пресетами заключается в том, что оружие при стрельбе греется и это учитывается. Если вы хотите применить для текстуры пресет для тела неписей, поставьте material в пределах 0,6-0,7. В данном случае 0,6 - холодная геометрия, 0,7 - горячая. Для оружия применяйте диапазон 2,85-2,95. Впрочем, в случае оружия лучше ставить всегда минимум (2,85), чтобы нормально выглядел эффект нагрева оружия.
Цвета в тепловизоре также можно настроить. Откройте shaders/r2/ogse_config.h. За цвета отвечают параметры IKV_DEAD_COLOR (цвет холодной геометрии), IKV_LIVE_COLOR (цвет горячей геометрии), IKV_MID3_COLOR, IKV_MID2_COLOR, IKV_MID1_COLOR (промежуточные "опорные" цвета). Все параметры приведены в RGB, подбирайте где-нибудь в пэинте.
Далее можно не читать, если вы не понимаете, для чего в игре параметр material. Если же вы понимаете и негодуете насчет того, что приходится менять ваши любимые настройки текстур ради тепловизора, внимайте.
Интервал значений material для тепловизора также можно изменить. За это отвечают параметры IKV_PRESET_1_MIN, IKV_PRESET_1_MAX (первый пресет) и IKV_PRESET_2_MIN, IKV_PRESET_2_MAX (второй пресет) в том же ogse_config.h. Правило конвертации - в ogse_config.h вносится значение (material + 0.5) / 4. Т.е., если нижний предел для первого пресета у вас 0,8, то IKV_PRESET_1_MIN назначаете равным (0,8+0,5)/4 = 0,325. Выглядит, странно, да, но вот так работает движок. И не без причины.

 

Есть такие консольные команды:
Цветокоррекция: r2_color_grading [0.0, 0.0, 0.0, 0.0]
Известный эффект, "подкрашивает" картинку на экране в выбранный цвет. Поставьте какой-нибудь синий цвет, мигом узнаете ранние Battlefield. Фича мощная, однако, требует некоторых усилий дизайнеров, поскольку цвет должен зависеть от локации и игровой ситуации.
 
Оптимизация отрисовки травы: r2_details_opt [0.0, 0.0, 0.0]
Три параметра, все три - расстояние в игровых метрах. Смысл такой: в игре трава рисуется квадратами 2х2, т.е. в одном "гнезде" четыре куста травы. С этим параметром по достижении первого расстояния перестает рисоваться один куст из четырех, по достижении второго - два куста из четырех, по достижении третьего - три куста из четырех. При тщательной настройке позволяет сберечь фпс без ухудшения картинки.

 

 

---

[YaSoN 63]

@Mirage2000, и таскать в инвентаре потом кучу всяких подсумков, которые будут снимать эти апгрейды (аля SWM 1.0), ага? @Shoker'у и @Sin!'у видимо делать было нечего, раз они сделали это добавлением костей. Да и вообще куча этих моделей будет весить таки не слабо, т.е. банальная оптимизация, да и скрипты эти имеют больше минусов (не сохранность подствольной гранаты например), чем если это будет скрытие костей.

[Dyadka_Yar 156]

@k01jan, не лучше, но делать так намного легче, чем заморачиваться с добавлением костей и переанимированием всей этой новогодней елки.

 

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

[k01jan 816]

Нужен скрипт для проверки. Прицел с костью добавить недолго.

[Malandrinus 615]

Хочешь скину? У меня есть такое.

Был бы признателен. А там в целом стандартные анимации есть? Стрельба, перезарядка и т.д.? Т.е. аддоны анимировать не надо, но всё остальное должно быть.

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

1. Кости для разных прицелов все используют в качестве корневой кость стандартного прицела "wpn_scope". По-моему, нельзя делать кость совсем без поверхности, поэтому в этом случае надо прицепить к стандартной кости хоть что-то, чтобы не было вылета.

2. Разных прицелы используют в качестве корневой кости корпус. На стандартной кости "wpn_scope" сидит один из прицелов (как обычно).

 

Я пока не знаю, какой из этих двух вариантов сработает лучше. Надо экспериментировать. Стандартные анимации худа должны быть в модели как обычно.

[k01jan 816]

@Malandrinus, для второго варианта прицелу дополнительному кость как называть? wpn_scope2? Её ж по имени скрывать/показывать скрипт будет? Какова будет глубина вложения скрипта? 3 кости ("средний", "дальний", коллиматор), больше?
И прошу сразу предусмотреть в скрипте возможность смены магазина. ИМХО достаточно будет 3 доп.костей для сменных магазинов разной ёмкости.
Первый вариант подойдёт?
По второму варианту так будет работать? Или 2-й (и очередные) прицелы (аддоны) скрытыми делать надо?
И неплохо какой-то стандарт на скелет ввести (типа тех.задания) - они ж нестандартные.
И ещё: есть ли в движке метод alpeta по смене текстуры?

Не прокатило.. Анимации *.skls от "старой" модели без долоднительной кости прицела ожидаемо не импортируются в СДК

Изменено 26 Января 2015 пользователем k01jan

[Malandrinus 615]

для второго варианта прицелу дополнительному кость как называть? wpn_scope2?

Да

Её ж по имени скрывать/показывать скрипт будет?

Да

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

Мне сейчас достаточно одного дополнительного прицела, чисто для эксперимента.

 

И прошу сразу предусмотреть в скрипте возможность смены магазина.

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

 

ИМХО достаточно будет 3 доп.костей для сменных магазинов разной ёмкости.

А может для начала обойдёмся двумя прицелами?

 

Первый вариант подойдёт?

По второму варианту так будет работать? Или 2-й (и очередные) прицелы (аддоны) скрытыми делать надо?

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

 

 

И неплохо какой-то стандарт на скелет ввести (типа тех.задания) - они ж нестандартные.

Я выше, как мне кажется, довольно подробно описал два возможных варианта. Названия для доп. костей не имеют значения. Важно только оставить стандартную кость и её имя "wpn_scope". Это имя зашите в движке.

 

И ещё: есть ли в движке метод alpeta по смене текстуры?

По-моему нет.

 

Не прокатило.. Анимации *.skls от "старой" модели без долоднительной кости прицела ожидаемо не импортируются в СДК

Я себе представлял, что надо перегнать модель с анимациями из сдк в некий общий редактор (MilkShape, Maya, 3ds Max), там добавить кость и к ней поверхность, затем перегнать модель с новой костью обратно в сдк. В принципе понятно, что кость, которая стоит на месте относительно корневой, на самом деле тоже анимируется, просто никуда не едет. Но редактор как раз и должен взять на себя работу по включению доп. кости в существующую анимацию. Или я не прав? Ну не верится мне, что надо переанимировать вообще всё при добавлении одной неподвижной кости.

[RayTwitty 492]

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

Ну, при изменении скелета (а добавление кости это изменение скелета), надо переделывать и анимации. Точнее, заставить двигаться новую кость вместе с этими анимациями.

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

 

---

И что на счет вопросов? Я уже не знаю куда тебе писать - в личку не отвечаешь, тут тоже игноришь...

http://www.amk-team.ru/forum/index.php?showtopic=13118&p=910909

 

http://www.amk-team.ru/forum/index.php?showtopic=10538&p=910580

Я конечно понимаю, мб времени нет и всё такое, но чиркнуть пару предложений - вполне можно.

 

И ещё: есть ли в движке метод alpeta по смене текстуры?

В xray-extensions нет этого. Без исходников там очень много править бы пришлось. Изменено 26 Января 2015 пользователем Shadows

[Dyadka_Yar 156]

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

 

Если модель открыть в 3д редакторе, а это можно сделать при помощи конвертера бардака, и плагинов Den Stash-а, можно спокойно добавить новую кость, анимации переделывать не надо, там положение костей не относительно центра сцены, а родительской кости, только СДК сталкера насколько я помню старый skls не подключит к модели с новыми костями, придеться импортировать каждую анимацию к измененной модели в 3д редакторе и пересохранять в skl, с анимацией ничего случиться не должно. Правда я не совсем модельщик, в основном мое моделирование заключается в том что я вынимаю модели из Unreal Engine, или еще какой-то игры где есть плагины с импортом анимаций, и портирую в Half-Life, там намного проще с моделями, ну или скидываю их кому надо, а в сталкером мороки много с моделями из других игр, и он обычно плохо переваривает такие модели, если делать новые модели то лучше всего делать заново свои анимации, с стандартным скелетом рук, или как у новых ОГСЕ-шных моделей, только у меня навыков анимирования вообще нет, если бы были то я бы не мучался переносами готовых анимаций.

[k01jan 816]

 

 

надо перегнать модель с анимациями из сдк в некий общий редактор (MilkShape, Maya, 3ds Max), там добавить кость и к ней поверхность, затем перегнать модель с новой костью обратно в сдк

так и есть

 

 

СДК сталкера насколько я помню старый skls не подключит к модели с новыми костями

так и есть

 

 

прийдеться импортировать каждую анимацию к измененной модели в 3д редакторе и пересохранять в skl

попробую

[Dyadka_Yar 156]

попробую

 

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

 

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

Изменено 26 Января 2015 пользователем Dyadka_Yar

[Malandrinus 615]

что на счет вопросов?

Это насчёт set_ignore_game_state_update? Я уже смутно помню. Какая-то затычка от какого-то нежелательного эффекта при промотке времени. Если вспомню, напишу в вики.

[Malandrinus 615]

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

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

[killersan6 184]

@Malandrinus

Ну так исходники движка в общем доступе. Все эти не стандартные кости вполне реализуемы.

[Kondr48 314]

 

killersan6, так-то оно так, но схема в первую очередь для ogse, который не базируется на исходниках =)

 

[killersan6 184]

killersan6, так-то оно так, но схема в первую очередь для ogse, который не базируется на исходниках =)

В таком случае сложнее...

[k01jan 816]

 

 

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

Даже лучше - меньше работы вариантов делать
Технически всё вроде получается.
К стандартной кости wpn_scope добавлена кость s1 и решена проблема анимаций - останутся со старой модели.

Теперь дела пойдут быстрей. На днях добавлю s2 для второго прицела, доэкспортирую анимации и соберу модель для теста. Мировую, думаю, можно пока не трогать?

 

Сменные прицелы будут крепиться каждый к своим костям (их видимость надо переключать скриптом), а те, в свою очередь, к стандартной wpn_scope.

 

Вот только как быть, если никакой прицел не надет? Не вылетит ли? Не будет ли движок приближать при прицеливании и не захочет ли текстуру прицела? Может действительно на wpn_scope заглушку какую прикрепить и спрятать в теле оружия?

[Kondr48 314]

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

Хотя стоп, в конфиге же это не укажется, хм, интересно))

Изменено 27 Января 2015 пользователем Вампир35

[RayTwitty 492]

Это насчёт set_ignore_game_state_update?

Там вроде бы не только про set_ignore_game_state_update было. По первому линку - 2 вопроса, по второму - 3 набора методов, один из которых (uint cast_ХХХ()) используется в OGSE. Изменено 27 Января 2015 пользователем Shadows

[Malandrinus 615]

,

по последнему вопросу https://code.google.com/p/xray-extensions/wiki/type_check

по create_light01 и к нему относящимся. Это была моя попытка создать источник света на худе. Создавался, но толку не дало, поскольку создавался в координатах игры, а худ рисуется со своим FOV,

По остальным вопросам уже не помню, что и зачем.

 

Ещё скажу. wiki проекта x-ray extentions является его официальной документацией. Формат wiki специально предназначен для совместной работы и модификации того, что сделали другие. Так что вся информация в первую очередь должна быть там.

[k01jan 816]

@Malandrinus, сделал.

В архиве - худовая и мировая модели Эммы. Вариант, когда аддоны все сидят на нестандартных (добавленных) костях s1 (посажен ACOG) и s2 (сидит какая-то "труба" -что под руку попалось), каждая из которых, в свою очередь, расположена на стандартной wpn_scope.

P.S.: Сейчас в игре видимы оба прицела ОДНОВРЕМЕННО. Надо поочерёдно скрывать их кости скриптом в зависимости от установленного прицела.

P.P.S.: Анимации остались прежние.

Изменено 28 Января 2015 пользователем k01jan