Ru/Prop Types Overview

Слово prop (реквизит) на движке Source, как правило, является синонимом энтити "модели". Существуют разные категории пропов, каждая из которых представляет собой модель с конкретными функциями. Они выбираются в соответствии с задумкой автора и имеют определенные компромиссы по функциональности и производительности.

Виды prop-моделей

В нижеследующей таблице перечислены основные виды пропов и их общие характеристики.

Вид энтити	Свойства
prop_detail	Детальная геометрия - статичные, не перемещаемые модели. Не имеют каких-либо физических свойств и данных о столкновениях. Не разбиваются. Не отбрасывают теней. Могут автоматически вставляться назначением типа материала детали. Как правило, не ставятся индивидуально. Наиболее сложная геометрия для визуализации. На старых машинах может не прорисовываться. Примеры: Трава, камни, растения.
prop_static	Статичная геометрия - не перемещаемые модели. Не содержат физических свойств, кроме столкновений, не разбиваются. Не имеют соединений и анимации. Отбрасывают тени. Нересурсоемкая геометрия для визуализации. Примеры: трубы, светильники, камни, телефонные столбы.
prop_physics	Модели с внедренными физическими свойствами. Перемещаются и соударяются с помощью системы физики твердого тела. Прикрепляются к другим физическим объектам с помощью шарниров или других способов сцепления. Разбиваются, если получат достаточно повреждений, указанных в настройках. Отбрасывают динамические тени. Ресурсоемки для перемещений и визуализации. Работают хуже с настройкой sv_turbophysics. Примеры: бочки, мелкий мусор, мебель.
prop_ragdoll	Физические пропы скелетов моделей. Имеют все свойства физических пропов и физику твердого тела. Ресурсоемки для передвижения и визуализации. Примеры: Трупы, части картонных коробок, матрасы.
prop_dynamic	Модели, которые могут быть размещены по иерархии, имеют суставы и проигрывают анимацию. Разбиваются, если получат достаточно повреждений, указанных в настройках. Прикрепляются к другим объектам. Отбрасывают динамические тени. Обрабатываются тяжелее статичной геометрии, но легче физической. Примеры: Роботы, техника, анимированные модели.
prop_physics_multiplayer	Физичесике пропы, имеющие упрощенную физику столкновений для многопользовательских игр. Дают меньшую нагрузку на сеть, чем стандартные физические пропы, разгружая канал многопользовательской игры. Работают лучше с настройкой sv_turbophysics.
prop_physics_override	Специальный тип, используемый для изменения встроенных в модель свойств. Нагружает так же, как и prop_physics.
prop_dynamic_override	Специальный тип, используемый для преобразования моделей prop_static в prop_dynamic. Нагружает так же, как и prop_dynamic.

Примеры некоторых пропов можно посмотреть на SDK-карте mapsrc\sdk_prop_types.vmf.

Ограничения в использовании

Чтобы не перегружать карту, в Source встроен ограничитель производительности используемых моделей. Например, у вас стоит физическая бочка, значит не должно быть такой же статичной бочки, если нет задачи сделать именно так. Если вы используете неправильный вид модели, то игра удаляет её с карты.

В Хаммере, в Model browser, на вкладке "info" есть три флажка. Это: "physics" (физика), "static" (статика), и "dynamic" (динамика)

• Если стоит "physics", модель может быть только prop_physics или prop_ragdoll, или же prop_dynamic_override.
• "Static" используется только с prop_static.

Если вы используете неправильный вид модели prop_static, то получите ошибку компиляции в журнале :

Error! prop_static using model "[model]", which must be used on a dynamic entity (i.e. prop_physics). Deleted.

или:

Error! To use model "[model]"
      with prop_static, it must be compiled with $staticprop!
Error loading studio model "[model]"!

Вы получите консольную ошибку в игре, если поместите prop_physics не как физику:

prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED.

Override Энтити

prop_dynamic_override

Большинство моделей будет работать с prop_dynamic, за исключением физических моделей. Если вы хотите использовать физическую модель без всей ее физики, используйте prop_dynamic_override.

prop_physics_override

Props which are to be physically simulated must have prop data compiled into them. The entity prop_physics_override allows you to input this data from Hammer, and allows you to use most models as a physics prop.

