Paranoia 2 Savior map compile tools (beta version)
Ну чтоже. Вы все этого так долго ждали, и вот наконец первая публичная бета. А те кто не ждал, но всё равно заинтерисовался, может почитать вот эту тему. Сперва немного идеологии, которой я руководствовался при разработке своих компиляторов, ну и ответов на вопрос, чем же меня не устроили VHLT.
Если бы у меня был так или иначе мод под халфу или просто карты под CS 1.6, то меня бы устроил и VHLT. Даже если бы у меня был просто собственный движок и мне бы хотелось прикрутить к нему кое-какие модные фишки, то я бы немного модифицировал VHLT (что я собственно и сделал). Всё дело в том, что компиляторы полны ошибок, т.к. зачастую их писали люди, слабо разбирающися в компиляторах. Китаец сделал много хорошего (ну и спорные вещи тоже), профиксил множество ошибок, однако в его коде невозможно ориентироваться из-за громадного числа переключающих макросов, в которые он обворачивал все устраняемые ошибки и фичи. Плюс еще неравномерное форматирование, оставшееся от ZHLT, где-то табы, где-то пробелы. В этой каше очень тяжело понять где тот код, который сейчас используется, а где тот, который выключен. Ну и со временем накопилась критическая масса лично моих замечаний к VHLT, каких-то ошибок или багов, которые следовало бы исправить, но залезать туда и разбираться в этом нагромождении не было никакого желания. Постепенно пришло понимание что компиляторы всё же придется писать самостоятельно. Не с нуля разумеется, на это нет времени, но и смысла в этом нет тоже. Так или иначе используя весь опыт накопленный в этой области, тестируя и сравнивая различные решения, исправляя то, что так никто и не исправил. Ну а затем, когда база была готова уже начались оригинальные вещи - например повертексное освещение моделей
Но более подробно в описании возможностей.
Технические особенности, основные отличия и преимущества новых компиляторов:
Несмотря на тот факт, что компиляторы делались целенаправленно для Paranoia 2:Savior, в процессе разработки я попытался учесть множество пожеланий и охватить соседние области маппинга, например для первого квейка, ксаш-мода, ну и просто голдсорса.
1. Карты собираются в особом расширенном формате, который тем не менее, если включать особые фичи и не выходить за лимиты прекрасно воспринимается голдсорсом (на самом деле я давно уже не проверял, ну на то это и бета, чтобы мы всё вместе проверили). Некоторые вещи будут работать только на Xash3D, еще некоторые - только на XashXT и P2:Savior, а совсем уж некоторые предназначены специально для паранои. Однако фичей много и я думаю каждый найдет для себя кое-что интересное.
2. Поддержка компиляции уровней от первого квейка. Это заявление не вполне корректно, поскольку компилятор не собирает карты в формат BSP 29, но учитывая что почти все форки квейка преспокойно умеют грузить BSP30, не думаю что это большая проблема. К тому же, как вы понимаете есть и мои собственные римейки квейка и враппер для него же. Поддержка заключается в корректной обработке освещения по квейковски с чётко заданным радиусом, за пределы которого свет не выходит. Так же на некоторых картах квейка присутствуют специфичные ошибки, от которых тот же VHLT впадает в ступор. Это я тоже учёл. Тестирование проводилось на картах от Arcane Dimensions. Так же присутствует поддержка теней от алиас-моделей. В кваке где любят ставить якобы статуи монстров, которые потом внезапно оживают, я полагаю это будет весьма полезная штука. Когда я открою исходники в с лёгкостью сможете полностью адаптировать их непосредственно для кваки, если у кого-то возникнет такая необходимость.
3. Набор некоторых специфичных настроек-расширений, которые будут работать только в Xash3D (ну или где-то еще, если их туда внедрят). Например отвязка разрешения люкселей от скейла текстур и привязка их к мировым юнитам. Это даёт более равномерную сетку и убирает швы. Однако на сложной геометрии типа скал их не рекомендуется использовать. Фича включается прописыванием следующего параметра в worldspawn:
zhlt_worldluxels 0/1/2
Один и два это разные модели лайтмапной матрицы, второй вариант - всегда положительная. Так же следует учитывать что на соотношении люксель к юниту общий объем лайтмапы может уменьшиться, но соответственно немного упадёт и качество. Зато классические динамические лайты из стандартного рендерера перестанут сжиматься на текстурах с разным скейлом.
Из остальных настроек, доступных только в моих компиляторах:
zhlt_nocsg 0/1
Полурабочее решение есть и в UMHLT, но там оно способно лишь глобально выключить CSG для всего мира или энтити. А здесь вы можете задать это для группы мировых брашей, поместив её(группу) в func_group.
Так же разумеется, присутствует поддержка кастомного субдивайда, параметр
zhlt_maxextent 16/64/128
вы можете задавать и другие значения, но обычно в этом нет смысла. Поддержка кастомного разрешения текстур тоже никуда не делась, напоминаю, это
zhlt_texturestep 32/16/8/4/2
Точно так же вы можете задавать и другие числа, но кратные предпочтительнее.
Из недокументированных возможностей
zhlt_forcelightmap 0/1
Мои компиляторы по дефолту не рассчитывают лайтмапы для водных поверхностей, т.к. она всё равно не используется нигде, кроме второй паранои. А эта настройка позволяет рассчитать принудительно.
Из параметров освещения, так или иначе завязанных на освещение модели добавились:
zhlt_modelshadow 0/1
это замена ключу zhlt_studioshadow поскольку мой компилятор умеет освещать и алиас-модели тоже. Здесь есть некоторое неудобство конечно, но я думаю мы еще придём к общему варианту. Напоминаю ключ нужен чтобы включить тень от статичной модели, например в голдсорсе, для CS 1.6. В данной версии компилятора учтено противоречие, что тень отбрасываемая от модели одновременно же мешает её осветить методами голдсорса (взять освещение под ногами). Так что эта фича теперь вполне юзабельна. И тень есть и освещение в порядке. Ну а для тех, у кого в распоряжении имеется энтитя env_static настроек поболе:
Во первых напомню спаунфлаги для самого env_static:
spawnflags 4 - запрет на отброс тени
spawnflags 8 - запрет на обсчёт повертексного освещения (ксаш-мод, параноя 2)
zhlt_selfshadow 0/1 - включает самозатенение моделей при повертексном освещении. Поскольку вертексное освещение низкочастное, это далеко не всегда выглядит красиво и поэтому выключено по дефолту. Но вы конечно можете прописать намертво в FGD.
zhlt_halflambert 0/1 - некоторые товарищи, ну как наш Креозот например, ставт на карту два полигона с листвой, называют это ky4ka_derevo.mdl и ждут когда оно нормально осветится. Проблема в том, что по блин-фонгу это никогда не осветится нормально. Впрочем даже высокополигональные деревья с листвой из masked-текстуры предпочтительнее освещать при помощи этой опции - будет красивее.
Еще из приятных плюшек для пользователей ксаш-мода: компилятор автоматически даёт оригин-брашы всем энтитям, для которых он умел найти родителя (заполненное поле parent). Это чтобы вручную этим не заниматься. Так же реализовано то, что меня и самого бесило и других тоже. Компилятору теперь абсолютно насрать на те абсолютные пути, прописанные в поле "wad". Точнее говоря, сперва он разумеется ищет их по этому пути. Но если не находит - просматривает окружение мода, базовую, игровую и фаллбэк-папку мода. Информацию о об этих папках он берёт из gameinfo.txt и liblist.gam, если используется для халфы. Обращаю ваше внимание - компилятор не заставляет вас компилить карты непременно в папке mymod\maps, но тогда не будет и теней от моделей и вады он найти тоже не сможет. Да и рефлективность от текстур не будет работать. Вообщем это в ваших же интересах.
Новые параметры командной строки для компиляторов:
CSG
-epsilon <value> используется только в паре с аналогичным параметром у BSP. Значения надо ставить меньше дефолтного. Это для экстремальных случаев, когда геометрия на вашей карте даёт не то лики (хотя вы точно уверены что дырок нет), не то кромсает полигоны и они исчезают. Использовать ОЧЕНЬ ОСТОРОЖНО. Будьте уверены, что это может принести массу проблем, если применять ко всем картам подряд.
BSP
-merge 0/1/2
После того как все фейсы лежащие на одной плоскости уже принадлежат одной ноде, компилятор попытается объединить эти фейсы в один. Не всегда у него это хорошо получается, камрад Ксерокс в своих незвершённых компиляторах реализовал более продвинутый алгоритм, который я и задействовал в своих. По дефолту стоит merge 1 (оригинальный халфовский код). Режим Ксерокса включается при -merge 2, но поскольку это толком не тестировалось, то и вынесено в опцию. Возможно где-то оно сделает только хуже. Проверяйте
VIS
Это не новый параметр, просто хочу обратить внимание. Единственный параметр, который нужен вам у виза, это -fast. Без него будет фуллвиз, но достаточно быстрый + еще некоторые оптимизации, которых нет у китайца.
RAD
-nomodelshadow альтернатива -nostudioshadow для UMHLT.
-balance как я уже и говорил, халфовские компиляторы умножают прямой свет на два, а потом плюсуют индирект. Китаец уверен, что прямой и непрямой свет надо сложить вместе, а уже потом умножить на два. Так или иначе по дефолту освещение считается в халфовском стиле, а этот параметр позволяет задать стиль VHLT (и для вертексного тоже). А параметр -dscale теперь регулирует либо прямой свет (без ключа -balance), либо суммарную яркость (с ключом -balance). В принципе этого достаточно.
Писать еще можно долго, но я полагаю, вы устанете это читать, да и в прямом общении всегда можно раскрыть больше аспектов. А нормальную документацию к релизной версии я оформлю в CHM, ведь это же всего лишь бета и мы собрались её тестировать, правильно? Поэтому пару слов про тестирование и наконец-то ссылка на сами компиляторы. Чтобы избежать захламления этой темы несуществующими ошибками, вы сперва должны убедиться, что проблема не в карте, а именно в моих компиляторах. Для этого вы можете использовать как референсные компиляторы от меня в соседней теме, так и оригинал от китайца, если не доверяете UMHLT. И ваш багрепорт должен соответственно включать в себя описание того, как выглядит баг, на каких компиляторах он лезет, а где его нет. Я не исключаю и обратной ситуации, когда мои тулзы компилируют то, что не может собрать VHLT, например. Замеряйте время работы, сравнивайте расход лимитов, делитесь впечатлениями, задавайте вопросы. Это общая тема для тестирования.
Первый апдейт. Чтобы можно было сравнивать до багфиксов и после старые версии пока не удаляю. Что изменилось:
1. поддержка wadautodetect. Это что-то такое для GoldSource, ксашу это не нужно. Я не проверял, но думаю будет работать.
2. Некоторые исправления с генерацией планесов (самое стрёмное место во всех компиляторах). Ошибки проявляются либо как исчезнувшие на ровном месте полигоны (при чём карта собирается без дырки), либо наоборот карта, которая совершенно точно без дырок, вдруг начинает ликовать. Проверяйте, сравнивайте.
3. Исправлена трасса в раде (где-то могли генериться лишние тени).
4. Отключил домножение лайтмапы на тень, чтобы размытие было посильнее как вы любите. Хотя это спорное дело, возможно потом вынесу в настройку.
Второй апдейт
1. исправлены баги с трассой
2. исправлен баг с большой брашевой энтитей®
Ну чтоже. Вы все этого так долго ждали, и вот наконец первая публичная бета. А те кто не ждал, но всё равно заинтерисовался, может почитать вот эту тему. Сперва немного идеологии, которой я руководствовался при разработке своих компиляторов, ну и ответов на вопрос, чем же меня не устроили VHLT.
Если бы у меня был так или иначе мод под халфу или просто карты под CS 1.6, то меня бы устроил и VHLT. Даже если бы у меня был просто собственный движок и мне бы хотелось прикрутить к нему кое-какие модные фишки, то я бы немного модифицировал VHLT (что я собственно и сделал). Всё дело в том, что компиляторы полны ошибок, т.к. зачастую их писали люди, слабо разбирающися в компиляторах. Китаец сделал много хорошего (ну и спорные вещи тоже), профиксил множество ошибок, однако в его коде невозможно ориентироваться из-за громадного числа переключающих макросов, в которые он обворачивал все устраняемые ошибки и фичи. Плюс еще неравномерное форматирование, оставшееся от ZHLT, где-то табы, где-то пробелы. В этой каше очень тяжело понять где тот код, который сейчас используется, а где тот, который выключен. Ну и со временем накопилась критическая масса лично моих замечаний к VHLT, каких-то ошибок или багов, которые следовало бы исправить, но залезать туда и разбираться в этом нагромождении не было никакого желания. Постепенно пришло понимание что компиляторы всё же придется писать самостоятельно. Не с нуля разумеется, на это нет времени, но и смысла в этом нет тоже. Так или иначе используя весь опыт накопленный в этой области, тестируя и сравнивая различные решения, исправляя то, что так никто и не исправил. Ну а затем, когда база была готова уже начались оригинальные вещи - например повертексное освещение моделей
Технические особенности, основные отличия и преимущества новых компиляторов:
Несмотря на тот факт, что компиляторы делались целенаправленно для Paranoia 2:Savior, в процессе разработки я попытался учесть множество пожеланий и охватить соседние области маппинга, например для первого квейка, ксаш-мода, ну и просто голдсорса.
1. Карты собираются в особом расширенном формате, который тем не менее, если включать особые фичи и не выходить за лимиты прекрасно воспринимается голдсорсом (на самом деле я давно уже не проверял, ну на то это и бета, чтобы мы всё вместе проверили). Некоторые вещи будут работать только на Xash3D, еще некоторые - только на XashXT и P2:Savior, а совсем уж некоторые предназначены специально для паранои. Однако фичей много и я думаю каждый найдет для себя кое-что интересное.
2. Поддержка компиляции уровней от первого квейка. Это заявление не вполне корректно, поскольку компилятор не собирает карты в формат BSP 29, но учитывая что почти все форки квейка преспокойно умеют грузить BSP30, не думаю что это большая проблема. К тому же, как вы понимаете есть и мои собственные римейки квейка и враппер для него же. Поддержка заключается в корректной обработке освещения по квейковски с чётко заданным радиусом, за пределы которого свет не выходит. Так же на некоторых картах квейка присутствуют специфичные ошибки, от которых тот же VHLT впадает в ступор. Это я тоже учёл. Тестирование проводилось на картах от Arcane Dimensions. Так же присутствует поддержка теней от алиас-моделей. В кваке где любят ставить якобы статуи монстров, которые потом внезапно оживают, я полагаю это будет весьма полезная штука. Когда я открою исходники в с лёгкостью сможете полностью адаптировать их непосредственно для кваки, если у кого-то возникнет такая необходимость.
3. Набор некоторых специфичных настроек-расширений, которые будут работать только в Xash3D (ну или где-то еще, если их туда внедрят). Например отвязка разрешения люкселей от скейла текстур и привязка их к мировым юнитам. Это даёт более равномерную сетку и убирает швы. Однако на сложной геометрии типа скал их не рекомендуется использовать. Фича включается прописыванием следующего параметра в worldspawn:
zhlt_worldluxels 0/1/2
Один и два это разные модели лайтмапной матрицы, второй вариант - всегда положительная. Так же следует учитывать что на соотношении люксель к юниту общий объем лайтмапы может уменьшиться, но соответственно немного упадёт и качество. Зато классические динамические лайты из стандартного рендерера перестанут сжиматься на текстурах с разным скейлом.
Из остальных настроек, доступных только в моих компиляторах:
zhlt_nocsg 0/1
Полурабочее решение есть и в UMHLT, но там оно способно лишь глобально выключить CSG для всего мира или энтити. А здесь вы можете задать это для группы мировых брашей, поместив её(группу) в func_group.
Так же разумеется, присутствует поддержка кастомного субдивайда, параметр
zhlt_maxextent 16/64/128
вы можете задавать и другие значения, но обычно в этом нет смысла. Поддержка кастомного разрешения текстур тоже никуда не делась, напоминаю, это
zhlt_texturestep 32/16/8/4/2
Точно так же вы можете задавать и другие числа, но кратные предпочтительнее.
Из недокументированных возможностей
zhlt_forcelightmap 0/1
Мои компиляторы по дефолту не рассчитывают лайтмапы для водных поверхностей, т.к. она всё равно не используется нигде, кроме второй паранои. А эта настройка позволяет рассчитать принудительно.
Из параметров освещения, так или иначе завязанных на освещение модели добавились:
zhlt_modelshadow 0/1
это замена ключу zhlt_studioshadow поскольку мой компилятор умеет освещать и алиас-модели тоже. Здесь есть некоторое неудобство конечно, но я думаю мы еще придём к общему варианту. Напоминаю ключ нужен чтобы включить тень от статичной модели, например в голдсорсе, для CS 1.6. В данной версии компилятора учтено противоречие, что тень отбрасываемая от модели одновременно же мешает её осветить методами голдсорса (взять освещение под ногами). Так что эта фича теперь вполне юзабельна. И тень есть и освещение в порядке. Ну а для тех, у кого в распоряжении имеется энтитя env_static настроек поболе:
Во первых напомню спаунфлаги для самого env_static:
spawnflags 4 - запрет на отброс тени
spawnflags 8 - запрет на обсчёт повертексного освещения (ксаш-мод, параноя 2)
zhlt_selfshadow 0/1 - включает самозатенение моделей при повертексном освещении. Поскольку вертексное освещение низкочастное, это далеко не всегда выглядит красиво и поэтому выключено по дефолту. Но вы конечно можете прописать намертво в FGD.
zhlt_halflambert 0/1 - некоторые товарищи, ну как наш Креозот например, ставт на карту два полигона с листвой, называют это ky4ka_derevo.mdl и ждут когда оно нормально осветится. Проблема в том, что по блин-фонгу это никогда не осветится нормально. Впрочем даже высокополигональные деревья с листвой из masked-текстуры предпочтительнее освещать при помощи этой опции - будет красивее.
Еще из приятных плюшек для пользователей ксаш-мода: компилятор автоматически даёт оригин-брашы всем энтитям, для которых он умел найти родителя (заполненное поле parent). Это чтобы вручную этим не заниматься. Так же реализовано то, что меня и самого бесило и других тоже. Компилятору теперь абсолютно насрать на те абсолютные пути, прописанные в поле "wad". Точнее говоря, сперва он разумеется ищет их по этому пути. Но если не находит - просматривает окружение мода, базовую, игровую и фаллбэк-папку мода. Информацию о об этих папках он берёт из gameinfo.txt и liblist.gam, если используется для халфы. Обращаю ваше внимание - компилятор не заставляет вас компилить карты непременно в папке mymod\maps, но тогда не будет и теней от моделей и вады он найти тоже не сможет. Да и рефлективность от текстур не будет работать. Вообщем это в ваших же интересах.
Новые параметры командной строки для компиляторов:
CSG
-epsilon <value> используется только в паре с аналогичным параметром у BSP. Значения надо ставить меньше дефолтного. Это для экстремальных случаев, когда геометрия на вашей карте даёт не то лики (хотя вы точно уверены что дырок нет), не то кромсает полигоны и они исчезают. Использовать ОЧЕНЬ ОСТОРОЖНО. Будьте уверены, что это может принести массу проблем, если применять ко всем картам подряд.
BSP
-merge 0/1/2
После того как все фейсы лежащие на одной плоскости уже принадлежат одной ноде, компилятор попытается объединить эти фейсы в один. Не всегда у него это хорошо получается, камрад Ксерокс в своих незвершённых компиляторах реализовал более продвинутый алгоритм, который я и задействовал в своих. По дефолту стоит merge 1 (оригинальный халфовский код). Режим Ксерокса включается при -merge 2, но поскольку это толком не тестировалось, то и вынесено в опцию. Возможно где-то оно сделает только хуже. Проверяйте
VIS
Это не новый параметр, просто хочу обратить внимание. Единственный параметр, который нужен вам у виза, это -fast. Без него будет фуллвиз, но достаточно быстрый + еще некоторые оптимизации, которых нет у китайца.
RAD
-nomodelshadow альтернатива -nostudioshadow для UMHLT.
-balance как я уже и говорил, халфовские компиляторы умножают прямой свет на два, а потом плюсуют индирект. Китаец уверен, что прямой и непрямой свет надо сложить вместе, а уже потом умножить на два. Так или иначе по дефолту освещение считается в халфовском стиле, а этот параметр позволяет задать стиль VHLT (и для вертексного тоже). А параметр -dscale теперь регулирует либо прямой свет (без ключа -balance), либо суммарную яркость (с ключом -balance). В принципе этого достаточно.
Писать еще можно долго, но я полагаю, вы устанете это читать, да и в прямом общении всегда можно раскрыть больше аспектов. А нормальную документацию к релизной версии я оформлю в CHM, ведь это же всего лишь бета и мы собрались её тестировать, правильно? Поэтому пару слов про тестирование и наконец-то ссылка на сами компиляторы. Чтобы избежать захламления этой темы несуществующими ошибками, вы сперва должны убедиться, что проблема не в карте, а именно в моих компиляторах. Для этого вы можете использовать как референсные компиляторы от меня в соседней теме, так и оригинал от китайца, если не доверяете UMHLT. И ваш багрепорт должен соответственно включать в себя описание того, как выглядит баг, на каких компиляторах он лезет, а где его нет. Я не исключаю и обратной ситуации, когда мои тулзы компилируют то, что не может собрать VHLT, например. Замеряйте время работы, сравнивайте расход лимитов, делитесь впечатлениями, задавайте вопросы. Это общая тема для тестирования.
Первый апдейт. Чтобы можно было сравнивать до багфиксов и после старые версии пока не удаляю. Что изменилось:
1. поддержка wadautodetect. Это что-то такое для GoldSource, ксашу это не нужно. Я не проверял, но думаю будет работать.
2. Некоторые исправления с генерацией планесов (самое стрёмное место во всех компиляторах). Ошибки проявляются либо как исчезнувшие на ровном месте полигоны (при чём карта собирается без дырки), либо наоборот карта, которая совершенно точно без дырок, вдруг начинает ликовать. Проверяйте, сравнивайте.
3. Исправлена трасса в раде (где-то могли генериться лишние тени).
4. Отключил домножение лайтмапы на тень, чтобы размытие было посильнее как вы любите. Хотя это спорное дело, возможно потом вынесу в настройку.
Второй апдейт
1. исправлены баги с трассой
2. исправлен баг с большой брашевой энтитей®
Вкладення
-
137.9 КБ Перегляди: 307
-
138.2 КБ Перегляди: 295
-
138.9 КБ Перегляди: 337
Останнє редагування:


