Видимость

INFO: Перевод страницы не завершен! The translation of the page is not completed!

Важно убедиться, что у вас есть правильная геометрия, идущая к процессору видимости для того, чтобы скомпилировать эффективное "vis" решение для ваших карт. Решение Vis в Half-Life:Alyx работает по внутреннему/внешнему алгоритму и пытается выяснить, что находится "внутри" карты при выполнении расчетов видимости. Фактически всё, что находится внутри, будет отображаться, а всё, что находится снаружи, будет отброшено.

Внутри VS снаружи

Visbuilder попытается автоматически определить, какие пространства находятся внутри и за пределами уровня. Основным фактором, который он использует для этого, является видимость передней и задней поверхностей. В общем, пространства с прямым видом достаточной геометрии лицевой стороны и достаточно ограниченным видом геометрии лицевой стороны будут отмечены внутри. Затем, когда работает visbuilder, любые линии обзора, проходящие через внешнее пространство, будут устранены. Это сделано, чтобы компенсировать отсутствие каких-либо ограничений на построение уровней. Уровни часто включают геометрию, которая не является закрытой или имеет геометрию, которая каким-то образом перекрывается. Эти случаи следует обрабатывать, не заставляя систему хранить информацию о видимости под этажами или местностью только потому, что через эти поверхности пробивается некоторая допустимая геометрия. Когда этот алгоритм терпит неудачу, это чаще всего происходит из-за непреднамеренных отверстий во входной геометрии. Важно проверить геометрию ввода, прежде чем искать другие проблемы (используйте предварительный просмотр в Hammer). В общем, вы должны думать о видимости Source 2 как о двусторонней. Каждое видимое пространство также должно выглядеть как действительное пространство для размещения камеры.

Основное использование

Геометрия мира, построенная в Hammer по умолчанию, блокирует видимость. Это можно отключать с помощью опции Исключить из VIS (Exclude from VIS) в свойствах объекта (Object Properties).

Exclude from VIS можно использовать в мешах Hammer для пропуска проверки видимости.

Каждый тип 'энтити' не будет блокировать вычисления видимости по умолчанию, включая типы "prop_". Это касается моделей prop_static, которые частенько слишком малы, чтобы блокировать разумное количество видимости за собой, поэтому они полностью пропускаются. Любая геометрия prop_static, которую вы хотите включить в решение vis, должна быть помечена как 'Vis Occluder.'

Использование опции Vis Occluder позволяет пропу блокировать видимость за собой

Различные типы материалов, в основном текстуры "инструменты", также могут изменять поведение геометрии, к которой они применяются.

Вот некоторые из наиболее распространенных материалов-инструментов, влияющих на видимость:

• tools/visblocker - Surfaces textured with this tool texture will delete any lines of sight when they hit the surface. This is useful to block unwanted (but real) lines of sight due to holes in the map. If you see a case where some hole in the level is actually allowing visibility to some other part of the map file that shouldn't be visible you can use visblocker to block those lines of sight. It does not have to perfectly seal the hole.
• tools/toolsskybox - Surfaces textured with this tool texture will form valid lines of sight. When voxelizing the world, voxels get subdivided when they contain geometry. If the only geometry in a voxel is toolsskybox, the voxelization will stop at a more coarse resolution. This improves performance of the visibility compiler.
• tools/toolsnodraw - Surfaces textured with this tool texture will function like normal visible surfaces. The only exception is the inside/outside test. In that test toolsnodraw will be effectively ignored. So if there aren't other bits of visible geometry from a volume, that volume may be eliminated from the PVS.

Просмотр vis в игре

Движок может выполнять запись положения камеры для отладки (debug) видимости. Когда запись воспроизводится, визуализация отладки PVS анимирует записанную камеру и обновит визуализацию в режиме реального времени. Например, вы можете использовать это, чтобы увидеть, что происходит с вашим лицом, когда вы идете по коридору. Затем вы можете вылететь и изучить PVS с другой перспективы.

Можно использовать следующие консольные команды:

vis_enable 0/1	Toggle the precomputed visibility system. vis_enable 1 is the default, vis_enable 0 disables the PVS.
vis_debug_show	This will show the PVS debug visualization. The camera position is rendered as a red sphere, the frustum is rendered in white and visible clusters are rendered as green wireframe outlines. You can independently move your camera and spectate the recorded PVS debug visualization.
vis_debug_record_start	Starts recording the camera frustum for playback.
vis_debug_record_stop	Stops recording the camera.
vis_debug_find_los	This will find any lines of sight between the current position of the recorded camera (the cluster containing the recorded camera is draw in red) and the position of the actual camera (that cluster is drawn in blue). The lines of sight connecting these two cluster volumes will be drawn in yellow. This tells you why the PVS thinks the recorded camera position can see another position.
vis_debug_tracelos	Use this to fix things that should be visible from the current camera position, but aren't. It will trace a grid of rays covering the current screen and update the vis to include any new lines of sight found. These lines of sight are recorded in your los.bin file for future map compiles.
vis_debug_lock	Toggle locking vis LOS origin to current camera position on/off.
vis_debug_currentcluster	Prints the current cluster number to the console.
vis_debug_dumpvisibleclusters	Prints the list of visible clusters to the console.
vis_debug_drawcluster	Add cluster # to visualization, (-1) to clear.

Просмотр vis в Hammer

Используйте Visibility contributors view, чтобы переключать любую геометрию, которая не влияет на vis. Этот режим скрывает любую геометрию, которая не будет блокировать визы и облегчит обнаружение ошибок на ваших уровнях. Для дальнейших примеров загрузите выпущенные карты из игры, которые поставляются вместе с SDK.

Смотрите Load Compiled Vis Data для загрузки данных vis кластера в 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.

A hole in the boundary geometry of the level causing vis to extend into empty space.

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.

skyvisblocker is being used to seal the level instead of tooksskybox causing unexpected results. Note the large clusters on the left which are outside of the world.

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.

Using toolssolidblocklight outside the level causing unwanted vis clusters to be added.

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.

An outward facing wall at the edge of the level resulting in vis filling 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.

A building roof poking through the boundary of the level resulting in extra spacing being added.

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.

The entire water tower object is outside the visible region of the map and does not show up in game and should probably be in the skybox based on its position.