Обзор типов объектов

From Valve Developer Community
Revision as of 19:06, 17 October 2014 by Cocu xep (talk | contribs) (Creating Props)

Jump to: navigation, search
English 简体中文


Слово prop В Движке Source, является синонимом слово "модель" коим и является. Ниже приведены все типы "пропов", каждай тип имеет свой функционал и предназначение.

Типы объектов(пропов)

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

Модель Энтити Свойства
prop_detail Detail geometry - Статичные модели, которые не двигаются. Не имеет физ. свойств и коллизии. Не ломаются. Без теней. Can be automatically placed by assigning a detail type to a material. Generally not placed individually by level designers. The least expensive geometry to render. These may not even be rendered on low-end machines.


Примеры: Grass, rocks, plants.

prop_static Статический геометрия - модели, которые не двигаются. Не содержит физические свойства, кроме столкновений, и не могут ломаться. Не может иметь любые соединения или анимации. Casts lightmap shadows. Нересурсоемкая геометрия для рендеринга.


Примеры: pipes, light fixtures, rocks, telephone poles.

prop_physics Models with built-in physical properties. Moves and collides using the rigid-body physics system. Can be constrained to other physics objects using hinges or other constraints. It can also be configured to break when it takes enough damage. Casts dynamics shadows. Expensive to move and render. Works worse with sv_turbophysics set.


Примеры: barrels, small debris, furniture.

prop_ragdoll Physics props with ragdoll physics skeletons. Have all the properties of physics props and can also use the rigid body ragdoll physics system to have multiple colliding or bending parts. Very expensive to move and render.


Примеры: Corpses, multi-piece cardboard boxes, mattresses.

prop_dynamic Models that can be placed in hierarchy and can have joints and play animations. Can also be configured to break when taking enough damage. Can be hierarchically attached to other objects. Can cast dynamic shadows. More expensive than static geometry, less expensive than physics geometry.


Примеры: Robotic arms, machinery, models animated in cut scenes.

prop_physics_multiplayer Physics props using a simplified physics collision system designed for multiplayer games. Have less networking overhead than standard physics props, necessary for the bandwidth-limited environment of multiplayer games. Works better with sv_turbophysics set.
prop_physics_override Special prop type used to override the properties built into the model. Has identical cost of a prop_physics.
prop_dynamic_override Special prop type used to convert a model that is designed to be used as a prop_static, and giving it the properties of a prop_dynamic. Has identical cost of a prop_dynamic.

See the Source SDK sample map mapsrc\sdk_prop_types.vmf for examples of some of the prop types in use.

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

To ensure consistency in the behavior of props across maps, Source restricts what models may be used for each prop type. For example, a barrel which is physics-based in one map should not be static in another, unless there is very good reason for it to be so. If you use the wrong prop type with a model, the game may delete the prop from your map.

In Hammer's Model browser, There are three check marks in the "info" tab. These are: "physics", "static", and "dynamic"

  • If "physics" is checked, the model may only be used as prop_physics or prop_ragdoll, or as prop_dynamic_override.
  • "Static" is required to use with prop_static.

You will get an error in your compile log if you use the wrong type of model for a prop_static:

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

or:

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

You will get a console error in-game if you place a prop_physics which is not set up for 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.

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

Specific qc code will make your model suitable for some types of props, and unsuitable for others.

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

Примечания: "Да" или "Нет" означает, что проп может быть удален из игры, либо просто не работать, если сделан неправильно. "Опционально" означает, что код будет работать и, как правило, это хорошее решение. Click the links for instructions on how to use the corresponding .qc code and what they do.

Prop_detail models may only use materials with the UnlitGeneric shader. See Detail props for more info.

$staticprop has the effect of collapsing all bones and nullifying all skeletal animations. If your prop needs no bones or animations, staticprop is a worthwhile optimization. In Hammer's Model browser, the check box marked "static" lets you know that $staticprop has been used.

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