Hello all, I'm new on this forum (I am reading it for a long time, but only decided to post now).
I'm working on a Quake 1 map for quite a long time (in Quark) and I got a warning telling me that I have too many marksurfaces in the map (limit seems to be 32k). But the map compiles ok and I can run it in standard glquake.

Questions :
1. What is "marksurfaces" ? I think they are the total polygon number from the map, but I want a confirmation.
2. If the answer to question 1 is "yes", then should I try to keep it under 32k ? What will happen if I go way beyond this ?
...Because my map is not very big, I'd say it's rather small and it's not very detalied either, but I plan to add more details.

Ah, one last note - the map is NOT surrounded by some big box and it doesn't have "leaks" :)

Thanks in advance for your responses and please escuse my bad english. 

Hi RaverX. I'm not sure what marksurfaces are, I only know that you get more of them when your map becomes bigger :) Engine coders will know what they are.

When you exceed the 32 k limit, the map won't run in standard (old) Quake engines. Newer engines, like Fitzquake 0.85, Quakespasm, darkplaces, FTE, and probably DirectQ, have higher marksurfaces limits (and generally higher limits for most things). So with a modern engine, nothing will happen except a warning might be printed to the console.

How a pretty small map could exceed marksurfaces I'm not sure. It might be the editor. Quark is a little infamous among mappers. But if it compiles and runs, then fine.

Remember sending your map to people like negke for playtesting before eventually releasing. It helps. 

View 'all posts' and then do a word search whenever you've got a question - chances are it'll pop up somewhere.

Marksurfaces are produced by complex brushwork, or just lots of brushes intersecting / touching each other. Making simpler structures will reduce marksurfaces, as will just making less map.

But I wouldn't worry about it too much - most people now use a modernised engine so you should be fine.

But!

Make sure to use the compile tools from here:

http://user.tninet.se/~xir870k/

And the documentation there is very good as well - it'll give you a much more concise explanation of marksurfaces and all the other terminology as well.

There are newer versions of the compilers like Willem's WVis which allows for multi-threading - handy, but not necessary if you're just starting.

Any tools you want can be found on http://www.quaddicted.com/ which also has all the maps etc. 

Thank you all for your response, they are greatly appreciated. I really didn't expect anyone to answer so fast.

ijed, I already use those tools, I'll try to read the documentation as well...

You are right, I'm using a lot of small brushes, like small "screws" to hold pillars on the ground, duplicated a lot of times, I guess that might be the problem...

One more question - when the compiler splits the polygons in the map, does it matter how many lights and shadows (lightmaps) are in the map ?

What I'm trying to say :
Let's say I have a face of a cube with a single texture applied there, that's a rectangle. It should be split in 2 triangles, right ? (best case scenario). But what if there's a light nearby casting some shadows there ? Will I still get 2 triangles or a lot more ?

I'm asking this because I alos have a lot of lights in my map (I like playing with shadows). 

with pictures.

http://www.quaketastic.com/upload/files/misc/curvetut.7z

I can make a .zip if you need. 

Try turning the screws into a func_wall (one per room or so), this should help a little. In some cases you can also move brushes 1 unit away from adjacent ones (walls or floor) so the faces behind them don't get split multiple times. This two techniques can be used to lower marksurfaces quite a bit, but their effectiveness also depends on the situation - what helps in one area might be counterproductive in another. Walk around the map with r_showtris 1 (Fitzquake, DP) to see how the faces are split and where optimization makes most sense.

Lights have no influence on the geometry and how it's compiled. 

Reducing Marksurfaces can be done by making some of those small detail-brushes into func_illusionaries. You can make a group of seperate detail brushes into one func_illusionary entity. This will heavily reduce the marksurfaces count and it will also stop the player from clipping agains the brush. If they are small then you wont notice any difference whatsoever.

func_illusionaries, walls, doors, trains etc dont cast shadows though. But this is OK - if you have a large structure like a detailed tank for example, the you can make the whole thing into a func_illusionary or whatever, and then put a solid brush inside this so that you can quite see it, but it creates a shadow and also stops the player from being able to move through it.

If you want to see the marksurfaces and how the world model fits together then in Fitzquake anyway, you can use the console command "r_showtris 1". This will draw the lines of the world model (BSP). Someone said that you can reduce marksurfaces buy seperating touching brushes. This can work very well. Imagine a square face with a cuboid light fitting stuck in the middle of it.
The square face would be made up of two triangles ideally, but the touching brush means that it needs to be a lot more than two triangles, connecting points at each corner of the touching brush to the four outside corners of the square face :)

Confusing eh?

In short, my advice:

Make each of the clusters of "screws" into a func_illusionary (this is exactly what I would do), re-compile, and watch your marksurface count go down :D 

full of missing letters and typos.

"theN you can make the whole thing"

"canT quite see it" 

I started a radiant curve tutorial at kneedeepinthedoomed.wordpress.com, for now only pics, will fill in words in a while. Not everything will work in other editors, but the basics are the same. Radiant has very easy ways to make cylinders, circular holes, and rings with a lot of sides and perfectly snap them to the grid. I'll also do pipes, connecting pipes, circles out of pipes, and finally terrain etc.

I've stuck to 16 sided circles, maybe you want to do something about 24 sided ones, and correct all my mistakes, ijed. 

