SV_RecursiveHullCheck: bad node number

*** WARNING 30: Clipnodes 84117 exceed normal engine max 32767
*** WARNING 37: Faces 42056 exceed normal engine max 32767
*** WARNING 31: Marksurfaces 49951 exceed normal engine max 32767

Thank you, friendly BSP format limit.

After just a few hours of mapping, e1m2rq’s clipnodes count went from 47k to 84k yesterday, crashing all of RMQe, DP and FTE upon loading the map. Oops. Seems like I broke Quake. Again.

What happened? Here’s the best idea I have:

The older parts of the map were already very detail heavy, without the map even being layout complete. I’m talking Doom 3 level of detail here, using models for things like new torches, candles, human base equipment and turrets, but largely brush-based detail which makes the count of a number of esoteric quantums somewhere in the BSP format increase.

In this situation, I then decided to turn the entire map into playable area – inside and out. You can basically walk on the roofs, and you can grapple up through openings in the roofs. You could even jump out a high window, or fall off a tower. Stuff like that. I surrounded the level with terrain until it formed a square. Then I built a simple box of sky around the entire thing, and started detailing the roofs of the entire structure and turning them into playable area.

As you can see, I was planning to surround this “core” with triangle terrain. Some I did by hand, and for the rest of the outlying terrain I wanted to use the Canyon Terrain Editor, which had already proven its usefulness.

What is a map with terrain without vegetation? So, coming from Crysis mapping, you know, and with quite some optimism, I thought to put grass and trees in. I even got there, without many problems, as I already showed you, and the results were pleasing.

At this point, it still ran, and looking down from the central tower the r_speeds showed about 18k wpoly and 60k epoly max. The RMQengine, magnificent as it is, handled this punishment gracefully.

So yesterday I did a good bit of blocking out and adding basic geometry to the end of the map, in order to get it finished for the coming demo. I built another 24 sided tower, some bits of castle wall, some broad-strokes type of detail for the towers etc, an archway, and a broken bit of wall. I also started to divide the terrain of my large courtyard into terraces, in preparation for eventual detailing with triangle mesh. This is about what was added yesterday:

I also had to enlarge my surrounding terrain on two sides to keep it a square.

So this bit of stuff apparently broke Quake. Anyway, it crashed the engine with the error given above. At first I thought I might have too many vertices; so I deleted about 4000 triangles (which is why the brush count is down to 7000-something). Nope. Turns out it was the clipnodes – I went way, WAY over the BSP format limit of 64k in just a few hours.

Great.

Now as you might gather from the screenshots, there isn’t really much I could remove. The map isn’t even layout complete – the exit is still missing, and the large courtyard isn’t even detailed. Plus the outlying terrain isn’t even in yet. Can you imagine how many vertices and clipnodes that stuff will add?

Also, consider that stuff like this is still in the pipeline:

e1m5rq already breaks the old map size limit and there isn’t even any terrain to consider yet. Imagine that surrounded with nice mountains and stuff. But… but… the limits!!1!1one!

Fuck the limits, man. e1m2rq is the third map in RMQ that’s running into the limits of the BSP format (e2m1rq and e3m3rq were the others). Some of us were forced to hack around those, offloading geometry into external .bsp files for example. Frankly, that is quite horrid and it can’t go on like that. Eventually, something has to give, and something is going to give. Just not right before a release.

What this means for you guys is, this map might after all not be in the demo, or it will be included in a heavily restricted form. This sucks, naturally, but I think we have just, definitely, found the end of a technology that was devised in the 90s.

Advertisements

