Adding proper multi threading

The last couple of weeks I've been working on adding proper multi threading support in Ember. This builds on the work Manuel did during the 2009 Google Summer of Code.
Basically there are two goals with adding better multi threading:
1) Make Ember seamless, so there aren't any stuttering when large pieces of data is processed in the main thread.
2) Leverage the way modern CPUs today come with multiple cores, making the client faster overall.

The first goal is the most pressing. Since Ember is totally controlled from the server, and nothing about the world is known beforehand, situations often occur where as the user moves through the world new data is presented which requires extensive processing. The best example of this is the terrain and the way new terrain features are streamed to the user in real time.

When researching how best to implement multi threading two approaches presented themselves. Either I could devise a system where each subsystem had a dedicated thread, and then make sure that these subsystems communicated with each other in a safe way. Or I could try to identify smaller pieces of functionality which could be run in parallel and define tasks for these.
The first approach would solve the main issue, i.e. making sure that the main rendering thread works uninterrupted, but wouldn't help with the second goal. There's only so many subsystems to work with, and in some years time it won't be uncommon with 16+ cores. Instead I opted for the second approach, which is to try to identify "tasks" which then can be designed to be executed in separate threads. This approach puts more demand on the ability to identify tasks, and to design them so that the data they operate on is safely separated from other threads. But the benefit is that it's now possible to better utilize multiple cores.

For this purpose I've implemented a simple task execution framework in Ember. The first target of improved multi threading support using this framework has been the terrain system. Unfortunately our terrain library, Mercator, is not designed at all to allow multiple threads to access it, so currently I still have to make sure that only one thread at a time is interacting with Mercator. But this interaction now always happen in a thread separate from the rendering thread. As the terrain changes settle I'll be moving on to other parts of Ember which also will benefit from multi threading.

Ember 0.5.7 released!

I've just pushed the 0.5.7 release of Ember. More information here.

This release includes a lot of new nifty authoring features, such as snap-to movement. We've also put some effort into getting it to run correctly (with all nice shader effects) on ATI cards. And there are lots of speedups, especially in the terrain handling code.

The multi-threading work done during this year's Google Summer of Code isn't included in this release because of a couple of regressions; it will hopefully be merged in soon though.

Easier authoring

The latest addition to Ember is a new authoring mode in which all entities in the world are easily selectable through graphical representation. While most entities in the world normally are represented by a graphical mesh, not all are, and not all meshes are easily selectable. This is most obvious when trying to alter terrain areas and mods, since these in most cases don't have any graphical representation at all. Previously one then had to either know the id of the entity and access the editor for it through the console, or use the entity browser to find it.
With the new visualizations this becomes much more natural, since it's now only a matter of selecting the entity in the game.

Another new addition is a feature for easier selecting entities obscured by other entities. The need for this arose from changes on the server for how the ocean is handled. Previously it were solely a client effect, putting a transparent plane in the world to represent the ocean. Now it's however a entity just like any other. This however presents a problem when picking things that are in the ocean, since the normal operation then would be for Ember to always report that the ocean was picked. The solution for this is a new feature in Ember which allows multiple "mouse pick results" to be presented. If any of the entities picked is transparent (such as the water) Ember will also look for any entity beyond the transparent entity. Through a simple paging mechanism in the mouse picker widget the user can then flip through the picked entities and select the one she wants to interact with.
I think it works pretty well, but I'm a bit biased so I would love to get some feedback from other users about this feature.

Major refactoring

I've just pushed a major refactoring I've been working on the last couple of weeks to the master repo. In the end it turned out really well.
The main part of the refactoring was to totally revamp the whole entity hierarchy in Ember, and how the entities are tied to graphical Ogre representations (meshes, lights, particle systems etc.). As with most refactorization, I had made some assumptions about how things worked a couple of years back which didn't hold anymore, and the code was beginning to creak from workarounds and special cases.
One of the assumptions made was that all entities in the entity hierarchy tree would be represented as an Ogre scene node. Another was that all graphical entities would be shown using the Model class. As one of our GSoC students, Amey, began to implement his task and needed some client extension for this it became apparent that these assumptions do not always hold. It's not always certain that an entity will be arranged in the Ogre scene graph through the use of a scene node. The most common instance is when something is attached to a skeleton (like a person wielding something). In addition, there are many kinds of entities which need graphical representation, but not through the use of a Model. In Amey's case it was the ocean.
Furthermore, when I first made the entity class system I used inheritance, so that each different entity would be of either just a normal EmberEntity class, or a PhysicalEmberEntity class, depending on whether it had a graphical representation in the world. However, as I work more and more with software I've come to realize some of the issues with depending too much on inheritance. Instead I now more often find myself component based design. In such a system the behaviour of instances are mainly determined by the interactions between the components that make up them. This of course leads to more complex systems, where it's a bit harder for a newcomer to get the full picture of how any given part should work. But it also leads to much more powerful systems, without many of the incorrect inheritances one tend to end up with when over using inheritance.

