Patching of maps in runtime

[0x4E69676874466F78]

• [x] Edit or disable lights [high]
  • [x] entity_id R G B V — OK, similar logic as with rad files [high]
  • [x] full control entity keys — may be needed for light_spot/light_environment correction [low]
  • [x] change position feature — maybe not all bad light should be turned off but move them to optimal position [low]
• [x] Emissive texture only for specific brush or brush surface (surface_id R G B V?) [medium]
• [ ] Add plane-brush (func_wall/func_illusionary) — for c1a4f (for holes near the water where droplets fall) [low]
• [x] Remove specific brush or brush surface by his id [low]
• [x] Add light entity [lowest]

If this is not difficult, you can immediately give full control over the entity, but if it is difficult it is better to implement simple support (entity_id R G B V).

Full control entity format example:

[
    {
        "id": 1,
        "position": [100, 200, 300], // X, Y, Z
        "data": {
            "_light": "0 255 0 50",
            "pitch": -80,
            "_cone": 45, 
            "_cone2": 0,
        }
    },
]

[w23]

Hmmm.. This is a nice idea! It is not that difficult to add a command that can add overrides to various things (entity light properties, emissive textures color, etc). We could also dump these overrides into a file and start working on a patch file format.

1. Do entity light have an unique id or something? Or just a sequence number is enough? Do we need find-by-parameters (e.g. position, color, ...)?
2. Does xash support writing into files? (we could just use fopen/fwrite any time though)
3. What structured file format can xash read? Can it read Source vmf (or whatever it's called)? We could also write our own parser (e.g. take one from https://github.com/w23/OpenSource/blob/master/src/vmfparser.c)

[0x4E69676874466F78]

@w23

Do entity light have an unique id or something? Or just a sequence number is enough?

I think you can do the sequence order as in bspguy: https://user-images.githubusercontent.com/4449851/137719945-de816320-36d6-4b2f-a440-ea03d4c1c1fb.png https://sourcegraph.com/github.com/wootguy/bspguy@7d72ce7df394a90248b45a9c7f1667193826fba6/-/blob/src/editor/Gui.cpp?L2800:8 https://sourcegraph.com/github.com/wootguy/bspguy@7d72ce7df394a90248b45a9c7f1667193826fba6/-/blob/src/editor/Gui.cpp?L2739:24 https://sourcegraph.com/github.com/wootguy/bspguy@7d72ce7df394a90248b45a9c7f1667193826fba6/-/blob/src/bsp/Bsp.cpp?L2257:27 https://sourcegraph.com/github.com/wootguy/bspguy@7d72ce7df394a90248b45a9c7f1667193826fba6/-/blob/src/bsp/Bsp.cpp?L4022:2&subtree=true

Do we need find-by-parameters (e.g. position, color, ...)?

Probably no. I don't see the point in mass replacement yet.

Does xash support writing into files? (we could just use fopen/fwrite any time though)

https://github.com/FWGS/xash3d-fwgs/blob/e5e1570aed435acc3216bf73a39e812853d2aa0c/engine/common/filesystem.c#L2755-L3248

What structured file format can xash read? Can it read Source vmf (or whatever it's called)?

No.

[w23]

Надо обсудить, что именно делаем-то. И как.

Я начну:

1. Всё, что касается удаления-добавления-редактирования энтитёвых источников света (не площадники, а point/spot/env) мы можем оставить встроенному в ксаш механизму. entpatch или как его там.
2. Редактирование поверхностей брашевых моделей. Выбирается одна или несколько surface, применяется операция к ним.
   • выборка surface:
     • по model name и index
     • по имени текстуры
   • операции:
     • удалить к чертям
     • изменить текстуру (по имени)
     • умножить emissive из rad на константу
     • заменить emissive из рада на заданные rgb

Что ещё может быть нужно?

[0x4E69676874466F78]

1. проблема entpatch в том что это по сути кусок карты, там всегда должны быть ВСЕ энтити, это неудобно, придётся делать специальные пометки для себя где изменённые энтити, комментировать рядом оригинальные (на случай если понадобится вернуть), но если совсем нет желания/времени добавить их патчинг через через собственный конфиг чтобы без лишних записей то ладно. К сожалению мне пока сложно понять сколько те или иные задачи могут отнять у тебя времени.

2. model name и index

model name = ключ model у энити-брашей? Типа достать все surface index которые связаны с model? index это что щас у нас в ui_infotool называется surface index? Если да то ок.

по имени текстуры

Вероятно не пригодится.

изменить текстуру (по имени)

Хочешь сказать что что для конкретного surface index мы не сможем выставить другую текстуру? Или к чему было "(по имени)"?

умножить emissive из rad на константу

Типа для конкретной поверхности задаём отклонение в нужную сторону от значений из рада?

Остальное да.

Что ещё может быть нужно?

1. Задать конкретному спрайту-энтити светимость. https://github.com/w23/xash3d-fwgs/issues/153 То есть вот есть спрайт красных огней у забора в комнате с лучевой установкой с кристаллом где этот самый кристалл в тележке поднимается наверх. Там нет лампочек, но есть спрайты, эти спрайты по идее должны испускать свет, хорошо бы по иду энтити задать им большую светимость. В ряде мест можно ещё таким образом можно выкинуть лампочки которые там приделаны сбоку как хак (потому что в оригинале спрайты не могут светиться). Это связано с: https://github.com/w23/xash3d-fwgs/issues/171

2. в других местах мы можем избавиться от кучи glow спрайтов если добавим к источникам света процедурный эффект лучей с блумом. Пример какой эффект можно сделать: https://www.shadertoy.com/view/4sX3Rs вот это крутой вариант, чуть более быстрый форк с линзой: https://www.shadertoy.com/view/XdfXRX https://www.shadertoy.com/view/3d3yWl https://www.shadertoy.com/view/wsXSzM (совсем просто, но естественно пульсацию надо выпилить) Связано с https://github.com/w23/xash3d-fwgs/issues/186

[w23]

1. проблема entpatch в том что это по сути кусок карты, там всегда должны быть ВСЕ энтити, это неудобно, придётся делать специальные пометки для себя где изменённые энтити, комментировать рядом оригинальные (на случай если понадобится вернуть), но если совсем нет желания/времени добавить их патчинг через через собственный конфиг чтобы без лишних записей то ладно. К сожалению мне пока сложно понять сколько те или иные задачи могут отнять у тебя времени.

Ок. Отдельным комментом напишу предложение по этому поводу.

model name и index

model name = ключ model у энити-брашей? Типа достать все surface index которые связаны с model? index это что щас у нас в ui_infotool называется surface index? Если да то ок.

Оба, и model name, и surface index, это то, что показывается в ui_infotool. Понятия не имею, что там в энтитях просходит. Я не очень хорошо понимаю, как оно устроено внутри.

по имени текстуры

Вероятно не пригодится.

Ок, тогда не делаю. Но потом можно приделать если что.

изменить текстуру (по имени)

Хочешь сказать что что для конкретного surface index мы не сможем выставить другую текстуру? Или к чему было "(по имени)"?

Почему? Я именно и хочу сказать, что мы можем назначить произвольную текстуру выбранным поверхностям. Там, наверное, нужно будет ещё уметь текстурные координаты запатчить. Если нужно уметь полностью переориентировать текстуру, то нужно будет просовывать T/B вектора. Либо, если нужно просто отмасштабировать, то просто 2 вектора по 2: offset и scale.

умножить emissive из rad на константу

Типа для конкретной поверхности задаём отклонение в нужную сторону от значений из рада?

Ага. Можно сделать тусклее или светлее пропорционально.

[w23]

1. Задать конкретному спрайту-энтити светимость. [Emit light from sprite for specific entity (by map config) #153](https://github.com/w23/xash3d-fwgs/issues/153)

Не уверен, что у меня есть доступ из рендера до информации о том, откуда спрайт прилетел. Надо смотреть. Скорее всего я могу максимум выбрать по имени текстуры, режиму рендеринга и координатам (bounding box).

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

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

В ряде мест можно ещё таким образом можно выкинуть лампочки которые там приделаны сбоку как хак (потому что в оригинале спрайты не могут светиться).

Лампочки можно будет выкинуть через патчинг энтитей (1).

   Это связано с: [rtx: sprite orientation #171](https://github.com/w23/xash3d-fwgs/issues/171)

Ориентация спрайтов больше про то, как разные спрайты выглядят с разных сторон.

2. в других местах мы можем избавиться от кучи glow спрайтов если добавим к источникам света процедурный эффект лучей с блумом. Пример какой эффект можно сделать:
   https://www.shadertoy.com/view/4sX3Rs вот это крутой вариант, чуть более быстрый форк с линзой: https://www.shadertoy.com/view/XdfXRX
   https://www.shadertoy.com/view/3d3yWl
   https://www.shadertoy.com/view/wsXSzM (совсем просто, но естественно пульсацию надо выпилить)
   Связано с [how much stuff do we lose if glow sprites are completely disabled for ray tracing? #186](https://github.com/w23/xash3d-fwgs/issues/186)

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

[0x4E69676874466F78]

Оба, и model name, и surface index, это то, что показывается в ui_infotool. Понятия не имею, что там в энтитях просходит. Я не очень хорошо понимаю, как оно устроено внутри.

Дело в том что surface index уникален и абсолютен-глобален, если ты не будешь искать surface index принадлежавшие брашу по ключу model то смысла в model вообще никакого нет!

Ок, тогда не делаю. Но потом можно приделать если что.

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

Почему?

Сбила формулировка, на всякий случай уточнил.

Там, наверное, нужно будет ещё уметь текстурные координаты запатчить.

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

Не уверен, что у меня есть доступ из рендера до информации о том, откуда спрайт прилетел.

Ну ты же как-то получаешь список лампочек и сними работаешь, чем тут спрайты от лампочек отличаются? Это те же энтити.

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

Жаль, ну ладно, переживём.

Лампочки можно будет выкинуть через патчинг энтитей (1).

Без задания нужной светимости от спрайтов это делать нельзя. А раз мы не можем сделать свет от конкретных энтити спрайтов нужного уровня то лампочки придётся оставить и как-то их правильно расположить. Ах да не забудь про механизм отсечение у point light рядом лежащей геометрии, это точно нужно!

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

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

[w23]

1. Патчинг энтитей.

Что нужно:

• выборка:
  • тупо порядковый номер (в подробном логе будет виден, можно будет оттуда взять; bspguy его показывает?)
  • targetname (тоже в логе виден)
• удаление
• модификация
  • наверное ровно такие же параметры как в обычных энтитях о свете
  • плюс radius для "точечных" источников
• добавление: то же самое, что и модификация, просто нет инструкций для выборки.

Примерно формат:

{
  "ent_id" "31337"
  "delete" "1"
}

{
  "ent_id" "23"
  "radius" "17"
  // прочие параметры
}

{
   // параметры light как обычно -- это создаст новый источник просто
}

// сюда же можно подложить и (2)
// удалит поверхность
{
   "model_name" "*42"
   "surface_id" "69"
   "delete" "1"
}

// заменит текстуру везде
{
   "surface_texture" "lab1_something"
   "texture" "lab1_something_else"
}

Вопрос такой: этот весь патчинг в одном файле (per map конечно), или по разным группам (свет отдельно, surface отдельно, спрайты отдельно)? Это немного влияет на формат.

[0x4E69676874466F78]

тупо порядковый номер (в подробном логе будет виден, можно будет оттуда взять; bspguy его показывает?)

Да bspguy показывает, можно взять его логику.

[w23]

Дело в том что surface index уникален и абсолютен-глобален, если ты не будешь искать surface index принадлежавшие брашу по ключу model то смысла в model вообще никакого нет!

Ок, можно только surface_index

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

Ок, пока не делаю. Надо будет -- сделаем.

Ну ты же как-то получаешь список лампочек и сними работаешь, чем тут спрайты от лампочек отличаются? Это те же энтити.

В том-то и дело, что нет. Мне прилетает какая-то ентити на отрисовку в рендер. Это динамическая энтити, которая никакого прямого отношения к тому, что лежит в картовых ентитях, не имеет. Никакого способа сопоставить её с тем, что лежит в карте, я не нашёл (и индекс у неё другой и динамический)

Без задания нужной светимости от спрайтов это делать нельзя. А раз мы не можем сделать свет от конкретных энтити спрайтов нужного уровня то лампочки придётся оставить и как-то их правильно расположить. Ах да не забудь про механизм отсечение у point light рядом лежащей геометрии, это точно нужно!

Может просто радиус проканает. А если не проканает, добавим ещё параметр теневого радиуса.

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

https://developerfreaks.com/unity/D/dirty-lens-effect-6936/dirty-lens-effect-6936-004-scaled.jpg

[0x4E69676874466F78]

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

А в каком виде оно прилетает? У него ключи какие-то есть может хотя бы по origin можно?

https://developerfreaks.com/unity/D/dirty-lens-effect-6936/dirty-lens-effect-6936-004-scaled.jpg

Заляпанное стекло объектива считаю не стоит делать так как у нас вроде как не шлем или шлем? А вот испускающиеся лучи они есть и у зрения.

[0x4E69676874466F78]

Вопрос такой: этот весь патчинг в одном файле (per map конечно), или по разным группам (свет отдельно, surface отдельно, спрайты отдельно)? Это немного влияет на формат.

Каким образом влияет на формат?

Планировал что для каждой карты свой файл где всё вместе.