7 responses to “SV_RecursiveHullCheck: bad node number

  • jakub

    hi gb,

    it’s an interresting piece of writing. there is only one thing i’m quite worried about. it seems to me like you are going to create something bigger than it’s possible in q1 engine. don’t get me wrong, i don’t want to question your determination to finish quake remake. it just seems to me that you’re heading inevitably to the decision that q1 is simply not enough for you to express your ideas. the wip pictures of your maps look great, but i’s clear your mapping skills exceeded the limitations of q1.

    i’m looking forward to the quake remake, really, but i’ve seen too many promising projects being killed by similar desire for perfection. i don’t want to discourage you from making spectacular maps… just remmember you can still make a great map, even without creating an overgrown monster that breaks all the limits.

    those roofs look good …. it’s just …. are these roofs going to be a part of gameplay or will they be there with all the details only because “we can”?

    jakub

  • Inkub0

    hey that map is really HUGE =)
    maybe you played crysis too much hehehehe

  • kneedeepinthedoomed

    Jakub, thanks for that. You are of course right.
    Rest assured that most of Episode 1’s maps are indoor levels, which goes a long way towards avoiding these limits. Maybe you have played e1m6rq from the last demo – it’s well inside the old BSP format limits. The problems there were more related to details taking up a lot of vis time – I’m sure mh and Lardarse still remember trying to push that map through their PCs and almost melting them in the process. This was “resolved” by turning most details into func_walls, with one eye on the possibility of having detail brush support in the future.
    e1m6rq breaks some old engine limits, but those have been raised long ago in most modern day engines, so it runs quite happily in Darkplaces for example.
    e1m3rq breaks the old map size limit, which breaks the protocol. That’s not really a problem though, since many engines support newer protocols like Fitzquake’s 666 and Darkplaces’ DP7. What I did was expand protocol 666 to create RMQ’s experimental protocol 999. That solved the map size issue.
    The BSP format problem is a little harder to overcome. It revolves around limitations of how many vertices, clipnodes, marksurfaces and so forth you can have in a map. All of those are related to the map’s physical size (brush count), complexity (brush based detail), and whether it contains large open spaces or not. That last one is what caused the clipnodes problem.
    I’m aware that good maps don’t need to be big. e1m2rq isn’t actually physically large. It’s just a) pretty detailed, and b) pretty open. I didn’t anticipate any issues while making it, which might be due to lack of experience with making Quake levels, and I certainly didn’t mean it to be limit breaking. I didn’t see it coming.
    As it stands now, I can decide to row back until the map fits into the BSP limits again, or continue and “do it right”. I discussed this with others, and the tendency was to go ahead and do it right, and make it possible.
    Especially since other RMQ mappers have also run into the same limits.
    So the team’s tendency is, and has been for a while, to opt for creative progress, even if that means breaking the limits, getting flamed for “killing Quake” or “not being Quake enough”, and having to come up with ways around these obstacles.
    To be honest, that’s the spirit of RMQ.
    Also to be honest, the limits of the BSP format were chosen pretty arbitrarily, back in 1996 when Quake maps had to fit on a 1.44 MB floppy disk! Is that relevant to us today?
    Be sure I won’t add additional stuff just for the sake of it. I have a vision of what I want each map to be, and I’ll stop as soon as that is accomplished. 🙂
    The roofs are good for something, they’ll be playable area, there will be secrets up there, possibilities to use the grapple to the fullest, additional flying monsters, and freedom for the player – the one thing that’s missing in many recent shooters.
    The outlying terrain should create the impression that the level is a real place, and that there’s more to it than just what the player can explore.

  • =peg=

    I think the 24 sided towers are the problem here.. and build order.. curved surfaces tend to ‘cut up’ a lot of the existing faces, resulting in a lot higher poly-count.. use wire-frame-mode when testing, to see if you get lots of extra poly’s in places they were not there before placing the towers.. func_wall’ing them towers may be the only real short-term solution, or experiment with the build order (as in which brushes are the first to get processed by QBSP and effectively determine the branching in the bsp-tree)

    *hope any of that makes sense, it’s been a while since I’ve been mapping for quake*

  • =peg=

    To illustrate my point above:

    If your tower is sitting on a floor brush that is fairly large, QBSP will do something like this to it, while if you manually ‘cut up’ that floor like so, the damage is limited..

  • Chip

    I once tested a Darkplaces feature. Loading a misc_model .md3 file and using it as a map feature. It was a well. I don’t remember the BBOX setting I chose (I’ll look it up), but I was able to climb the well and jump inside. The .md3 model behaved as a normal brush. And it was more detailed. It was perfectly circular.

    Now that you brought up the subject of using .md3 models for certain map objects, such as torches, I’ll try to further push the limits of my old function and see if I can convert an .obj/.3ds layout into an .md3 file, then import it into a level.

    Darkplaces promises OBJ loading.

  • jakub

    thanks for extensive reply gb,

    i’m not a mapper, just a player. my mapping skills don’t exceede occasional few-brush-attemps. on the other hand, i’ve played almost everything worh playing for q1 (sp only – not interested in deathmatch) in recent 15 years. so… i just wanted to say that size isn’t always the matter :-).

    as i’ve said, i’m looking forward to the qr, but i would like to play it with darkplaces without a necessity of buying some ĂĽbercomputer.

    as for the “not enough quake” debate …… my point of view is simple. is an ogre in there? is an double-shotgun in there? is an shambler in there? yes? then, it’s definitely quake. i always read one particular pointless thread on func_msgboard regarding this issue when i feel down. it makes me laugh.

    jakub

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: