Ruminations of alchemy, animations, and death
The Alchemy implementation is complete. Bug testing has revealed some issues that will surely get resolved soon.
Zini is also working on the “Death” branch. There was a bug where everything/everyone was insta-killed. That is no longer a problem, but there are more to be fixed.
The newly finished quick travel services in the “Travel Dialogue” branch is being refactored by Gus.
Pvdk continues working on our launcher with the support for profiles now back!
Greye is working in the “Storedevel” branch on lower level structures of the engine, rather than on user visible features ─ but that doesn’t make it unimportant. In fact quite opposite: without it we would be screwed in many ways.
Chris is digging around in the animations. The number of commits increases, the number of issues decreases but the goal of fully implemented animations is still far away…
The OpenMW engine is so big and interrelated that every feature requires quite a lot of work…
Eli2 as usual continues to work on the editor. Stopgap json serializer has been replaced with the qt variant. There was also Qt5 experiment ─ not very important from practical point of view but some of you may be interested that “It works”.
Welcome! All of you!
The OpenMW editor, which some of you might not even be aware of, has been progressing stably for quite some time now. Eli2 is currently focusing on loading and saving projects. Once this groundwork is finished, other features can be edited more quickly.
Scrawl is not working on shaders at the moment (mark this historic date on your calenders). Instead he’s working with zini on the alchemy implementation. The new code needs to be integrated into the game engine, and also requires its own GUI. He made the original alchemy window, so clearly he’s fit for the current job. Scrawl is becoming a true MyGUI adept. When the GUI first appeared bugs appeared with it, but these are getting squashed now.
BTW, compile time of OpenMW on Scrawl’s computer is about 2 minutes.
Zini assigned the “Death” task to himself. I wouldn’t be surprised if WeirdSexy’s videos get a little more of thriller/horror feel or maybe something ala Overgrowth. Hopefully WeirdSexy will also be able to show some more animations as Chris is working on this feature. Although getting animations to behave correctly is not trivial, the concept has already taken shape.
lgro, the fearless spambot slayer, holy guardian of… eh never mind. Lgro is working on books. The task proved to be harder then it first appeared to be. The only current benefit from Lgros effort is realizing there are problems that need to be solved in the parser. Lgro promises to do the trick, but it will take quite some time.
Another careful operation in the works is on the performance of cell loading. For some users loading is very slow. To fix this, Zini introduced changes, and the testing brought some surprising results. Unfortunately surprising in the negative sense. Honestly, nobody knows what to do! But the team will figure this out, eventually.
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.