Area Portal usage question

[lil_binger]

---I moved this question from introductions.---

 

I do have one question about somethign I came across recently.

 

My question is about areaportal usage.  I see people putting them in doors and elevators and saying it's essential for map making etc.  (I think one of the video tutorials suggests areportal usage whenever possible.)(I watched them yesterday)   I am no stranger to using area portals,  I used to use them a lot.  I was wondering, if the maps being made are so big it exceeds max visibility and won't compile vis and areaportal usage is the only way to separate vis with connected areas of a map or are they being used in addition with the vis compile not exceeding max visibility?

 

For instance, the two maps I am working on is based on vis separation.  I have no doors separating areas from each other.  All areas connected to each other using vis to separate them, not doors or teleports.  One thing I learned in mapping (and I didn't learn it until late in my JK2 mapping career) is to create a map with vis in mind first and work the map around the vis and don't work the vis around what's in the map.  In doing so, areaportal usage should be rare if you have not exceeded max visibility.

 

I am mainly against areaportal usage unless it's absolutly necessary.  I used to think of it as a necessity but changed my mind over time.  If you need me to elaborate a bit more or explain what I am talking about better let me know.

[MoonDog]

---I moved this question from introductions.---

 

I do have one question about somethign I came across recently.

 

My question is about areaportal usage.  I see people putting them in doors and elevators and saying it's essential for map making etc.  (I think one of the video tutorials suggests areportal usage whenever possible.)(I watched them yesterday)   I am no stranger to using area portals,  I used to use them a lot.  I was wondering, if the maps being made are so big it exceeds max visibility and won't compile vis and areaportal usage is the only way to separate vis with connected areas of a map or are they being used in addition with the vis compile not exceeding max visibility?

 

A lot of times when I help people with vis, they do have a ton of vis data. Area portals are not going to fix that. Usually because the levels in question are very large. This I almost always fix by increasing the block size, or making the block size 0 so less arbitrary portals are being created by these automated split blocks conjoining with structural brushes.

 

If you are splitting areas with regular vis design and hint brush usage, that is great. I agree that you design with the intent of using area portals as lightly as possible for an MP map.

 

What usually happens is that people run out of options because of their initial design. There isn't a realistic way to split the vis to reduce the render between two cells, and they have obscene geometry, entities and so forth on both sides of a threshold. Therefor, an area portal helps on performance in those cases. That isn't always a bad thing. Cookie cutter designed levels are not very fun.

[lil_binger]

I just uploaded a WIP in the wip section for ffa_bespinarena.  The map does not have any areaportals or hints in it anywhere.  There are 2 doors which are elevators.  The other elevators are from an idea I had for the first map I ever made.....water elevators and bots will navigate lol.  Vis should always be priority one over everything else in making a map. I didn't always create maps this way but as I have learned vis is the 1st factor to consider when making one.

 

It's hard to fix something that is already made if an area is too open and has too many drawable objects.  Sometimes you just have to compromise or redesign.

[MoonDog]

 Vis should always be priority one over everything else in making a map. I didn't always create maps this way but as I have learned vis is the 1st factor to consider when making one.

 

That shouldn't be your first consideration. The only problem with designing completely around the idea of having the perfectly vis optimized map, is that you will have to make concessions that could compromise the fun of the gameplay in your level. I'd say you should be very aware of your budgets while blocking out the level, and focus on designing something fun that meets your goals. It's best just to be constantly aware of your budgets while designing playspace. You'll know the purpose of each area, and thus will be able to estimate how it will be dressed artistically later on after play testing and iteration.

 

I've played old Q3 maps designed entirely for vis. They tend to have hallway cancer. Thus, are not fun.

.

[lil_binger]

I'd like to hear your thoughts about my Wip if you get the chance.  The vis in the wip was mostly working with many premade areas putting them together then working vis around and through what was already made but make it so you can get most anywhere in the map very quickly.  (turn a corner , jump, jump, you're there.)

 

I agree Mapping is not a one sided process and everything should be considered including compromising vis as well to get the effect u want.  Compromise vis too much however, your map will suffer. I've played a lot of games and it's not hard to read how most publishers pull it off.  There are tricks to making an area to feel less confined and feel more natural which helps with continuity of the map.  It needs to feel like it belongs yet serve a purpose, direct flow, vis, etc. In my opinion, I do like the feel of a map without doors, space feels more open and less confined.  

 

When I create a new map or connect old areas I do consider vis when making anything in radiant.  I always consider fun factor, flow and purpose as well.  My maps are well known for their gameplay for those who have seen them however I was not very good at working vis most of my mapping career.  Now I am trying to work the fun and the vis together a lot better and have been pretty happy with the results.  

[lil_binger]

So, increasing block size is the answer to my question. Therefore vis is still being drawn etc.  So you are still using areaportals in addition to drawing vis, increasing block size.  What are block sizes normally used in maps you guys have been involved with?

[MoonDog]

So, increasing block size is the answer to my question. Therefore vis is still being drawn etc.  So you are still using areaportals in addition to drawing vis, increasing block size.  What are block sizes normally used in maps you guys have been involved with?

 

I had previously used area portals when I need to split (sort of) two areas from each other to increase performance while a barrier is thrown.

 

Increasing the _blocksize in the world spawn is something I have used on large open maps, large terrain maps, etc... Blocksize is automatically 512. Meaning that every X unit, q3map2 will automatically create portal splits on X Y Z. This is why large open maps benefit from a larger blocksize. If you have 512 blocks split on a huge map, vis data can pile up pretty quickly.

 

I'm not sure how other modders use blocksize, but when I was doing JKO/JKA stuff I usually set blocksize to 0 and did my own portal optimization with hint brushes. I don't like how blocksize throws splits, and I don't like having to design around 512 blocks to accommodate this behavior. Usually, I'd end up with awkward splits where I didn't want them, or splits across cells that did nothing to optimize vis. I suppose if you don't want to do much hint optimization, you can rely a bit on blocksize to automatically create some portals. It's not intuitive at all though, as previously stated.