.Map :: MoHAA Mapping

I have been seeing topiuc about this for quite a while now. And everytime I get a hang of one thing something else pops up in the .MAP forums and I totaly forget about everything else.

1. My map (even really small ones) have really low FPS like 13, 20, 25. No its not a big map. How do I solve this problem?

2.What is make detail. And what does it do?

3.What is Vis leaf group. And what does it do? How do I apply it?

Thats all for now until I think of some more questions. If any one have any other tips that I havent asked yet please do tell.

During compile the map will be split up into "a lot of" portals. Portals are like boxes and when you are in game you move between these invisible boxes. You don?t see them but you are always inside a portal.

It is the structural brush faces that cause the split. The Vis process then calculates what the portals can see. It calculates which other portals that can be seen from one portal. This is important for FPS later on in the game! Because when the player are inside a portal only that portal and the others that the compile process have calculated as seen from that portal will be drawn. The rest will not be drawn! The thing that blocks the view between portals is the structural brush. As I said, if you pretend that a portal is a box and you from that box can draw a straight line to an other box without passing through a structural brush then that box (portal) will be able to see the other box (portal). If it?s not possible to draw a straight line between them then it will not be able to see it.

ALL structural brushes causes split, even if the brush is only 1x1x1 units. The problem for most mappers is that they don't have a clue about this and in 99% of the cases they will end up with a map where every portal can see (almost) every other portal. That basically means that the whole map will be rendered wherever you are, that will of course give you low FPS.

More structural brushes will cause more splits that will rapidly increase VIS data. VIS data is not a bad thing but you will need the "right" VIS data. With some knowledge of this you can plan your map so that the structural brushes will cause splits into portals (boxes) in such way that you know that they won?t see to many other portals (boxes). Some brushes will never create portals that help your FPS, example a small sign on the wall (1 unit thick placed in front of the actual wall). That brush will cause a split for each side except the backside, which are aligned against the wall. The portals created will never help the map and the sign brush will never block the view between portals.

In such a case as mentioned above the brush should be turned into a ?detailed? brush. That brush will be ignored during compile. It will no longer cause any splits (new portals) but it will not be able to block any views either. That doesn?t matter in the case above since it would not have blocked any views if it were left as a structural brush either. You will never notice any difference in game?the sign will look the same!

Bah!! It?s difficult to write something in a post and make sense?I tried to make a tutorial about this. Still most people have problems understanding it. It?s really difficult to explain, I did not understand anything of this either but one day it suddenly became clear! As soon as it happens to a person?they will have no problem understanding my tutorial (but then it?s to late. he he). I really tried to write the tutorial without using to many difficult terms. Still there is a part in it that have some of these terms and that should be read too! Read it several times!
There is also a link in the tutorial to a site ?spog?s? where you can read more advanced stuff about it.

Newer game engines don?t work in the same way as the quake3 so hopefully it will be easier to map in the future. There is no VIS process; it?s a real time calculation of what can be seen and what can?t be seen.

Below is a link to my tutorial about VIS, it also have a part about detail brushes! For Vis_leafgroups check the documentation about manual vis that came with Spearhead SDK. But don?t use it to the same extent as they have in their example map ?Berlin?.

VIS For Dummies

Thanks thanks a lot man that will really help me. Because the map I showed earlier of the saving map had like a 15 12 16 fps. And it wasnt even big. Man that got me down on my knees and crying [/quote]

Remember that compiling with fast VIS or a hole in the skybox will make it skip the calculations. It will just say that every portal can be seen from each portal. You won't know your final FPS without a full vis compile. With some effective mapping the compile won't take that long even on full VIS.

I tried to make a picture tutorial that I post here! This might help some people or just get you more confused. This might be better pictures then in my tutorial that I linked to but the "text description" is better in the tutorial (and the compiling examples). Therefore I recommend that you read my tutorial, look at these pictures, read the tutorial again, look at the pictures...read other posts/tutorials about VIS.

Wow thanks for taking the time and making a more detailed tutorial

Storm, U rock!
Your vis-for dummies is the refrence on my page for understanding the vis process. I was clue-less until I read it.

I'd just like to add one thing: To see what TheStorm is talking about here and how it affects YOUR map, you can write r_showportal 1 in the consol to see green lines outline the portals ( for this to work you must first copy the <MyMapName>.prt file generated by the compiler to the same place you put you'r <MyMapName>.bsp file ).

Result:

This is an old pic I used to show a vis problem, and the portals are really wierd . But it gives an idea of what to expect.

Yea! That command will outline the portals in game (the one the player are inside). Sadly it doesn't seem to work as good in spearhead as in Mohaa?? Strange?

When inside game you will sometimes see that the portal you are inside stretches all the way up to the sky top. Then if a lot of portals are like that and you don't have anything that blocks the view between them (wich you usual don't have at that height), then they can all see each other and will be drawn. The same goes for portals going under ground when you use lod terrain.

