Hey,Let's Make A List: ..

[metal_head]

After lots of hours of level editing, I decided to write this topic in the forum because I think that it will be usefull not only to me,but to all the RF community members,who have just started a big game project,but have framerate problems.

I would like to make a list of all these thing which optimize the framretate and all the others,which slow it down,so let's get started :

Actor LOD (Level of detail) this can be found in the enviroment setup entity,shortly it changes a high poly actor with a low poly actor when you get in a defined distance from it.You'll have to make a low-poly version of the actor you want this to be applied to,you can read about that in the documentation.

FarClipping I assume that everyone knows what far clipping is,it can be found in the Enviroment setup too and it's a pretty good choice if you want to optimize an indoor level.

Marking unseen brush faces as sky - I do this in all of my levels and it really helps (or at least I think it helps )

Models - making figures,which are made from several brushes models.I think that really speeds the game up.

Making small brushes empty - I'm not pretty sure about this one,but I thik it should be optimizing the game since collision is not used.Also for lights on the floor (which my game has) or something like that it's very uncool when the player collides with them,he stops moving and you have to avoid them.

Detailed- marking small brushes detailed.Once again,I don't know how does this help,but I posted a topic like this before and I think Jay told me this,as he is a moderator of the forum I beleve him .

Full Vis - When you click the build button in the level editor,chech the Full Vis box.It will take some time for the editor to compile the level,but it's REALLY working.

Let everyone who knows some more tips and stuff for optimization or for framerate killers,it would be nice if you post it here!
I don't have much time now,but I'll post some more tips soon! Oh yeah,If I'm wrong about something,correct me immediately,I don't wat people to screw up something in their games because of me.

[Jay]

And it's coming again... the same old topic....

from:
http://www.realityfactory.info/forum/vi ... ing#p26154

Some guidelines for optimizing performance:

