Visportals - Revision history

Datiswous: /* How and where to create visportals */ added info about DR-button "make visportal"

2025-12-09T23:28:55Z

How and where to create visportals: added info about DR-button "make visportal"

← Older revision		Revision as of 23:28, 9 December 2025
Line 51:		Line 51:
	* Make a thin brush like a wall. Ideally make it rectangular for best sound propagation (see ''Sound Propagation'' later.) It can extend beyond the gap so does not necessarily need to be the same shape - see ''Where to place your Visportal'' later.		* Make a thin brush like a wall. Ideally make it rectangular for best sound propagation (see ''Sound Propagation'' later.) It can extend beyond the gap so does not necessarily need to be the same shape - see ''Where to place your Visportal'' later.
	* Give it '''textures > editor > visportal''' to either of the main surfaces facing towards or away from you. It does not matter which except you need to be aware which it is because the visportal will be effective at that one face. (Use {{Ctrl}} + {{Shift}} + {{LMB}} on the face in the Dark Radiant camera view to select one face.)		* Give it '''textures > editor > visportal''' to either of the main surfaces facing towards or away from you. It does not matter which except you need to be aware which it is because the visportal will be effective at that one face. (Use {{Ctrl}} + {{Shift}} + {{LMB}} on the face in the Dark Radiant camera view to select one face.)

			Instead of this custom method there's also a dedicated button for this in DarkRadiant. 1. Select a brush. 2. Right-click. 3. Choose option "Make Visportal".

Thebigh: /* Sound Propagation */ typo

2025-02-07T20:52:41Z

Sound Propagation: typo

← Older revision		Revision as of 20:52, 7 February 2025
Line 148:		Line 148:


	Sound ''going to the AI'' travels the shortest distance through a visportal, passing at any point on the visportal surface. Mappers should always use rectangular visportals unless you have no choice with an awkwardly shaped gap or if the gap is out of range of AI, for example along a sloping roof where AI never go. '''It also still assumes that when you do have four sides, they are perpendicular.''' If you have some non-90 degree angles between the sides, some ~~wierdness~~ may ensue. For example, an AI that is alerted in the dark (or facing away) by hearing a sound from the player that passes through an irregular visportal might run to the center of the visportal rather than directly to where the player made the noise. Irregular visportals large enough to make this effect noticeable are likely to be uncommon.		Sound ''going to the AI'' travels the shortest distance through a visportal, passing at any point on the visportal surface. Mappers should always use rectangular visportals unless you have no choice with an awkwardly shaped gap or if the gap is out of range of AI, for example along a sloping roof where AI never go. '''It also still assumes that when you do have four sides, they are perpendicular.''' If you have some non-90 degree angles between the sides, some weirdness may ensue. For example, an AI that is alerted in the dark (or facing away) by hearing a sound from the player that passes through an irregular visportal might run to the center of the visportal rather than directly to where the player made the noise. Irregular visportals large enough to make this effect noticeable are likely to be uncommon.

	This will be okay for smaller irregular visportals, but the error (path difference from the minimal path) will get more noticeable the larger the visportal.		This will be okay for smaller irregular visportals, but the error (path difference from the minimal path) will get more noticeable the larger the visportal.
Line 174:		Line 174:
	[[Sound Propagation: Part 1]] and		[[Sound Propagation: Part 1]] and
	[[Sound Propagation: Part 2]]		[[Sound Propagation: Part 2]]



	== Engine changes ==		== Engine changes ==

OrbWeaver: Update troubleshooting section with minor formatting and mention DR's ability to load the pointfile without renaming.

2021-10-20T19:41:26Z

Update troubleshooting section with minor formatting and mention DR's ability to load the pointfile without renaming.