I just once again want to say that ONLY structural brushes block the view and creates portals. Lod terrain, models, entities etc doesn't not block the view. If you are in a room with no windows and only a door then the compiler sees this as a room with one wall that has a hole to the outside world. If you wan't to imagine what the compiler sees in mohradiant when it calculate portals/VIS then filter out everything but the sky and structural brushes.

It's difficult to see in your picture how the portal looks! But they don't always have to be a "box". Depending on angles and stuff of the structural brushes they can get different shapes which makes it even harder to plan for VIS.

Commands that I think are useful are the one that Bjarne mentioned (remember that you need the .prt), r_showtris 2 is useful to see what's actually drawn when you are standing in a certain location. r_lockpvs 1 is a command that will lock everything that's drawn from that location where you stand when you enter the command in the console. Then you can move around in your map to see what was drawn (without getting new stuff to be drawn, when you use this command all entities will be shown, even if they not will be drawn in game....so ignore that fact, and just look at which brushes that were drawn. To unlock type r_lockpvs 0)

So can you please tell me exactly what I should do????? Like everything that blocks view I do this. I Now understand what It does but can you tell me how to apply it to my map?

nice work, Storm.

One point of notice; leaf-groups should be a last resort. One should always keep VIS in mind while building and laying out the map. Most newer mappers make the mistake of drawing a big rectangular box and fill it up with structures. Then afterwards they have a hard time keeping fps up due to poor vis-design. While building on a map, always think about the player's LOS(line of sight). Be creative and use smartly placed bends, u-turns, walls, hallways or even skybrushes, to help you control the portal-view as much as possible. Sure, the engine might draw things you didn't expect it to draw, but your map will always benefit from some smart vis-blocking trick. In the end, every little bit counts!

(avoid lay-outs like this:)
__|__|__
__|__|__
__|__|__


(rather make it less symmetrical, which can also provide more interesting gameplay:
__|__
__|_..|_
|____|_|
__|__|__

panTera wrote:__|__
__|_..|_
|____|_|
__|__|__

...nice map... when can we play it?

And another VIS question:
With r_showportal 1 and r_showtris 2, I can see almost everything in my map from almost everywhere. Is the reason for this, that I turned so many brushes into detail? I mean, I didn't detail brushes that might block view like walls, but in a staircase e.g. all the steps.

It was said that a portal A is drawn if any point of it is visible from any point in the portal B in which the player stands. Does this also mean, all detail brushes in portal A are drawn?
So, for FPS (surely not for compiling) it would be better to make no detail brushes?!

On the other hand, with BSP -fulldetail (i.e. detail is handled as structural?!), I get
****************** ERROR *******************
LoadPortals: NumVisBytes 2293552 exceeds 2097152
which is even yet worse for compiling because there's no bsp coming out...

Wacko wrote:With r_showportal 1 and r_showtris 2, I can see almost everything in my map from almost everywhere. Is the reason for this, that I turned so many brushes into detail? I mean, I didn't detail brushes that might block view like walls, but in a staircase e.g. all the steps.

If the combined mass of a staircase blocks view ( like massive concrete stairs ), make a structural brush under it and make the staircase detail. Because to the vis complie a detail is "invisible". Filter away all details, static models and entity brushes in Radiant to get an idea of what the vis compile "sees". You may be shocked and enlightend.

Wacko wrote:It was said that a portal A is drawn if any point of it is visible from any point in the portal B in which the player stands. Does this also mean, all detail brushes in portal A are drawn?

Yes, all brushes in a portal is drawn when the portal is visible.

Wacko wrote:So, for FPS (surely not for compiling) it would be better to make no detail brushes?!

No, because you'll get too many brushes and compile will fail like you said:
****************** ERROR *******************
LoadPortals: NumVisBytes 2293552 exceeds 2097152
Unless its a really small map...

Any clearer? If so: go forth and be merry! If not ask again.

Wacko wrote:And another VIS question:
With r_showportal 1 and r_showtris 2, I can see almost everything in my map from almost everywhere. Is the reason for this, that I turned so many brushes into detail? I mean, I didn't detail brushes that might block view like walls, but in a staircase e.g. all the steps

If you turned the wrong brushes into detail you could get this effect, but you could still get this even if every brush that you have turned into detail should be detail. It can be the general lack of structural brushes that actually block any view or just the general layout of your map that makes most portals visible from eachother even if the correct brushes are structural.

It's hard to say without seeing the map, what kind of ground are you using, lod or brushes (or both), have you tried to tighten the skybox where possible, also remember that a sky box doesn't have to be a box, it can have any shape just make sure it's completly enclosed.

Also keep in mind that the portal layout q3map generates is often quite bad. You might want to tweak some areas with hint brushes.

If you can create the right portals, you'll find the vis compiler much more effective.