1. Use a FarClipPlane, helps alot (It' in EnvironmentSetup). In a dungeon-like level (not outdoor), check for the longest corridor/biggest room. Then set your FarClipPlane to a value that is slightly over the lenght of the corridor. For outdoor levels, try out.
2. If you don't need light, you can disable it with Setting 'FullBright' in the FaceAttributes to true. Or you can make the lightmaps bigger with LightmapScale (also in the FaceAttributes). This alot helps too. In any case, set 'FullBright' for the big hollow cube.
3. Don't know if you've been doing this, but make all small objects 'Detail' brushes and NEVER make the big ones, like the buildings 'Detail' brushes. Also don't do this with the big hollow box around your level.
4. How big is the big hollow cube? It should not be ultra-big(>4000TexelX4000Texel). I think that lowers the framerate a bit. Always just make the big cube so big that you can fit in what you need.
5. For the final compile, use FullVis. This needs much longer, but makes sure that the BSP culls 100% of the unseen polys.
6. Look at the skydome script if you're using one. Sometimes it uses high polycounts for the sky, when you could go with much lower polycounts and it would still look good. Also disable the skydome terrain if possible. If you're unsure, post your skydome script here.
7. If possible, use 'Area'-Brushes for world models like doors and such. This causes the engine to ignore the secluded areas completely. Sometimes, non-transparent empty brushes are an option too.
8. DON'T use Mirrors in open places. I have warned you. If possible, use Area or non-transparent empty brushes to seclude the place where the mirror is. Mirrors double polycount.
9. Do not place two mirrors in the same room and in no case directly opposite from each other (or in an angle that is less than 90degrees). Placing them in the same room might work, but will make polycount 4 times as high as before. The engine puts a stop to the mirror recursion after one or two mirrors (don't know exactly anymore), so placing two mirrors in the same room might not look realistic.
10. Rain and Fog entities are frame-rate-killers.
11. Prefer actors (as SEPs) over detail brushes if you don't need detailed collision on the object. The smaller the actor is, the better (for clipping reasons). With SEPs you can also have nice stencil shadows, although that will lower the framerate again. SEPs are very good for ambience objects.
12. Use ClipBrushes instead of using the built-in StaticMesh collision for terrains. Some terrain generators can export both to a modelling format and to *.map. Export to both, then use the actor for the visuals and the imported *.map file for the collision (as 'Clip' brushes)
13. Do not use too many entities. The engine has to cycle through all entities, and each entity takes its time. Remember that.
14. Use TGAs to lower polycount for thinghs like ladders, fences, rounded doors, windows, trees. In short, everthing that has holes in it.
15. Make tree leaves out of 2 planes using TGAs. But you can not use stencil shadows on the trees then.
16. Outdoors and Indoors should be in different parts of the level. (Can also be done with Area brushes for the doors) Then when you go inside/outside, you must teleport the player.
Windows are a nice thing. But looking from inside to outside or vice-versa too much (like 30 houses with insides) kills performance. This is why you should seperate the indoors and outdoors.

At the moment i cannot think of more thinghs.

This topic might also be interesting:
http://www.realityfactory.info/forum/vi ... f=6&t=3575



EDIT: Oh and another: Build your levels brush by brush, because then the level compiler can make the bsp-tree as simple and small (=fast) as possible, if you use cut brushes the bsp tree will be as complex and big as possible (=slow). I had a level in which i could shrink the bsp tree from like 800 leafes to 18 leafes (!!!!) by not using cut brushes and making the rooms seperate (you get teleported to another room when you use a door). So it was far less complex and i had really high framerates.

The reason why to make small brushes detail brushesis the same as to build the levels brush by brush. To keep the bsp tree small. If your brush is small, it cannot cull many polys. Most of the time nothing is culled by a small brush, because big thinghs behind small thinghs are still visible partially. But the engine still needs to test this brush everytime even if it will never occlude any other brushes. It's wasted energy.

[metal_head]

thanks,Jay I guess,that's really all about the optimizing stuff,anyway,if someone knows about something optimizing,that's not mentioned by me or Jay,post it.
BTW my player's scale in my game is set to 0.5,so that way the levels won't need so much space.If someone has made his player a smaller scale and it looks like the player is small,try making the ground or floor textures in your game with smaller scale.

Also I was wondering about the texture scale...does this affect the framerate too?

[Juutis]

BTW my player's scale in my game is set to 0.5,so that way the levels won't need so much space

If I'm not totally mistaken here the only advantage of this is that you can make bigger levels (read: RFEditPro lets you create relatively larger levels without crashing). But you can't create as detailed brushes since one texel is relatively bigger (and one texel is the minimum length for a brush, I believe). And you're only gonna get increased framerate if you don't scale the light maps (Face Attributes -> Light Map Scale). And the bigger the light map scale the less detail the lighting has. Basically you could leave the level to normal size and use a larger scale for light maps. That would do the same thing.

Also I was wondering about the texture scale...does this affect the framerate too?

I don't think so. The size of the texture only affects the memory it takes.

[metal_head]

You got a point,but that has not affected my game's framerate by now,I think.Also I made my game like this: when you reach a ceratin point in your level (in this case the end of it ) the game stops and loads the next level and the player has the illusion that you just proceed through the same level.The only problem is that this will wok only if the level change model is somewhere,really narrow,so the player won't be able to move sideways,because when the next level i sloaded the player starts at the player start poit at the level,if you get what I mean.
that way I can split a level in several parts,and it won't take so much from the framerate .

[scott]

that kind of thing will be good if we had progressive loading, however i do not belive RF has it at the moment.

Now im not entirly sure about this one, it is a theory and as such needs proving if anyone wants to give it a shot, as many people know spliting large terrains into smaller ones means that the engine doesnt have to render all at once and so on, however on a smaller scale, if you have a very complex and detialed model, spliting this up into sections would also improve frame rate as back faces wont even have to be loaded, but the main point of this is collision detection, as i understand it, RF does collision by bounding box and then by per poly collision, now i may even be wrong but i think it then calculates all pollys within the model to get the correct collision, splitting the models would give them all smaller bounding box and in turn when a bullet enters the box it has less pollys for per polly collision, as it is most modern game engine uses something called octtree collision, this automatiucly splits any given model into segments in a grid style.

If this is the case, splitting the models down into small sections could possibly speed up the game rate and still have per polly collision.
I would like a second opinion on this from someone who knows the engine better.

[paradoxnj]

that kind of thing will be good if we had progressive loading, however i do not belive RF has it at the moment.

You cannot do this with the current Genesis BSP or any BSP for that matter. In order to achieve this with RF, you need to remove the BSP from Genesis which is a huge task and will change the way levels are created.

[Jay]

Now im not entirly sure about this one, it is a theory and as such needs proving if anyone wants to give it a shot, as many people know spliting large terrains into smaller ones means that the engine doesnt have to render all at once and so on, however on a smaller scale, if you have a very complex and detialed model, spliting this up into sections would also improve frame rate as back faces wont even have to be loaded, but the main point of this is collision detection, as i understand it, RF does collision by bounding box and then by per poly collision, now i may even be wrong but i think it then calculates all pollys within the model to get the correct collision, splitting the models would give them all smaller bounding box and in turn when a bullet enters the box it has less pollys for per polly collision, as it is most modern game engine uses something called octtree collision, this automatiucly splits any given model into segments in a grid style.

If this is the case, splitting the models down into small sections could possibly speed up the game rate and still have per polly collision.
I would like a second opinion on this from someone who knows the engine better.

Exactly. This is why i always split up terrains and terrain-like models like caves (i use similar techniques for terrains and caves/tunnels).