|
|
| (40 intermediate revisions by 12 users not shown) |
| Line 1: |
Line 1: |
| {{lang|Half-Life:_Alyx_Workshop_Tools/Introduction|title = 介绍}} | | {{LanguageBar|title = Half-Life: Alyx 创意工坊工具集/概述}} |
| {{translate}}
| |
| {{HLATools topicons}}
| |
|
| |
|
| 本文旨在解释《半衰期：爱莉克斯》游戏引擎和开发工具背后的一些基本概念。使用过《[[SteamVR/Environments|SteamVR Home]]》创意工坊工具的用户将拥有领先优势，因为这些工具采用的框架与《[[Dota 2]]》等其他游戏所提供的框架相同。不同的是：[[Half-Life: Alyx Workshop Tools/Lighting|照明]]得到了极大的改善，其中ModelDoc是模型编辑器的完全修订版，标准着色器有所不同，并且还有更多的实体和内容可供使用。尽管并非全部都能直接适用，但该Wiki上的[[SteamVR/Environments|SteamVR Home创意工坊工具]]文档仍然可以为制作《半衰期：爱莉克斯》插件的人们提供一些有用的信息。 | | |
| | 本文旨在解释《半衰期：爱莉克斯》游戏引擎和开发工具背后的一些基本概念。使用过《{{L|SteamVR/Environments|SteamVR Home}}》创意工坊工具的用户会有一定优势，因为这些工具采用的框架与《{{L|Dota 2}}》等其他游戏所提供的框架相同。不同的是：{{L|Half-Life: Alyx Workshop Tools/Lighting|光照系统}}得到了极大的改善，其中ModelDoc是模型编辑器的全面改进版，标准着色器有所不同，并且还有更多的实体和内容可供使用。尽管并非全部都能直接适用，但本Wiki上的{{L|SteamVR/Environments|SteamVR Home创意工坊工具}}文档仍然可以为制作《半衰期：爱莉克斯》插件的人们提供一些有用的信息。 |
|
| |
|
| == 启动《半衰期：爱莉克斯》创意工坊工具 == | | == 启动《半衰期：爱莉克斯》创意工坊工具 == |
|
| |
|
| [[Half-Life:_Alyx_Workshop_Tools/Creating_an_Addon|创建插件]]指南！
| | 请查看{{L|Half-Life: Alyx Workshop Tools/Creating an_Addon|创建插件}} |
|
| |
|
| == 插件, 以及内容和游戏文件夹 == | | == 插件, 以及content和game文件夹 == |
|
| |
|
| 插件是一组文件，这些文件依靠于基础游戏上，其概念与Source 1的mod相似，但允许在运行时交换插件。 您的文件将分为两种类型-源文件（原始文件）和成品文件（处理或编译后的文件）。 | | 插件是一组文件，这些文件依靠于基础游戏上，其概念与Source 1的mod相似，但允许在运行时更改插件。 您的文件将分为两种类型-源文件（原始文件）和编译文件（处理或编译后的文件）。 |
|
| |
|
|
| |
|
| 源文件位置
| | 原始文件位置 |
| * <code>\Steam\steamapps\common\Half-Life Alyx\content\hlvr_addons\your_addon_name</code> | | * {{Code|style=2|\Steam\steamapps\common\Half-Life Alyx\content\hlvr_addons\your_addon_name}} |
|
| |
|
|
| |
|
| 成品文件位置:
| | 编译文件位置: |
| * <code>\Steam\steamapps\common\Half-Life Alyx\game\hlvr_addons\your_addon_name</code> | | * {{Code|style=2|\Steam\steamapps\common\Half-Life Alyx\game\hlvr_addons\your_addon_name}} |
|
| |
|
|
| |
|
| 当您将插件上传到创意工坊时，内容文件夹将不会重新分发，而游戏文件夹中的数据将打包到VPK的文件中。
| | 当您将插件上传到创意工坊时，content目录将不会上传，而game目录中的数据将打包到VPK文件中。 |
|
| |
|
| == 内容编辑 == | | == 资产编译 == |
|
| |
|
| Source 通常以不太适合重新分发或快速加载和呈现的格式保存。例如，纹理可以是一个Photoshop文档，其中包含数十个图层，这些图层包含数百兆字节，然后将其编译成针对引擎优化的格式，以尽可能快地进行渲染。它会丢弃所有不需要的数据（例如，图层或标记数据），并将其压缩为渲染系统的着色器所要求的形式（在显卡上运行的小程序，负责渲染图形？）使它适合于尽可能快速有效地加载和显示。
| | Source引擎的资产通常以不太适合重新分发或快速加载和呈现的格式保存。例如，纹理可以是一个Photoshop文档，其中包含数十个图层，这些图层包含数百兆字节，它们将被编译成针对引擎优化的格式，以尽可能快地进行渲染。它会丢弃所有不需要的数据（例如，图层或标记数据），并将其压缩为渲染系统的着色器所要求的形式（在显卡上运行的小程序，负责处理屏幕上所看到的像素）使它适合于尽可能快速高效地加载和显示。 |
|
| |
|
| 内容文件夹中的所有文件都是友好的格式，可以在《半条命：Alyx》工具中创建，而游戏文件夹中的文件通常由内容中的文件产生，并且都直接由引擎使用。
| | content文件夹中的所有文件都是对用户友好的格式，有的是被用户放在这里，有的则是在《半衰期：爱莉克斯》工具中创建，而game文件夹中的文件通常由content文件夹中的文件编译后产生，并且都能被引擎直接使用。 |
|
| |
|
| 通常，当磁盘上的内容发生更改时，引擎将自动重新编译，从而允许用户将文件保存在Photoshop中，并使所有内容都在“VTF Editor”和“Hammer”中进行更新。如果没有发现有变更，还可以强制重新编译。
| | 通常，当磁盘上的内容发生更改时，引擎将自动重新编译，从而允许用户在Photoshop中保存文件，并使所有内容都在材质编辑器和地图编辑器中进行更新。如果引擎没能发现变更，也可以强制重新编译。 |
|
| |
|
| == Basic Files - Textures, Materials, Models, and Maps == | | == 基础文件 - 纹理, 材质, 模型和地图 == |
|
| |
|
| * '''Textures''' – An image of some bricks on a wall for example, or a normal map (a description of precise surface direction, for imitating extra detail), or one of numerous other possibilities. Textures are usually made in software like Adobe Photoshop, The GIMP or similar and are automatically recompiled whenever content updates. To be rendered in game however requires them to be referenced by a Material. | | * '''纹理''' – 例如一张墙壁上砖块的图像,或者一张法线贴图 (准确地描述了表面的位置，用来模拟额外的细节),或者很多其他的可能性之一。纹理通常在类似于Photoshop之类的软件中制作,GIMP或类似的每当内容更新时就会自动重新编译。但是，要在游戏中渲染需要材质引用它们。 |
|
| |
|
| * '''Materials''' – A description of how all the textures work together. For the brick wall a material might point at a color map, a normal map, a roughness map and so on to define what the brick wall is supposed to look like in game. You may have an alternative version of the brick wall which has a different color map but the same normal and roughness maps. The material untangles all of these, and allows simple configuration of all the shader’s inputs. | | * '''材质''' – 描述了所有纹理如何协同工作。对于砖墙，材质也许会指向一张色彩图，一张法线贴图,一张粗糙度图等等来明确在游戏中砖墙看起来会是什么样子。您可能会有一种可供替代的砖墙版本，虽然有不同的色彩图，但是有相同的法线贴图和粗糙度图。材质会整理所有这些内容，并允许对所有着色器输入进行简单配置。 |
| ** Materials are set up in the [[Dota_2_Workshop_Tools/Materials/Material_Editor|Material Editor]]. | | ** 材质通过 {{L|Dota_2_Workshop_Tools/Materials/Material_Editor|Material Editor}} 来创建. |
|
| |
|
| * '''Models''' – Produced in a 3D modelling program such as Maya, Modo, or Blender for example. These are 3D shapes made out of triangles. Examples would include furniture, trees, details on buildings, and characters or creatures. A good deal of what you’ll see in Half-Life: Alyx is based around these 3D models. The surfaces these models are made out of are assigned to particular materials which in turn point at the appropriate textures to use. While the underlying model files will usually be built using external software, their use in the engine will be set up in [[Half-Life: Alyx Workshop Tools/ModelDoc_Editor|ModelDoc]]. | | * '''模型''' – 在使用例如Maya,Modo或者Blender等3D建模程序中生成。这些是由三角形组成的3D形体，例如家具、树木、在建筑物上的细节以及人物或怪物。在《半衰期：爱莉克斯》中您会看到有很多东西是基于这些模型的。这些模型所用的面分配了特定材质，这些材质依次分配了要使用的适当纹理。 虽然底层模型文件通常使用外部软件构建，他们在引擎中的用途可被在 {{L|Half-Life: Alyx Workshop Tools/ModelDoc_Editor|ModelDoc}} 里设置。 |
| ** Automatically recompiled when you change source content – aspects of the resulting compiled model can be defined by the materials it uses. For instance, a model with a simple, unlit material can be automatically compiled to be without vertex normals to save space – but you’ll need to force a model recompile if you subsequently change the material to use proper lighting. Similarly, you change your material to start using secondary UVs for something, you may need to recompile the model for it to render properly. | | ** 更改content目录下的原始内容时将会自动重新编译 – 生成的编译过的模型的规格可以由它使用的材质定义。例如，有简单的未照明材质的模型可以被自动编译为没有顶点法线的模型以节省空间 – 但是，如果后续要更改材质以使用适当的照明，就要强制重新编译模型。类似的是，如果更改材质以开始对某些对象使用次要UV，就可能需要重新编译模型以使其正确渲染。 |
|
| |
|
| * '''Maps''' – Think of this as a container for everything in the world you are creating. Maps contain data for lighting, where props are placed, sounds to play when and where, and even the basic scripting linking object behaviors together. Everything you see in Half-Life: Alyx is ultimately placed into a map – it’s the film set or theatrical stage in which everything happens. | | * '''地图''' – 把它想象成您正在世界上创造的所有物品的容器。地图包含照明数据、放置道具的位置、何时何地播放声音，甚至是将对象行为链接在一起的基本脚本。您在《半衰期：爱莉克斯》中看到的一切最终都会被放到地图上 – 那是将会发生所有游戏内事件的电影布景或舞台。 |
| ** The Half-Life: Alyx Workshop Tools include [[SteamVR/Environments/Getting_Started|Hammer]] as the map editor. | | ** 《半衰期：爱莉克斯》创意工坊工具集包含了 {{L|SteamVR/Environments/Getting_Started|Hammer}} 来作为它的地图编辑器。 |
| ** Maps are not automatically recompiled and always require a compile to view changes in game. This includes such processes as calculating [[Half-Life: Alyx Workshop Tools/Lighting|lighting]] and visibility for example. | | ** 地图不会自动重新编译，并且总是需要编译才能查看游戏内的变化。这个过程包括例如计算{{L|Half-Life: Alyx Workshop Tools/Lighting|光照}} 和可见性。 |
|
| |
|
| Other files include sounds, particle systems and more – these all have source versions in the content folder for your addon, and get compiled into streamlined, efficient versions in the game folder for your addon.
| | 其他文件包括声音、粒子系统等 – 这些在你content文件夹中的原始版本，将在该插件中的game文件夹下编译成精简、高效的版本。 |
|
| |
|
| === Exceptions to the Rule === | | === 文件分布规则的例外情况 === |
|
| |
|
| There are some file types such as various script files which get consumed by the engine directly. These text files get placed somewhere inside the game folder and are not compiled. These include things like Soundscape definitions, localization, etc.
| | 有一些文件类型，例如引擎直接使用的各种脚本文件。这些文本文件放在游戏文件夹中的某个地方，并不会被编译。这些包括Soundscape定义、本地化文件等。 |
|
| |
|
| == Entities, Geometry, Entity Logic and More == | | == 实体, 几何体, 实体逻辑与更多 == |
|
| |
|
| An empty map in Hammer is the blank canvas for a VR experience in Half-Life: Alyx. This is where just about everything gets placed and until you add things to your map the world will be entirely empty.
| | 在《半衰期：爱莉克斯》里，Hammer内的一张空的地图是一段VR体验的空白画布。这是几乎所有东西都被放置的地方，除非您把一些物品添加到地图上，否则世界将完全是空的。 |
|
| |
|
| * '''Entities''' – Each of these are effectively custom bits of code written to execute a specific set of instructions which allow users, when combined with other entities, to create the various experiences in the game. They will almost always have a visible (and/or audible) representation in the world and will react to things in specific ways. A physics prop is an example of an entity where the user can specify which model should be rendered as a physics prop, how it should react to the player throwing it, etc. Some of that data is contained in Hammer and can be edited while other data specific to the model is contained in the model files. Another example would be NPCs (Headcrabs, Combine Soldiers), light sources, or an invisible trigger volume which tells another entity to do something when a specific entity enters it. | | * '''实体''' – 每一个都事实上是自定义代码位，用于执行一组特定的指令，当用户与其他实体结合，互动时，这些指令允许用户在游戏中创建各种体验。他们在世界上几乎总是有一个可见（和/或可听见）的表象，并以特定的方式对事物做出反应。一件物理道具是实体的一个示例，用户可以在其中指定哪个模型应渲染为物理道具，它应如何响应玩家投掷道具的动作等。其中一些数据包含在Hammer中，可以编辑，而模型文件中包含特定于该模型的其他数据。另一个例子是NPC（猎头蟹，联合军士兵），光源，或一个不可见的触发体，当一个特定实体进入它时，它告诉另一个实体执行某事。 |
|
| |
|
| * '''Geometry''' – [[Dota_2_Workshop_Tools/Level_Design/Basic_Construction|map geometry built in Hammer]] is mostly used like fixed architecture upon which everything happens. You can also tie particular sections of map geometry to specific entities – this tells the entity (such as a sliding door, or a rotating platform) to use that map geometry as its visible representation. In the case of that invisible trigger volume, a block of map geometry will define the space it encloses. | | * '''几何体''' – {{L|Dota_2_Workshop_Tools/Level_Design/Basic_Construction|在Hammer中创建几何体}} 主要像固定的体系结构一样使用，所有事件都发生在它上面。您还可以将地图几何体的特定部分绑定到特定实体–这会告诉实体（如滑动门或旋转平台）使用该地图几何结构作为其可视化表现。 |
|
| |
|
| * '''Entity Logic''' – This is the basic glue sticking the behaviors of entities in a map together. Made from Input and Output definitions on entities an entity might experience a particular thing happening (such as a player putting a hand into a specified volume) which causes it to fire an OnTrigger Output. This is connected to an Input on another entity which tells it to do something else such as turn on a light. There is an in-depth article on [[Inputs_and_Outputs|Inputs and Outputs]] to read through for more information. Note this is a Source 1 tutorial so links and specifics will often wander off into topics not applicable to Half-Life: Alyx but the core concepts are the same. | | * '''实体逻辑''' – 这是将地图中实体的行为粘在一起的基本粘合剂。根据实体的输入和输出定义，一个实体可能会经历一个特定的事件发生（例如玩家将一只手放入指定的区域中），这会导致它触发OnTrigger而输出。它连接到另一个实体上的输入，该实体告诉它执行其他操作，例如打开灯。有一篇关于 {{L|Inputs_and_Outputs|输入和输出}} 的文章，请注意，这是一个Source 1的教程，因此链接和细节经常会偏离到不适用于《半衰期：爱莉克斯》的主题，但核心理念是相同的。 |
|
| |
|
| == 灯光 == | | == 光照 == |
|
| |
|
| The engine uses a simulation of how light appears in real life to render objects allowing surfaces to respond realistically to light sources. Objects can cast shadows on to themselves and other objects. Lighting is a a huge aspect of a map and properly lighting worlds is a bit of an art in itself. There's an overview of the [[Half-Life: Alyx Workshop Tools/Lighting|lighting system]] you can read to get a better idea as to its capabilities and limitations.
| | 游戏引擎使用一种模拟光线在现实世界中的反应的方式来渲染物体以使物体表面对光线的反应更加真实。物体的阴影不止可以投射到其他物体上，同样也可投射到其自身表面上。光照是地图的一个重要组成部分，而且恰当地布置光源也是一种艺术。有一篇页面是对光照系统的总览性介绍，你可以阅读{{L|Half-Life: Alyx Workshop Tools/Lighting|光照系统}}来对它的能力和限制进行了解。 |
|
| |
|
| == 命令控制台 == | | == 命令控制台 == |
|
| |
|
| Referred to simply as "the console" it is a command line interface that relays logs and messages back to the user and also accepts many text-based commands for controlling features deep inside the engine. It takes the form of a separate program and with the tools running you can bring it up by pressing the tilde key (~) just below the escape key to the top left of your keyboard, or from the Tools menu in the top right corner of most tool windows.
| | 简称为“控制台”，它是一个命令行界面，将日志和消息转发给用户，还能接受许多基于文本的命令，用于控制引擎内部的功能。它采用单独程序的形式，在工具运行时，您可以通过按键盘左上角Esc键正下方的平铺键（~）或在大多数工具窗口右上角的“工具”菜单来打开它。 |
| | |
| == 运行 rformance ==
| |
|
| |
|
| VR is extremely taxing on system requirements and as such various trade offs must be made when building content inside of Half-Life: Alyx. One of the largest computational costs is rendering a scene, and in this case, two binocular views in high definition at 90 frames per second. Any time the framerate drops, much more so than with games on a flat monitor, missed frames in VR can be pretty obvious and unpleasant. This may cause shimmering at best or painful juddering at worst. The rendering system and shaders in Half-Life: Alyx are specifically engineered to be as efficient as possible but it’s still very possible to overload it.
| | == 性能 == |
|
| |
|
| The adaptive fidelity system used in Half-Life: Alyx will dynamically enable and disable render size and features to get the best possible quality from your hardware but to prevent excessive blurriness it won’t go below a certain level. When running in Tools mode this will be disabled. It will be only enabled in game mode. Proper performance testing of your addon should be done in the game mode (as opposed to running the game with tools loaded in the background).
| | VR对系统要求非常严苛，因此在《半衰期：爱莉克斯》内构建内容时必须做出某些妥协。最大的计算成本之一是渲染场景，在本例中，两个高分辨率双目视图以每秒90帧的速度渲染。任何时候帧数下降，比平板显示器上的游戏更严重，在虚拟现实中丢失的帧可能是非常明显和令人不快的。在最好的情况下可能会导致闪烁，最坏的情况下可能会导致痛苦的视角抖动。《半衰期：爱莉克斯》中的渲染系统和着色器经过专门设计以变得尽可能高效，但仍有可能使其过载。 |
|
| |
|
| Here are some potential high cost areas:
| | 《半衰期：爱莉克斯》中使用的自适应保真度系统将动态启用和禁用渲染大小和功能，以从硬件中获得最佳质量，但为了防止过度模糊，它不会低于某个特定的级别。在工具模式下运行时，此功能将被禁用。它只会在正常的游戏模式中才会开启。应该在您的游戏模式下对插件进行适当的性能测试（而不是在后台加载工具时运行游戏）。 |
|
| |
|
| * '''Too much geometry''' The world can be too detailed and building too detailed of geometry in Hammer or placing too many static props can start causing the framerate to drop. Use the example maps provided as a gauge.
| | 以下是一些潜在的高性能花销的地方: |
|
| |
|
| * '''Expensive lighting''' – Having too many indexed (baked, precomputed lighting) light sources can all add to the rendering cost. While the lighting system in Half-Life: Alyx is remarkably efficient, misunderstandings and over-expectations can cause significant issues. A general rule of thumb is to not have too many indexed lights shining on any one surface. The hard limit is four, though the game will run more efficiently if there's only one or two indexed lights hitting a surface. Dynamic lights should be used conservatively, and are usually reserved for highly specialized use cases, such as the flashlight. {{Tip|There are various visualization modes available in Hammer's 3D view - use the menu at the top right to set 'Tools Visualization Mode' to 'Baked Lighting Complexity'. Black corresponds to zero indexed lights on that surface, red one, orange two, yellow three, white four and cyan is four plus (this should always be avoided as it will cause lighting errors when baking the lighting). There's more information in the [[Half-Life: Alyx Workshop Tools/Lighting|lighting]] overview.}} | | * '''太多的几何体''' 在Hammer中放置太多静态道具或者地图中的建筑有太复杂几何体会造成帧率的下降。使用所提供的示例地图作为几何体数量的参照标准。 |
| ** If you can, find a user with an entry-level GPU (such as an Nvidia GeForce GTX 1060 or AMD Radeon RX 580 with 6GB VRAM) to test things with as a good baseline to evaluate your map.
| |
|
| |
|
| For an up-to-date view of current rendering cost, bring up the frame timing window in SteamVR : Settings : Performance : Display Frame Timing. At a very simplistic level, the GPU graph at bottom should stay below 11ms for a 90Hz display, without any non-zero red line popping up at the bottom – if running in game mode, the adaptive fidelity should try to maximize GPU usage, but it should rarely if ever go above 11ms.
| | * '''开销过大的照明''' –有太多的光源索引（烘焙、预计算的照明）都会增加渲染成本。虽然《半衰期：爱莉克斯》中的光照系统非常高效，但误解和过度期望可能会导致重大问题。通常的经验告诉我们不要在一个表面使用太多的光源照射。虽然四个光源索引是硬性上限，但是仅使用一或两个光源索引会使游戏更加高效的运行。动态光源应谨慎使用，通常用于特殊情况，例如手电筒。 {{提示|在Hammer工具的3D视图里有多种显示方式，使用右上角的按钮将 'Tools Visualization Mode' 切换至'Baked Lighting Complexity'。黑色表示0个光源索引，红色为1个，橙色2个，黄色3个，白色4个，青色是4个以上（应该始终避免这种情况，因为它将在烘焙光照时导致错误）。更多的信息在 {{L|Half-Life: Alyx Workshop Tools/Lighting|光照概述}} 中提及。}} |
| {{Tip|Most performance discussions will revolve around milliseconds as opposed to frames per second. It takes marginally over 11ms a frame to maintain 90fps, so 'saving 2ms' is much more meaningful to say than 'saving five frames per second', as the latter gives no indication of the absolute rendering cost saved. Did you start at 10 or 1000 FPS?}} | | ** 如果可以的话，以使用入门级GPU的用户作为地图评估的基准。（如Nvidia GeForce GTX 1060或AMD Radeon RX 580 6GB显存版本） |
|
| |
|
| If your CPU graph is frequently leaping above 11ms, then there are possibly some other performance costs going on. Here are some potential CPU costs:
| | 要想了解当前渲染花销的情况，可以在SteamVR>设置>性能>高级帧定时。简单那来说，对于90Hz的显示器，底部的GPU图表应该保持在11ms以下，没有任何非零的红线出现在底部 - 如果在游戏模式下运行，自适应保真度应尽量提高GPU的使用率，但它应该很少超过11ms。 |
| | {{提示|大多数有关性能的讨论将围绕毫秒展开，而不是每秒的帧数。维持90帧每秒只需略微超过11毫秒，因此“节省2毫秒”比“每秒节省5帧”更有意义，因为后者没有显示节省的绝对渲染成本。 你是从每秒10帧还是每秒1000帧开始的？}} |
|
| |
|
| * '''Too many entities''' – It’s much more likely to be some aspect of the specific entities you have in the map, rather than an overall count of all entities. If you have many more than usual of a certain thing, it may be worth investigating further. For example, a simple box map with a hundred Combine Soldiers may be challenging to render, but it's even more challenging to have all those AI calculate paths, targets, cover locations, and collision with the world.
| | 如果您的CPU图像经常超过11毫秒，那么还存在一些性能开销。以下是一些潜在的CPU开销： |
|
| |
|
| * '''Complex rendering''' – Counter-intuitively, you can have a high rendering cost even if the GPU isn’t maxed out thanks to draw calls. If you have many separate models and/or materials, the CPU has to tell the GPU to render each one, which incurs a cost that goes up the more things you have. | | * '''过多的实体''' – 可能是地图中某个区域有太多实体，而不是所有实体总数。如果你的某样东西比正常时多很多，可能值得进一步去调查。例如，一个简单的盒子地图放置一百个联合军士兵，渲染起来可能很有挑战性，要是再加上AI路径，目标，掩体位置及世界的碰撞，就更是难上加难了。 |
|
| |
|
| * '''Complex physics''' – Having too many physically simulated objects in the scene at the same time can be a significant computational cost – and in particular, having one complex collision hull collide with another can be very expensive, causing severe frame drops. While the example maps may have hundreds of physics objects, not all of them are active at the same time. Keep this in mind when building your addons. | | * '''复杂的渲染''' – 与直觉相反的是，即便Draw Call没有到GPU的最大值，也可能会有很高的渲染开销。如果你有许多单独的模型或材质，CPU必须告诉GPU去渲染每一个模型或材质，这会导致你拥有的东西越多，开销就越大。 |
|
| |
|
| == 地图案例 ==
| | * '''复杂的物理''' – 在场景中同时有太多的物理模拟对象可能是一个巨大的计算开销，尤其是让一个复杂的碰撞体与另一个碰撞体相撞会有高昂的开销，导致帧数严重下降。 虽然示例地图里可能有数百个物理对象，但并非所有的物理对象都在同一时间活动。 在编译你自己的插件时，请牢记这一点。 |
|
| |
|
| Some example maps are provided in <code>\Steam\steamapps\common\Half-Life Alyx\content\hlvr\maps</code>.
| | == 示例地图 == |
| * <code>workshop_examples</code> contains some annotated examples of various Half-Life: Alyx features.
| |
| * <code>release</code> contains full sources for all the maps shipped in the final game.
| |
| You're ''not'' expected to recompile the release maps. The full lighting and audio calculations would likely take an excessive amount of time on a home PC - but you'll be able to add content at an entity level using the new [[Half-Life:_Alyx_Workshop_Tools/Map_Extensions|Map Extensions]] feature.
| |
|
| |
|
| == Documentation ==
| | 一些示例地图被放在了 <code>\Steam\steamapps\common\Half-Life Alyx\content\hlvr\maps</code>。 |
| | * <code>workshop_examples</code> 放有一些带有注释的《半衰期：爱莉克斯》功能演示地图。 |
| | * <code>release</code> 放有最终游戏成品的全部地图源文件。 |
| | 你不需要去重新编译游戏成品的地图。完整的音频和光照计算对于一般家用个人电脑来说会消耗大量的时间 - 但你可以通过{{L|Half-Life:_Alyx_Workshop_Tools/Map_Extensions|地图扩展}}功能来对现有地图增加实体类内容。 |
|
| |
|
| Finally, welcome to the Valve Developer Community wiki! This documentation is a never-ending work in progress and is built in part by people like you - each page has a discussion section, and each page can be edited and extended as you see fit. If you have any questions, please do post them - and if you have any answers, post those too!
| | == 文档 == |
|
| |
|
| [[Category:Half-Life: Alyx Workshop Tools:zh-cn]]
| | 最后，欢迎来到Valve Developer Community Wiki！本文档一直都在编写中，并且是由像你一样的的人所建立 - 每个页面都有一个讨论区，而且如果你认为有需求，每个页面都可被编辑和扩写。如果你有任何疑问，请将其发在讨论区 - 如果你有答案，也请发出来！ |
| | {{HLATools page}} |
本文旨在解释《半衰期：爱莉克斯》游戏引擎和开发工具背后的一些基本概念。使用过《SteamVR Home(en)》创意工坊工具的用户会有一定优势，因为这些工具采用的框架与《Dota 2(en)》等其他游戏所提供的框架相同。不同的是：光照系统(en)得到了极大的改善，其中ModelDoc是模型编辑器的全面改进版，标准着色器有所不同，并且还有更多的实体和内容可供使用。尽管并非全部都能直接适用，但本Wiki上的SteamVR Home创意工坊工具(en)文档仍然可以为制作《半衰期：爱莉克斯》插件的人们提供一些有用的信息。
启动《半衰期：爱莉克斯》创意工坊工具
请查看创建插件(en)
插件, 以及content和game文件夹
插件是一组文件，这些文件依靠于基础游戏上，其概念与Source 1的mod相似，但允许在运行时更改插件。 您的文件将分为两种类型-源文件（原始文件）和编译文件（处理或编译后的文件）。
原始文件位置
- \Steam\steamapps\common\Half-Life Alyx\content\hlvr_addons\your_addon_name
编译文件位置:
- \Steam\steamapps\common\Half-Life Alyx\game\hlvr_addons\your_addon_name
当您将插件上传到创意工坊时，content目录将不会上传，而game目录中的数据将打包到VPK文件中。
资产编译
Source引擎的资产通常以不太适合重新分发或快速加载和呈现的格式保存。例如，纹理可以是一个Photoshop文档，其中包含数十个图层，这些图层包含数百兆字节，它们将被编译成针对引擎优化的格式，以尽可能快地进行渲染。它会丢弃所有不需要的数据（例如，图层或标记数据），并将其压缩为渲染系统的着色器所要求的形式（在显卡上运行的小程序，负责处理屏幕上所看到的像素）使它适合于尽可能快速高效地加载和显示。
content文件夹中的所有文件都是对用户友好的格式，有的是被用户放在这里，有的则是在《半衰期：爱莉克斯》工具中创建，而game文件夹中的文件通常由content文件夹中的文件编译后产生，并且都能被引擎直接使用。
通常，当磁盘上的内容发生更改时，引擎将自动重新编译，从而允许用户在Photoshop中保存文件，并使所有内容都在材质编辑器和地图编辑器中进行更新。如果引擎没能发现变更，也可以强制重新编译。
基础文件 - 纹理, 材质, 模型和地图
- 纹理 – 例如一张墙壁上砖块的图像,或者一张法线贴图 (准确地描述了表面的位置，用来模拟额外的细节),或者很多其他的可能性之一。纹理通常在类似于Photoshop之类的软件中制作,GIMP或类似的每当内容更新时就会自动重新编译。但是，要在游戏中渲染需要材质引用它们。
- 材质 – 描述了所有纹理如何协同工作。对于砖墙，材质也许会指向一张色彩图，一张法线贴图,一张粗糙度图等等来明确在游戏中砖墙看起来会是什么样子。您可能会有一种可供替代的砖墙版本，虽然有不同的色彩图，但是有相同的法线贴图和粗糙度图。材质会整理所有这些内容，并允许对所有着色器输入进行简单配置。
- 模型 – 在使用例如Maya,Modo或者Blender等3D建模程序中生成。这些是由三角形组成的3D形体，例如家具、树木、在建筑物上的细节以及人物或怪物。在《半衰期：爱莉克斯》中您会看到有很多东西是基于这些模型的。这些模型所用的面分配了特定材质，这些材质依次分配了要使用的适当纹理。 虽然底层模型文件通常使用外部软件构建，他们在引擎中的用途可被在 ModelDoc(en) 里设置。
- 更改content目录下的原始内容时将会自动重新编译 – 生成的编译过的模型的规格可以由它使用的材质定义。例如，有简单的未照明材质的模型可以被自动编译为没有顶点法线的模型以节省空间 – 但是，如果后续要更改材质以使用适当的照明，就要强制重新编译模型。类似的是，如果更改材质以开始对某些对象使用次要UV，就可能需要重新编译模型以使其正确渲染。
- 地图 – 把它想象成您正在世界上创造的所有物品的容器。地图包含照明数据、放置道具的位置、何时何地播放声音，甚至是将对象行为链接在一起的基本脚本。您在《半衰期：爱莉克斯》中看到的一切最终都会被放到地图上 – 那是将会发生所有游戏内事件的电影布景或舞台。
- 《半衰期：爱莉克斯》创意工坊工具集包含了 Hammer(en) 来作为它的地图编辑器。
- 地图不会自动重新编译，并且总是需要编译才能查看游戏内的变化。这个过程包括例如计算光照(en) 和可见性。
其他文件包括声音、粒子系统等 – 这些在你content文件夹中的原始版本，将在该插件中的game文件夹下编译成精简、高效的版本。
文件分布规则的例外情况
有一些文件类型，例如引擎直接使用的各种脚本文件。这些文本文件放在游戏文件夹中的某个地方，并不会被编译。这些包括Soundscape定义、本地化文件等。
实体, 几何体, 实体逻辑与更多
在《半衰期：爱莉克斯》里，Hammer内的一张空的地图是一段VR体验的空白画布。这是几乎所有东西都被放置的地方，除非您把一些物品添加到地图上，否则世界将完全是空的。
- 实体 – 每一个都事实上是自定义代码位，用于执行一组特定的指令，当用户与其他实体结合，互动时，这些指令允许用户在游戏中创建各种体验。他们在世界上几乎总是有一个可见（和/或可听见）的表象，并以特定的方式对事物做出反应。一件物理道具是实体的一个示例，用户可以在其中指定哪个模型应渲染为物理道具，它应如何响应玩家投掷道具的动作等。其中一些数据包含在Hammer中，可以编辑，而模型文件中包含特定于该模型的其他数据。另一个例子是NPC（猎头蟹，联合军士兵），光源，或一个不可见的触发体，当一个特定实体进入它时，它告诉另一个实体执行某事。
- 几何体 – 在Hammer中创建几何体(en) 主要像固定的体系结构一样使用，所有事件都发生在它上面。您还可以将地图几何体的特定部分绑定到特定实体–这会告诉实体（如滑动门或旋转平台）使用该地图几何结构作为其可视化表现。
- 实体逻辑 – 这是将地图中实体的行为粘在一起的基本粘合剂。根据实体的输入和输出定义，一个实体可能会经历一个特定的事件发生（例如玩家将一只手放入指定的区域中），这会导致它触发OnTrigger而输出。它连接到另一个实体上的输入，该实体告诉它执行其他操作，例如打开灯。有一篇关于 输入和输出(en) 的文章，请注意，这是一个Source 1的教程，因此链接和细节经常会偏离到不适用于《半衰期：爱莉克斯》的主题，但核心理念是相同的。
光照
游戏引擎使用一种模拟光线在现实世界中的反应的方式来渲染物体以使物体表面对光线的反应更加真实。物体的阴影不止可以投射到其他物体上，同样也可投射到其自身表面上。光照是地图的一个重要组成部分，而且恰当地布置光源也是一种艺术。有一篇页面是对光照系统的总览性介绍，你可以阅读光照系统(en)来对它的能力和限制进行了解。
命令控制台
简称为“控制台”，它是一个命令行界面，将日志和消息转发给用户，还能接受许多基于文本的命令，用于控制引擎内部的功能。它采用单独程序的形式，在工具运行时，您可以通过按键盘左上角Esc键正下方的平铺键（~）或在大多数工具窗口右上角的“工具”菜单来打开它。
性能
VR对系统要求非常严苛，因此在《半衰期：爱莉克斯》内构建内容时必须做出某些妥协。最大的计算成本之一是渲染场景，在本例中，两个高分辨率双目视图以每秒90帧的速度渲染。任何时候帧数下降，比平板显示器上的游戏更严重，在虚拟现实中丢失的帧可能是非常明显和令人不快的。在最好的情况下可能会导致闪烁，最坏的情况下可能会导致痛苦的视角抖动。《半衰期：爱莉克斯》中的渲染系统和着色器经过专门设计以变得尽可能高效，但仍有可能使其过载。
《半衰期：爱莉克斯》中使用的自适应保真度系统将动态启用和禁用渲染大小和功能，以从硬件中获得最佳质量，但为了防止过度模糊，它不会低于某个特定的级别。在工具模式下运行时，此功能将被禁用。它只会在正常的游戏模式中才会开启。应该在您的游戏模式下对插件进行适当的性能测试（而不是在后台加载工具时运行游戏）。
以下是一些潜在的高性能花销的地方:
- 太多的几何体 在Hammer中放置太多静态道具或者地图中的建筑有太复杂几何体会造成帧率的下降。使用所提供的示例地图作为几何体数量的参照标准。
- 开销过大的照明 –有太多的光源索引（烘焙、预计算的照明）都会增加渲染成本。虽然《半衰期：爱莉克斯》中的光照系统非常高效，但误解和过度期望可能会导致重大问题。通常的经验告诉我们不要在一个表面使用太多的光源照射。虽然四个光源索引是硬性上限，但是仅使用一或两个光源索引会使游戏更加高效的运行。动态光源应谨慎使用，通常用于特殊情况，例如手电筒。
提示:在Hammer工具的3D视图里有多种显示方式，使用右上角的按钮将 'Tools Visualization Mode' 切换至'Baked Lighting Complexity'。黑色表示0个光源索引，红色为1个，橙色2个，黄色3个，白色4个，青色是4个以上（应该始终避免这种情况，因为它将在烘焙光照时导致错误）。更多的信息在 光照概述(en) 中提及。- 如果可以的话，以使用入门级GPU的用户作为地图评估的基准。（如Nvidia GeForce GTX 1060或AMD Radeon RX 580 6GB显存版本）
要想了解当前渲染花销的情况，可以在SteamVR>设置>性能>高级帧定时。简单那来说，对于90Hz的显示器，底部的GPU图表应该保持在11ms以下，没有任何非零的红线出现在底部 - 如果在游戏模式下运行，自适应保真度应尽量提高GPU的使用率，但它应该很少超过11ms。
提示:大多数有关性能的讨论将围绕毫秒展开，而不是每秒的帧数。维持90帧每秒只需略微超过11毫秒，因此“节省2毫秒”比“每秒节省5帧”更有意义，因为后者没有显示节省的绝对渲染成本。 你是从每秒10帧还是每秒1000帧开始的？
如果您的CPU图像经常超过11毫秒，那么还存在一些性能开销。以下是一些潜在的CPU开销：
- 过多的实体 – 可能是地图中某个区域有太多实体，而不是所有实体总数。如果你的某样东西比正常时多很多，可能值得进一步去调查。例如，一个简单的盒子地图放置一百个联合军士兵，渲染起来可能很有挑战性，要是再加上AI路径，目标，掩体位置及世界的碰撞，就更是难上加难了。
- 复杂的渲染 – 与直觉相反的是，即便Draw Call没有到GPU的最大值，也可能会有很高的渲染开销。如果你有许多单独的模型或材质，CPU必须告诉GPU去渲染每一个模型或材质，这会导致你拥有的东西越多，开销就越大。
- 复杂的物理 – 在场景中同时有太多的物理模拟对象可能是一个巨大的计算开销，尤其是让一个复杂的碰撞体与另一个碰撞体相撞会有高昂的开销，导致帧数严重下降。 虽然示例地图里可能有数百个物理对象，但并非所有的物理对象都在同一时间活动。 在编译你自己的插件时，请牢记这一点。
示例地图
一些示例地图被放在了 \Steam\steamapps\common\Half-Life Alyx\content\hlvr\maps。
workshop_examples 放有一些带有注释的《半衰期：爱莉克斯》功能演示地图。release 放有最终游戏成品的全部地图源文件。
你不需要去重新编译游戏成品的地图。完整的音频和光照计算对于一般家用个人电脑来说会消耗大量的时间 - 但你可以通过地图扩展(en)功能来对现有地图增加实体类内容。
文档
最后，欢迎来到Valve Developer Community Wiki！本文档一直都在编写中，并且是由像你一样的的人所建立 - 每个页面都有一个讨论区，而且如果你认为有需求，每个页面都可被编辑和扩写。如果你有任何疑问，请将其发在讨论区 - 如果你有答案，也请发出来！
