Reducing number of nodes in terrain map?

[o'dium]

Can somebody help me or give me a few tips on how i should go about reducing the number of nodes in a Quake 3 terrain map?

TIA.

[^misantropia^]

To be sure, what's your exact definition of 'node'?

[o'dium]

TBH dude i'm not sure. While mapping i'm getting some poor frame rates and Berserk has told me thereason for this is probably related to the number of nodes...? Any help on optimizing terrain maps in general then

[^misantropia^]

In how many vertexes and polygons is your terrain split up? How many portals does it currently have? How much is detail and how much is structural?

[o'dium]

Terrain is a small test map, around 8k brushies, textured with terrain and all none visible sides are caulk, its all detail ATM, none structural, and no portals.

[4days]

never tried to make a terrain map - isn't there a thing you're supposed to do with a func_group and specific keys/values?

could you stick some structural caulk inside the terrain to break the map up a bit? or put sky walls in areas where the player can't reach?

[Kaz]

hmmm... iirc it's the gridsize key or something like that...

[obsidian]

Reducing nodes in this case probably means reducing the tessellation of the terrain mesh. Example, instead of making 256x256 unit quads, make them 512x512.

Terrain maps are no different than normal maps, optimize, optimize, optimize. Make sure you hint properly and think about how you are going to place your portals to reduce line of sight.

Perhaps you will also want to play around with Q3Map2 style terrain shaders. I can't help but feel that Q3TA type metashaders are greatly out of date and a huge fuss to set up. Not sure if your project allows for this.

[Kat]

Also get rid rid of 'dead' tris from the terrain, anything you can't physically see, delete (usually the tops of terrain sections).

If you're getting those type of errors on a small test map then something is wrong. As Obsidian said, if you can go with Q3Map2 shaders then you'll have a lot more flexibility.

[o'dium]

Texture wise we can do what we want thats not a problem. The results have been fine this far so i wouldn't worry about that for now.

Theres not a lot of brush work we can delete, or a lot of places to block vis because its quite an open tech map

[Detoeni]

One way that I got to work quite well was to make two ase terrain models, one high poly and one low. The low poly gets used in game while the high is used to make a normal map* which is used by the shader for the low poly with an over sized (for q3) lightmap being exported by q3map2, 512x512 gives a very nice level of detail for small terrains. (*for best results the normal map should be the same size as the exported lightmap)

Q3map2 does not export the lightmaps cleanly and it will need some editing in Photoshop to be useful.

Leaf nodes are also used in the bsp to manage the contents of the map and you also need to bear in mind that complex collision objects (like terrain) and q3 code are not good bed fellows, as well as using portals to control what’s drawn, they also need to be used so that each leaf has a manageable amount of data in it so that the level can run smoothly.

[o'dium]

Our game doesn't use lightmaps mate.

[Kat]

Our game doesn't use lightmaps mate.

It might help if you let people know exactly what you're working with, that way you'll get answers better fitting to the info you actually need. Right now we're all assuming you're using "Quake 3 Terrain" the way that Quake 3 uses it, and from what you've said elsewhere in the forums, that doesn't appear to be the case.

[o'dium]

Our game doesn't use lightmaps mate.

It might help if you let people know exactly what you're working with, that way you'll get answers better fitting to the info you actually need. Right now we're all assuming you're using "Quake 3 Terrain" the way that Quake 3 uses it, and from what you've said elsewhere in the forums, that doesn't appear to be the case.

Yeah forgive me, i've been making a few threads on a few forums as late and jsut assumed everybody knew for some reason:

That map would rock in Quake 4 kaz. This isn't a request its an ORDER

I've just started working on a little (Read: Tiny) techmap for our new full MP only game "OverDose". Its based on the Quake II Evolved engine, so its fully per pixel lit with fancy effects and what not. ATM we only have a few things done, such as terrain and Quake 3 map support (Supporting maps as large as the GTK grid), Doom 3 Materials, MD5 models etc, but we hope soon to be adding more, like md5anim, scripted UIs and particle effects and more.

Anyways, ignore the trees, as they suck and i haven't done fake shadows for them yet (Fake shadows on this many objects helps a hit load, trust me), and ignore other tatty things (Also ignore the big open spot, i'm working on buildings for there.)

Anyway:

[lvlshot]http://www.quake2evolved.com/odium/overdose_1.jpg[/lvlshot]

[lvlshot]http://www.quake2evolved.com/odium/overdose_2.jpg[/lvlshot]

[lvlshot]http://www.quake2evolved.com/odium/overdose_3.jpg[/lvlshot]

All artwork, models, textures etc are mine except for the sky, which ATM is using hipshots wicked textures because they rock for testing

[obsidian]

Nice screenshots, but since I'm pretty sure that no one else here uses Q2E, you'll have to explain a little about what your engine is capable of.

Does the Q2E engine support q3map_alphaMod directive, or only Q3TA style metashaders? What about D3/Q4 style vertex paint terrain?

Do those trees make use of LOD? I imagine that they are as big of a performance hit (or more) than the terrain itself.

[o'dium]

A lot of people use Q2E, we have a few full retail games that use our engine

As for your questions, it supports D3/Q4 vertex painterd terrain, and the terrain is made in the original Quake 3 TA method (using an alphamap to assign vertex colours)

Trees ATM our not our main concern so they dont have LOD ATM, but the trees will be a special case as when far away they will be replaced with billboard sprites. LOD is generaly frowned upon in Per Pixel engines because the shadows appear odd, but with our trees this is fine as they wont cast sahdwos anyway (Tree shadows will be a shadow decal)

[Kat]

How big a 'feature' is terrain in the engine? The most versatile is using alphamods if using brushwork and vertexpainting for models (unless you can impliment being able to assign alphamods to models by grouping them together - something I quized ydnar about - would have required a rewrite of q3map2 basically).

As Obsidian mentioned if the engine isn't using Q3 terrain the way Q3 does then you're going to be pretty much on your own on this one becasue we won't have working knowledge of the system as you're using it. Everything mentioned so far is pretty much the standard 'look see' things to consider when trying to optimize 'terrain' so beyond that is anyones guess atm.

[o'dium]

Well, we can pretty much say that any tips on how Quake 3 optimized terrain maps will work here. its the same basic code base. Seeing as our maps are all terrain maps its gonna be a needed speed up

[SCDS_reyalP]

Well, we can pretty much say that any tips on how Quake 3 optimized terrain maps will work here.

That sounds like an unwarranted assumption to me, but FWIW...

One problem you get in quake3 maps like what your screenshots show is too many brushes in a given leaf node. Q3 traces [1] essentially do a linear search of the brushes in a given leaf [2] . If you have too many brushes per leaf, the physics code (both on the server and on the client for prediction [3]) bogs down.

I have an ET test map that is a simple box full of nodrawnonsolid brush, which gets only ~50FPS on an Athlon 64 3000 client. Simply splitting the box into a few leafs (using a lower blocksize, for example) brings the FPS back into the hundreds.

People tend to think that BSP splitting only matters for vis, but this isn't true. A BSP that is too simple or too complex are both potential problems.

Empty, non-structure space can have a non-trivial cost, because it results in useless clusters, which in turn bloat the vis data.

Without knowing more about the construction of your map, or the details of your engine and gamecode, it is impossible to give useful specific advice. You need to figure out what aspect of your map is causing the biggest performance hit, and adjust accordingly. The best way to do this is by understanding in detail how your game uses the BSP data.

Notes
1: A 'trace' is the function used for collision detection.
2: brushes are not used for drawing in Q3, but they are kept in the .bsp file for collision detection. See http://graphics.stanford.edu/~kekoa/q3/
3: This is particularly true for vanilla Q3 gamecode, which does prediction in a really inefficient way. How it applies to your engine/gamecode is open to question.

[sock]

Can somebody help me or give me a few tips on how i should go about reducing the number of nodes in a Quake 3 terrain map?

Does your engine support variable sized triangle meshes? Like this for example:



The above terrain mesh was created with an alphamap. The alphamap was based on the small triangle size for XY co-ordinates. If you need to go up a triangle size then remember to use edge flipping to smooth out the triangle edges, especially if you are using old style alpha maps.

Sock