Propper++

Инструмент Propper++ в Hammer++ позволяет превращать брашворк в модели, или объединять разные модели в одну. Он служит как полная замена устаревшему Propper.

Интерфейс Propper++

Установка

Перед использованием инструмента Вы должны указать StudioMDL в Tools -> Options -> Build Programs -> MDL executable. Это компилятор, который сделает модели для движка.

Предупреждение: Garry's Mod ещё не имеет 64-битного StudioMDL. Вы должны использовать 32-битный, который находится в папке bin вместо bin/win64. Если Вы получите ошибку с кодом 0x2, то это и есть причина.

Предупреждение:В Team Fortress 2 64-битный StudioMDL не работает. Вы должны использовать 32-битный, который находится в папке bin вместо bin/win64.

Базовое использование

Браши

В первую очередь выберите браши, которые Вы хотите превратить в модели. Если Вы хотите превратить их в одну модель вместо нескольких, то сначала нужно их сгруппировать либо через инструменты групп, либо через превращение их в одну энтити. Затем откройте Propper++ в меню Tools -> Propper++ или используя сочетание клавиш Ctrl + Shift + P.

Вы увидите множество опций. Практически все из них неважны, кроме Model Path + Name наверху. Имя в конце станет именем, данным Вашей модели. Поменяйте его на что-нибудь подходящее для модели, например moykrutoystul.

Нажмите Build + Compile и браши должны быть успешно превращены в модель после того, как компилятор закончит работу. Превращенная брашевая геометрия будет сохранена в визгруппу Propper. Это можно использовать, чтобы сохранить или восстановить изначальную геометрию при необходимости.

Примечание:Запомните! Так как это пользовательские ассеты, Вам необходимо убидеться, что они запакованы в карту когда Вы делитесь ей с другими людьми. Такие инструменты, как CompilePal или VIDE могут помочь Вам с этим.

Изменение размера пропов

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

Чтобы изменить размер prop_static во всех направлениях одновременно, превратите его в prop_dynamic для того, чтобы поменять Model Scale, или добавить значение modelscale, выключив SmartEdit.

Совет:В Hammer++ размер выделенного в 3D окне пропа можно менять, зажав Ctrl и вращая колёсиком мыши. Зажатие Shift будет изменять размер не по 0.5, а по 0.05.

Альтернативно, смените значение Scale в меню Propper++. Вы можете использовать отрицательные значения чтобы отразить проп по какой-либо из осей.

Объединение брашей и моделей

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

Продвинутое использование

Редактирование перед компиляцией

Иногда изменение сгенерированных файлов модели может быть полезно, например чтобы добавить дополнительные параметры, такие как $texturegroup, или чтобы изменить меши. Propper++ позволяет это, используя двухэтапный процесс: Build, а потом Compile. Обычно оба этих шага запускаются одновременно, но их так же можно запускать вручную.

• Build сгенерирует файлы QC и SMD для модели.
• Compile отправит сгенерированные файлы в компилятор, а потом заменит выделение (если это включено).

Таким образом, вы можете нажать Build-Only, отредактировать файлы, а потом Compile-Only, чтобы скомпилировать модель.

Совет:Используйте кнопку Explore чтобы быстро открыть папку, содержащую сгенерированные файлы.

Передвижение ориджина модели или точки освещения

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

Если использовать инструмент Propper++ на брашевой энтити, и у энтити есть параметр origin, то будет использовано это значение.

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

Подтвердить:Что насчёт использования инструмента на группах энтити, возможно включающих пропы? Может ли ориджин быть указан каким-либо другим методом?

Добавление скинов

Multiple_Skins_for_a_Single_Model(en)

Нужно сделать: Туториал про добавление скинов в QC

Массовая конвертация

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

Дисплейсменты

Дисплейсменты(en) так же можно конвертировать, используя Propper++. Однако в отличие от брашей, для дисплейсментов не будет построена коллизия. Это намеренно, так как автоматически сгенерированная модель коллизии для дисплейсментов была бы очень дорогой(en) и возможно вызывала бы задержки на сервере (каждый треугольник должен быть отдельной невогнутой частью коллизии). Если Вам требуется коллизия для дисплейсментов, постройте им упрощённые версии из брашей и укажите их в параметре Entity name as physics mesh.

Ещё одно ограничение заключается в том, что смешанные текстуры не появятся после конвертации, так как модели не поддерживают повертексное смешивание текстур.

Объединение статичных пропов

Сравнение производительности 240 статичных пропов деревьев на пустой карте: не используя настроек, используя расстояние пропадания и объединение Propper++.

Скопление коробок, показанное с использованием r_colorstaticprops 1. Это хороший кандидат для объединения, чтобы сократить 3 запроса на отрисовку до 1.

Propper++ так же может быть использован для объединения пропов с целью оптимизации, похожего на Static Prop Combine(en) в более новых играх. Демонстрация прироста производительности от объединения статичных пропов в один находится справа.

