GTK's limit thread [aka. MAX_xxx]

[monaster]

Don't know if this could be anything useful, but since I tend to max out nearly every map when working with GTKRadiant, I wondered if anyone else ever had the same problem and maybe tried to find the exact limit for brushes, planes, lights etc. that my beloved editor can cope with.

So the idea behind all this is listing these maximums for brushes,... according to a certain version of GTK, for example:
GTKRadiant 1.2.1:
max_planes: 5375
max_patches: 354 (try to avoid patches having sizes larger than 5000x3600 units)

GTKRadiant 1.5.0:
max_brushes: bla
bla: bla


and so on. [Please note: These values are just made up and do not represent the real limits GTKRadiant has.]

This way people (like me ) will know what they did wrong (by reading the error sticky thread) AND get a slight idea of how much they have to delete or simplify and so forth.
Just hope, that this topic makes sense (i.e. if you can't solve a MAX_XXX-error by simply deleting some brushes so you'd end up with 5375 brushes, then this thread would be useless).

[obsidian]

Errr... I don't think those are GTKRadiant limitations per se, so much as limitations with Q3Map2 (they show up when you compile your map, not when you're building it). Some limitations may be a little silly by today's standards (consider that most things were designed for 10 year old hardware in mind), but most are still in place else memory limitation issues, etc.

Most of these don't have any clear limitations, it depends on the map, construction techniques, system resources among other things. If you build "clean" and smart on any reasonable sized map, you can sidestep most of these issues.

[monaster]

obsidian wrote:

Most of these don't have any clear limitations, it depends on the map, construction techniques [...]

You're right: I just managed to successfully compile a map with -2076464019 grip points envelope culled. Yep, minus 2 billion (of course, there's been some value displayed wrong, but it must have been pretty high nevertheless. Just like reaching the maximum money value in SimCity 2000 which then changes automatically to a negative of -2 bn. and something. ).

[fKd]

show us these insane maps... i've been building quite detailed stuff and im nowhere near the limits...

[monaster]

I know your maps fkd (and I like them, keep on working), and some of my projects tend to grow pretty detailed too, but most of the time it's about the size of my maps that make me reach a limitation ot two (and the other time it's just stupid and unprofessional mapping but good lord these situations are getting rarer every time I start up GTKRadiant, thankfully ). It's the same with the billion error: One of my recent maps features a huge abyss you can fall into and obviously it's been a 'bit' too huge for my compiler (playing cool since obsidian hinted that one ). Maybe I'll upload it but especially this map is far from finished and ususally I release my maps if I think they are nearly done... which is why I couldn't get myself to release ANY map up to this day. Enough of those smilies, since I wanted to create a new thread with some preview screenshots of my projects to push me further towards releasing them and thus avoid starting a new map every time the first one is nearly completed, I could as well publish a preview version of the billion error map (hell there's even someone interested in it, so why not?). But don't expect too much, my studies cut off much time I otherwisely would have invested in proper and dencent mapping.

[monaster]

Hm, I'd rather publish a few screenshots because it's really not worth it to spread that unfinished piece of brush crap at that early stage, sorry, but trust me, it's for the better.
For the rest actually topic-related stuff:

Found some old Q3Radiant limitations, some could be valid for even newer releases like GTK, I'll try to find out some more but always keep in mind, that

Most of these don't have any clear limitations, it depends on the map, construction techniques, system resources among other things. If you build "clean" and smart on any reasonable sized map, you can sidestep most of these issues. (obsidian)

:

MAX_MAP_MODELS 1024
MAX_MAP_BRUSHES 8192
MAX_MAP_ENTITIES 2048
MAX_MAP_PATHS 2048
MAX_MAP_TEXTURES 1024
MAX_MAP_TEXINFO 8192
MAX_MAP_PLANES 65536
MAX_MAP_PORTALS 65536
MAX_MAP_NODES 65536
MAX_MAP_BRUSHSIDES 65536
MAX_MAP_LEAFS 65536
MAX_MAP_VERTS 65536
MAX_MAP_FACES 65536
MAX_MAP_SURFEDGES 256000
MAX_MAP_EDGES 128000
MAX_MAP_VISIBILITY 0x100000 (that stands for a certain value too, but I can't figure it out right now, I have some notes elsewhere for doing this though, so expect some updates)

[Silicone_Milk]

MAX_MAP_VISIBILITY 0x100000 (that stands for a certain value too, but I can't figure it out right now, I have some notes elsewhere for doing this though, so expect some updates)

1048576 (ie. 1 MB)

You can find the MAX_ values in q3map2.h which comes with the GTKRadiant source code if you're ever curious.

[monaster]

Guess where I got the values listed above from
That raises the question if there is any need to continue this thread if anyone can actually do the same and just look up the different files in the source code. Continuation would only make sense if there's anyone knowing other -more recent - sources to gather information from. I'll probably just wait and see if anyone responds.
Thanks for the clarification with the 0x100k thing by the way!

[Noruen]

We can try it Now I have map with 12177 brushes and 636 entities and still working well

[^misantropia^]

Yeah, radiant and q3map2/quake3 have different definitions of what a brush is. In radiant a brush is the basic building block, in q3map2/quake3 it's a volume of space that contains one or more 'traditional' brushes. Though by that time they aren't brushes any more but vertex strips. But I digress.