← Older revision		Revision as of 19:41, 20 October 2021
Line 192:		Line 192:
	*# dmap_fixBrushOpacityFirstSide 0		*# dmap_fixBrushOpacityFirstSide 0

	== ~~Trouble-shooting~~ ==		== Troubleshooting ==

	Starting from TDM 2.08, dmap provides several useful diagnostics for visportalling problems. Every visportal with a problem is reported to the game console as a warning. You might want to [[Reporting Problem#condump\|enable logFile]] to make it easier to read the whole dmap output. Aside from that, most warnings are accompanied by .lin files (generated near your .map), which can be viewed in DR.		Starting from TDM 2.08, dmap provides several useful diagnostics for visportalling problems. Every visportal with a problem is reported to the game console as a warning. You might want to [[Reporting Problem#condump\|enable logFile]] to make it easier to read the whole dmap output. Aside from that, most warnings are accompanied by .lin files (generated near your .map), which can be viewed in DR.
	Below you can see the different types of warnings produced by dmap.		Below you can see the different types of warnings produced by dmap.

			;<tt>Portal %d at (%s) dropped</tt>
			: The mentioned visportal does not separate the space into two isolated areas. This is usually called "internal leak". Such visportal is dropped because it appears to be fully contained in one visleaf, while every visportal must separate two different visleafs from each other.
			:Remember, the visportal face must be surrounded by opaque worldspawn brushes. Entities have no effect on visportals and visleafs, and brushes with any nodraw material are also ignored. If brief inspection does not help, load the .lin file in DR: it shows a closed path passing through the visportal which is not blocked by anything. In order to make visportal functional, you must block this path at least somewhere: the exact understanding of what went wrong and how to fix it is up to you.

	<tt>Portal %d at (%s) dropped</tt>: ~~The mentioned visportal does not separate the space into two isolated areas.~~ This is ~~usually called~~ "~~internal leak~~". ~~Such~~ visportal ~~is dropped because it appears to be~~ fully ~~contained~~ in ~~one visleaf, while every visportal must separate two different visleafs from each~~ other.		;<tt>Portal %d at (%s) dropped as leaky</tt>
	~~Remember,~~ the visportal ~~face must be surrounded by opaque worldspawn brushes. Entities have no effect on visportals and visleafs~~, ~~and brushes with any nodraw material are also ignored. If brief inspection does not help~~, ~~load the~~ .~~lin file in DR: it shows a closed path passing through the visportal which is not blocked by anything~~. ~~In order to make visportal functional, you must block this path at least somewhere: the exact understanding of what went wrong and how to fix~~ it ~~is up to you~~.		:This is popular subcase of "dropped" warning, implemented in TDM 2.10.
			:A proper visportal must have all of its boundary edges fully in contact with opaque geometry or other visportals. You should see "as leaky" clarification when this rule is broken.
			:To fix the visportal, inspect its boundary, i.e. where it touches solid geometry.

	~~<tt>Portal %d at (%s)~~ dropped as leaky~~</tt>:~~ This ~~is popular subcase of "~~dropped~~" warning, implemented in TDM 2~~.10.		: '''TIPS:''' If you have any portals "dropped as leaky", save yourself some time by correcting them first. This will often stop other (good) visportals from being dropped. The .lin file discussed below will often show you exactly where the boundary problem is. Be aware that occasionally you may find a "dropped" portal that should have been tagged "dropped as leaky"; the detection algorithm is approximate.
	~~A proper visportal must have all of its~~ boundary ~~edges fully in contact with opaque geometry or other visportals~~. ~~You~~ should ~~see~~ "as leaky" ~~clarification when this rule~~ is ~~broken.~~
	~~To fix the visportal, inspect its boundary, i.e. where it touches solid geometry~~.

	~~'''TIPS~~:~~''' If you have any portals "dropped as leaky"~~, ~~save yourself some time by correcting them first~~. ~~This will often stop other (good)~~ visportals ~~from being dropped~~. ~~The~~ .~~lin file discussed below will often show you exactly where~~ the ~~boundary~~ problem ~~is. Be aware that occasionally you may~~ find ~~a "dropped" portal that should have been tagged "dropped as leaky"; the detection algorithm is approximate~~.		;<tt>Portals [%s] at (%s) overlap</tt>
			:Two or more visportals geometrically overlap, which is going to be confuse the engine. In most cases the offending visportals are exactly equal, which is why it is very hard to notice without warning. Note that it is OK for visportals to touch each other.
			:In order to fix the problem, find both visportals in DR, and probably just delete one of them.

	<tt>Portals [%s] at (%s) overlap</tt>: Two or more visportals geometrically overlap, which is going to be confuse the engine. In most cases the offending visportals are exactly equal, which is why it is very hard to notice without warning. Note that it is OK for visportals to touch each other.		;<tt>Portal %d at (%s) is useless</tt>
	~~In order to fix the problem, find both visportals in DR, and probably just delete one of them.~~		:No part of this visportal is within the playable space. Sometimes such visportal is fully inside opaque brushes or lie on the boundary of opaque brush. Sometimes the whole visportal hangs somewhere in outer space, outside of any playable locations.
			: Find this visportal in DR, verify that it is not necessary, and delete it.
	<tt>Portal %d at (%s) is useless</tt>: No part of this visportal is within the playable space. Sometimes such visportal is fully inside opaque brushes or lie on the boundary of opaque brush. Sometimes the whole visportal hangs somewhere in outer space, outside of any playable locations.
	Find this visportal in DR, verify that it is not necessary, and delete it.

	<tt>brush %d has multiple area portal sides at %s</tt>: More than one side/face of this brush is marked with visportal texture, which is not supported by engine. Remember that visportal brush must have exactly one face with visportal texture and all the other faces with nodraw texture.
	First, find the brush. If any face has visportal material by mistake, change it to nodraw material. If both sides should work as visportals, then split the brush into two, each with one visportalled face.

			;<tt>brush %d has multiple area portal sides at %s</tt>
			:More than one side/face of this brush is marked with visportal texture, which is not supported by engine. Remember that visportal brush must have exactly one face with visportal texture and all the other faces with nodraw texture.
			:First, find the brush. If any face has visportal material by mistake, change it to nodraw material. If both sides should work as visportals, then split the brush into two, each with one visportalled face.

	When investigating a particular warning, there are several ways to find and debug the visportal.		When investigating a particular warning, there are several ways to find and debug the visportal.
	# The brush number of the problematic portal is reported in the warning itself (like: <tt>Portal 5237</tt>). You can quickly find the brush in DR by using "Map -> Find Brush" feature, setting "Entity Number" to 0. Beware that brush numbering changes when you modify the map. If the numbers lead you to non-visportal brushes, then you most likely need to rerun dmap to get the new numbers.		# The brush number of the problematic portal is reported in the warning itself (like: <tt>Portal 5237</tt>). You can quickly find the brush in DR by using "Map -> Find Brush" feature, setting "Entity Number" to 0. Beware that brush numbering changes when you modify the map. If the numbers lead you to non-visportal brushes, then you most likely need to rerun dmap to get the new numbers.
	# The warning usually contains world 3D coordinates (like: <tt>at (347.25 -490 790)</tt>). These coordinates are much more stable that brush numbers and won't change between runs. You can use '''setviewpos''' in-game to teleport to specified coordinates, and hopefully DR will have such feature too in future.		# The warning usually contains world 3D coordinates (like: <tt>at (347.25 -490 790)</tt>). These coordinates are much more stable that brush numbers and won't change between runs. You can use '''setviewpos''' in-game to teleport to specified coordinates, and hopefully DR will have such feature too in future.
	# For every dropped or overlapped visportal, a leakfile is dumped into a .lin file. The filename is reported right after the warning itself (like: <tt>saved mapname_portalL_coords.lin (%i points)</tt>. The capital letter after the word "portal" indicates the type of problem (e.g., with TDM 2.08, O = Overlap, L = dropped/Leaked; with TDM 2.10, O = Overlapped, D = Dropped, L = dropped as Leaky). The file is located in the same directory where .map file is located. In order to open it in DR, ~~rename it~~ to ~~<tt>mapname~~.lin~~</tt> and click at "File -> Pointfile" DR menu~~. Use "View -> Camera -> Next/Previous leak spot" (or respectively Ctrl+Shift~K and Ctrl+Shift~L) to teleport to leak location and travel along its points. Fly around: follow the path, see where it crosses something that you considered opaque while it is not. ~~Hopefully, future version of DR would make it easier to open arbitrary .lin file, so that renaming files manually won't be necessary.~~		# For every dropped or overlapped visportal, a leakfile is dumped into a .lin file. The filename is reported right after the warning itself (like: <tt>saved mapname_portalL_coords.lin (%i points)</tt>. The capital letter after the word "portal" indicates the type of problem (e.g., with TDM 2.08, O = Overlap, L = dropped/Leaked; with TDM 2.10, O = Overlapped, D = Dropped, L = dropped as Leaky). The file is located in the same directory where .map file is located. In order to open it in DR, use the '''File → Pointfile''' menu option, which will show a dialog allowing you to choose the appropriate .lin file if there is more than one available. Use '''View → Camera → Next/Previous leak spot''' (or respectively '''Ctrl+Shift+K''' and '''Ctrl+Shift+L''') to teleport to leak location and travel along its points. Fly around: follow the path, see where it crosses something that you considered opaque while it is not.


	If you have fixed all warnings but some visportal doesn't work at all (i.e. does not show as either red or green while you are directly in its area and looking at it and you have '''r_showPortals''' enabled), then make sure the visportal is worldspawn, not some entity with a misapplied visportal texture.		If you have fixed all warnings but some visportal doesn't work at all (i.e. does not show as either red or green while you are directly in its area and looking at it and you have '''r_showPortals''' enabled), then make sure the visportal is worldspawn, not some entity with a misapplied visportal texture.

Nbohr1more: /* What is rendering? */

2021-09-25T19:53:59Z

What is rendering?

← Older revision		Revision as of 19:53, 25 September 2021
Line 31:		Line 31:

	You ''should'' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.		You ''should'' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.
	<br>Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you		<br>Scissors happen on the GL driver side after geometry has already been uploaded.
	~~<br>~~prevent the geometry from being uploaded to your GPU in the first place.		<br> They help with performance but the best performance happens when you prevent the geometry from being uploaded to your GPU in the first place.

	'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still		'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still

Nbohr1more: /* What is rendering? */

2021-09-25T19:53:06Z

What is rendering?

← Older revision		Revision as of 19:53, 25 September 2021
Line 30:		Line 30:
	You can see that for the purpose of testing performance use 2 above which shows all that would be rendered (whether visible to the player or not.) You can use 3 to see ''all'' triangles up to the next closed visportal but remember not all of it will be rendered so will not affect performance.		You can see that for the purpose of testing performance use 2 above which shows all that would be rendered (whether visible to the player or not.) You can use 3 to see ''all'' triangles up to the next closed visportal but remember not all of it will be rendered so will not affect performance.

	You '''should''' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.		You ''should'' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.
	<br>Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you		<br>Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you
	<br>prevent the geometry from being uploaded in the first place.		<br>prevent the geometry from being uploaded to your GPU in the first place.

	'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still		'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still

Nbohr1more at 19:51, 25 September 2021

2021-09-25T19:51:53Z

← Older revision		Revision as of 19:51, 25 September 2021
Line 31:		Line 31:

	You '''should''' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.		You '''should''' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.
	Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you		<br>Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you
	prevent the geometry from being uploaded in the first place.		<br>prevent the geometry from being uploaded in the first place.
	'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still optimize away geometry that you were
	unable to optimize away with visportals.		'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still
			<br>optimize away geometry that you were unable to optimize away with visportals.

	Here is a short video with a decent visual breakdown:		Here is a short video with a decent visual breakdown:

Nbohr1more: /* What is rendering? */

2021-09-25T19:50:47Z

What is rendering?

← Older revision		Revision as of 19:50, 25 September 2021
Line 30:		Line 30:
	You can see that for the purpose of testing performance use 2 above which shows all that would be rendered (whether visible to the player or not.) You can use 3 to see ''all'' triangles up to the next closed visportal but remember not all of it will be rendered so will not affect performance.		You can see that for the purpose of testing performance use 2 above which shows all that would be rendered (whether visible to the player or not.) You can use 3 to see ''all'' triangles up to the next closed visportal but remember not all of it will be rendered so will not affect performance.

	You ~~might~~ also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card ~~but tells it not to render~~. ~~'''r_useScissor 1''' helps~~ performance but ~~even sending~~ the geometry ~~uses processor time so if you can reduce it by adjusting visportal placement so much~~ the ~~better~~.		You '''should''' also use '''r_useScissor 0''' to show geometry outside the visportal wireframe that Doom still sends to the video card.
			Scissors happen on the GL driver side after geometry has already been uploaded. They help with performance but the best performance happens when you
	(Remember to return to '''r_useScissor 1''' when you are done with visportal testing.)		prevent the geometry from being uploaded in the first place.
			'''Remember''' to return to '''r_useScissor 1''' when you are done with "visportal testing" so that scissors can still optimize away geometry that you were
			unable to optimize away with visportals.

	Here is a short video with a decent visual breakdown:		Here is a short video with a decent visual breakdown:

Nbohr1more at 19:44, 25 September 2021

2021-09-25T19:44:24Z

← Older revision		Revision as of 19:44, 25 September 2021
Line 287:		Line 287:
	== See also ==		== See also ==
	There are other good visportal tutorials to be found under:		There are other good visportal tutorials to be found under:
	~~http~~://~~www~~.~~iddevnet~~.~~com~~/doom3/visportals.~~php~~ and ~~http~~://~~www~~.~~modwiki~~.~~net/wiki~~/Visportal		https://iddevnet.dhewm3.org/doom3/visportals.html and https://modwiki.dhewm3.org/Visportal

	== Visportals, Func_statics and Worldspawn Brushes ==		== Visportals, Func_statics and Worldspawn Brushes ==

Geep: /* See also */ Location_Settings

2021-04-23T02:13:01Z

Geep: /* Trouble-shooting */ Added TIPS about "dropped as leaky"; more about naming of O, D, L leakfiles

2021-04-23T02:01:01Z

Trouble-shooting: Added TIPS about "dropped as leaky"; more about naming of O, D, L leakfiles

← Older revision		Revision as of 02:01, 23 April 2021
Line 201:		Line 201:
	A proper visportal must have all of its boundary edges fully in contact with opaque geometry or other visportals. You should see "as leaky" clarification when this rule is broken.		A proper visportal must have all of its boundary edges fully in contact with opaque geometry or other visportals. You should see "as leaky" clarification when this rule is broken.
	To fix the visportal, inspect its boundary, i.e. where it touches solid geometry.		To fix the visportal, inspect its boundary, i.e. where it touches solid geometry.

			'''TIPS:''' If you have any portals "dropped as leaky", save yourself some time by correcting them first. This will often stop other (good) visportals from being dropped. The .lin file discussed below will often show you exactly where the boundary problem is. Be aware that occasionally you may find a "dropped" portal that should have been tagged "dropped as leaky"; the detection algorithm is approximate.

	<tt>Portals [%s] at (%s) overlap</tt>: Two or more visportals geometrically overlap, which is going to be confuse the engine. In most cases the offending visportals are exactly equal, which is why it is very hard to notice without warning. Note that it is OK for visportals to touch each other.		<tt>Portals [%s] at (%s) overlap</tt>: Two or more visportals geometrically overlap, which is going to be confuse the engine. In most cases the offending visportals are exactly equal, which is why it is very hard to notice without warning. Note that it is OK for visportals to touch each other.
Line 215:		Line 217:
	# The brush number of the problematic portal is reported in the warning itself (like: <tt>Portal 5237</tt>). You can quickly find the brush in DR by using "Map -> Find Brush" feature, setting "Entity Number" to 0. Beware that brush numbering changes when you modify the map. If the numbers lead you to non-visportal brushes, then you most likely need to rerun dmap to get the new numbers.		# The brush number of the problematic portal is reported in the warning itself (like: <tt>Portal 5237</tt>). You can quickly find the brush in DR by using "Map -> Find Brush" feature, setting "Entity Number" to 0. Beware that brush numbering changes when you modify the map. If the numbers lead you to non-visportal brushes, then you most likely need to rerun dmap to get the new numbers.
	# The warning usually contains world 3D coordinates (like: <tt>at (347.25 -490 790)</tt>). These coordinates are much more stable that brush numbers and won't change between runs. You can use '''setviewpos''' in-game to teleport to specified coordinates, and hopefully DR will have such feature too in future.		# The warning usually contains world 3D coordinates (like: <tt>at (347.25 -490 790)</tt>). These coordinates are much more stable that brush numbers and won't change between runs. You can use '''setviewpos''' in-game to teleport to specified coordinates, and hopefully DR will have such feature too in future.
	# For every dropped visportal, a leakfile is dumped into a .lin file. The filename is reported right after the warning itself (like: <tt>saved mapname_portalL_coords.lin (%i points)</tt>. The file is located in the same directory where .map file is located. In order to open it in DR, rename it to <tt>mapname.lin</tt> and click at "File -> Pointfile" DR menu. Use "View -> Camera -> Next/Previous leak spot" (or respectively Ctrl+Shift~K and Ctrl+Shift~L) to teleport to leak location and travel along its points. Fly around: follow the path, see where it crosses something that you considered opaque while it is not. Hopefully, future version of DR would make it easier to open arbitrary .lin file, so that renaming files manually won't be necessary.		# For every dropped or overlapped visportal, a leakfile is dumped into a .lin file. The filename is reported right after the warning itself (like: <tt>saved mapname_portalL_coords.lin (%i points)</tt>. The capital letter after the word "portal" indicates the type of problem (e.g., with TDM 2.08, O = Overlap, L = dropped/Leaked; with TDM 2.10, O = Overlapped, D = Dropped, L = dropped as Leaky). The file is located in the same directory where .map file is located. In order to open it in DR, rename it to <tt>mapname.lin</tt> and click at "File -> Pointfile" DR menu. Use "View -> Camera -> Next/Previous leak spot" (or respectively Ctrl+Shift~K and Ctrl+Shift~L) to teleport to leak location and travel along its points. Fly around: follow the path, see where it crosses something that you considered opaque while it is not. Hopefully, future version of DR would make it easier to open arbitrary .lin file, so that renaming files manually won't be necessary.

← Older revision		Revision as of 02:13, 23 April 2021
Line 310:		Line 310:
	*[http://forums.thedarkmod.com/topic/18948-have-we-been-selling-visportals-short/ Have we been selling visportals short?]		*[http://forums.thedarkmod.com/topic/18948-have-we-been-selling-visportals-short/ Have we been selling visportals short?]
	*[http://forums.thedarkmod.com/topic/19707-diagonaly-placed-vis-portal/ Diagonally placed visportal?]		*[http://forums.thedarkmod.com/topic/19707-diagonaly-placed-vis-portal/ Diagonally placed visportal?]
			*Visportals also help delineate Location Zones, with specific ambient lighting, ambient sounds, and enter/exit script events. See [[Location Settings]].

	[[Category:Skybox]]		[[Category:Skybox]]
	[[Category:Visportal]]		[[Category:Visportal]]
	{{tutorial-editing}}		{{tutorial-editing}}