InsideQC Forums

Do you guys have any tips for achieving good speeds with big open areas? I'm targeting vanilla WinQuake/GLQuake by the way, AirQuake mod.

You should probably avoid complex geometry, especially surfaces at unusual angles. Keep the amount of brushes and details low. Use as many axis-aligned brush faces as possible, as well as other simple angles like 45 degrees. Small detailed objects should be func_wall. You don't want to have tons of bsp planes spamming all the open air.

As for the simple overhead of rendering large or distant surfaces in software Quake, I don't really know anything about that.

Cranking up the texture scale helps, since then there will be less lightmap to process

Avoid using sky; this is quite evil in GLQuake and a major source of performance loss in open areas.

Try to keep the number of textures used really low, as OpenGL will be able to batch things up better for you, so you get more efficient drawing.

Engine-side, assuming you're using unmodified GLQuake, disabling multitexturing and using a really large value of gl_subdivide_size (for sky if you must use it - although it will look awful) can help in some cases.

Whether you like it or not, QBSP is going to take your nice clean and simple geometry and carve it up into a hideous amount of small polygons. This is a Very Bad Thing for any hardware accelerated renderer, and Quake formats totally lack what's needed to ameliorate it, so the best you can do is a limited form of damage containment. Even a very large box room will get you a high polycount and GLQuake itself unfortunately just isn't up to the job here.

leileilol wrote:Cranking up the texture scale helps, since then there will be less lightmap to process

However, WinQuake doesn't scale dynamic lights along with the textures, and no software-rendered Quake engine has fixed this yet, as far as I know.

mankrip wrote:

leileilol wrote:Cranking up the texture scale helps, since then there will be less lightmap to process

However, WinQuake doesn't scale dynamic lights along with the textures, and no software-rendered Quake engine has fixed this yet, as far as I know.

GLQuake's like that too.

So, plain terrain generated from GenSurf for example, surrounded by a big box to cover leaks and be the sky, won't work?

It might work, but it'll probably end up being retardedly inefficient.

Have a look at the Marcher Fortress or Masque of the Red Death. They're probably reasonably representative of the upper limit of what Quake can handle.

Really though, you're dealing with 15-year-old technology that was never designed to handle this kind of rendering. It's just the wrong tool for the job in this case. Yes, you can code around it in your engine's renderer, and get very significant performance boosts there, but ultimately the BSP format is working against you and unless you change the BSP format it's a fight you're not going to win.

someone should make a new engine , (maybe not based on quake) that still uses simple but expanded .QC similar to darkplaces, but not built around quake? hard to explain. (maybe new formats for everything? aside from .QC? ) i would most definantly switch to that engine. just for the sake that it ran fast and if i had to i could develope what i want alone.

If you where to make a new engine, I wouldnt use qc .

why not .qc ? it's simple and useable? have you any idea how easy it is to learn?

Stay on topic... he is targeting vanilla Quake.

By the way, I think that the Quake map compiler subdivides large surfaces. So even you have a simple map, if it's really big you are probably already close to getting "greyflashes"... so I guess the answer is to make fairly small, fairly low detail maps

QC is simple and usable but it's also completely useless for the matter being discussed. It's like saying a screwdriver is a simple and usable tool, but if you wanted to mow your lawn...well you wouldn't use a screwdriver, would you?

Yes, QBSP splits up your brushes. This was really essential in 1996 when trying to get polygon count (and overdraw) down as low as possible for a software renderer that ran on a pentium 60 with 8 MB of RAM. (Although it wasn't really polygons but we'll let that pass.)

In 2011 - it's evil.

This is one of the things about the Quake engine. It's perfectly fine within it's design limits, but as soon as you start trying to go beyond those limits you very quickly hit a wall. If you're restricting yourself to the ID Quake engines then you'll just hit that wall sooner.

a geforce2mx can push about 100 million verts per second. a million verticies and you still get a decent framerate.
a quake engine cannot push that many separate surfaces per second.
qc is not the bottleneck.

a BSP renderer is designed to reduce overdraw. things are culled by the BSP. Its great for large archetectural stuff.
It sucks for detail. Its fairly good for maps like quake has, but as soon as you add extra detail, not only do your mappers complain about lack of tools (like curves), but the engine starts to crawl when it has 10k surfaces in sight.
Especially when you consider that each and every surface has a lightmap, which may need updating.

a lot of engines nowadays directly support heightmaps. this is because it is so much faster to build a mesh from it instead of using a bsp tree. its better to forsake vis culling entirely than it is to use a bsp tree. plus, collisions can usually be faster too.

combine them, use nodraw type surfaces under your heightmap, you get culling from the bsp tree, and performance from the heightmap. if your nodraw type surfaces aproximate the heightmap sufficiently, you can cull the other side of mountains and things like that.
of course, if you're using heightmaps, you probably want some sort of terrain texture blending.
but that's another story.