Marksurfaces advice please

Discuss the construction of maps and the tools to create maps for 3D games.
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Marksurfaces advice please

Post by ajay »

I'm making a fairly large 'city' map (see "What you're working on" thread) for which I had a rough plan of how big it was going to be and what it would contain. I've exceeded that and it's still growing!
I'm really ploughing on with it until something breaks or creaks to a halt. The only constraints I'm applying to it are that it runs in Fitzquake (which I'm continually impressed by) and on my aged laptop (which struggles with DP, just to give it a measure as it were).
Right now, without optimising it and without fully vis-ing it, frame rates are pretty smooth, however I get the message below as the map loads:
WARNING: MARKSURFACES 33297 EXCEEDS STANDARD LIMIT 32767
What are, if any (I'm guessing some Quake engines wouldn't load it), the implications of this warning? What are 'marksurfaces' (I'm guessing 'sides' of brushes, maybe??) and what can (other than efficient brush work - big fail for me!) overcome this?
Cheers.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

The implications of this warning are none so long as you use FitzQuake or any other high capacity engine (if your laptop has an Intel adapter be sure to try out DirectQ, by the way). The warning is purely there as advice for the mapper, and indicates that the map will fail to load in a regular engine.

Opinions will vary as to whether or not the warning should be there at all; I would personally feel that it shouldn't, or that it should be a developer 1 warning, as warnings like this will only serve to confuse the eventual player (or anyone else not intimately familiar with Quake's inner workings). It's certainly useful for mappers, but in a more player-targetted engine I would think it serves no purpose, and would even be more useful for mappers if it was in qbsp instead. The player is only concerned about whether or not the map will load; they don't need to know info like this (especially not if the map did load OK).

A "marksurface" is just a reference stored in a leaf to a surface in the map. The BSP doesn't actually contain your map brushes (or their faces) at all; instead it contains it's own faces (which are brush faces broken down even further) which the engine then converts to surfaces at load time. That's a pretty brief summary of the thing, but there is a lot more detail involved in terms of how the final bsp is constructed.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

The simplest way to reduce them is probably to reduce the number of window-type indents/jutting-out blocks, and not just because of the reduction in surfaces due to this.

The warning that fitzquake reports means only that it will not work in vanilla quake, as mh said. I agree that the warning ought to be in qbsp instead.
ajay
Posts: 559
Joined: Fri Oct 29, 2004 6:44 am
Location: Swindon, UK

Post by ajay »

Thanks for that both of you. I'm relieved to hear its not too much of a worry... I'm just loving making this map at the moment - I want to be ambitious, while remembering Quake's restraints...
negke
Posts: 150
Joined: Wed Apr 16, 2008 5:53 pm
Contact:

Post by negke »

There are ways to bring down the marksurfaces count. You can try to avoid unnecessary face splitting by moving brushes that touch 1 unit away from the adjacent ones, e.g the lantern posts from the floor. In some cases it helps if you turn certain structures into func_wall entities. Note that both techniques may have unfortunate side-effects to lighting like missing or unwanted shadows. Though I take it your map is far from being finished, so marksurfaces will probably increase even more, which means those tricks won't be enough anyway.But since you're going for Fitzquake (v0.85, that is), you don't have to worry about that for the time being, like the others said.

I agree with mh about the warning message being unnecessary and possibly confusing for casual players. However, apparently many mappers are unaware of the developer mode, or just too lazy to use it, so I'm not unhappy about the message being displayed at all times... This way it's a bit more foolproof.
BJP's QBSP does display a warning if any of the bsp limits are being exceeded. If you don't use it, ajay, I strongly recommend switching to it. And also to the final version of WVIS - running a fullvis on this map will most likely be a journey through hell and back still...
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

i might have to agree with MH about the messages... yes. its nice to know for mappers. but with any developer i think you should do research on the engine to see things like "developer 1" not knowing about it isnt an excuse to me. also aj, i know you want a big map. but another thing to solve this problem is to link your maps almost as if they're 1 map. like how your walking through oblivion and you hit a certain part and it has to load.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

Regarding the warning:
What's the point in supporting large maps if you're going to scare the user away (not just the mapper) every time they play such a map?

Regarding developer 1, some engines might generate a heck of a lot of spam which is really useless unless you're looking for a specific message. My own engine is guilty of this, and most engines will spam like crazy any time someone gets the ring of invisibility (due to too-high frame numbers). Expecting people to use it purely because they're making a map/mod is unreasonable.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

Spike wrote:Regarding developer 1, some engines might generate a heck of a lot of spam which is really useless unless you're looking for a specific message. My own engine is guilty of this, and most engines will spam like crazy any time someone gets the ring of invisibility (due to too-high frame numbers). Expecting people to use it purely because they're making a map/mod is unreasonable.
That's a fair point; I'm guilty myself of using developer 1 for notifying of external textures being loaded, models being freed, etc.

I wonder would it be a viable idea to pop up such messages based on heuristics, such as if a map has no visdata it would be reasonable to assume that it's WIP? I woulddn't suggest this as a solution I'd have my heart set on, just floating an idea.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Post by frag.machine »

Logging verbosity can be controlled by the cvar directly:

developer 1: only real problems/errors are printed
developer 2: engine/QuakeC warnings (like "texture dimensions are not power of 2, automatically resizing" or "not light info found, map will be fullbright")
developer 3: spam mode

If keeping behavior compatibility is an issue, invert the values (developer 1 behaves as usual, and developer 3 is the more restrict mode).
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Post by metlslime »

word on the street is that excessive marksurfaces do not guaranteed a crash in standard engines. My theory is that the worldspawn marksurfaces are the only ones that matter, so as long as they are under 32k, you are fine. Of course the current fitzquake warns you about *total* marksurfaces.

As for the warnings being displayed when developer = 0; I was on the fence about this but decided there are enough clueless mappers that you'd better make sure they see the message even if they don't know about the "developer" cvar. But it's true that there is a potential to confuse players.
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

once again i would have to say that the experience of the gamer is far more important than what ever the developer is doing. the developer can either just do what they're doing and find out later down the line and fix their problem or they can just not be lazy and research the engine they're using. As a gamer i seriously wouldnt want any kind of developer chatter up on my screen disrupting my gameplay.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

metlslime wrote:word on the street is that excessive marksurfaces do not guaranteed a crash in standard engines. My theory is that the worldspawn marksurfaces are the only ones that matter, so as long as they are under 32k, you are fine. Of course the current fitzquake warns you about *total* marksurfaces.
Wouldn't in->firstmarksurface wrap and become negative? Causing out->firstmarksurface to potentially point at some block of data further back in hunk? Causing data corruption somewhere else? Maybe there's a case where the data that got corrupted was in the lighting or visibility and as a result just wasn't noticed?

in->firstmarksurface in Mod_LoadLeafs should matter, but I think it can benignly overflow during R_RecursiveWorldNode.
metlslime wrote:As for the warnings being displayed when developer = 0; I was on the fence about this but decided there are enough clueless mappers that you'd better make sure they see the message even if they don't know about the "developer" cvar. But it's true that there is a potential to confuse players.
That's a fair point; the experience with fullbrights and overbrights is proof enough that some content creators lack the necessary understanding of the game that they're creating content for. :evil:

It would still be really nice if a solution that was suitable for all parties could be found though.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

mh wrote: It would still be really nice if a solution that was suitable for all parties could be found though.
developer 0/1 toggle in options menu?
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

Who even looks at the options menu, aside from new players? Most mappers will have their configs already set the way they want them and won't even go there.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

right. but those are the gamers that you need to attract back to quake.
Post Reply