I recently tried the infinite terrain sample from the A7.80 update. The vegetation seems very unoptimized because each grass is a single mesh. The debug panel says there are 2000 entities visible at once . Like mentioned before, use a single mesh for many small objects. This reduces the list the cpu has to send to the rendering chain and takes load off of the cpu.

To make many objects out of one mesh I have an idea that should work. In your modeling application you group all the objects into a single mesh and save it as one mdl file. For example, you could have hundreds of trees in a single mdl file. Arrange the trees in a grid pattern. Keep each tree farther away from the other trees than the maximum length of one tree. You then make a rough measurement of that distance. In the code do a distance check on all the verts to all the verts. Depending on how many verts there are this could take a few seconds since it is a distance check on number of vertices in the mesh squared . Now all the distances that are under the maximum length of a tree are associated with a single tree (via indexed array 1,2,3,4...). Keep which tree the vertices are attached to in a file (each vertice has a unique number that stays the same), then you just have to read from the file upon the game loading. The trees can be individually positioned by creating an array of positions for each tree and checking the array with the index in the text file. If you wanted to put the trees on a terrain you would just use c_trace for each tree and update the array.

Now when the game loads, it modifies the position of all the vertices using ent_set_vertex, and if a tree where rotated you could call ent_fixnormals(). The initial setup of the trees is cpu hungry, but once done has no load on the cpu. Only one call to the rendering chain has to be made for one hundred trees. It is even possible to move individual trees where you want to while the game is running. Waving in the wind can be done by a vertex shader without any modification. This approach may be similar to what speedTree uses, I'm not sure though.

Hopefully you understood some of what I was trying to explain.

A7 has a nice WED feature that says export as MDL. you can automatically group all your in WED placed trees and export them as ONE model

I think this won't be a good idea because you can't use correct-LOD for the trees (one model) anymore! Also coll. dectection, shaders, events etc. will be very slow. This is not a good scene-managment!

@sPIKe: Thanks for the tip, that would be a quick and easy way to place them by hand.


Good point. There is never going to be a perfect way to do something, it always depends on the situation.

Why would the shaders/events slow down?

My example may be a little misleading, rather than doing this for trees, (usually collision detection is needed as well as lod) you could just do it for grass/brush that has no collision detection. You may even be able to group dense regions of trees into meshes and still have collision/lod working. There is always a balance that depends on your game though.

This will be slow because:
* for shaders you use also LOD -> trees which are far away don't need a "treeWind"/"SpecBump" Shader, for example, so you switch them of (for each tree which is "far" away)
* events will be slow because the collision detection must alwas check the compelte model (more polygons) instead of checking some bounding-boxes of some trees and then check the polygons of these entites which got hit -> much faster

i said you can do this, not that its good to do so

basically, id genereally sue clipping and removing of trees in the distance. place a boudler or something in front of the view you have to walk around. dont make flat terrains. you can clip alot that way...

thanks for the optimization tips, how do i pause unseen entities?

you can read up about the CLIPPED flag, basically:

if(my.eflags&CLIPPED)
-run code

I played around with this idea about one year ago:
http://hummel.slindev.com/bilder/everywhere_grass.png
Instancing should be still faster and easier to use but you get a usefull amount of performance through this method too.
You can handle the clipping of the 'groups' by linking it to the clipping of an invisible box using the mentioned CLIPPED flag.

Try to avoid the usage of the trigger event and trigger_range.
Those range checks have to be done all the time and for many entities it's many checks each frame.

If you don't need it, turn off GLIDE for c_move. It's slow.

Depending on what kind of level you're aiming for try to block the view of the player to allow better clipping. It makes sense to use BSP then (pro only).
Probably not suitable for outdoor levels.

Instead of scaling down textures on blocks, scale up everything else to get the same result. It's faster.

Remove and purge unused stuff.