Achieving good speeds on open areas

Discuss the construction of maps and the tools to create maps for 3D games.
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Achieving good speeds on open areas

Post by JasonX »

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.
Sajt
Posts: 1215
Joined: Sat Oct 16, 2004 3:39 am

Post by Sajt »

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.
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Post by leileilol »

Cranking up the texture scale helps, since then there will be less lightmap to process
i should not be here
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

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.
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
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Post by mankrip »

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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Post by leileilol »

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.
i should not be here
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Post by JasonX »

So, plain terrain generated from GenSurf for example, surrounded by a big box to cover leaks and be the sky, won't work? :(
Sajt
Posts: 1215
Joined: Sat Oct 16, 2004 3:39 am

Post by Sajt »

It might work, but it'll probably end up being retardedly inefficient. :P
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

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.
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 »

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.
Arkage
Posts: 66
Joined: Thu Nov 19, 2009 4:17 pm

Post by Arkage »

If you where to make a new engine, I wouldnt use qc :S .
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

why not .qc ? it's simple and useable? have you any idea how easy it is to learn?
Sajt
Posts: 1215
Joined: Sat Oct 16, 2004 3:39 am

Post by Sajt »

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 :P
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

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.
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 »

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.
Post Reply