Объединение улучшает производительность, уменьшая количество запросов на отрисовку. Вкратце: запросы на отрисовку - метод, которым пользуется процессор, чтобы сказать видеокарте что и как нужно отрисовать. Эта коммуникация дорогая и современные игры обычно стараются как можно больше сократить количество запросов на отрисовку. Каждый проп в игре будет создавать новый запрос на отрисовку. Если в пропе несколько материалов, то каждый из них будет создавать новый запрос на отрисовку. Объединяя пропы, количество таких запросов уменьшается. Со слов Valve: использование объединения статичных пропов на картах CS:GO (которые используют очень много статичных пропов) улучшило производительность на 40%.

При поиске моделей для объединения, убедитесь, что Вы следуете этим принципам:

• Вы должны объединять только те модели, которые делят одни и те же материалы - иначе пользы от объединения не будет. Разные материалы всё ещё будут создавать новые запросы. Например, не объединяйте дерево с коробкой, но объединяйте коробку с другими такими же коробками.
• Объединяйте модели, которые находятся рядом. Объединение моделей расширит границы пропа и сделает отрезку его рендера ареапорталами или чем-либо ещё менее вероятной.
• Старайтесь не объединять модели, которые имеют коллизию и не находятся близко, так как физический движок не сможет эффективно оптимизировать такую модель. Если Вам нужно такое сделать, то отключайте коллизию или делайте упрощённую физическую модель самостоятельно.
• Не объединяйте объекты, проходящие через или под тень, если модели не поддерживают повертексное освещение (т.е. ни один из материалов не имеет $bumpmap(en) или $phong(en)). Объединенный проп будет использовать освещение только из своего центра и по этой причине может смотреться странно в месте, где проходит тень. Альтернативно, разделите объединенный проп напополам по границе тени, чтобы обе стороны получали правильное освещение.

Чтобы легко находить скопления пропов, которые можно объединить, используйте команду r_colorstaticprops 1 в игре. Каждый уникальный цвет пропа означает, что он создаёт новый запрос на отрисовку. После объединения пропов, Вы заметите, что они имеют один цвет (что хорошо).

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

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

Примечание:Движок имеет ограничение по количеству вертексов в меше. Propper++ автоматически разделяет модель на разные меши после 65535 вертексов.

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

Освещение статичных пропов

В некоторых играх prop_static(en) поддерживает использование лайтмапа, сгенерированного VRAD(en). Однако у этой функции есть большие ограничения:

• Пропы с пересекающейся UV(en)-развёрткой или несколькими материалами не могут быть правильно освещены.
• Брашевая геометрия, превращённая в модели, не может быть правильно освещена в связи с искажённой UV(en)-развёрткой.
• Материалы, использующие $bumpmap(en) или $phong(en) не могут быть освещены.

Функция ```Lightmap Atlas``` обходит все эти ограничения. Она берёт выбранные модели и (или) браши и генерирует одну непересекающуюся UV(en)-развёртку (или "атлас") для всей модели, а потом накладывает на неё текстуры. Она так же автоматически убирает бампмапы и фонг с материалов.

Чтобы использовать эту функцию, включите Generate atlas.

Измените ширину и высоту атласа на своё усмотрение. Внешний вид будет зависеть от самой геометрии, от количества объединенных объектов и так далее, так что экспериментируйте с этим. Оставляйте разрешение степенью двойки. Более высокие разрешения будут иметь более хорошее качество текстур и больший вес. Это не размер лайтмапа - он указывается отдельно в настройках prop_static(en).

Есть 4 формата сжатия на выбор: DXT1, DXT5, RGB888 и RGBA8888. Форматы DXT сжаты, остальные - нет и поэтому имеют улучшенное качество, но гораздо больший размер файла. DXT1 и RGB888 не поддерживают прозрачность, сохраняя размер файла. Вы не должны использовать DXT5 или RGBA8888, если Вам не нужен альфа-канал для чего-либо (например для маски для $envmap(en))

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

После построения и компиляции модели, она будет готова для лайтмапного освещения. Смотрите статью про prop_static(en) для деталей. Если текстура смотрится слишком "мыльно", увеличьте разрешение атласа или уменьшите количество объединяемых пропов.

Текстуры-атласы сохраняются в Material Path + Model Name, если Вы хотите на них посмотреть.

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

Предупреждение:Браши занимают много пространства в атласе, так как они большие и повторяющиеся. Это может привести к тому, что всё остальное (например модели) станет непропорционально размытым в атласе. Желательно использовать модели. Если Вам нужно использовать браши, используйте nodraw на как можно большем количестве сторон, чтобы они не появлялись в атласе.

Настройки

• Model Path + Name

Это путь и название модели, которая будет сгенерирована. он находится относительно папки models в Вашей игре. Например, в Garry's Mod, "propper/moykrutoystul" сгенерирует модель по этому пути:

.../GarrysMod/garrysmod/models/propper/moykrutoystul.mdl

Все маркеры $vmf будут заменены на название текущего VMF(en). Это удобно для организации файлов и для ограничения конфликтов между картами, если они делят модели с одинаковыми названиями.

