Спасибо за наиподробнейшее описание, заценил шутку
Post automatically merged:
Плюс программа умеет делать экспорт моделей, то есть можно на goldsrc все лимиты обойти без каких либо проблем. Ну я так понял в xash это не понадобится.
Но в goldsrc это крайне полезная вещь должна быть, правда из-за того что модель будет в виде сущности возможно слегка оптимизация пострадает т.к VIS по идее не будет работать из-за этого раз он только на мир работает.
но если в карте 100000 клипнодов, то её просто на 3 модели разбить, скомпилировать с освещением, а затем сделать экспорт в BSP формат через bspguy по очереди, и в основную карту импортировать в виде func_breakable неразрушаемого(там автоматически прекеш делает если прописать модель дважды), получится такой сэндвич из кусков карт, но тогда лимитов не будет никаких.
А в чём шутка-то? Исходники паранои, ксаш-мода и самого движка давно лежат на гитхабе и форкнуты не по одному разу. Качай, изучай, разбирайся, задавай вопросы што непонятно.
А в чём шутка-то? Исходники паранои, ксаш-мода и самого движка давно лежат на гитхабе и форкнуты не по одному разу. Качай, изучай, разбирайся, задавай вопросы што непонятно.
Ага я и так скачал, но что бы в чужом коде не сидеть часами и разбираться, думал задокументирован формат ну как все форматы goldsrc подробно что куда и зачем, какие там лумпы новые и что они делают, и т.п.
Но если нет такогл то придется расковыривать код написанный чужими руками и разбираться что да как самому )
Вот читал описание статьи по оригинальному движку, там все красиво расписано, можно понять что зачем для чего и т.п, даже интересно было читать
Post automatically merged:
а вот если у карты нет превышения по клипнодам, то как понять что она bsp30ext? пытаться читать extralump и надеяться что краша не будет если вдруг случайно совпадут байты после оригинального заголовка с "расширенным" или это маловероятно?))
BSP30ext - это неявный формат. Он не говорит, что здесь - явно я. Он меняет только клипноды, которые и надо проверять. А всё остальное остаётся прежним. Заголовки следуют один за другим, вот так:
Ну давай прикинем. Все компиляторы сразу после заголовка пишут лумп с плоскостями. В плоскостях первой переменной идёт normal.x. Все нормали в плоскостях нормализованы, т.е. приведены к диапазону -1..1 Любое значение float в этом диапазоне никаким чудом не выдаст тебе ксашевскую сигнатуру.
Post automatically merged:
Аж самому интересно стало, не поленился и проверил. Корочи сигнатуре XASH соответствует значение с плавающей точкой: 216325.375
Но повторюсь, поскольку все нормали приведены к диапазону -1..1 оно там возникнуть не может никоим образом.
Жаль только, что половина - враньё, либо устаревшая информация.
BSP30ext - это неявный формат. Он не говорит, что здесь - явно я. Он меняет только клипноды, которые и надо проверять. А всё остальное остаётся прежним. Заголовки следуют один за другим, вот так:
Ну давай прикинем. Все компиляторы сразу после заголовка пишут лумп с плоскостями. В плоскостях первой переменной идёт normal.x. Все нормали в плоскостях нормализованы, т.е. приведены к диапазону -1..1 Любое значение float в этом диапазоне никаким чудом не выдаст тебе ксашевскую сигнатуру.
Post automatically merged:
Аж самому интересно стало, не поленился и проверил. Корочи сигнатуре XASH соответствует значение с плавающей точкой: 216325.375
Но повторюсь, поскольку все нормали приведены к диапазону -1..1 оно там возникнуть не может никоим образом.
порядок может быть рандомным, например bspguy в порядке как в заголовке сохраняет, а вот смотрю карты оригинальные там походу другой порядок то ли вообще рандомный , я так понял вообще движку побоку как они расположены в файле, например в КС 1.6 смотрю карты и в некоторых видно сразу LUMP_ENTITY идёт судя по содержимому
В любом случае теперь спасибо за инфу теперь понял как определять расширенный формат
Ну вот sponza.bsp после оптимизации, удалено ~3к плоскостей и ~10+к клипнодов. + по какой-то причине удалилось ещё несколько кбайт VIS данных(понятия не имею почему )
Карта исправно запускается в xash как и оригинал, никаких отличий нет
Post automatically merged:
Добавил поддержку XASH карт (bsp30ex и 32bit клипноды) !
Дополнительные данные просто сохраняет в память а потом обратно в файл при сохранении.
BSP2 и 2PSB - это форматы для первой кваки. Они отличаются от халфовских тем, что все 16-битные переменные в дисковых структурах заменены на 32-х битные. 2PSB - это такой тестовый формат, первая попытка расширить лимиты у него есть какие-то ограничения. Лично мне он никогда не попадался в модах, поэтому его поддержку я делать не стал. А BSP32 встречается например в замечательном моде Arcane Dimensions а так же Raven Keep. Ну и в других модах под Кваку он тоже есть.
Там далеко не все карты - BSP2. ad_sepulcher, ad_swapmy - это точно BSP2. Так же там встречаются карты с поддержкой Arguire Broken Clipnodes, к сожалению не помню название. Но можно под ксашем быстро посмотреть статистику всех карт прямо из консоли, даже не загружая их.
mapstats имякарты
Ххаха добавил в загрузку клипнодов "std::for_each(std::execution::par_unseq" , не знаю как но это ускорило загрузку клипнодов в 100 раз как минимум))) за секунду все загружаются, а грузились секунд 40- ... странно)
Добавил поддержку и этого "2PSB" нашел инфу что NODES и LEAVES там short Mins/Maxs и больше ничем не отличаются ?
Пока еще тестирую, возможно только завтра в репозиторий загружу, надо подумать как конвертировать карты между форматами раз уже загрузку добавил
(ну из старых в новее, или может вообще не надо хз пока что сам не знаю)
Хех. Ну тогда добавь ещё поддержку Hexen II, до кучи. От Quake BSP там единственное отличие - в структуре dmodel_t ссылка не на четыре хулла, а аж на восемь. Других отличий нет.
Где-то у меня даже было хитрое условие, позволяющее их отличать от ванильного Q1. Вспомню - напишу.
Можно привязать монохромность лайтмапы прямо к версии BSP. Если 29 - то монохром, если 30, то цветное. Однако существуют еще карты из Half-Life beta, где номер версии 29, а освещение при этом цветное. Я устал придумывать хитрые условия и в ксаше запилил анализатор цветности лайтмап, там довольно хитрый алгоритм, можешь посмотреть. Но зато он реально анализирует содержимое лайтмапы, а не полагается на жесткие условия. Это самое надёжное.
Можно привязать монохромность лайтмапы прямо к версии BSP. Если 29 - то монохром, если 30, то цветное. Однако существуют еще карты из Half-Life beta, где номер версии 29, а освещение при этом цветное. Я устал придумывать хитрые условия и в ксаше запилил анализатор цветности лайтмап, там довольно хитрый алгоритм, можешь посмотреть. Но зато он реально анализирует содержимое лайтмапы, а не полагается на жесткие условия. Это самое надёжное.
Yesлибы. Это бы сработало только для халфы, т.к. там оффсеты последовательно генерятся в одном потоке. А в оригинальных кушных картах они заполнялись в мультипотоке из-за чего такая простая проверка не сработает. К тому же из-за выравнивания там своя погрешность получается, вообщем много ньюансов.
Ну там загрузка изначально выведена в отдельный поток, потому что длительный процесс, да и сам рендер, жёстко тупит, там где карты очень большие, фпс падает жёстче чем от рендера моделей, с помощью std::for_each сильно ускоряется загрузка клипнодов, т.е процессор например загружало на 20% то теперь грузит на все 100% и намнооого быстрее идёт процесс.
Полезная вещь, я уже и в загрузку lightmap это вставил)) две строки кода добавить а такое ускорение даёт, правда пару mutex'ов вставить пришлось, а то какая-то хрень творилась когда пыталось в один std::vector записывать и читать из него, в std::for_each.
Yesлибы. Это бы сработало только для халфы, т.к. там оффсеты последовательно генерятся в одном потоке. А в оригинальных кушных картах они заполнялись в мультипотоке из-за чего такая простая проверка не сработает. К тому же из-за выравнивания там своя погрешность получается, вообщем много ньюансов
Ну найти первый фейс с lightmap, затем от него до конца перебрать и найти второйближайший, это ж вообще не проблема, ну да на счёт выравнивания я не знал, потом гляну как это работает в ксаше.
Я добавил монохромный lightmap для bsp29 карт но пока ещё не загрузил в репозиторий, т.к не доделал, то есть это сработало для обычной 29 версии, а вот на этих 2bsp и bsp2 все текстуры все равно рандомными пикселями усыпаны, думаю пока что там еще не так. Плюс первая bsp2 версия, которая устаревшая, хоть я и добавил short ноды и листья, оно все равно крашит на некоторых картах, вот про что, а про этот формат я не могу ничего нагуглить кроме как про изменённые nodes/leaves
Ещё потом буду пытаться разобраться в EXTRA lump'ах и загрузке внешней карты освещения что бы карты на xash смотрелись красиво, а не рандомными цветами заполнялись
Плюс чето обнаружил что встроенный StudioModel рендер крашится на моделях ксаша, на 30% моделей где-то, там какие-то лимиты увеличены в формате моделей?
Карты все равно странно выглядят, видимо это текстуры криво читает
В blp файлах (warcraft 3) вроде как был флаг compressed, если сжатый, то использовалась палитра, иначе jpeg. В quake/goldsrc то же самое палитра и RGB ? или только палитра бывает?
Да с каких пор реконструкция геометрии из дерева стала длительным процессом?
Я тебе говорю ксаш эту операцию даже на самых тяжелых картах производит за 2-3 секунды максимум.
Ну естественно криво. В кушных текстурах нет встроенной палитры, отнимай от размера 770 байт в конце. Палитру можешь грузить либо из самой игры либо встроить прямо в код BSPGuy, я чёт ни разу не видел чёб она менялась. Хотя нет вру, видел, на одном моде-римейке Wolfenstein 3D для первого квейка.
Я имею ввиду, что там проверяется на 1 и 3, даже если float, то там ведь просто физически никак не может стать 0
в int lightmap_samples;, должно что-то невероятное произойти что бы из 1.0 превратилось в 0
Я конкретно про последнюю строку bmod->lightmap_samples = Q_max( bmod->lightmap_samples, 1 ); // avoid division by zero