Another week — once again brings things that moves our project toward playability and full compatibility with Morrowind. It’s true that we are once again progressing with nice speed.
Since animation task is closed both jhooks1 and Chris was left without a task, but happily not for long…
Jhooks1 currently returned to physics implementation — you probably noticed that collision with npc is flawed: It’s very easy to get stuck and in general behavior is very different then in Morrowind. This is not surprising at all since the way collision with npc works is itself not like in Morrowind. To make story short: while player character has it’s own collision capsule (sphere that replaces the actually body mesh for the collision) npc are still half baked and use the body mesh for physics. That’s the source of problems.
Jhooks1 is now busy with enabling the collision capsule also for npcs. That should solve most (if not all) problems in this area.
Meanwhile Chris is researching the morrowind feature not actually present in the vanilla game but often used in mod enthusiasts content: Billboard nodes. Most of you seen only billboard trees that adds a lot of eye-candy to the game, especially when compared with plain flora — but yet, the billboard nodes itself are more universal. Currently it’s hard to tell if this feature will be present in OpenMW any time soon since experiments didn’t brought ultimate insight.
greye continues being awesome. Dropping related job is finished and this week He is actually working on two branches. First off He started (and made a nice progress with it) task of player control. That’s a big road blocker for a few… sorry Did I wrote “a few”? For a countless other tasks and features that are yet to come!
gus is back! And He is programming again! I missed him a lot — He is a really friendly guy… and developing openmw makes him super cool.
gus works on Object_movement_creation branch to add new script instructions related to object movement and creations. In theory, objects should be able to cross cell borders. Although It’s not tested, now we have script instructions to test it… effects will be known next week.
This branch attacks roadblocker at least as large as player control. We must finish it before adding another large features.
Eli2 works on editor. Not just this week, but now it’s time to say that actually this is a really good job. Although a lot of it is actually mostly provisional It already looks pretty good: The filters are working, the list displays items. Personally I see the beginning of the editor I would like to work with: very simple approach, very minimal yet ergonomic design, more then just enough of planning.
We need the editor, sooner or later, and it would be better to have it sooner — before OpenMW 1.0.0 so We won’t need to hold work on long awaited modding features in the game data format only because there is no editor to work on this format in the first place. Everybody would love to have multiple exteriors and other goodies, right?
Although our multiple esm and esp support is still in embryonic state mark76 helps to test it a little. After returning from India and sharing the experience about it. He created a few small test plugins to expose complications in the current implementation. It can take a long time before issues will be solved and this long awaited feature will debut in the release.
Zini decided to add a brand new options “–script-console” and “–script-run”. The first one enables additional console only commands that are intended to test our engine (currently none) while –script-run allows to point a file containing script instruction that are about to be run on game start.
Sorcerer, a new developer that joined us recently works now on task of importing configuration from morrowind.ini to openmw.cfg file. The importer is functional right now and soon should be complete.
Scrawl does not work on OpenMW at the moment, but instead He focused on the shiny lib, supporting us this way. He implemented LOD material generator and although we are not going to use it before OpenMW 1.0.0 at some point it may become a really handy tool for us.
Though there won’t be a new release for July, last week was a great one for OpenMW. So let’s recap.
First off, we have a new developer, _greye, who finished his first task (making CreatureStats into a class) in a single day. Then he picked another one (maintenance in the item dropping code) and finished that in a short period of time. Both were very well done, so thank you _greye and welcome to the team!
nhydock, another new developer, has taken the camera control task (which is composed of four or five subtasks).
scrawl’s new shader system has been merged into the main branch. What does that mean for OpenMW? Until now we have been using the Nvidia CG toolkit. This toolkit works with DirectX and OpenGL on all graphics cards, but only gives good performance with Nvidia cards (which is understandable since its developed by Nvidia). We need both DirectX and OpenGL support because Radeon graphics cards (built by amd) lack quality OpenGL drivers. Otherwise we’d just write our shaders in OpenGL. Again the problem is CG doesn’t provide good performance for the Radeon cards. To make matters worse, CG is closed source and available for on Linux, windows, OSX and not on BSD.
To avoid the above mentioned problems with CG, many game developers instead write all their shaders twice: in GLSL for OpenGL and in HLSL for DX or just ignore OpenGL and focus on DirectX.
But the situation is improving because Scrawl made a library called “shiny”. From now on we can write a shader once and then compile it as either GLSL or HLSL. But that’s not all, here’s scrawl detailing the new library’s design and features:
– High-level layer on top of OGRE’s material system. It allows you to generate multiple techniques for all your materials from a set of high-level per-material properties.
– Several available Macros in shader source files. Just a few examples of the possibilities: binding OGRE auto constants, binding uniforms to material properties, foreach loops (repeat shader source a given number of times), retrieving per-material properties in an #if condition, automatic packing for vertex to fragment passthroughs. These macros allow you to generate even very complex shaders (for example the Ogre::Terrain shader) without assembling them in C++ code.
– Integrated preprocessor (no, I didn’t reinvent the wheel, I used boost::wave which turned out to be an excellent choice) that allows me to blend out macros that shouldn’t be in use because e.g. the shader permutation doesn’t need this specific feature.
– User settings integration. They can be set by a C++ interface and retrieved through a macro in shader files.
– Automatic handling of shader permutations, i.e. shaders are shared between materials in a smart way.
– An optional “meta-language” (well, actually it’s just a small header with some conditional defines) that you may use to compile the same shader source for different target languages. If you don’t like it, you can still code in GLSL / CG etc separately. You can also switch between the languages at runtime.
– On-demand material and shader creation. It uses Ogre’s material listener to compile the shaders as soon as they are needed for rendering, and not earlier.
– Shader changes are fully dynamic and real-time. Changing a user setting will recompile all shaders affected by this setting when they are next needed.
– Serialization system that extends Ogre’s material script system, it uses Ogre’s script parser, but also adds some additional properties that are not available in Ogre’s material system.
– A concept called “Configuration” allowing you to create a different set of your shaders, doing the same thing except for some minor differences: the properties that are overridden by the active configuration. Possible uses for this are using simpler shaders (no shadows, no fog etc) when rendering for example realtime reflections or a minimap. You can easily switch between configurations by changing the active Ogre material scheme (for example on a viewport level).
– Fixed function support. You can globally enable or disable shaders at any time, and for texture units you can specify if they’re only needed for the shader-based path (e.g. normal maps) or if they should also be created in the fixed function path.
This library should make the lives of developers easier and since it is designed for the Ogre3d rendering engine, it could have bright future beyond even the OpenMW project. Huzzah for open source!
Take a look at the new water shader scrawl made using the “shiny” shader library.
If all that is not awesome enough, then wait dear readers, because there’s more.
In every blog post since time immemorial we have talked about getting animations to work, but now that saga’s beginning its conclusion. That’s right, the new and completed animation system awaits testing in the main branch. jhooks1 and Chris’s huge effort is bearing fruit. You can expect only falling action (bug fixes and performance improvements) from here on out.
Although animations have been present in OpenMW for some time, they did not use ogre’s animations system, instead OpenMW manually moved all bones. This was not efficient and not all creatures were correctly animated, especially those from expansions sets. For example, Bloodmoon’s werewolf animations looked really bizarre.
But now those problems are solved and we employ Ogre for the animations. Even hardware skinning can be added as a post 1.0 feature.
Zini is finishing up the potion usage task. Now the drinking sound effect plays correctly. Additionally, zini refactored the action class.
Corristo made sure that OpenMW still works for you OSX users out there. There were mac specific bugs that should now be resolved.
We migrated to new servers after the result of the slashdot effect exposed our inability to handle heavy users loads (our servers crashed). The first choice was amazon cloud which looked quite nice, but soon it became clear that they are insufficient for our needs. At the moment OpenMW.org is on one MyDevil.net server, while bugtracker and forum are on OVH server. In addition OpenMW.org is protected by Cloudflare CDN “proxy”, so it has chance to handle next slashdot effect.
Another week, another post for you, dear readers. This summary includes the most significant changes by our veteran developers, but there are some folks doing important work that is not credited here. So thank you to all our contributors.
Last week, I wrote about the shaders used in terrain rendering. This week scrawl, using shaders, reduced the amount of code for terrain implementation by 75%. THREE CHEERS FOR EFFICIENCY!!!
OpenMW employs shaders for our skybox, water, and soft shadows. Scrawl has worked on refining the first two, resulting in marked visual improvements over the original Morrowind. The process of refining shaders will continue, so expect many perty pictures and videos. Great work Scrawl!
Speaking of great work, Chris pushed a large number of code revisions (50!) towards integrating .nif animations into Ogre3d’s animation system. Once complete, this will prove to be a more efficient method for animations and boost OpenMW’s frames per second. It works… to some extent. Currently, animations are lacking integration with the physics system, some meshes (for unknown reasons) are not animated, and other meshes occasionally ( and seemingly randomly) are not animated. However, clothes (including robes) are working, as well as the majority of creatures. We cannot give you an exact date when it will be finished, but what needs to be done to get physics integration working is mostly understood. The other issues are cryptic and it is difficult to tease out their causes.
Meanwhile Zini, our fearless leader, finished the magical effects drain and fortify. Also, the bug in the auto-equip logic was fixed, as well as a few other bugs in various areas. Zini also refactored the code for dynamic statistics and merged a lot of branches into the main development branch.
Reverse engineering formulas is going well. The ingredient eating formula appears close to completion (some things still need to checked and verified) thanks to Lazaroth. The acrobatics task is also progressing nicely, BrotherBrick is using his powerful server to calculate data points and Epsilon is a very dedicated worker, designing formulas to test. It may be finished as early as next week.
As you probably noticed, the site was down. This was due to a sudden and sharp increase in page views that occurred when OpenMW made the news aggregating website slashdot.org. A veritable horde of readers clicked on the story, passed to our site, and soon all I could do as an admin was log into the server and watch with shock and awe as the heart of apache processes was torn out. Normally we get 10,000 page views a month, and because of slashdot we had 25,000 in one day.
However, we benefited as many new developers and contributors have discovered us and are now joining. So we’d like to say, Thank You Slashdot! And despite the setback of the site being down, the development team continued their work as usual.
Zini was working on the refactoring task when he found many unnecessary “includes” in the source code. Don’t worry readers about what includes are, all you need to know is that many were unnecessary and that translated to slow downs in compile times. Many users complain that it takes forever to compile and build OpenMW and while users could perhaps view compiling OpenMW as exercise in patience, they won’t have to as removing these “includes” improved build times by nearly half.
He also worked on proper skill development implementation. As of now, the only skill that can be seen in game is Alchemy (and even it’s not finished), but that will soon change.
Scrawl has been tinkering with shaders. Interestingly, he found that using GLSL shaders caused build time improvements twenty-one times. Since the number and complexity of shaders OpenMW uses can be described as “modest”, the impact on the total compile time is negligible, but it’s still intriguing.
jhooks1 is still working with animations.
Figuring out Morrowind’s formulas has finally gained momentum. Myckel is bravely working on alchemy, and he has a couple new colleagues on the forums which include Epsilon. Epsilon is developing scripts to speed up the testing phase exponentially. It’s great work and we welcome them to the team.
It’s that time of the month folks. The 0.16.0 Release Candidates for linux, OSX and windows are available and need testing! They can be found here.
Chris made a breakthough with animations! The new Ogre animation system can now animate all the creatures nearly perfectly. The new animation system should be substantially faster than our current system, which involves manually moving bones. You can check out two preview videos of the new system here; animations of werewolves are working, and the Ancestor Ghost is almost there!
zini is working on a way to compensate for performance loss from a badly written morrowind.esm script by changing our implementation of the offending script. Most fans of our project are hoping that OpenMW will bring performance improvements to morrowind… so it’s exciting to see things like this.
The situation with the physics improvements is still unclear and additional work is required to tell how useful it will be. Here’s hoping!
Many of our developers also worked on bug fixes for the upcoming release.