• Add incremental suffix if already existing MDL name is found

Когда включено, то при нахождении MDL(en) с таким же названием, как в Model Path + Name, к названию модели будет добавлен цифровой номер (_0, _1 и так дале). Этот номер будет добавляться, пока не будет найдено неконфликтующее название. Это удобно для предотвращения случайной перезаписи существующих моделей, так как после этого файлы было бы невозможно восстановить. Отключите эту опцию, если Вы хотите перезаписать модель новыми файлами (или просто удалите существующую модель).

• Source file directory

Это место, где будут расположены файлы, необходимые для модели. Как и выше, может быть либо относительно директории игры, либо полным путём до любого места на Вашем компьютере. Этот параметр так же поддерживает маркеры $vmf. Пример с Garry's Mod: "modelsrc/propper/rpassets" положит исходные файлы SMD(en) и QC(en) в эту директорию:

.../GarrysMod/garrysmod/modelsrc/propper/rpassets

• Material path

Это папка, в которую будут положены сконвертированные материалы. Брашевые материалы обычно используют шейдер LightmappedGeneric, несовместимый с моделями, так что Propper++ конвертирует эти шейдеры в VertexLitGeneric. Как и ранее, этот параметр относителен директории игры, но внутри папки materials. Поддерживает маркеры $vmf. Пример с Garry's Mod: "models/propper/rpassets" сгенерирует материалы в эту директорию:

../GarrysMod/garrysmod/materials/models/propper

• Entity name as physics mesh

Этот параметр позволяет Вам указать, какая именная энтити должна быть использована как модель коллизии. Это полезно для создания упрощённых физических моделей для сложной геометрии. Поставив этот параметр на $self, модель будет использовать выделение как физическую модель. Если оставить этот параметр пустым, то коллизии не будет. Имена энтити не будут работать, если выделить несколько групп объектов.

• Entity classname

Если включен параметр Creaty entity after compile, то выделение будет заменено энтити с этим классом и сгенерированной моделью.

• Surfaceprop

$surfaceprop(en) модели. Если оставить пустым, то материал, который покрывает самую большую площадь, будет выбран как материал поверхности. Если в выделении есть модели, то будет использован $surfaceprop(en) той модели, которая появляется больше всех.

• Scale

Размер по осям X, Y и Z для модели. Отрицательные значения поддерживаются и применят исправление, чтобы перевернуть стороны в правильное направление.

• Mass

Заменяет массу модели. Если оставить пустым, то масса будет автоматически вычислена компилятором, используя $automass(en).

• Smoothing angle

Сглаживает нормали вертексов угол между которыми меньше, чем значение этого параметра. Похож на -smooth в VRAD(en). 0 отключает сглаживание. Полезно для круглых форм, как цилиндры.

• Relocate materials

Если включено, передвигает брашевые материалы в папку, указанную в Material path. Это предотвращает замену обычных материалов на новые.

• Rename shaders

Если включено, то шейдеры LightmappedGeneric(en), WorldVertexTransition(en) и Water(en) будут переименованы в VertexLitGeneric(en).

• $concave collision

Включает $concave(en) (вогнутые) модели коллизии. Если выключено, то компилятор сделает shrinkwrap на модели, чтобы создать новую модель коллизии.

• Remove bad collision faces

Маленькие или тонкие стороны брашей могут вызывать проблемы при компиляции коллизии. Этот параметр автоматически удалит такие стороны (добавив $remove2d в $collisionmodel(en)).

• Skip nodraw faces

Пропускает добавление сторон, покрытых текстурой tools/toolsnodraw, к видимой геометрии. Они всё ещё будут добавлены к модели коллизии.

• Wait for keypress after compile

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

• Create entity after compile

Если включено, то заменит выделение новой энтити со сгенерированной моделью.

• Move selection to 'Propper' visgroup

Если включено, то выделение сохраняется в визгруппу под названием "Propper" после компиляции.

• $casttextureshadows

Добавляет команду $casttextureshadows(en) в QC(en). Полезно для работы теней от полупрозрачных поверхностей в VRAD(en) (с -textureshadows) без ручного добавления модели в lights.rad(en)

• Lightmap Atlas

Смотрите секцию про продвинутое использование выше.

Параметры

Propper++ использует следующие параметры:

Origin (origin) <origin(en)>

Если в данной группе есть только одна энтити, то параметр Origin будет использован, как ориджин получившейся SMD-модели.

Pitch Yaw Roll (Y Z X) (angles) <angles(en)>

Поворачивает получившуюся SMD-модель.

Name (targetname) <targetname(en)>

Lighting Origin (lightingorigin) <targetname(en)>

Выставляет $illumposition(en) на основе положения указанной именной энтити.

Model (model) <model path(en)>

MDL(en) для использования.

Skin (skin) <integer(en)>

Скин(en) используемой MDL(en).

Bodygroup (body) <integer(en)>

Бодигруппы(en) модели(en).

Uniform Model Scale (modelscale) <float(en)>

Масштабирует получившуюся SMD-модель по всем осям.