Fr/VIS optimization: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{LanguageBar|title = Visibilité}} | {{LanguageBar|title = Visibilité}} | ||
{{gldsrc topicon}} {{Source topicon}} | {{TabsBar|main=Visibility}} | ||
{{gldsrc topicon}} {{Source topicon}} {{ACategory|Hammer}} {{ACategory|Level_Design}} | |||
{{subpage|{{L|Optimization/Level_Design|Optimization (level design)}}}} | {{subpage|{{L|Optimization/Level_Design|Optimization (level design)}}}} | ||
{{cleanup|Cet article couvre à l'origine uniquement {{src|2}}, mais des informations {{gldsrc|2}} ont été ajoutées, tout comme la plupart des concepts. Néanmoins, beaucoup d'éléments Source ne sont pas suffisants, et les éléments d'optimisation fournis par | {{cleanup|Cet article couvre à l'origine uniquement {{src|2}}, mais des informations {{gldsrc|2}} ont été ajoutées, tout comme la plupart des concepts. Néanmoins, beaucoup d'éléments Source ne sont pas suffisants, et les éléments d'optimisation fournis par {{L|ZHLT}} et le standard {{L|VHLT}} ne sont pas mentionnés.}} | ||
Sans | Sans {{L|VIS}}, tout ce qui est dans une carte est dessinée en permanence, indépendamment du fait que le joueur puisse le voir ou non, ce qui réduit les performances du jeu (et sa fréquence d'affichage). Très clairement, la liste de objets à afficher doit être découpée, mais comment ? Cela prendrait beaucoup trop de temps pour déterminer si un objet ou une surface peut être vu plutôt que les générer en premier lieu! | ||
Les moteurs de jeux doivent faire un compromis. {{L|GoldSrc|GorldSrc}} et {{L|Source|Source}} utilisent tous deux le format {{L|Binary Space Partition|BSP}}, basé sur l'implémentation {{quake|2}} de {{Wikipedia|John Carmack|John Carmack}}. Cette page explique comme cela fonctionne et comment l'utiliser. | Les moteurs de jeux doivent faire un compromis. {{L|GoldSrc|GorldSrc}} et {{L|Source|Source}} utilisent tous deux le format {{L|Binary Space Partition|BSP}}, basé sur l'implémentation {{quake|2}} de {{Wikipedia|John Carmack|John Carmack}}. Cette page explique comme cela fonctionne et comment l'utiliser. | ||
| Line 15: | Line 16: | ||
L'image ci-contre à gauche montre comment les feuilles devraient être générées sur un couloir en U (un découpage blanc a été ajouté pour plus de lisibilité). Il n'y a pas de ligne de mire entre les feuilles 1 et 3. Par conséquent lorsque la camera est dans l'une de ces feuilles, le contenu de l'autre feuille n'est pas généré. Ce calcul très simple consiste à consulter un tableau de visibilité. | L'image ci-contre à gauche montre comment les feuilles devraient être générées sur un couloir en U (un découpage blanc a été ajouté pour plus de lisibilité). Il n'y a pas de ligne de mire entre les feuilles 1 et 3. Par conséquent lorsque la camera est dans l'une de ces feuilles, le contenu de l'autre feuille n'est pas généré. Ce calcul très simple consiste à consulter un tableau de visibilité. | ||
Il y a cependant un problème avec la feuille 2. Le contenu des 3 feuilles est généré lorsque la caméra est à l'intérieur de celle-ci, mis à part l' | Il y a cependant un problème avec la feuille 2. Le contenu des 3 feuilles est généré lorsque la caméra est à l'intérieur de celle-ci, mis à part l'{{L|:File:Frustum culling.png|élimition des objets hors champ}}, même si le mur de gauche bouche complètement la vue. Il existe des outils permettant de surmonter ceci, que nous allons bientôt aborder. Gardez bien à l'esprit que dans beaucoup de situations, résoudre ce problème sera plus {{L|expensive|couteux}} que de simplement dessiner la scène de manière moins optimale. | ||
Soyez bien conscient que les {{L|displacement|displacement}}s, {{L|Point entity|point}}s et {{L|Brush entity|bloc}}s (incluant [[#Blocs_détail|Blocs détail]]) n'affectent pas les feuilles. Créer un {{L|world brush|bloc monde}} {{L|nodraw|NODRAW}} si cela pose problème: il est assez courant que des displacements soient créés comme des 'skins' détaillés par dessus un bloc de structure, par exemple. | Soyez bien conscient que les {{L|displacement|displacement}}s, {{L|Point entity|point}}s et {{L|Brush entity|bloc}}s (incluant [[#Blocs_détail|Blocs détail]]) n'affectent pas les feuilles. Créer un {{L|world brush|bloc monde}} {{L|nodraw|NODRAW}} si cela pose problème: il est assez courant que des displacements soient créés comme des 'skins' détaillés par dessus un bloc de structure, par exemple. | ||
| Line 25: | Line 26: | ||
===Réduire le temps de compilation VIS=== | ===Réduire le temps de compilation VIS=== | ||
{{L|VVIS}} (or {{L|VIS}}/{{L|HLVIS}} in {{gldsrc}}) the tool that calculates visibility between leaves (whereas {{L|VBSP}} (or {{L|QBSP2}}/{{L|HLBSP}} creates them). It shouldn't take more than a few minutes to finish work on even the most complex maps, and if it does, chances are you need to do some of the following. Even if it doesn't, they're good practice! | |||
* Use [[#Detail_brushes|detail brushes]] appropriately. | * Use [[#Detail_brushes|detail brushes]] appropriately. | ||
* Keep | * Keep {{L|world brush}}es on the grid as much as you can. Dimensions in the power of two are good. | ||
* Use simple world brushes that have not been manipulated via other tools excessively, such as carve or vertex manipulation | * Use simple world brushes that have not been manipulated via other tools excessively, such as carve or vertex manipulation | ||
* Place {{Ent|func_viscluster}}{{hl2ep2|since}} in large areas with unbroken visibility. Leaves within it will be assumed able to see each other. | * Place {{Ent|func_viscluster}}{{hl2ep2|since}} in large areas with unbroken visibility. Leaves within it will be assumed able to see each other. | ||
* Avoid creating large open areas that the player won't see or interact with in the first place, if it's reasonable to do so. Use a | * Avoid creating large open areas that the player won't see or interact with in the first place, if it's reasonable to do so. Use a {{L|3D Skybox}} to reduce sky size, and create a world brush skeleton beneath {{L|displacement}}s. | ||
Remember that VIS compile time and in-game performance are two very different things. It may well be worth bearing a long compile if shortening it compromises your result. | Remember that VIS compile time and in-game performance are two very different things. It may well be worth bearing a long compile if shortening it compromises your result. | ||
| Line 38: | Line 39: | ||
Since {{src07|4}}, Hammer has a new function to view the current map's leaves in the 3D view: ''Map > Load Portal File''. This displays leaf edges that touch other edges as thick blue lines. It's a fantastic learning tool, as if you compile your map without VIS or RAD (then reload its portal file to refresh the display), you can see your changes' effects very quickly. | Since {{src07|4}}, Hammer has a new function to view the current map's leaves in the 3D view: ''Map > Load Portal File''. This displays leaf edges that touch other edges as thick blue lines. It's a fantastic learning tool, as if you compile your map without VIS or RAD (then reload its portal file to refresh the display), you can see your changes' effects very quickly. | ||
{{Src06|4}} users and earlier must rely on the | {{Src06|4}} users and earlier must rely on the {{L|glview}} application. | ||
{{tip|For even more clarity, use auto | {{tip|For even more clarity, use auto {{L|visgroup}}s to remove objects from your map that don't block visibility—generally everything but "World Geometry," plus "Tool Brushes," "Water," and "Displacements."}} | ||
For in-game inspections, there is a | For in-game inspections, there is a {{L|console variable}} called "{{ent|mat_leafvis}}". <code>mat_leafvis 3</code> will outline all the visleaves in the {{L|PVS}}, while <code>mat_leafvis 1</code> will just outline the leaf that the camera is currently in. (This variable is a {{L|sv_cheats|cheat}}.) | ||
You can also inspect the geometry itself through using the {{ent|mat_wireframe}} console variable. <code>mat_wireframe 1</code> will display how polygons are drawn in the current | You can also inspect the geometry itself through using the {{ent|mat_wireframe}} console variable. <code>mat_wireframe 1</code> will display how polygons are drawn in the current {{L|PVS}}. (This variable is a {{L|sv_cheats|cheat}} as well.) | ||
==Conseils== | ==Conseils== | ||
| Line 52: | Line 53: | ||
Unfortunately, leaves don't always work out so well as they did in our first example. Consider the alternative layout on the left (in practice things would be configured as per the first image, but put that aside for a moment): in this example the leaves can all see each other, leading to the whole area being drawn at once for no good reason. This is where '''Hints''' come in. | Unfortunately, leaves don't always work out so well as they did in our first example. Consider the alternative layout on the left (in practice things would be configured as per the first image, but put that aside for a moment): in this example the leaves can all see each other, leading to the whole area being drawn at once for no good reason. This is where '''Hints''' come in. | ||
A hint is a brush face | A hint is a brush face {{L|Applying Materials|textured}} with the special <code>tools\toolshint</code> material, which slices any leaves it intersects in two (faces of the brush that should ''not'' split leaves must be textured with <code>tools\toolsskip</code>). In our example, we would place a hint where the purple line indicates, so that it slices leaves 1 and 3 to the same shape that they were in our first example. | ||
It isn't possible to merge leaves together, so after hinting there will be three separate leaves on the right-hand side. Thankfully this isn't a huge problem. | It isn't possible to merge leaves together, so after hinting there will be three separate leaves on the right-hand side. Thankfully this isn't a huge problem. | ||
{{tip|It's a good idea to use hints to separate | {{tip|It's a good idea to use hints to separate {{L|expensive}} and {{L|cheap}} areas of the same leaf, if doing so will reduce the amount of time that the expensive areas are drawn for.}} | ||
==Blocs détail== | ==Blocs détail== | ||
As was mentioned above, leaves are molded around world brushes. But what if you ''don't'' want a brush to do that? If you have a brush that can be seen around at all times (e.g., a statue plinth, or a small free-standing wall), there’s no point in creating lots of extra leaves around it. | As was mentioned above, leaves are molded around world brushes. But what if you ''don't'' want a brush to do that? If you have a brush that can be seen around at all times (e.g., a statue plinth, or a small free-standing wall), there’s no point in creating lots of extra leaves around it. | ||
In these situations you want '''{{ent|func_detail}}'''. It's an | In these situations you want '''{{ent|func_detail}}'''. It's an {{L|internal entity}} which makes the compilers ignore the brush when calculating visibility, without otherwise affecting its behaviour. {{L|func_detail#Good_candidates|It's not uncommon for large portions of a map's brushes to be detail}}. | ||
== Surfaces Nodraw== | == Surfaces Nodraw== | ||
[[File:toolsnodraw.gif|right|link=nodraw|tools\toolsnodraw, in Source]] | [[File:toolsnodraw.gif|right|link=nodraw|tools\toolsnodraw, in Source]] | ||
[[File:DOD hlbasics-NULL.png|right|link=Tool_textures_(GoldSrc)#ZHLT.WAD|64px|NULL, from ZHLT.WAD and HLBASICS.WAD]] | [[File:DOD hlbasics-NULL.png|right|link=Tool_textures_(GoldSrc)#ZHLT.WAD|64px|NULL, from ZHLT.WAD and HLBASICS.WAD]] | ||
If a player cannot see a brush face without cheating or being a spectator, it's a good idea to apply the special {{mono|toolsnodraw}} material {{src|in}} or {{mono|NULL}} texture {{gldsrc|in}} to it. Nodraw removes the entire face when the map is compiled without affecting visibility, which reduces both rendering time and, since no | If a player cannot see a brush face without cheating or being a spectator, it's a good idea to apply the special {{mono|toolsnodraw}} material {{src|in}} or {{mono|NULL}} texture {{gldsrc|in}} to it. Nodraw removes the entire face when the map is compiled without affecting visibility, which reduces both rendering time and, since no {{L|lightmap}} needs to be calculated, map file size. | ||
You do ''not'' need to apply Nodraw to faces that are touching the void (i.e., outside the map) or to brush faces touching other brush faces tied to the same entity (the world being one big entity of its own). See | You do ''not'' need to apply Nodraw to faces that are touching the void (i.e., outside the map) or to brush faces touching other brush faces tied to the same entity (the world being one big entity of its own). See {{L|Brush#In-game}}. {{tip|{{src|in}} VBSP combines all <code>func_detail</code>s into one at compile time, so faces of <code>func_detail</code>s that are flush with each other don't need to be nodrawn, either.<br>{{gldsrc|in}} HLCSG removes func_detail faces that share a detail level, or are flush with a lower detail level.}} | ||
==Areaportals {{only|{{src|4.1}}}} == | ==Areaportals {{only|{{src|4.1}}}} == | ||
| Line 78: | Line 79: | ||
In the image to the left all of the leaves can see each other, and this time there is very little that hint brushes can achieve. | In the image to the left all of the leaves can see each other, and this time there is very little that hint brushes can achieve. | ||
In this situation we should create ''' | In this situation we should create '''{{L|Areaportal}}s''' at the mouth of selected openings. These make the engine perform the per-object line of sight testing that Carmack created the BSP/visleaf system to avoid—but with that system behind it, and with the calculations restricted to when the camera looks through the areaportal, performance can be gained if one blocks enough objects from view. | ||
The image has areaportal locations marked over each mouth, but placing all four would likely hinder performance more than help it. Your strategy depends on the relative | The image has areaportal locations marked over each mouth, but placing all four would likely hinder performance more than help it. Your strategy depends on the relative {{L|Budget|cost}} of each area—in most situations, creating the large areaportal to the right and leaving the corridors alone would be best. | ||
(It is ''possible'' to use hints to reduce visibility in this situation, but only with a ridiculous number of them at very precise angles, which impacts performance in its own way. If you can't see across a room for hint brushes, then you should be using an areaportal!) | (It is ''possible'' to use hints to reduce visibility in this situation, but only with a ridiculous number of them at very precise angles, which impacts performance in its own way. If you can't see across a room for hint brushes, then you should be using an areaportal!) | ||
{{tip|Areaportals are also useful because they can be closed to completely and | {{tip|Areaportals are also useful because they can be closed to completely and {{L|cheap}}ly block visibility past them. It's a good idea to attach an areaportal to every window-less door in your map, so that they can automatically perform this function.}} | ||
{{note|Areaportals make no account for objects ''in front'' of them.}} | {{note|Areaportals make no account for objects ''in front'' of them.}} | ||
{{warning|Areaportals can cause problems if placed incorrectly, | {{warning|Areaportals can cause problems if placed incorrectly, {{L|Areaportal|so be sure to read about them carefully}}.}} | ||
==Occluders {{only|{{source|4.1}}}}== | ==Occluders {{only|{{source|4.1}}}}== | ||
| Line 92: | Line 93: | ||
Sometimes you want to block visibility in a way that visleaves simply don't allow: consider a destructible free-standing wall behind which are standing several expensive character models. You don't want to draw the models if they aren't being seen, but without any connected world brushes to work with except the ground you can't do it by separating leaves. | Sometimes you want to block visibility in a way that visleaves simply don't allow: consider a destructible free-standing wall behind which are standing several expensive character models. You don't want to draw the models if they aren't being seen, but without any connected world brushes to work with except the ground you can't do it by separating leaves. | ||
An ''' | An '''{{L|func_occluder|Occluder}}''' is the tool for the job. It's a brush that hides models (not brushes, alas) behind it when enabled, in a similar manner to an areaportal hiding things that ''aren't'' behind it. For obvious reasons, it should be entirely contained inside an opaque object. | ||
It is possible, however, to convert some brushes into models with something like | It is possible, however, to convert some brushes into models with something like {{L|Propper}}. That way, it's possible to hide more models with an occluder. This should be done on {{L|func_detail|detail}} brushes, which aren't used for cutting {{L|visleaf|visleaves}}. | ||
== Draw Distance == | == Draw Distance == | ||
If you are dealing with a large open area without any cover at all then there isn't a lot you can do but remove detail or employ | If you are dealing with a large open area without any cover at all then there isn't a lot you can do but remove detail or employ {{L|env_fog_controller|fog}} to disguise a low draw distance. Configure draw distance with ''Map > Properties > Far z_clip plane''. | ||
Draw distances can also be applied selectively to props, even {{ent|prop_static}}, with the <code>Start Fade Dist/Pixels</code>and <code>End Fade Dist/Pixels</code> | Draw distances can also be applied selectively to props, even {{ent|prop_static}}, with the <code>Start Fade Dist/Pixels</code>and <code>End Fade Dist/Pixels</code>{{L|keyvalue}}s. As the names suggest, these values can represent either distance in units or pixels on-screen as per the<code>Screen Space Fade</code>KV.{{tip|In fact, all entities with a model can be faded, as well as {{L|info_overlay|overlays}}. These keyvalues are {{not in FGD}} for most of these entities, however.}} | ||
If you enter fade distances on props, it’s a good general rule to have the difference between the two numbers (start and end) be 200. It looks pretty good, and the larger that number is, the longer the model incurs an increased cost to render. Fading models do not go through the fast path and incur additional sorting cost. | If you enter fade distances on props, it’s a good general rule to have the difference between the two numbers (start and end) be 200. It looks pretty good, and the larger that number is, the longer the model incurs an increased cost to render. Fading models do not go through the fast path and incur additional sorting cost. | ||
| Line 112: | Line 113: | ||
= See also = | = See also = | ||
* | * {{L|Skybox Optimization}} | ||
Revision as of 10:44, 9 February 2025
Source, mais des informations 
GoldSrc ont été ajoutées, tout comme la plupart des concepts. Néanmoins, beaucoup d'éléments Source ne sont pas suffisants, et les éléments d'optimisation fournis par ZHLT et le standard VHLT ne sont pas mentionnés.Sans VIS, tout ce qui est dans une carte est dessinée en permanence, indépendamment du fait que le joueur puisse le voir ou non, ce qui réduit les performances du jeu (et sa fréquence d'affichage). Très clairement, la liste de objets à afficher doit être découpée, mais comment ? Cela prendrait beaucoup trop de temps pour déterminer si un objet ou une surface peut être vu plutôt que les générer en premier lieu!
Les moteurs de jeux doivent faire un compromis. GorldSrc et Source utilisent tous deux le format BSP, basé sur l'implémentation 
Quake de 
John Carmack. Cette page explique comme cela fonctionne et comment l'utiliser.
Feuilles
L'espace intérieur (i.e., non occupé par un bloc monde d'une carte BSP est divisée en feuilles. La visibilité entre ces volumes 3D est calculée au moment où la carte est compilée, et embarquée dans le fichier BSP pour utilisation par le moteur. Tout comme les blocs, les feuilles sont toujours convexes.
L'image ci-contre à gauche montre comment les feuilles devraient être générées sur un couloir en U (un découpage blanc a été ajouté pour plus de lisibilité). Il n'y a pas de ligne de mire entre les feuilles 1 et 3. Par conséquent lorsque la camera est dans l'une de ces feuilles, le contenu de l'autre feuille n'est pas généré. Ce calcul très simple consiste à consulter un tableau de visibilité.
Il y a cependant un problème avec la feuille 2. Le contenu des 3 feuilles est généré lorsque la caméra est à l'intérieur de celle-ci, mis à part l'[[Fr/
- File:Frustum culling.png|élimition des objets hors champ]], même si le mur de gauche bouche complètement la vue. Il existe des outils permettant de surmonter ceci, que nous allons bientôt aborder. Gardez bien à l'esprit que dans beaucoup de situations, résoudre ce problème sera plus couteux que de simplement dessiner la scène de manière moins optimale.
Soyez bien conscient que les displacements, points et blocs (incluant Blocs détail) n'affectent pas les feuilles. Créer un bloc monde NODRAW si cela pose problème: il est assez courant que des displacements soient créés comme des 'skins' détaillés par dessus un bloc de structure, par exemple.
Note:Les blocs monde avec textures $translucent découpent les feuilles.
Attention:Les feuilles ne peuvent pas être générées si votre carte a une fuite.
Astuce:Les feuilles sont découpées toutes les 1024 unités sur le plan xy indépendamment des blocs dans le but de découper les vastes zones. La grille sur Hammer est mise en surbrillance en rouge pour vous assister.Note:Les feuilles fonctionnent aussi bien verticalement qu'horizontalement. Le ciel est traité comme une extension des pièces et rues.Réduire le temps de compilation VIS
VVIS (or VIS/HLVIS in ) the tool that calculates visibility between leaves (whereas VBSP (or QBSP2/HLBSP creates them). It shouldn't take more than a few minutes to finish work on even the most complex maps, and if it does, chances are you need to do some of the following. Even if it doesn't, they're good practice!
- Use detail brushes appropriately.
- Keep world brushes on the grid as much as you can. Dimensions in the power of two are good.
- Use simple world brushes that have not been manipulated via other tools excessively, such as carve or vertex manipulation
- Place func_viscluster(depuis
) in large areas with unbroken visibility. Leaves within it will be assumed able to see each other. - Avoid creating large open areas that the player won't see or interact with in the first place, if it's reasonable to do so. Use a 3D Skybox to reduce sky size, and create a world brush skeleton beneath displacements.
Remember that VIS compile time and in-game performance are two very different things. It may well be worth bearing a long compile if shortening it compromises your result.
Contrôler les feuilles
Since 
Source 2007, Hammer has a new function to view the current map's leaves in the 3D view: Map > Load Portal File. This displays leaf edges that touch other edges as thick blue lines. It's a fantastic learning tool, as if you compile your map without VIS or RAD (then reload its portal file to refresh the display), you can see your changes' effects very quickly.
Source 2006 users and earlier must rely on the glview application.
Astuce:For even more clarity, use auto visgroups to remove objects from your map that don't block visibility—generally everything but "World Geometry," plus "Tool Brushes," "Water," and "Displacements."For in-game inspections, there is a console variable called "mat_leafvis". mat_leafvis 3 will outline all the visleaves in the PVS, while mat_leafvis 1 will just outline the leaf that the camera is currently in. (This variable is a cheat.)
You can also inspect the geometry itself through using the mat_wireframe console variable. mat_wireframe 1 will display how polygons are drawn in the current PVS. (This variable is a cheat as well.)
Conseils
Unfortunately, leaves don't always work out so well as they did in our first example. Consider the alternative layout on the left (in practice things would be configured as per the first image, but put that aside for a moment): in this example the leaves can all see each other, leading to the whole area being drawn at once for no good reason. This is where Hints come in.
A hint is a brush face textured with the special tools\toolshint material, which slices any leaves it intersects in two (faces of the brush that should not split leaves must be textured with tools\toolsskip). In our example, we would place a hint where the purple line indicates, so that it slices leaves 1 and 3 to the same shape that they were in our first example.
It isn't possible to merge leaves together, so after hinting there will be three separate leaves on the right-hand side. Thankfully this isn't a huge problem.
Astuce:It's a good idea to use hints to separate expensive and cheap areas of the same leaf, if doing so will reduce the amount of time that the expensive areas are drawn for.Blocs détail
As was mentioned above, leaves are molded around world brushes. But what if you don't want a brush to do that? If you have a brush that can be seen around at all times (e.g., a statue plinth, or a small free-standing wall), there’s no point in creating lots of extra leaves around it.
In these situations you want func_detail. It's an internal entity which makes the compilers ignore the brush when calculating visibility, without otherwise affecting its behaviour. It's not uncommon for large portions of a map's brushes to be detail.
Surfaces Nodraw
If a player cannot see a brush face without cheating or being a spectator, it's a good idea to apply the special toolsnodraw material (Dans ) or NULL texture (Dans ) to it. Nodraw removes the entire face when the map is compiled without affecting visibility, which reduces both rendering time and, since no lightmap needs to be calculated, map file size.
You do not need to apply Nodraw to faces that are touching the void (i.e., outside the map) or to brush faces touching other brush faces tied to the same entity (the world being one big entity of its own). See Brush#In-game.
Astuce:(Dans ) VBSP combines all func_details into one at compile time, so faces of func_details that are flush with each other don't need to be nodrawn, either.(Dans
) HLCSG removes func_detail faces that share a detail level, or are flush with a lower detail level.Areaportals (seulement dans Source)
In the image to the left all of the leaves can see each other, and this time there is very little that hint brushes can achieve.
In this situation we should create Areaportals at the mouth of selected openings. These make the engine perform the per-object line of sight testing that Carmack created the BSP/visleaf system to avoid—but with that system behind it, and with the calculations restricted to when the camera looks through the areaportal, performance can be gained if one blocks enough objects from view.
The image has areaportal locations marked over each mouth, but placing all four would likely hinder performance more than help it. Your strategy depends on the relative cost of each area—in most situations, creating the large areaportal to the right and leaving the corridors alone would be best.
(It is possible to use hints to reduce visibility in this situation, but only with a ridiculous number of them at very precise angles, which impacts performance in its own way. If you can't see across a room for hint brushes, then you should be using an areaportal!)
Astuce:Areaportals are also useful because they can be closed to completely and cheaply block visibility past them. It's a good idea to attach an areaportal to every window-less door in your map, so that they can automatically perform this function.Note:Areaportals make no account for objects in front of them.Attention:Areaportals can cause problems if placed incorrectly, so be sure to read about them carefully.Occluders (seulement dans Source)
Sometimes you want to block visibility in a way that visleaves simply don't allow: consider a destructible free-standing wall behind which are standing several expensive character models. You don't want to draw the models if they aren't being seen, but without any connected world brushes to work with except the ground you can't do it by separating leaves.
An Occluder is the tool for the job. It's a brush that hides models (not brushes, alas) behind it when enabled, in a similar manner to an areaportal hiding things that aren't behind it. For obvious reasons, it should be entirely contained inside an opaque object.
It is possible, however, to convert some brushes into models with something like Propper. That way, it's possible to hide more models with an occluder. This should be done on detail brushes, which aren't used for cutting visleaves.
Draw Distance
If you are dealing with a large open area without any cover at all then there isn't a lot you can do but remove detail or employ fog to disguise a low draw distance. Configure draw distance with Map > Properties > Far z_clip plane.
Draw distances can also be applied selectively to props, even prop_static, with the Start Fade Dist/Pixelsand End Fade Dist/Pixelskeyvalues. As the names suggest, these values can represent either distance in units or pixels on-screen as per theScreen Space FadeKV.
Astuce:In fact, all entities with a model can be faded, as well as overlays. These keyvalues are !FGD for most of these entities, however.If you enter fade distances on props, it’s a good general rule to have the difference between the two numbers (start and end) be 200. It looks pretty good, and the larger that number is, the longer the model incurs an increased cost to render. Fading models do not go through the fast path and incur additional sorting cost.
func_lod is a special brush entity that can fade out. You can't use any brushes tied to it as any other entity, however!
Sample Maps
sourcesdk_content\hl2\mapsrc\sdk_func_detail.vmfsdk_hints.vmfsdk_occluders.vmf