Are completely separate. All that the light tool does is draw the lightmap - a big texture made of shadows that gets painted over your world geometry.

Any func_ brushes aren't part of world geometry so don't affect Vis times, marksurfaces etc. although they can have other problems like flickering in and out of visibility if within different Vis leafs - usually only for big brush entities though.

They don't make shadows either, but if you have something big and intricate you can turn it into a func_wall and stick a simple rectangular world brush inside it to make a shadow.

Curve tutorial... I will add to it, but in a month or so. If I have an attack of boredom (sweet, sweet boredom) maybe I'll get back from holiday with something ready. 

The hint with r_showtris really helped. I turned on r_showtris and ... HOLLY SH*T ! The screen was full of lines and I notices something - I can see the entire map. First it was like WTF, then (in 2-3 seconds) it hits me : the map is not fully VISED, I compiled it with novis, because I always add stuff and I need to compile it quickly to see if my "new things" really look like I want to...

Could that be my problem ? 

As long as your map runs OK in a modern engine I don't think you *have* a problem.

It needs to be fullvised before you release it, though.

Fullvis it and load it into an engine that supports r_lockpvs. This allows you to freeze your current field of view, so to speak, and then noclip around to see how much of the map gets actually drawn. This is often quite enlightening, too.

Those lines should get less once you apply the func_illusionary or func_wall trick. In a detailed map it's normal to have a lot of polies, though. 

you can also use r_showtris instead of r_lockpvs to see how much is being drawn. This can break down in polygon-dense areas, if you can't clearly see what you're looking at, though. 

About newskip. Is it normal that it doesn't remove all faces when running it once? I mean I can't find any visible instances, but when running it a second time, it says that another six faces were removed that it apparently didn't catch the first time. 

Marksurfaces isn't influenced by VIS either. Although it's not a bad idea to at least run "vis -fast" for WIP compiles, this isn't the cause of your problem. The only two reasons I can imagine are either a leak (so QBSP didn't remove the outside or backsides of brushes), which you said there isn't, or excessive detail made of world brushes. The latter sounds odd since you mentioned the map was fairly small and plain. 

with no leaks by doing the following:

load the map into your engine
bring down the console and type:

"gl_clear 1" (this makes the engine draw the void outside the map each rendered frame as a grey colour, so you dont get the "hall of mirrors" type effect you would normally get when outside the map)

then

"noclip" (so you can walk through walls)

You can now move outside the map. If you can see the outside of the map's brushes then you know there is a leak.

Another way of identifying errors would be to post the entire QBSP log onto this thread, so we can look at it :) 

.. if the compiler claims the map leaks, then it generates a .prt file. Type "pointfile" in the console, and a white doted-line will spot where the leak is, at least the first detected leak by the compiler... ;)
Enjoy ! 

The map complies fine, no leaks. Sometime, when I add or remove stuff and there's a "hole" in the map it won't compile, but it's not the case this time.

I'll try tommorow the func_ilusionary trick, I think this will help in other areas too, some shadows casted on small polys look bad, so I hope that converting those brushes into func_ilusionary will help me get rid of that. 

Entity brushes don't plug leaks. They can be outside the map no problem but won't stop a map leaking on their own. 

The marksurfaces are not truly removed, just moved to the end of the list.

So, during a second run it will find the same six marksurfaces, and again move them to the end of the list (but they were already there so it's not changing anything.) 

... but, i can see the message is misleading, theoretically it could be smart enough to notice that those marksurfaces were already "hidden" and not re-report them. 

func_illusionary dind't work so good :(
Compiling the map before generated this warning:

WARNING: Marksurfaces 35716 exceed normal engine max 32767

But the map compiles ok and can be run without any problems, I get the same error in Quake engine when the map loads, but no other problems.


I take some small brushes (they are also duplicated and mirrored) and I put the brushes inside the func_illusionary.
Then I compile the map again.
This time I get two warnings in compiler :

WARNING: Models 520 exceed normal engine max 256
WARNING: Marksurfaces 33494 exceed normal engine max 32767

So, I still exceed the marksurfaces and I get a new warnig, that prooves to be fatal in engine, because when the map loads I get something like :

Excessive marksurfaces (33494, normal max=32767)
Excessive models (520, normal max=256)

Host_error : cl_parse_static: too many (256) static entities, max = 256

So, the marksurfaces dropped a little, but the func_illusionary caused a MUCH worse error...

I don't know what to do now, I'm really frustrated, my map is not very big, nor very detalied (ok, it's not plain floors, walls and ceil - I have some decors, but nothing TOO fancy)

I saw maps MUCH bigger and with a lot more details that didn't seem to exceed limits...

Any other ideas ? Please. 

To take a look. Its odd that didn't work, but there's a lot of stuff to get used to with bsp.

I can't take a look because I'm going away in two days, but someone on the board should be able to help.

In fact, send it to me anyway - the email is in my profile. It should just be a case of looking at it for five minutes.

Try not to get discouraged. 

the map.
send it on email. 

You say you put the small brushes INSIDE func_illusionary. Don't do this! Instead, group a bunch of these small brushes in a common area, and while all selected, turn them into func_illusionary, or func_wall, or even func_door. Any entity will do, with func_door you can make them move if you like.