Za nami bardzo udany tydzień, obfitujący w osiągnięcia będące podsumowaniem wytężonej pracy zespołu programistów, której (co bardzo istotne) początek datuje się całe miesiące temu. Gdy jednak do pokonania jest tak długa droga potrzeba wiele czasu by dojść do upragnionego celu. Ta prosta zasada w żadnym stopniu nie umniejsza sukcesu — wręcz przeciwnie, nadaje mu drogocennego blasku.

Innymi słowy dotarliśmy nareszcie do finału Odysei znanej lepiej jako „OGRE3D animuje modele nif”.

Czy muszę jeszcze przypominać jak wiele pracy trzeba było włożyć w tą funkcję? Nie wystarczył jeden deweloper: potrzeba było połączonych sił jhooks1 i chrisa by dojść do obecnego punktu. Teraz owoce tego trudu oczekują w gałęzi main na śmiałków chcących przeprowadzić testy.

Dla osób nie w temacie: co prawda OpenMW miał animacje od dłuższego czasu, ale system opierał się na ręcznym manipulowaniu szkieletami modeli — nie na dobrodziejstwach jakie niesie ze sobą biblioteka OGRE3D. Stara metoda była więc zupełnie nie efektywna, a na domiar złego nie wszystkie stworzenia mogliśmy animować poprawnie — przykładowo animacja wilków dodanych w Bloodmoonie była kompletnie schrzaniona.

Zostawiliśmy te problemy za sobą. Animacje wyglądają prawidłowo, a wydajność nie wypada wcale beznadziejnie; nawet pomimo braku hardware skinningu. Pełen sukces!

Jeśli wam mało to mam dla was kolejną bombę: nowy, ulepszony system shaderów również wylądował w gałęzi main. Co prawda po dziś dzień nie pofatygowałem się wyjaśnić o co tu w zasadzie chodzi, ale teraz postaram się to nadrobić.

Do tej pory powszechnie używa się trzech języków do pisania shaderów: HLSL (wynalazek MS, tylko DX), GLSL (tylko OpenGL) oraz CG (od nVidia, DX oraz OpenGL). Ułomność sterowników OpenGL dla radeonów to fakt powszechnie znany, a deweloperzy gier którzy chcą by ich produkty sprawnie działały u każdego gracza muszą wspierać DX. Oczywiście nie jesteśmy wyjątkiem, tyle tylko, że my nie możemy zrezygnować z OpenGL, a pisanie wszystkich shaderów w dwóch językach równolegle to znaczące utrudnienie.

Wydawać by się mogło, że rozwiązaniem jest nVidia CG. Można używać go razem z DirectX i OpenGL, i to na karcie każdego producenta — fajnie no nie?

No właśnie nie!

Po pierwsze: nVidia CG to własnościowy, zamknięty toolkit dostępny na Linux, Windows, OSX ale już nie na BSD, haiku i inne systemy. Po drugie: jak się okazało nVidia CG działa naprawdę dobrze na kartach (niespodzianka!) nVidii (oddychaj! Wiemy, że jesteś w szoku) i znacznie gorzej na produktach konkurencji. Oprócz tego CG ma inne wady które ujawniły się aż nazbyt wyraźnie, bo niestety ale używaliśmy CG.

Na szczęście scrawl znalazł wyjście z tego bagna.

Biblioteka shiny pozwala, zależnie od potrzeby, specyfikacji sprzętowej oraz platformy skompilować shader napisany w specjalnym meta-języku zarówno jako GLSL jak i HLSL. Już sama ta możliwość jest ogromną pomocą, a zalety są szersze:

– 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.

Biblioteka zdaje się mieć przed sobą świetlaną przyszłość, być może nie tylko w ramach projektu OpenMW.

To, oczywiście, jeszcze nie koniec dobrych wieści…

Do zespołu dołączył nowy programista kryjący się pod nickiem _greye i już na starcie wykazał się sprawnością i determinacją, szybko radząc sobie z pierwszym zadaniem: CreatureStats w oddzielnej klasie. Zajęło mu to ledwie dzień, a gdy Zini wyszukał nowe, zdecydowanie większe zadanie (uporządkowanie kodu odpowiadającego za upuszczanie przedmiotów) _greye jedynie zakasał rękawy i wziął się znowu do pracy. Po kilku dniach ukończył zadanie.

Efekty wysiłków _greye są już w gałęzi master.

Oprócz tego w zespole jest jeszcze jeden nowy programista. nhydock już pracuje nad zadaniem „camera control”.

Zini wciąż nie odszedł daleko od napojów magicznych, a dzięki kodowi dodanemu w tym tygodniu wypicie mikstury wreszcie wiąże się z odtworzeniem odpowiedniego dźwięku (siorbnięcia?). Oprócz tego Zini zrefaktoryzował klasę Action.

Corristo naprawił błędy występujące jedynie na platformie OSX, więc także ci spośród was którzy używają komputerów z logiem jabłka mogą „doświadczyć” OpenMW.

Łukasz, od czasu slashdot miał mniej czasu by bawić się swoim vamp-botem na kanale IRC, gdyż przenosiny na nowy serwer wymagały znalezienia oferty, która byłaby dla nas odpowiednia. Zadanie to samo w sobie niewdzięczne, stanowi jedynie przedsmak wyzwań stojących przed administratorem. Tak czy owak aktualnie OpenMW.org hostowane jest na mydevil.net, zaś bugtracker oraz forum na serwerze OVH. Dodatkową ochronę przed hordami odwiedzających zapewnia „proxy” Cloudflare CDN.

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.

Wpatruję się w miękkie kształty chmur i słucham muzyki z płyty „Kind of Blue”. Czas płynie, tak jak zawsze: strumieniem; górą, dołem i między palcami, ale ja tkwię w miejscu i obserwuję bo na tym polega moja rola. Całe szczęście, że natura obdarzyła mnie inercją — więc gdy inni pędzą już naprzód ja nawet nie drgnąłem.

Pozostaje mi obserwować i dzielić się obserwacjami.

Widzę Scrawla, który jak zwykle pracuje nad shaderami. W zeszłym tygodniu wspomniałem, że używamy shaderów do renderowania terenu, a dziś mogę podać nową ciekawostkę: w ramach prac nad systemem shaderów powstała nowa implementacja terenu składająca się z o 3/4 mniejszej ilości linii kodu.

Ponadto wszystkie inne obszary, w których używamy shaderów siłą rzeczy również uległy zmianom. Cienie, woda — akurat tu już teraz mamy czym się pochwalić, i to nie tylko względem leciwego Morrowinda. W przyszłości zapewne uda się poprawić znacznie więcej.

Chris również zdziałał bardzo wiele w tym tygodniu. Na githubie znaleźć możecie świadectwo w postaci chociażby ilości commitów, ale co w istocie najważniejsze i nie oddawane przez gołe liczby to fakt, iż nowy system działa już w grze. Nie zrozumcie mnie źle — nie jest moim zamiarem tworzeniu fałszywego obrazu sytuacji: aktualnie brak jest integracji z fizyką, a oprócz tego wciąż obecne są drobne problemy które być może są banalnie proste w naprawie gdy już odkryje się ich przyczynę, ale jak pokazuje doświadczenie same znalezienie źródła takich, zdawać by się mogło, błahych kłopotów wymaga trudnej do przewidzenia ilości czasu.

Jednak przede wszystkim chciałbym podkreślić, że zdecydowana większość stworzeń (wliczając bestie spotykane w dodatku Bloodmoon), jak również npc (w tym postacie odziane w kłopotliwe od strony technicznej szaty) jest już animowana poprawnie.

Tym czasem Zini wprowadził do gry dwa efekty magiczne: Drain i Fortify, które zdolne są do modyfikowania statystyk postaci. Dodatkowo usunął też bug w kodzie automatycznie zakładającym zbroje i ubrania na postacie, jak również kilka innych błędów dotykających rozmaitych dziedzin silnika, uporządkował kwestię dynamicznie wyliczanych statystyk postaci i zmergował parę gałęzi.

Odkrywanie matematyki stosowanej przez Morrowinda postępuje dość dobrze. Dzięki Lazaroth przypuszczalnie wiemy już jak wyliczana jest siła efektu magicznego uzyskanego po zjedzeniu składnika, ale pewność uzyskamy dopiero gdy sprawdzimy jeszcze kilka kwestii. Wzory powiązane z akrobatyką są bardziej zagmatwane i wymagają więcej wysiłku, ale BrotherBrick użyczył nam swojego mocarnego serwera by zautomatyzować prace, a oddany sprawie Epsilon już zaciera ręce na myśl o wynikach które otrzyma.

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.

Hello,
Bugtracker has been moved from RootNode to OVH server last night and since then there is only one valid URL: http://bugs.openmw.org. Please don’t use http://bugs.openmw.org:81/ (URL with :81, port number, suffix), it won’t work any more.