Создание Пропсов

Специальный qc код сделает вашу модель подходящей для некоторых типов пропсов, и неподходящей для других.

	prop_detail	prop_static	prop_dynamic	prop_physics	prop_ragdoll
$staticprop	Да	Да	Опционально	Опционально	Нет
prop_data	Нет	Нет	Нет	Да	Да
$collisionjoints	Нет	Нет	Опционально	Нет	Да
$collisionmodel	Нет	Опционально	Опционально	Да	Нет

Примечания: "Да" или "Нет" означает, что проп может быть удален из игры, либо просто не работать, если сделан неправильно. "Опционально" означает, что код будет работать и, как правило, это хорошее решение. Кликните по ссылке для инструкций по использованию соответствующего .qc кода и что он делает.

Prop_detail модели могут использовать материалы только с UnlitGeneric шейдером. Смотри Detail props для более полной информации.

$staticprop обладает эффектом разрушения всех костей(связей) и уничтожает все скелетные анимации. Если проп не требует костей(связей) или анимации, staticprop стоит выбрать для оптимизации. В Hammer's Model browser, отмеченный флажок "static" означает, что $staticprop может быть использован.

Characteristics

prop_detail

• Can have 10's of thousands of them in a level. (64,000 limit in Left 4 Dead)
• Can be .MDLs or sprites. Sprites are much faster to render than .MDLs.
• Can be placed inside the Hammer editor or by adding a material property %detailtype to a .vmt file which causes Vbsp to automatically generate detail props over particular materials (described below).
• Can never collide with them.
• Are lit with a constant color (for optimization)
• Don’t affect lightmaps in the world.
• Automatically fade out when they exceed a particular distance from the player (controlled by the console variables cl_detaildist and cl_detailfade).
• Will probably not ever be rendered on low-end hardware.
• Must use models compiled with $staticprop in their .qc file.
• Have no network overhead + very low memory usage.
• Is not a real entity, has no inputs or outputs.
• May not have animations.
• Can not be hierarchically attached to other entities.
• From a visibility standpoint, they are assumed to be points.

prop_static

• Can have thousands of them in a level.
• Can be placed inside the Hammer editor.
• Can have collision associated with them.
• Will affect lightmaps in the world – can cast lightmap shadows.
• Will be vertex lit like standard studio models.
• Will use LOD system.
• User selectable as to whether the prop is rendered on low end hardware.
• Fade distances can be set in Hammer editor.
• Must use models compiled with $staticprop in their .qc file.
• Have no network overhead + very low memory usage.
• Is not a real entity, has no inputs or outputs.
• May not have animations or joints.
• Can not be hierarchically attached to other entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.

prop_dynamic

• Can have hundreds of them in a level.
• Can be placed inside the Hammer editor.
• Can have collision associated with them.
• Will not affect lightmaps in the world, but they can cast dynamic shadows.
• Will be vertex lit like standard studio models.
• Will use LOD.
• Will render on low-end hardware.
• Fade distances can be set in Hammer.
• May use models that are not compiled with $staticprop.
• May have animations.
• Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
• Is a real entity with inputs and outputs.
• Can be hierarchically attached to other entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.
• From a visibility standpoint, they are assumed to be boxes.

prop_physics

• Can have tens to hundreds of them in a level, depending on complexity.
• Can be placed inside the Hammer editor.
• Must have collision associated with them.
• Will not affect lightmaps in the world, but they do cast dynamic shadows.
• Will be vertex lit like standard studio models.
• Will use LOD system.
• Fade distances can be set in Hammer editor.
• Are faded earlier on low-end hardware unless settings changed.
• May use models that are not compiled with $staticprop.
• May have animations.
• Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
• Is a real entity with inputs and outputs.
• Can not be directly hierarchically attached to other entities.
• Can be constrained to other entities by various physics constraints entities.
• Optimal from a visibility standpoint, it uses the convex hull of the object.
• From a visibility standpoint, they are assumed to be boxes.
• Additional characteristics?

prop_ragdoll

• Same as prop_physics, but can use skeletons for ragdoll physics.
• Has very high network overhead.

See also

• Automatically emitting prop_details on a material