MAX_MAP_DRAW_VERTS <- what is it?

(G0-Gerbil) #1

Title says it all, just got this error and it’s a brand new empty map with maybe 200 or so brushes!
The map is extremely large though - might that have something to do with it?

(Ifurita) #2

200 brushes on top of your terrain? How large is the map?

(SCDS_reyalP) #3

MAX_MAP_DRAW_VERTS 0x80000

Seems like rather a lot for a 200 brush map.

Perhaps it is because of very large sky brushes being tessellated ?

(G0-Gerbil) #4

Sky brushes get tesselated?

The brushes are split into rings that don’t touch each other, apart from the bottom ring touching the ground. I did wonder if it was this causing the problem (the ground plane being split because the bottom set of brushes all touch it), so I shifted the ring a few units into the ground (so their vertices wouldn’t lie on the ground plane - I don’t think edges on planes caused splits, but just in case…) but no joy.

(ydnar) #5

Got a shot of the map in Radiant?

I don’t think I’ve ever seen this error once. Heh.

(G0-Gerbil) #6


As you may be able to guess, I’m simply trying to flesh out the rough shape / scale of my next map Minas Tirith - hence why the map is so large (hour plus time limit total anyone? :)).
Of course, if I can’t get out of the starting block I have a wee problem…

The bottom ring is the one I mentioned moving so it wasn’t flush with the ground plane. Everything except the bounding box is detail, and the little white blobs in the 3D view are the spawn entities. Well, actually the white blob by the bottom ring is a cluster of around 5 of 'em, but there’s just a solitary one at the top :slight_smile:

(G0-Gerbil) #7

In fact to give you a sense of the overall scale, here’s a close up of the top bit to put it in context (will work on the levels as individual files - too much all at once).
Note I am only trying to go a normal simple compile, no lighting (since of course lightmapping will take forever and use vast amounjts of lightmaps - chances are much of this will use vertex lighting to get around that issue).

(MuffinMan) #8

good luck with that one gerbil, hope you don’t run into our problems with a big map, there are several engine limits to hit that hardly anybody ever sees…

(rgoer) #9

It looks like you’ve got a detail brush sticking into the void. This is a no-no and could possibly be causing this error (though, generally, detail-in-the-void causes a “backwards tree volume” error).

(G0-Gerbil) #10

I’ll take a look at the detail in void situation and let you know if it helps - cheers for the thought.

(ydnar) #11

Isn’t that a bit small?

(G0-Gerbil) #12

Somewhere along the line scale has to be tweaked for gameplay reasons :slight_smile:
I’ve just worked on the scale that the road at each level must be wide enough for buildings and multiple routes, taking into account I’ll be having ‘caves’ (well, interior of normal buildings actually) built into the inner rock face of each level (so there’s an open route and a covered one).
In other words, I’m shrinking it as much as possible so it’s not simply a 10 minute slog from one side of the map to the other only to die and have to do it all again.

(G0-Gerbil) #13

OOOOOOH MY GOD I R TEH n00b!

Entirely my fault (aren’t virtually all mistakes exactly that? ;)).

I was using as my grass the shader I wrote for mml_claustrophobia which uses the automatic model placement shader property.
So yes, q3map2 was trying to cover my immense area of grass with an immense number of grass models. No suprise it borked.
Problem solved, stupidity felt, silence to follow :smiley:

(G0-Gerbil) #14

Anyway, now it compiles, here’s some ‘interesting’ stuff:

  • It takes over two minutes to run around the outside base
  • It takes 5 seconds to fall from the top layer to the ground
  • A panzer fired from the top takes 3 seconds to hit the ground
  • An airstrike will happen before the smoke cannister hits the ground

(rgoer) #15

oops ;^)

(G0-Gerbil) #16

Yeah I know, fairly intimidating :wink:
But then the combat is never supposed to take place at both ‘ends’ at once, you work your way up layer by layer.
The tricky part will be making the city look detailed from the outside, but hinting everything so when in the city it only actually draws a little bit.
I think spectators will get an atrocious frame rate, because they’ll be able to ‘back out’ and see everything all at once. But then, that’s their problem :slight_smile:

(rgoer) #17

good luck with that, I look forward to seeing it

(Jan) #18

Just a suggestion.

You could make the map bigger by turning it into a full campaign. Each map could be a ring (or 2.) It might get boring though after a few rings :o

(G0-Gerbil) #19

Yeah already thought of that, but don’t really want it like that if I can avoid it, it just wouldn’t feel right.
My current idea is that that if attackers take too long in a given section they automatically capture it and the fight moves up.
I’m favouring this over extending time limits at certain points (many matches with strong defence might never see top bit of city!) and over a simple long time limit (spawncamped for 3/4 of an hour? sounds like fun - not) since much of the map will be seen and it always gives attackers something to aim for.