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. 

20 brushes made into 1 func_illusionary = 1 model.

20 brushes made into 20 func_illusionary = 20 models.

func_illutionary can spread over a wider (larger) area and not disappear from view. func_doors on the other hand can disappear from view if spread all over an area.

Also, I make sure that all my entities are inside the level. 

ijed, MadFox - you want the bsp or the map file ? Anyway, I want to work a little more on it, right now it's very raw in some areas, then I will send it or upload it here.

roblot - the problem is that I don't have 20 brushes, I have (for example) 1 brush that have applied a basic duplicator (x5), then everything is mirrored, so I end up with 20 brushes in the map. If I will put the brush AND the duplicator and the mirror inside func_illusionary - will it be ok ?

I ask this because the duplicator and mirror is also used for other things in the map (too big to make them illusionary). So I need to take out the small brusesh, put them into the func_illusionary, then create again duplicators and mirror for them (inside the illusionary). 

The bsp will give a good idea what's going wrong and the .map will allow to give a specific 'this is why'. 

duplicator. 

just compile the source .map file of corse. 

If you want. Im a little confused really :)
I would like to see what is going on.....
You can just email it to me if you like:

trowbridge (dot) richard (AT) googlemail [dot] com

.map file and/or .rmf file are what I need, the BSP too if you want, but not necessary (unless you are using a custom texture wad) :) 

By the way, Fitz and Aguirre's gl engines has a 64,000 Marksurface limit, and warnings can be ignored as they are just info for developers. If your map is small and you are hitting limits, something could be wrong.

To reduce Marksufaces according to what people say here, select the brush and the duplicator and the mirror (any number of brushes) and make them into 1 func_illusionary entity. It does not need to go into another func_illusionary brush. A func_wall entity maybe a good choice also because it is solid.

If your map gets real big with lots of these multiple brush entities you could get the error:

Too many efrags

If so, just reduce a 20 brush func_illusionary to something like 15 or 10 brushes to make the error go away. 

I'll just cut some areas from the map for now, I have a lava cavern that sucks, it looks very bad... 

what's a duplicator?