Talk:Areaportal: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
(→‎Code tags: Okay. Looks good.)
(Off-topic discussion moved.)
Line 93: Line 93:
=== Code tags ===
=== Code tags ===


I am pleasantly surprised that you (Jeff) put so much effort into it with pictures and all. From being just a footnote mentioned as parts of several bloated articles, areaportals now have a beautiful "home". However, as uncomforting it is telling ''you'' this, the entity <nowiki><code></nowiki> format you used was scrapped years ago. (It looks ugly and distracting, and confusions over "light" entities has been unheard of.) Do you mind if I remove the code tags? --[[User:Andreasen|Andreasen]] 10:37, 20 Sep 2007 (PDT)
(Large off-topic discussion moved to [[Help talk:Editing]].) --[[User:Andreasen|Andreasen]] 09:14, 23 Sep 2007 (PDT)
:I mind. I think it has been established as part of this wiki style to code-tag entity names amongst others. --[[User:Tourorist|Tourorist]] 13:03, 20 Sep 2007 (PDT)
::Uh, name five articles that still has the code tag (that isn't 1-2 years old). --[[User:Andreasen|Andreasen]] 13:45, 20 Sep 2007 (PDT)
:::There was some discussion of this last year, but it was not conclusive enough to merit changes as the reasons given were completely subjective and there was no consensus. The [[Help:Editing#Formatting_guidelines]] page reflects the closest guide to current usage, as well as a number of existing articles on the site that use the tags in this way. The age of the articles is also not very relevant. In fact, it's the opposite if most of them are using this format and there was no consensus on a change. In the case of this article, I actually got most of this formatting when I moved sections from the original [[Controlling Geometry Visibility and Compile Times]] page.
 
:::That said, I don't feel that strongly about this either way, so if a significant number of editors come to a consensus and want to change it in some way, that's fine. Though I do feel that entity names really need some '''visible marking''' to show that they are not just English nouns. They are keywords with significance and are almost always the focus of the text. It's the same reason we highlight other keywords like '''Menu Titles'''. Why would it be any different? There are precedents in technical documentation for this. Capitalization is often used for important keywords, but that would just be confusing in this case. Another other option is bolding, which might work better. Hope that helps. --[[User:JeffLane|JeffLane]] 18:52, 20 Sep 2007 (PDT)
 
 
::::I tried to find the previous discussion we had about this, but couldn't find it.
::::I rarely see code tags being used in articles, so I don't think that the [[Help:Editing]] page ''is'' reflecting the current usage. I've seen only three pages that uses the tag for entities as of late: [[Controlling Geometry Visibility and Compile Times]], [[areaportal]] (this page), and the one that [[User:Tourorist]] "codified" himself, believing that the tag was current usage.
::::The reason for this is natural: Besides being an unnecessary eyesore to readers, "<nowiki><code>[[entity]]</code></nowiki>" also takes twice the amount of characters to write (including special characters) than "<nowiki>[[entity]]</nowiki>", and entities are used much more commonly than console commands and file paths are.
 
::::As for special marking, many articles doesn't focus on a particular entity, but of a topic involving many entities, where they themselves are often just mentioned as mere alternatives, or even exceptions (like "[[Prop_physics]] should not be used for this."), drawing attention to totally different topics. As it is now, when entities are first mentioned, they are linked to (according to current guidelines) which is marking them in blue, and the topic is then understood. If need be, we could mark them all in blue, every time they're mentioned. That should be the closest natural markup for authors, and just looking at this very text, that markup should make all the entity names stand out, without drawing ''too'' much attention to it.
 
::::I can't argue with technical documentation standard, but judging by the article you just wrote, turning a matter-of-factly (technical) article into something a little more greeting and fleshed out, I don't think that the VDC is a 100% technical manual. Also, if compared to wikipedia, I don't see any technical lingo being marked up there.
 
::::Entities are rarely even able to be confused with nouns. Of all the entities (I checked the lists.) only four doesn't have an underscore (_) in them: [[Cycler]], [[gibshooter]], [[infodecal]], and [[light]]. There are two easy methods to deal with these:
::::# You can set the topic by linking to the entity article at its first mention (and if in any way unclear, later mentions as well), like above. The latter mentions of it is then obvious.
::::# You can refer to it as "the xxxx entity". The only entity that even comes close to being confused then, is the [[light]] entity, if someone would assume that the article was about weight instead of lighting, which would be virtually impossible to do, considering how different these topics are. When dealing with light entities as a category, one can refer to them as "light source entities" to avoid confusion.
 
:::: I wish there ''was'' a significant number of authors around to vote for ''any'' change, but considering that most articles currently use the lighter "<nowiki>[[]]</nowiki>" markup, that change would be ''back'' to using code tags. It's easier to remove the guideline than to change most of the articles in the wiki. One can't seem to find entity code tags through the search engine, but could I, I would gladly hunt down the last remaining code tags myself, if only allowed, because it makes every mention of them a bother. --[[User:Andreasen|Andreasen]] 06:48, 21 Sep 2007 (PDT)
 
::::: I wasn't the one who introduced this practice, if that's what you imply. And like Jeff, I am neither for nor against on this issue, my sole interest (as evident from my contributions) is in overall consistency of wiki, whichever way we go. --[[User:Tourorist|Tourorist]] 07:23, 21 Sep 2007 (PDT)
:::::: I'm not at all blaming you for following what you believed to be current standards. --[[User:Andreasen|Andreasen]] 08:34, 21 Sep 2007 (PDT)
 
::::: The VDC documentation is [[Wikipedia:technical writing|technical writing]], like any type of help files or user manuals are. Creating content with the Source Engine is a technical subject. It is from that perspective we try to evaluate these kinds of decisions.
 
::::: I would agree with a change if it's a positive one, or even an equal one, but I'm not convinced that removing all the entity formatting is positive. They are an important keyword, essentially a cross between a menu command and a piece of code (depending on the context), and their exact name is significant. Text formatting of some type needs to reflect that distinction when no link is present.
 
:::::The suggestion of standardizing formatting in blue is reasonable one, but would make them look like false page links, so it shouldn't be that, and adding color tags is prone to errors. Using '''bolding''' after the first link is a better alternative since it has simple wiki syntax. That would put them on the same level as menu titles and commands, which does make some sense from the perspective of most of our users. For them, picking entities is a menu choice in Hammer and the primary context they will see them (few of our users read the .fgd file, for example). ''Italics'' is another alternative, though they don't read particularly well in this typeface and point size, and readability is critical for entity names.
 
:::::As an aside, I've never been too happy about the extra gray shading behind the text in the code tags. It too dark on some monitors and lighter on others and the <tt>monospace typeface</tt> that shows up with code tags is really sufficient for the purpose. I will likely remove it in the site-wide CSS, no matter what we decide with entities. --[[User:JeffLane|JeffLane]] 11:16, 21 Sep 2007 (PDT)
 
:::::The gray background is now removed from <code>code tags</code>, and the space between section headings is now slightly increased (especially level 2 sections). --[[User:JeffLane|JeffLane]] 14:47, 21 Sep 2007 (PDT)
 
::::::When you wrote that the format had precedents in technical documentation, I assumed the highlighting in gray was some sort of technical manual standard that I must have never seen before, but [http://www.io.com/~hcexres/textbook/high.html this page] tells me it's pretty in the hands of the manual designer.
::::::Why would linking to them look like false page links? All entity pages has been written, so unless they are spelled wrong, they'll definitely be blue - not red.
::::::Although I prefer bolding over code tags, the users just see the entities in the plain, unformated text format and font, if that's what you mean. I've never seen entities as titles or commands - just plain names - but I can't speak that much for other users. I really wish more people would take part in this discussion.
::::::I don't see any changes in the CSS. I've tried updating the page. Perhaps I will have to delete the browser cache for the changes to take effect. --[[User:Andreasen|Andreasen]] 16:16, 21 Sep 2007 (PDT)
::::::: You likely just need to [[Wikipedia:Wikipedia:Bypass_your_cache|Bypass your browser cache]].
::::::: I misunderstood when you said "we could mark them all in blue", which suggested to me blue text formatting, not linking. Now I understand that you meant -- that entity names could be linked at all times. This seems like an excessive choice and is not common practice for hyperlinking (which is link on first mention, and not thereafter, though I think you know that). The link you provided seems to be targeted at technical writing for printed works, but still reinforces what I have been saying -- technical terms deserve special formatting/emphasis. I never said that gray shading was some type of standard, though I could see how you could have misunderstood my statement. I said visible marking of significant keywords has precedent in technical writing. Beyond that, the exact formatting is not as critical as long as it is consistent.
::::::: With the removal of the gray background shading, and short of any more overwhelmingly compelling discussion, this matter has received enough attention and I consider it resolved. Code tags can be used for entities in any new articles and added to existing ones incrementally. --[[User:JeffLane|JeffLane]] 15:42, 22 Sep 2007 (PDT)
::::::::Okay, now that my cache has finally been updated, the code tags are not quite as disturbing anymore, so I consider it an acceptable compromise. I'll start using them, though it'll be a lot of pages to change overtime.
::::::::Yes, linking to entities consistently would not have been common practice, but still more discreet than the grey highlighting.
::::::::The link I provided also seemed to stress not to overdo highlighting.
::::::::...but all's well now. Just a little difficult to write down, but at least it looks decent now. --[[User:Andreasen|Andreasen]] 16:20, 22 Sep 2007 (PDT)

Revision as of 09:14, 23 September 2007

Areaportal cost

Do open areaportals cost anything when they're out of sight? --Cargo Cult 08:07, 23 Sep 2005 (PDT)

They have a slight cost, I don't believe it's measurable, but possibly negligible considering map geometry and if they weren't used at all. --wisemx 09:18, 23 Sep 2005 (PDT)

Once there is alot of them it tends to become more costly.--Gear 13:45, 16 Sep 2007 (PDT)

Example map

Here's a test project we did with Jeff Lane on always open areaportals. 2.3MB ZIP archive. --wisemx 09:18, 23 Sep 2005 (PDT)

The link seems to be dead, could you please rehost it? --Tourorist 09:04, 28 Aug 2007 (PDT)

Reference to nothing

I just noticed that the there is a link to the page leaks explained. However, that page has a reference to this page. Basically, there is no further information regarding areaportal leaks. Just a comment. --Darthkillyou 09:49, 25 May 2007 (PDT)

Hopefully, enough information has been added since, but if you are still missing information about portal leaks, please let me know straight away, so that I can get on it. --Andreasen 08:55, 16 Sep 2007 (PDT)

Additional information

I found some additional information on areaportals here: Optimization_Tutorial, BSP Map Optimization This information should be moved/merged into this page. --Andreasen 10:13, 16 Sep 2007 (PDT)

Is it called "area portals" or "areaportals"?

I asked myself this question when I started working on this article, and I need evidence to support any theory. --Andreasen 10:13, 16 Sep 2007 (PDT)

I found indisputable evidence that it's called "areaportals" and not "area portals" in the listing of r_areaportal.cpp. This article needs to be moved to areaportal. --Andreasen 11:33, 16 Sep 2007 (PDT)
Yeah it is called areaportals. However there is already a func_areaportal page so keeping it Areaportal would be okay.--Gear 13:47, 16 Sep 2007 (PDT)
I don't understand. What does the entity page have to do with this page? We can't flood that page with the entire topic. --Andreasen 13:59, 16 Sep 2007 (PDT)
thats what i was saying, since there is already a entity page. Lol, never mind.--Gear 14:13, 16 Sep 2007 (PDT)

Portals needing to be block shaped

How have you come to the conclusion that portals need to be block (cube) shaped? --Andreasen 14:43, 16 Sep 2007 (PDT)

Ah yes i have tested it out, even with different settings and even on Func_areaportalwindow. The engine seems to act crazy why? Because each side represents a face or in other words a vis leaf. If a areaportal is a triangle then it creates 3 leafs, meaning no working geometry to hide. It can only be two leafes. Room 1 and Room 2 in example. Cant have two rooms in Room 1 get what i mean?--Gear 14:50, 16 Sep 2007 (PDT)
The reason I'm asking is that I created an octagonally shaped portal (with the MAIN surface shapes being octagonal), and it worked perfectly. I'll experiment further with wedges to see what you mean. --Andreasen 15:14, 16 Sep 2007 (PDT)
Actually, you're both correct in a way. func_areaportal entities can have more than 6 sides, although they can only be one brush. They certainly don't need to be orthogonal (cubes with all 90 degree sides). It is fairly common to have angled areaportals with six sides but "skewed" along the angle to connect two areas. That said, I would not go out of the way to explain the usage of areaportals with more than six brush sides, because it's quite easy to create degenerate leaves this way. Only someone with a deep understanding of the portal and leaf system would likely make one efficiently. I've seen them used this way only a handful of times by any designers in many years, and even then they could have used standard shapes just as effectively. I would not suggest it as a technique to anyone. --JeffLane 15:33, 16 Sep 2007 (PDT)
Still, I'll move this discussion to the areaportal discussion page, so that particularly curious minds can find this explanation if interested. --Andreasen 16:05, 16 Sep 2007 (PDT)
Yup so thats cool, theres alot more advanced ways to do so, but its harder eh? Thats interesting. Are any of those maps in your possession Jeff? Is so i'd like to take a a gander at em', that would be cool.--Gear 15:56, 16 Sep 2007 (PDT)

Portals being 1 unit thick

I've removed lots of these comments because I don't understand why this needs to be mentioned. Portals break visleaves, and should do so at appropriate locations. A normal dynamic door is 2 units thick, and I see no reason for archway portals to be any smaller than the thickness of the archway itself, as that would create additional visleaves. --Andreasen 16:12, 16 Sep 2007 (PDT)

Ah but yet 1 unit is the default, ask jeff, he would know.--Gear 17:10, 16 Sep 2007 (PDT)
I've been told that the old SDK manual told editors that areaportals should be made 1 unit thick, but that doesn't make it a "default". If areaportals would somehow work better if they were only 1 unit thick, then I would support it, but as it is, this "default" just adds more visleaves. It's easy to tell designers that portals should be made 1 unit thick, because it's close enough, but it still isn't the best thickness. --Andreasen 18:53, 16 Sep 2007 (PDT)
Well it still makes 1 leaf either way, but alot tinier, which in this case is sort of better considering theres nothing passing through it. Yet 1 unit is sure a default and the best to use, but yet you can still make thicker sized brushes. Why 1? Because the areaportal makes two leafs, right, so in this case, 1 unit is smaller meaning alot easier to deal with due to certain limitations you might find in mapping. Yet you can make it any size you want, but 1 tends to be best for too many reasons too count.--Gear 21:03, 16 Sep 2007 (PDT)
It doesn't have to make a leaf that complicates the rest of the brushwork. Imagine that you have a door that is flush against a frame, or have a simple archway. Making the portal not tie into other leaves, can complicate the surrounding leaves. "Certain limitations you find in mapping"? "Too many reasons to count"? Unless you care to clearify that, I'm starting to suspect that you are making things up. One shouldn't go around doing things (like adhering to a certain thickness) just because everyone else is doing it. There has to be a reason for it. --Andreasen 03:20, 17 Sep 2007 (PDT)

About the section about multiplayer games

I'm thinking I've made a mistake. While several players in both areas of a portal would render portals useless, it's not really the same map they're in. One player is in the map that his computer renders, while the other player is in the map that his computer renders, so the areaportals could possibly account for this by being in different states at different computers. --Andreasen 20:25, 16 Sep 2007 (PDT)

Huh? why different computers, you cant use these in mp maps.--Gear 20:55, 16 Sep 2007 (PDT)
Wait well in theory yes where the player stands is the current part of the map they are in. Meaning in theory that if an areaportal is active it will not effect the player in room 1. But only the player in Room 2. However if does effect the map globally, which is why they arent used in mp maps at all, rather just single player maps where you have alot more control over them. So in other words the only entity that never has an control using triggers is areaportalwindow, which can be used, but not Func_areaportal.--Gear 20:59, 16 Sep 2007 (PDT)
I'm betting that at least modders have tried to implement them, so are you sure that the areaportal code is specificly tied to singleplayer maps?
You're not making sense, and I think you've misunderstood me: Does the server or the clients (in the multiplayer network) decide if the each portal is open or closed? You see, if their states were a client issue, that would allow the closing of a portal to hide things for one player, while displaying it for another, making areaportals worth while. I'm thinking that this may be a security issue - that areaportals may be set serverside to avoid exploits.
You can theoretically have full control over areaportals for several players because of the OnTouch trigger input. If you cover an area in a trigger_multiple to open a portal, and then close it OnEndTouch, you have full control. --Andreasen 03:42, 17 Sep 2007 (PDT)
That is exactly what i was saying. But yes, Single player maps only. And yeah i would go with hiding visleafes, sounds more better than geometry since they do hide all, you do not know much about areaportals huh?--Gear 13:37, 17 Sep 2007 (PDT)
I guess that I should remove that multiplayer part entirely then, but I'm putting this article on hold until Jeff Lane gets around to adding to it within a couple of days. --Andreasen 15:36, 17 Sep 2007 (PDT)
...and no, I don't know much about areaportals. This merge is where I started my learning process. I thought this was going to be an easy merge, as the two articles I merged was full of repetitions like "Make sure to seal the room. ...and oh, Seal the room!" or unnecessary instructions like "Click this very button to tie this brush to an entity." Now the article has grown to seem bigger than the two parts combined. In all honesty, I just want to go back to design my hospital level, and not just have to stare at a friggin door all week. --Andreasen 15:43, 17 Sep 2007 (PDT)
Gear, ts2do just told me that portals work exactly the same way in multiplayer as it does in singleplayer, and an article I've just read goes on and on about areaportals being able to be used (client-side) in multiplayer, but that they have the potential to draw more and more resources during game-play. What did you mean by "Single player maps only"? --Andreasen 17:16, 17 Sep 2007 (PDT)
This why its not worth it giving this information away. It hurts the game more than saves it, and it is alot more complicated to fully pull-off yet I've seen it done, in Fortress Forever for example. It isn't worth the time. Yeah i know what you mean though, this is very complicated, mainly a art within itself.--Gear 17:20, 17 Sep 2007 (PDT)

Mystery variables

Please provide more information about the following variables:

map_noareas [0/?]

"Disable area to area connection testing." Probably something to do with areaportals. (

Todo: Please find out what it does.

) Seems to fix the stuttering bug if activated! (I'm thinking that the opening of areaportals in mid-game is the actual cause of the infamous HL2 stutter, and setting this to 1 will instead load all areas at once. (

Todo: Again, please verify this.

))

r_ClipAreaPortals [?/1/2]

No idea what this does, but it has got "areaportals" in it. According to r_areaportal.cpp, line 468 it has been commented out due to occasionally huge performance hits.

r_ClipAreaPortals 1
This is the default setting.
r_ClipAreaPortals 2
Line 500: "Just leave the area clipping how it was (for debugging)."

r_snapportal [-1/?/1/2]

No idea what this does, but it is mentioned in r_areaportal.cpp, line 293.

r_snapportal 1
Sets up some kind of drawing of a box with the origin at the player origin. (It seems impossible to get rid of without restarting the game.)
r_snapportal 2
Sets up a different kind of drawing.

The term for what exactly is hidden.

I undertook creating this article under the misconception that "geometry" (in previous articles) meant world brush geometry, but as I tested it out, and read other articles, I found that areaportals hid EVERYTHING, including entities and models, so now I'm asking, what's the proper term for what areaportals are hiding? "PVS"? "BSP"? "Visleaves"? I'm going to go with "visleaves", but this is a guess.

Also, I'd like to know if "culling" is a well-used term that I can use. At first I thought it was just a vague description, as "culling", according to my dictionary, means to "sort something out". --Andreasen 11:14, 17 Sep 2007 (PDT)

Okay, based on the Wikipedia:Back-face_culling article, "culling" and "clipping" are common 3D techniques. According to r_areaportal.cpp areaportals uses both these techniques. If I understand correctly, the hiding caused by a closed portal, is called "culling", and the hiding outside the frame of an open portal is called "clipping". --Andreasen 11:59, 17 Sep 2007 (PDT)
No, the articles are confusing me: They are refering only to open portal hiding as both "culling" and "clipping". I now have no idea what closed portal hiding is called. I need help. --Andreasen 12:15, 17 Sep 2007 (PDT)
According to this article, closed portal hides geometry by using a technique called "cell-based occlusion culling", but the latter part of that section also says that the portal system uses some kind of "analytical clipping" which is too advanced for me to understand. --Andreasen 14:40, 17 Sep 2007 (PDT)
I should have time to work on clarifying some of the issues with this article within the next few days. --JeffLane 15:08, 17 Sep 2007 (PDT)
Thank you. I really appreciate it. --Andreasen 15:36, 17 Sep 2007 (PDT)
Thank You JEff that would be nice, theres still alot of things that are quite mysterious about areaportals.--Gear 17:21, 17 Sep 2007 (PDT)
I also appreciate if you both could tell me which things are mysterious/inaccurate, so that I can explain these things better in the article, because as the subject is mostly clear to me, I've lost the "newbie perspective". Edit: Also keep in mind that there exists an areaportal tutorial for those who would like a lengthy, simple and non-technical explanation. I haven't touched that article much, so if you think that a specific thing could be explained using more words, that article is the obvious choice. --Andreasen 06:56, 18 Sep 2007 (PDT)
I went ahead and did a pass on the article. The main thing that remains is to create examples of triggered areaportals, and perhaps areaportalwindows. This could likely be done in the separate tutoral article and then link it here when it is completed. --JeffLane 17:11, 18 Sep 2007 (PDT)

Code tags

(Large off-topic discussion moved to Help talk:Editing.) --Andreasen 09:14, 23 Sep 2007 (PDT)

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Talk:Areaportal&oldid=55859"