Improvements for 2.32
Version 2.32 will feature some internal improvements that ensures your games run their best when conditions get demanding. I've totally rewritten the vegetation rendering routines with a highly specialized quad tree algorithm. There's a lot more to it than that, and I could write ten pages about the technique, but the bottom line is its fast and dynamic. Rendering with many vegetation layers is much faster, and since the visibility determination routine is so optimized, the engine can perform a separate visibility determination step for each stage in a directional light. The amount of shadow polygons that have to be rendered was less than half what version 2.31 required, in our test scene. Realistically, you can now render more trees with Leadwerks than Crysis.
For entities, a scene octree has been implemented. This ensures that the engine only has to deal with objects in the near vicinity of the camera, even if there are tens of thousands of objects offscreen or far away. For scenes that have lots of little objects, you'll see a big performance gain, especially if you use the view distance feature. In version 2.32, each entity has a view distance setting which can be set to near, medium, far, or infinite. The engine stores lists of objects by view distance for each leaf in the octree, and skips object sets that are too far away, without having to iterate through each one. In the future, I would like to implement an update radius...this is how S.T.A.L.K.E.R. games are able to have so many AI characters walking around a map, and it's not too hard to add!
Another improvement is the hierarchical rendering and picking algorithm. In version 2.31, every entity was stored in the scene graph. In version 2.32, only entities with no parent are stored. The top-most entity has a recursive bouncing box that encompasses all its children and sub-children, and is automatically updated once a frame when anything in the hierarchy changes. Let's say you have a truck. The truck consists of a chassis, four wheels, and a rotating turret. In version 2.31, all six sub-objects would be stored in the scene graph and iterated through for rendering. In version 2.32, only the top-most entity is stored in the octree. If the top-most entity is not visible, the entire truck is skipped. If the top-most entity is visible, its children are iterated through until they are all rendered.
What about the case of animated characters, which might have 100 or more bones in their hierarchy? Wouldn't it be inefficient to have to iterate through the whole skeleton, especially when most of the time there won't even be anything that needs to get drawn? Yes, you are right. I got around this problem by adding a "renderable" setting to each entity. Meshes, coronas, emitters, etc., have the renderable setting set to True. Pivots, bodies, and other invisible entities have it set to False. Each entity also stores a recursive attribute that stores the number of children in its subhierarchy that are renderable. So when a bone is encountered in the rendering algorithm, if it doesn't have any renderable children in its sub-hierarchy, it will be skipped, and the engine won't have to iterate through all those bones for nothing. If the bone connects to a shoulder that connects to a forearm that connects to a hand that has a gun attached to it, the engine will iterate through those entities to get to the renderable gun mesh. It's the best of all worlds.
If you only have a simple scene running, you probably won't see any speed improvements. However, these features will make the difference between your game running or not when you get further along in development, and will ensure you get the best possible performance. I would like to be working on some more high-level features that make the development experience nicer for the end user, but the most important thing for me to do is make sure your games are the best they can be. That's why I thought it was important to devote time to the described areas.
14 Comments
Recommended Comments