Looking for technical advice on a map

Discuss the construction of maps and the tools to create maps for 3D games.
Post Reply
Tronyn
Posts: 6
Joined: Fri Aug 31, 2012 9:37 pm

Looking for technical advice on a map

Post by Tronyn »

Hi guys,
If you can believe it, even after Something Wicked I've built something that may break Quake even more (lol). I'm looking for some technical advice on a map (again BSP2 format), particularly with vising. In Something Wicked, I used giant func_walls in a few places to make the vising more bearable, and I'm looking to do that again here, but I'm unsure of how much I can get away with. If anyone wants to have a look, email me at Dustin dot Geeraert at umanitoba dot ca; also if anyone is interested in testing the gameplay that would be welcome. Thanks!
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Looking for technical advice on a map

Post by Spike »

engines generally have a maximum limit as to how many leafs an entity can be in at one time. if the entity is in more leafs than that, the engine will not properly check the pvs and it might become invisible if only the 'extra' leafs are currently visible.
vanilla quake has it at 16 or something low.
fte uses a limit of 32, but will trivially accept it (ignoring pvs) if the entity is in more leafs than that, less efficient, but you won't notice any actual bugs.
quake2 uses more expensive checking, and switches to checking *all* child leafs of a single root node.

long story short, use as many func_walls as you want. just don't make them too insanely huge - at least make sure they can still get frustum culled.
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Re: Looking for technical advice on a map

Post by LordHavoc »

A few of the main things you run into in the stock and nearly-stock engines:
network protocol limit : packet overflow - too many entities in pvs at once, darkplaces got rid of this limit, but in general you can expect it to happen in most engines, there may be some singleplayer-centric engines with unusually high packet sizes that reduce the problem but it can still occur.

network protocol limit : coordinate range - in most engines you are limited to having entity origins within +/-4096 coordinate range, you are free to have scenery outside this range however, and due to brush models frequently having origins at 0 0 0 you can actually have func_train entities outside the 4096 range entirely that are used for scenery, as long as they do not rotate (rotating ones will require origins to be inside the object and thus the center of the object being within 4096 coordinate range).

network protocol limit : MAX_EDICTS - in most engines this is either 640 (stock quake) or 2048 or even 8192, in darkplaces it is 32768 (and they can all be in the same room) so you aren't likely to run out under any circumstances but performance does tend to degrade past about 4000.

network protocol /renderer limit : efrags - as Spoike noted an entity can not be in more than a certain number of leafs (convex regions of the map) at one time in most engines, this can be visualized in darkplaces with r_drawportals 1 but it won't show any sort of alarms when an entity exceeds limits (as darkplaces has no efrags limitations), still you may be able to observe when too many portals (translucent "walls") are coming near your large entities which can help in finding those problem entities that other engines complain about.

network protocol limit : MAX_MODELS - requires network protocol changes to raise this limit, a fair number of engines do have those changes (in their respective custom protocols), this is 256 in stock quake and 8192 in darkplaces.

network protocol limit : MAX_SOUNDS - requires network protocol changes to raise this limit, the same engines that raise MAX_MODELS also raise this, 256 in stock quake and 4096 in darkplaces.

renderer limit: MAX_DLIGHTS - this is 32 in most engines, 256 in darkplaces, I think it won't be explicitly called out when exceeded but you can easily hit this limit on how many glowing entities (and explosion flashes/muzzleflashes) you can have at one time.

renderer limit: MAX_TEMP_ENTITIES - this is 64 in most engines, 4096 in darkplaces, it mainly affects how many lightning beams you can have going at one time (each one consumes several temp entities, depending on length).

There are various "gray flash" limits in the software quake to worry about but I assume you're not targeting software quake engines. You'll also run into -heapsize and -zone limits easily but I assume you understand those settings (again not applicable to darkplaces).

There used to be a lovely page with a table of several of these limits across various engines but I can't remember where it is.
negke
Posts: 150
Joined: Wed Apr 16, 2008 5:53 pm
Contact:

Re: Looking for technical advice on a map

Post by negke »

Engine limits table

Indeed, too large funcs can cause problems, and what's even more annoying is that they usually become apparent only after the (lengthy) fullvis which means a big waste of time. If it's only for VIS optimization, detail brushes would be preferable in your situation - the recently released compilers by rebb and Tyrann support them, but I don't know if they support the BSP2 format as well.
sock
Posts: 137
Joined: Thu Aug 23, 2012 7:16 pm
Location: Wandering Around
Contact:

Re: Looking for technical advice on a map

Post by sock »

negke wrote:the recently released compilers by rebb and Tyrann support them, but I don't know if they support the BSP2 format as well.
The latest compiler from Tyrann supports detail brushes and bsp2 format.
Tronyn wrote:In Something Wicked, I used giant func_walls in a few places to make the vising more bearable, and I'm looking to do that again here
You should be using detail brushes and avoiding func_walls at all cost. They also don't make very good shadows and if you have large parts of your geometry func_walls the shadows will look very odd. Also detail brushes will drop your compile time down to minutes instead of weeks! The future is detail brushes and rapid compile times! :P
Tronyn wrote:also if anyone is interested in testing the gameplay that would be welcome.
I find that you asking for testers on inside3d and not func really disappointing.
Well he was evil, but he did build a lot of roads. - Gogglor
Tronyn
Posts: 6
Joined: Fri Aug 31, 2012 9:37 pm

Re: Looking for technical advice on a map

Post by Tronyn »

Hi Sock,
Well no insult to anyone was intended, I already have a couple mappers who are going to playtest the map (ijed, OTP, maybe ORL since I tested one of his maps recently), although now that you mention it I should probably ask on func_ as well. This map was designed quite a while ago though and it is "yet another giant tronyn map" so I think some people there might be getting sick of that. Plus, I don't want to give the impression I have a map coming out right away, because I don't - heh. Mentioning gameplay testing here was just an afterthought, really, I was mostly interested in technical advice from people here, which I got. Now I just need the time to implement it - not this weekend, but maybe next week or closer to the end of the month. Thanks guys!
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: Looking for technical advice on a map

Post by qbism »

One idea could be tried that's even more 'wicked' than func_walls... a piece of Preach's mapgen qc code called func_section. Mapgen used func_section to create randomly generated maps from repeating modules, but another use would be to simplify repeating areas of the map. Model one portion and place instances at runtime. This would help the compiler tools but I don't know if it would help with engine limits.
Post Reply