SEED - Watching entities

Intoduction

Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:

1. static entities with an entity def (f.i. atdm:statue_aphrodite). This is basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE). You'd use "Create entity" in DR to create such a thing.
2. static models (f.i. models/darkmod/decorative/wall/longbanner_ragged.lwo). This is also basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE), except that the spawnclass is "func_static" for all of them. You'd use "Create model" in DR to create such a thing.
3. func_statics based on brushes or patches. You'd use "Create func_static" in DR to create such a thing.

There are fundamental differences betwen the first two cases and the third case:

In both the first cases you have an entity, and a model in a file. This means, it is always possible (inside the engine) to load the model data by just given the file. Also, the engine will only ever keep one copy of the model data around (sharing it).

In the third way, you have the "model data" stored in the map file. Not only is it not possible to reload that data (as there is no model file name), but also all the data is duplicated if you duplicate such a func_static in DR.

Why can combining entities improve performance?

• One important feature of the idTech4 engine is that if it has to render multiple things for multiple light passes, then it uses one drawcall per light per "what it renders". This means if you have two tables based on map geometry (brush or patch), then it is better to combine these two func_statics into one, as it will reduce the drawcalls.

Why can combining entities degrade performance?

• If the two things you combined cross a visportal afterwards, then they will be visible in both areas. That can lead to the situation where the entity is no longer culled, instead it is always fully drawn becaue the engine can't know that only half of it is visible.
• If each part of the entity is hit by one light, then the combined entity is hit by two lights, and thus both parts are drawn twice, where formerly only one part was draw once for one light, and the other for the other light.
• If the combined entity covers an huge area, the engine will often thing things are inside that entity space, even tho they are "between" the parts. This can lead to poor performance in case of stims or collision detection. For static entities (even solid ones) this is usually no concern.

When should you combine entities?

• When all parts are hit by the same light(s) (or none)
• AND all parts are in the same visportaled area
• AND all parts are reasonable close together (a few 1000 doom units)

func_statics based on map geometry

For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.

Entities with a model

For the first two ways there is, however, no way you can combine them in DR. The only recourse you have is by taking a modelling program (like Blender) and then combine the entities in it and create a new model. This is not only time consuming but also cumbersome.

And here is where the SEED entity comes into play.

For our example, we create 6 banners on a wall. 5 use the same model (ragged banner, 3 with one skin, 2 with another skin) and 1 uses a different model (big banner). Here is how it looks in the editor:

And here is how it looks in the game, before (without SEED) and after (with SEED combining models):

You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).

See also

• SEED
• SEED Usage - Examples on how to use SEED in real-map scenarios
• SEED - Known bugs