All this lead to me totally redesigning the entity class system. There's now only one entity class (well, except for the world entity, but that is a truly unique instance). The way something is shown is now handled completely separate in a graphical component, owned by the entity. And the way it's arranged in the Ogre scene graph is also handled by another distinct component. The end result is that there's now a much more robust system in place which more correctly maps how things really are arranged. This means that we now have a much more cleaner design, which is also extensible enough to handle more advanced cases than the previous system could. I've already pushed code which will connect an ocean entity to a water representation, something which in the old system would have required all kinds of hacks.

ATI graphics fixes

The last month saw both the release of Ember 0.5.6 and the start of the Google Summer of Code.
The Ember release included the really nice addition of real time shadows, thanks to the work done by Alexey. It also included some really nifty area editing tools for world authors, as well as the usual slew of polish and bug fixes.
After the release was done Alexey and me did some additional work on the shadow system, to fix some of the bugs and artifacts that existed in the release. Amongs them was some issues with shadow texture fidelity at certain distances and a bug where lights that were created in the world never disappeared. Another issue we found was that lights which were attached to entities which a character was wielding did't get updated as the character moved. The prime example here was the torch, which in turn had a "fire" child entity.
All of these issues has now however been fixed in git master.
I've also added a new nifty snap-to-move feature. It's activated when you move an entity in the world, and allows you to easily make it snap to another entity. The snapping is done by matching the bounding boxes of the entities. This is really useful when building fences or walls, since each wall section then can snap into the other.

However, the bulk of my time the last couple of weeks has been spent on graphic glitches, mainly those found on ATI cards. We've known for a little while that there are a couple of artifacts on ATI cards, but since none of the main developers use ATI cards (we use Nvidia, since at least historically their Linux support has been orders of magnitudes better than ATI) we haven't really known how bad these artifacts are.
After upgrading to Mandriva 2009.1 I began to run into X server segfaults when running OpenGL applications. I therefore had to abandon my Nvidia card until the issue has been fixed, and it just so happened that I was able to borrow an ATI cards from work.
Turns out there were all kinds of issues with ATI cards, amongs them the issue with random segfaults within the OpenGL driver. Just this issue had me spend more than a week trying to track down. Intially it wasn't clear that the crashes were random, since they seemed to occur near certain materials. However, after disabling more and more features it became apparent that they were indeed completely random. Thanks to cdleonard, developer of the Caelum environment system, we concluded that the issue was that using hardware generated mipmapping on ATI cards, as supplied by the SGIS_generate_mipmap extension, resulted in random memory corruption withing the (closed source) GL stack. Yep, pretty much the worst possible kind of bug to track down. Once we did track it down it down and disabled the crashes went away.
There are however still some artifacts on ATI cards. The paged geometry has some issues, since it in places mixes vertex shaders with fixed function fragment processing. And the high detail glsl shaders doesn't produce any output, so when running Ember in high detail level all meshes are hidden when viewed up close. But all of these issues are easily fixable and it shouldn't take long until we can do a new release, which will work much better on ATI cards.

The Summer of Code is also progressing nicely. Manuel reports on the progress over at the wiki. We're now mainly in the discovery stage, where we're identifying where in the code base it would be suitable to add threading support. Nonetheless Manuel has already submitted a series of patches for various code cleanup issues which I've merged into Ember trunk. Git is truly a wonderful tool!

Realtime correct shadows

