Полигональная сетка (Mesh)

Source

В Source термин "сетка(en)" обычно используется для обозначения отображаемой геометрии, а не габаритов столкновений модели. Иногда его называют облачением envelope или обликом skin. Отображаемый облик(en) проецируется(en) на сетку(en), которая облачается(en) на скелет(en).

Для каждой отображаемой модели требуется как минимум одна полигональная сетка сетка тела, но она также может содержать дополнительные сетки. Каждая из этих сеток также может иметь несколько версий, оптимизированных для замены уровней детализации.

Все данные сетки экспортируются из редактора моделей(en) в файлы SMD(en), DMX(en), OBJ(en) или FBX(en), а затем компилируются в двоичные файлы модели VVD и VTX. Данные сетки состоят из следующих составляющих для каждого треугольника :

• Данные смещений(en) : Координаты вершин (относительно назначенной родительской кости(en)),
• Данные сглаживания(en) : Вектор нормали вершинs (относительно назначенной родительской кости(en)),
• Данные облика(en) : Координаты вершин UV-разметки(en) и имена основного облика(en),
• Данные облачения(en) : Значения развесовки(en) вершин и родительской кости(en).

Совет:See SMD file format(en) for exactly how this data is stored in the triangles block of a "Studio Model Data" file.

Сетка тела

The "default" body mesh is rendered unless substituted by a specific LOD mesh. Sometimes it is called the Reference mesh because it is defined in the model's Reference.smd(en) and compiled via the $body(en) or $model(en) QC command.

Основная сетка тела (body mesh) отображается по умолчанию, если она не заменена другой сеткой с низким уровнем детализации. Иногда ее называют отображаемой сеткой (Reference mesh), потому что она определена в файле Reference.smd(en) модели и была скомпилирована с помощью QC-команды $body(en) или $model(en).

Дополнительные сетки

Optional Sub-meshes can be switched on and off at runtime. Like the body mesh, they are enveloped(en) to this model's Skeleton, and will deform (stretch and flex) as if part of the Default mesh. Specific pieces of clothing are good candidates for switchable sub-meshes; eg different types of body armor or headgear. By contrast Sub-models (eg weapons) can be attached to specific $attachment(en) points on this skeleton, but they remain enveloped to their own skeleton; their geometry will be moved by this skeleton but will not be deformed by it.

• The $bodygroup(en) configuration allows any number of sub-meshes (SMD(en)s) to be added to the Default mesh. By setting up multiple $bodygroup(en)s sub-mesh switching can be triggered by (code-level) events.
• Whereas "Alternative Skins" replace the Default Skin, Optional Meshes do not replace the Default Mesh.
• Sub-meshes do not affect the model's collision model(en).
• (
  Нужно сделать: $model(en)'s face mesh for facial animation ?
  )
• Sub-meshes must be exported in separate .smd files to the body mesh, but they must be enveloped(en) to the same skeleton so they align correctly with the model (see $bonemerge(en)).

Сетка низкой детализации (LOD mesh)

Source's LOD system(en) allows a "cheaper" (simplified) version of the Default mesh(es) to be rendered at a distance where the loss of "expensive" detail is not noticeable to the Viewer. Any number of replacement LOD_meshes can be made from pared-down Default meshes, and compiling the lod.SMDs via the $lod(en) configuration. A Default mesh is used when no LOD mesh is active; we could say it amounts to an "lod0" Mesh. See Creating LOD Models(en).

Source 2

Неполная

This article or section is a stub. You can help by expanding it.

В Source 2, BSP элементы больше не применяются, и карты теперь создаются с использованием сеточной геометрии.

Устранение неоднозначности

• A Model is a functional set of components, including whatever Skin, Mesh, Skeleton, Collision geometry, associated Animations, Sounds, Physics properties, etc. data it needs to fulfil a given role. Often a particular SMD(en) or Studiomodel(en) file is referred to as a model to distinguish it from an animation or a brush(en); for example the "reference model" usually refers to the reference.smd(en), whereas all "$collisionmodel" data (including the physbox.smd data and other parameters) is compiled to the PHY(en) file. Studiomodel(en) is only ever used to refer to the fully compiled model used in the Source Engine, Hammer, HLMV, etc. A particular Studiomodel is usually specified by modelname.mdl, because the MDL file acts as an index of the other data files a Studiomodel needs in order to function (ie its MDL, PHY, VVD, VTX Geometry data and VMT Skins).
• In Source, the term Collision Hull is preferred to Collision Mesh because every piece of 3D collision geometry must be a Convex Hull, whether its vertex geometry happens to be defined (in uncompiled code) by a simple BoundingBox Constructor or the SMD triangles format. In order to maintain its convexity, the Hull's vertex geometry must also be Rigid, ie not deformable. A Concave Collision Model consists of rigid system of (overlapping) rigid Hulls, a Jointed Collision Model consists of a flexible system of rigid Hulls which are displaced but not deformed by skeletal articulation. So while a "Collision Hull" is always a rigid convex hull a "Rendered Mesh" is always a deformable and indentable triangle mesh. Even rectangular world brushes are "split" into triangles before they are rendered (because GPU pipelines are optimised to process triangles).