Zh/Source 2/Docs/Level Design/Visibility: Difference between revisions
No edit summary |
No edit summary |
||
Line 34: | Line 34: | ||
* '''tools/toolsnodraw''' - 使用此工具纹理的表面将像普通可见表面一样工作。唯一的例外是内部/外部测试。在测试中,toolsnodraw将被有效地忽略。因此,如果一个体积中没有其他可见的几何体,那么这个体积可能会从PVS中消除。 | * '''tools/toolsnodraw''' - 使用此工具纹理的表面将像普通可见表面一样工作。唯一的例外是内部/外部测试。在测试中,toolsnodraw将被有效地忽略。因此,如果一个体积中没有其他可见的几何体,那么这个体积可能会从PVS中消除。 | ||
== | == 在游戏中观察VIS == | ||
引擎可以对镜头位置进行记录,以便进行可见性调试。当回放记录时,PVS可视化调试器将为记录的镜头设置动画,并实时更新可视化。例如,你可以用这个来看看当你走在走廊上时VIS发生了什么变化。然后你可以飞出去,从一个不同的角度检查PVS。 | |||
可以使用以下控制台命令: | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| '''vis_enable 0/1''' | | '''vis_enable 0/1''' | ||
| | | 切换预先计算的可见性系统。“'vis_enable 1'”为默认值,“'vis_enable 0'”关闭PVS。 | ||
|- | |- | ||
| '''vis_debug_show''' | | '''vis_debug_show''' | ||
| | | 这将显示PVS可视化调试器。镜头位置渲染为红色球体,将以白色渲染截面,可见簇将渲染为绿色线框轮廓。你可以独立地移动镜头和观察记录的PVS可视化调试器。 | ||
|- | |- | ||
| '''vis_debug_record_start''' | | '''vis_debug_record_start''' | ||
| | | 开始录制镜头截锥以供回放。 | ||
|- | |- | ||
| '''vis_debug_record_stop''' | | '''vis_debug_record_stop''' | ||
| | | 停止录像。 | ||
|- | |- | ||
| '''vis_debug_find_los''' | | '''vis_debug_find_los''' | ||
| | | 这将发现记录镜头的当前位置(簇包含被记录的绘制成红色的镜头)和实际镜头的位置(簇被绘制成蓝色)之间的任何视线。连接这两个簇块的视线用黄色绘制。这告诉你为什么PVS认为在记录的镜头位置可以看到另一个位置。 | ||
|- | |- | ||
| '''vis_debug_tracelos''' | | '''vis_debug_tracelos''' | ||
| | | 使用此选项可以修复从当前镜头位置应该可见但不可见的内容。它将跟踪覆盖当前屏幕的光线网格,并更新vis以包含找到的任何新视线。这些视线记录在los.bin文件中,以备将来的地图编译。 | ||
|- | |- | ||
| '''vis_debug_lock''' | | '''vis_debug_lock''' | ||
| | | 切换锁定VIS视线原点到当前镜头位置的开关。 | ||
|- | |- | ||
| '''vis_debug_currentcluster''' | | '''vis_debug_currentcluster''' | ||
| | | 将当前簇编号打印到控制台。 | ||
|- | |- | ||
| '''vis_debug_dumpvisibleclusters''' | | '''vis_debug_dumpvisibleclusters''' | ||
| | | 将可见簇列表打印到控制台。 | ||
|- | |- | ||
| '''vis_debug_drawcluster''' | | '''vis_debug_drawcluster''' | ||
| | | 将簇#添加到可视化,(-1)为清除。 | ||
|} | |} | ||
Revision as of 03:06, 16 April 2021
为了地图编译能有高效的“vis”解决方案,确保你的地图有正确的几何体是非常重要的。《半衰期:爱莉克斯》的VIS解决方案通过内部/外部算法尝试在执行可见性计算时确定哪些是在地图“内部”。实际上,里面的任何东西都会被渲染,外面的任何东西都会被丢弃。
注意:预先计算的可见性提高了渲染地图的性能,但增加了地图编译时间。如果要禁用整个地图的预计算可见性,可以将“地图属性(Map Properties)”对话框中的“预计算可见性(Precomputed Visibility)”属性设置为“禁用(Disabled)”。
内部与外部
visbuilder将尝试自动确定地图内外的空间。其用于执行此操作的主要因素是几何体的正面和背面的可见性。一般来说,拥有直接视野足够多的几何体正面和视野相当有限的几何体背面的空间将标记在内部。当visbuilder运行时,任何通过外部空间的视线都将被消除。这是为了弥补在地图构建方面没有任何限制。地图中通常会包含一些不封闭的几何体或以某种方式重叠的几何体。在处理这些情况时,不应该因为某些有效的几何体穿过了这些表面,就强迫系统保存这些穿过部分的可见性信息。当这个算法失败时,最常见的原因是要计算的几何体出现意外漏洞。在查找其他问题之前检查要计算的几何体非常重要(在Hammer中使用vis preview)。通常你应该认为起源2的可见性是双向的。每个可见的空间也应该看起来像一个放置相机的有效空间。
基本用法
默认情况下,Hammer中内置的世界几何体将阻止可见性。可以在网格对象的对象属性中勾选“从VIS中排除(Exclude from VIS)”选项以禁用此选项。
相反,默认情况下,每个实体类型都不会阻止可见性计算,包括“prop_”类型。这包括prop_static模型,它们通常太小而无法阻止任何合理的可视性,因此被完全跳过。任何你希望包含在vis解决方案中的prop_static几何体必须被标记为“Vis遮挡器(Vis Occluder)”。
各种材质类型(主要是工具纹理)也可以修改其应用于的几何体的行为。
影响可见性的一些最常见的工具材质有:
- tools/visblocker - 使用此工具纹理的表面将删除任何击中该面的视线。这对于阻止由于地图上的漏洞而产生的不需要的(但真实的)视线非常有用。如果你看到地图中的某些漏洞让地图文件中其他不应该可见的部分可见,你可以使用visblocker来阻止这些视线。它不需要完全密封这个洞。
- tools/toolsskybox - 使用此工具纹理的表面将形成有效的视线。当对世界进行体素化时,体素(voxels)会在包含几何体时被细分。如果体素中唯一的几何体是toolsskybox,则体素化将以更粗略的分辨率停止。这提高了可见性编译器的性能。
- tools/toolsnodraw - 使用此工具纹理的表面将像普通可见表面一样工作。唯一的例外是内部/外部测试。在测试中,toolsnodraw将被有效地忽略。因此,如果一个体积中没有其他可见的几何体,那么这个体积可能会从PVS中消除。
在游戏中观察VIS
引擎可以对镜头位置进行记录,以便进行可见性调试。当回放记录时,PVS可视化调试器将为记录的镜头设置动画,并实时更新可视化。例如,你可以用这个来看看当你走在走廊上时VIS发生了什么变化。然后你可以飞出去,从一个不同的角度检查PVS。
可以使用以下控制台命令:
vis_enable 0/1 | 切换预先计算的可见性系统。“'vis_enable 1'”为默认值,“'vis_enable 0'”关闭PVS。 |
vis_debug_show | 这将显示PVS可视化调试器。镜头位置渲染为红色球体,将以白色渲染截面,可见簇将渲染为绿色线框轮廓。你可以独立地移动镜头和观察记录的PVS可视化调试器。 |
vis_debug_record_start | 开始录制镜头截锥以供回放。 |
vis_debug_record_stop | 停止录像。 |
vis_debug_find_los | 这将发现记录镜头的当前位置(簇包含被记录的绘制成红色的镜头)和实际镜头的位置(簇被绘制成蓝色)之间的任何视线。连接这两个簇块的视线用黄色绘制。这告诉你为什么PVS认为在记录的镜头位置可以看到另一个位置。 |
vis_debug_tracelos | 使用此选项可以修复从当前镜头位置应该可见但不可见的内容。它将跟踪覆盖当前屏幕的光线网格,并更新vis以包含找到的任何新视线。这些视线记录在los.bin文件中,以备将来的地图编译。 |
vis_debug_lock | 切换锁定VIS视线原点到当前镜头位置的开关。 |
vis_debug_currentcluster | 将当前簇编号打印到控制台。 |
vis_debug_dumpvisibleclusters | 将可见簇列表打印到控制台。 |
vis_debug_drawcluster | 将簇#添加到可视化,(-1)为清除。 |
Viewing vis in Hammer
Use Visibility contributors view to toggle any geometry that does not contribute to vis. This mode hides any geometry that will not block vis and make it easier to spot errors in your levels. For further examples, load up the released maps from the game that shipped with the tools.
See Load Compiled Vis Data to load vis cluster data in Hammer.
Best practices/common issues
The rest of this article will focus on some of the more common issues and also best practices.
Avoid holes in vis contributing geometry at the level boundary
Although its not completely necessary, vis will produce the best results if there is a sealed shell of vis contributing geometry around the level that cleanly defines the boundary of the level. Holes in this geometry may cause vis to enclose extra empty space around the hole. Typically the Toolsskybox material is used to define the boundary of the level where it would otherwise be open to the skybox.
Do not use SkyVisBlocker
The material skyvisblocker is deprecated and should not be used. You must use toolsskybox texture to enclose parts of the level which are considered "open" to the the skybox, and visblocker should be used to block lines of sight without otherwise effecting the vis results. As an optimization, the skybox will not render in scenes that do not use toolsskybox.
Use Solid Block Light carefully
The "Solid Block Light" material, or toolssolidblocklight is a solid but invisible surface that also blocks light. Effectively this is functionally the same as toolsnodraw but also blocks light. For example, a location where a roof over a building should block sunlight from casting light into the interior but a player can also throw grenades onto the roof.
It should not be used in empty space where no vis clusters should be generated. The toolsblocklight material can be used to block light (cast shadows) without adding vis clusters.
Avoid outward facing geometry at level bounds
Geometry making up the outer shell of the level should always be facing inwards. If parts of the outer shell are facing outwards it will not only have similar effects as a hole, but may also generate additional undesired lines of sight and cause vis to further fill empty space.
Avoid vis contributors extending through the level bounds
Geometry which contributes to vis shouldn't poke through the outer shell of the level. Similar to outward facing geometry this can result in undesired lines of sight and cause vis to fill empty space.
Avoid placing objects outside the level
If you have created a sealed level boundary, ideally all geometry which is not part of the 3D skybox should be within the shell of the level even it it does not contribute to vis. Objects that are outside the shell will be culled by vis in an undesirable manner with part or all of the object being removed.