Finally, Ember has complete real time shadows. It took some time, and it wasn't until Alexey some months ago dove into it that we finally got a working implementation. But not only did he add shadows to the world, he also added a complete graphics level framework, where Ember will itself detect the kind of graphics card the user has and tune the graphics accordingly. This means that if you have low end card you'll still be able to run the client at playable frame rates, while if you have a newer card you'll also get real time shadows and other nice effects. One of the reasons we couldn't do this before was that it wasn't until Ogre 1.6 that we got easy access to the techniques needed to do shadows on the larger scale that our world presents (it's a bit harder to do outdoor shadows than shadows in an enclosed space).
Alexey did most of the work, and I got in at the end and fixed some issues with how the shadow system differentiated between semi-transparent and opaque materials. It turned out that Ogre doesn't have functionality where you can specify a template shadow material per technique (for example one shadow material for the "High" technique and another one for the "Medium" technique) and then have Ogre automatically supply all of the material settings from the regular material (alpha settings, textures to use, etc.). It can do that if you specify a scene manager general shadow material, but if you specify a shadow material per technique it expects you to provide all of the information needed in that material. Given the amount of materials we use that's not a viable solution; it's much more easier if we used a material template which would for each shadow pass get the correct data set. Thanks to the modular design of Ogre this wasn't hard to do, as can be seen in this commit. The result is both working shadows and a material setup that's both simple and flexible.

I've also put some work into improving the way the minimap for the compass is rendered. Previously it used the same lightning as the regular world, which mean that it was completely dark during the night. That's been fixed now, so it's always rendering it with a nice midday light. I also made it use a simpler material. This fixes some stuttering which presented itself when you moved rapidly through the world, as well as fixed the issue with ugly shadows appearing on the minimap.

A demonstration of the correct shadows, the runtime graphical settings changes and the new minimap lightning is shown here.

And a higher quality version is to be found here.

Using terrain mods to level ground for buildings

One of my pet peeves for quite a while is that most of the buildings in the game stand on uneven ground and have the terrain poking through their floor. This is an effect of the way we use Mercator to create a dynamic terrain, so that it's never guaranteed to be any level area in it.
And that's where the terrain mods come into play. By using terrain mods we can alter the terrain at specified areas. There are a couple of different types of "mods" we can apply, and for this problem the "level mod" seems most suited. It will make sure that the terrain specified is altered so that's it's leveled to a specified height.
There are two ways of specifying this height. Either we use a fixed height, telling the system for example that the area should be leveled to a height of 20 meters. Or we use a offset height, so that the height specified is relative to the position of the entity to which the terrain mod is attached. For this case the latter is more suitable, since we want the terrain to be leveled to the same height as the entity.
The clip below shows how this can be done in real time on the server. We first create a house, which when positioned on uneven ground will have the terrain poking through the floor. By adding a level terrain mod, with an offset positioning of 0 meters, the terrain will be altered so that it's level under the house. As we move the house, the terrain mod is moved as well.

Higher quality version here.

The level mod has one disadvantage however in that it will both raise and lower the terrain to the specified height. In this case, we would want it to lower the terrain, but not always raise it. It would be nice then to have floor functionality, so that terrain that is higher is lowered, but lower terrain is unaltered. The current terrain mods available don't allow for this yet however. If we would implement it it would also need a change in the terrain mod interface in the Mercator library, since the TerrainMods currently doesn't know about the existing terrain.

Switching topics, I'm glad to announce that for the second year Worldforge was accepted to the Google Summer of Code. The last year we had three students who all performed splendidly, and the whole program was a great experience. I'm really looking forward to this year. We're now in the phase where we're accepting students' applications. If you're a student which would rather spend your summer getting paid for writing FOSS code for virtual worlds than turning hamburgers or digging ditches, please take a look.

Completed terrain area editing

Initially I planned to have gotten the terrain area editing completed some weeks ago. However, when I started looking into the existing entity editor code I found that it was lacking in some areas, mainly the structure which made it cumbersome to add new adapters and to have it be easily extendable and handle suggestions of both attribute names and attributes types. So I spent a couple of days refactoring the entity editor to turn it into a better shape. It paid off in the end, since it's now much easier to extend it. And the lua code, which was quite haphazardly written, is now much better.
The main visible improvement is that we now have the ability to suggest an attribute name, not just a type. This will help with editing, since any author then won't need to keep track of the names of the important attributes.
The new terrain area adapter allows you to add new areas to any entity, and to edit any existing area. You can add or delete new points, and you can alter the layer which is to be used.
I've put together a small movie of this in action. In it I show how you easily can create a new entity (in this case a barrel), add an area to it, alter and edit the area, and then remove the entity from the world.

