When I build my map with the -fast option on, VIS only takes a few seconds. But now I'm compiling it without the -fast option on, and it has so far taken over 24 hours.

It's currently at:

--- PassagePortalFlow (15010) ---
0...1...2...3...4...5...6...7...8...9...

And that's where it's been since this morning. Is this a symptom of something being wrong with the map or does it really take this long? Or has something else gone haywire?

Will the full light compilation take a similar amount of time?

Good thing I have a multicore comp..

odd, I have a multicore cpu (2.7Ghz for each core) and the most it has taken me to compile a map is like 20 minutes to a half hour, that without the -fast option.

I'd try checking for stray entities, but that's all I can recommend...

Most likely you have omitted to use detail brushes. If you have no idea what im talking abt grab some basic quake3 mapping tutorial. This is a rather important step for most maps.

is your map very large ?

If yes, try to to enlarge the blocksize used to compile your map.
To do so, select a brush in your map inside the editor (a "worldspawn"-brush) and add the key _blocksize and a value larger then 1024 (must be power of 2) like 2048 or 4096.

Code: Select all

_blocksize : q3map always splits the BSP tree along the planes X=_blocksize*n and Y=_blocksize*n. Default _blocksize value is 1024. Increase the blocksize using larger powers of 2 to reduce compile times on very large maps with a low structural brush density.

Also be sure that your map is not leaked.

btw.: it's not normal that VIS stage takes longer then some minutes (unless you compile on a Pentium 60 or simliar)

The Stage that takes most of the time mostly is LIGHT.
VIS-Stage calculates the bsp-tree that is used by the engine to calculate what parts of the level should be drawn from the player's position.

tZork wrote:Most likely you have omitted to use detail brushes. If you have no idea what im talking abt grab some basic quake3 mapping tutorial. This is a rather important step for most maps.

A quick google on "detail brushes" got more this bit here:

"In theory, you might want every brush to be structural. The logic behind this is that the less the engine is thinking about, the faster it must be running. However, this theory doesn?t pan out. Its logic holds true only if players are holding perfectly still. Once he moves, the more pieces the level is broken up into (by the excess number of structural walls), the more pieces have to be loaded in real time. And because each of those pieces has to be calculated when you compile your map, in-game loading times, in-game re-renderings, and map compilation times all shoot through the roof. It takes well over ten thousand times longer to complete the VIS process in compiling if you have a small map that is entirely structural. As your map size increases, your compile times grow exponentially."

http://www.cs.rochester.edu/~brown/242/ ... structural

So the way to fix this is to turn some of the brushes into detial brushes? How do I decide which to change? Will a detail brush act like an ordinary brush in that it stops projectiles and blocks the players? The map I'm trying to compile is a very sparse map as it is (Great Devide). Not much in the way of detail at all.

Strahlemann wrote:is your map very large ?

Not really, but it has a fairly large bounding box.

If yes, try to to enlarge the blocksize used to compile your map.
To do so, select a brush in your map inside the editor (a "worldspawn"-brush) and add the key _blocksize and a value larger then 1024 (must be power of 2) like 2048 or 4096.

Does it matter which brush? I'll pick one by random and see if it makes any difference.

Code: Select all

_blocksize : q3map always splits the BSP tree along the planes X=_blocksize*n and Y=_blocksize*n. Default _blocksize value is 1024. Increase the blocksize using larger powers of 2 to reduce compile times on very large maps with a low structural brush density.

Also be sure that your map is not leaked.

Doesn't the BSP process always stop if the map leaks?

btw.: it's not normal that VIS stage takes longer then some minutes (unless you compile on a Pentium 60 or simliar)

The Stage that takes most of the time mostly is LIGHT.
VIS-Stage calculates the bsp-tree that is used by the engine to calculate what parts of the level should be drawn from the player's position.

Clueless Newbie wrote:So the way to fix this is to turn some of the brushes into detial brushes? How do I decide which to change? Will a detail brush act like an ordinary brush in that it stops projectiles and blocks the players? The map I'm trying to compile is a very sparse map as it is (Great Devide). Not much in the way of detail at all.

Structural brushes are good with optimization because they prevent anything behind them from getting rendered. Detail is for things like railings.
So just remember this: anything that's not a wall or ceiling or stairs, etc. would be a detail brush.

Strahlemann wrote:is your map very large ?

If yes, try to to enlarge the blocksize used to compile your map.
To do so, select a brush in your map inside the editor (a "worldspawn"-brush) and add the key _blocksize and a value larger then 1024 (must be power of 2) like 2048 or 4096.

I've set it to 8192. Didn't make any difference.

The map I'm having problems with is this one:

http://www.notam02.no/~clund/nexuiz/

There's no problem as long as I compile VIS -fast. Maybe I sohuld just make do with the -fast compile and leave it at that?

[TSA] Psychiccyberfreak wrote:Structural brushes are good with optimization because they prevent anything behind them from getting rendered. Detail is for things like railings.
So just remember this: anything that's not a wall or ceiling or stairs, etc. would be a detail brush.

Hmm.. My map is almost entirely made of walls, floors, and ramps. I changed the little lamp brushes to "detail", but it didn't seem to make any difference. VIS still takes forever.

This is the map in question, fwiw:

http://www.notam02.no/~clund/nexuiz/

as it's sort of a space map and most of the map is drawn all the time you can go with vis -fast. shouldn't make a difference there.

Using detail/strucutural brushes only makes sense if you have structural brushes blocking a large part of the map (like walls in a closed room). In your case you could make all brushes except the skybox detail. Or just use vis -fast

For an example of how to treat detail/strucutural brushes in a good way see basement.map

to toggle detail brushes press Ctrl+D

P.S.: Patches are always detail-brushes. Toggle them with Ctrl+P. Note: Your map can leak through detail brushes.

Strahlemann wrote:as it's sort of a space map and most of the map is drawn all the time you can go with vis -fast. shouldn't make a difference there.

Using detail/strucutural brushes only makes sense if you have structural brushes blocking a large part of the map (like walls in a closed room). In your case you could make all brushes except the skybox detail. Or just use vis -fast

I think I'll just use vis -fast..

Strahlemann wrote:For an example of how to treat detail/strucutural brushes in a good way see basement.map

Where do I find this map?

Clueless Newbie wrote:Where do I find this map?

It's one of the standard maps. The *.map file is included in data*.pk3

Easy rule of thumb for details : It its to small to block you line of site its a good candidate for being a detail. Just remember to make all non visible faces of the detail brush textured with caulk. (its good practice to keep all hidden faces caulkd)

I know waht you mean. I'm mapping for a Half-Life mod team, and it's taken the map i just created about 74 hours. I'm using my dad's computer in the meantime. It depends on the size and complexity of your map and the speed of your PC. If its got tonnes of entities and bizzare lighting effects, it'll take a while. If you make a room and chuck a spawn point and a point light, it'll take half a second at most. But i havn't used the Nexuiz editor, so I don't know.

tZork wrote:Easy rule of thumb for details : It its to small to block you line of site its a good candidate for being a detail.

Also, if it's large enough to block sight, it should be structural (the anti-wallhack only checks structural brushes, and so does vis).