Higher res version over here (be sure to try the HQ version).

The nice thing about the area editing is that it's implemented as a general feature, so now that we have support for editing terrain areas, it should be easy to also add support for editing terrain mods, which in much of their functionality are similiar to terrain areas (the former alters the heightmap while the latter alters the terrain layers).

Graphical area editing

I've committed a new feature to Ember, which is graphical area editing in real time. I've always felt that it was something that was missing and was crucial for easy world editing. A lot of what makes up the features in the terrain is based on areas. It's a really nifty feature which allows us to add all kinds of different details to the world. There are also some ideas of expanding them to be used for server side foliage definitions, as well as integrating the area code with the terrain modifier code.
However, editing areas have always been cumbersome, even with the improved entity editor in Ember. Basically the areas are made up of polygons, which are defined using a list of points. Editing an area thus involves manually altering the individual points, which is really time consuming and hard to do.
The new area editing feature presents a nice graphical way of altering the areas through simple dragging and dropping of points. The current implementation only allows for alterations of existing areas, and you cannot add or remove points. That's all to come however, but the current behavior is already a vast improvement over the previous functionality, as can be seen in this movie.



High quality version available on YouTube.

When creating the code for the placement and movement of the nodes I could reuse a great deal of existing placement code in Ember, much thanks to the way it previously was written to be generic. It's always nice to see some of the earlier hard work paying of in these ways.

Unified terrain mods

Since this summer's Google Summer of Code we've had support in both Ember and Cyphesis for terrain modifiers. The server side implementation was however incomplete and didn't support all of the shape types available. Furthermore, Sear didn't have any support for terrain mods.
When working on providing a more unified functionality for both the clients and server it quickly became apparent that we needed to push some of the functionality in Ember down to lower level libraries in order to avoid code duplication.
The first step was to extend WFMath to have atlas parsing and generating methods for the more complex shapes. Previously only primitives such as Position and Vector had such methods. One of the advantages of this is that all clients and servers won't have to bother themself with the format of the atlas data, since that's taken care of by WFMath.
Another issue was that the actual code for connecting terrain modifications to the entities to which they belonged was duplicated in both Ember and Sear. The main issue was that it would normally go into the Eris library, but Eris didn't have any dependency on Mercator. That was easily fixed by adding such a dependency, after which the bulk of the duplicated code could be moved into Eris.
The end result of all this is that we now finally have correct and unified support in both Cyphesis, Ember and Sear for all available terrain mods and the shapes used by them. One of the most useful of the mods are the level mod, which makes sure that an area of the terrain is levelled. This is extremely useful when placing houses and other structures, because you want to make sure that the house sits on level ground. If not, you run the risk of having ground poking through the floor, or the foundation of the house seemingly resting on air.
In the following movie you will see a house to which a rectangular polygon shaped level mod is attached. The level mod doesn't have any specific height set and will therefore use the height of the entity itself.

Higher quality can be found here.

Improved shadows

Alexey has spent some time lately improving both the shader and shadow support in Ember. The shaders for both the terrain and the regular meshes have been reimplemented in GLSL and have had a nice slew of improvements added to them. One of the most exciting feature is proper support for real time shadows.

One of the issues we've been having is that regular texture shadows tends to result in very low res and jagged shadows when used with a large scene such as our outdoor scenes. This is because the texture that is used can only be so large, and the outdoor scenes makes it hard for the shadow system to setup the most optimized camera setup for the shadows. However, thanks to the new support in Ogre 1.6 for PSSM shadows, which basically is a technique where multiple shadows maps are used for variable distances, we now have the option of having shadows that looks good both up front and in the distance.
Alexey has already done a great job in adding support for this, which can be seen in these videos showing off the shadows. Note that they are still a work in progress, so some things such as taking texture alpha into account or shadowing of normal meshes are not yet implemented.








Some more videos can be found over at YouTube.

There are still some work to be done, but the shadows are already looking mighty nice. Of course, lower end machines won't be able to take advantage of this, and one of the things that we need to work on is better support for fall back materials.