Fork me on GitLab

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.

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.

Wakacje 2012-07-16 - sir_herrbatka

Szybkość z jaką rozwija się projekt zmalała ostatnio znacznie. Wyjaśnienie jest proste.

Wakacje. A jak nie wakacje to zapalenie opon mózgowych.

Smutek, melancholia, i ociężałość — wielka, rozmiarów góry; głęboka jak oceany; mdła jak brazylijska telenowela. Chciałbym, bardzo bym chciał, wstawić w tym miejscu fragment z „Króla Lwa” w którym ginie Mufasa, ale drżę na myśl o fali samobójstw przetaczającej się przez kraj; o śledztwie prowadzącego jak po sznurku do niezwykle podejrzanej koherencja historii odwiedzanych stron z komputerów należących do denatów…

Nie będzie Mufasy.

Zamiast tego postaram się opisać tą garść istotnych informacji, a wy będziecie podziwiać moje poświęcenie; kreatywność; pomysłowość oraz sławić me imię.

Jeśli jeszcze tego nie wiecie to teraz się dowiecie: OpenMW jest dużo nowocześniejszym silnikiem niż ten stworzony przez Bethesdę na potrzeby Morrowinda. Nie jest to, a przynajmniej nie powinno być dla was zaskakujące jeśli tylko zważycie na to, że Morrowind ma już ponad dziesięć lat (dekadę!), a na dodatek był rozwijany jeszcze w epoce linii windows 95/98. Znaczenie słowa „nowoczesność” w kontekście silnika gry komputerowej można zamknąć w „wykorzystywaniu nowoczesnych technik”.

Takich jak shadery.

Scrawl wciąż pracuje nad systemem shaderów. Znaczenie tej pracy jest trudne do przecenienia. Przykładowo OpenMW wykorzystuje shadery na użytek wyświetlania terenu. Przynajmniej teoretycznie jest to podejście nieskończenie bardziej efektywne niż wykorzystywane przez morrowinda, umożliwia większą wydajność i lepsze wykorzystanie podzespołów komputera, a przecież to jedynie początek, ledwie demonstracja — same fundamenty możliwości jakie otworzą się po ukończeniu OpenMW 1.0.0.

Chris usprawnia obsługę formatu nif. Sprawa bezwzględnie kluczowa i wstęp przed intensyfikacją prac nad animacjami, a także prawdopodobnie wszystkich innych funkcji które w jakiś sposób odnoszą się do węzłów nif.

Zini utworzył nową gałąź o nazwie „Potions” wskazującej na przeznaczenie do pracy nad używaniem napojów magicznych. Bardzo niewielki, ale wciąż istotny fragment rozgrywki znanej z morrowinda i powinniśmy zacząć się przyzwyczajać, że to właśnie takie funkcje i wysiłki takie jak ten stanowią trzon projektu.

Co prawda zjadanie składników alchemicznych było planowane, ale z racji na drobne zderzenie z naszymi brakami w wiedzy na temat wzorów matematycznych, wedle których morrowind ustala siłę i czas trwania efektu, chleb może czuć się bezpiecznie jeszcze dość długo.

Koniec czerwca… 2012-07-10 - sir_herrbatka

Witajcie wszyscy,

Okropnie zaniedbałem pisanie postów w języku ojca i dziada mojego, wierzę jednak wiarą silną i mocną, graniczącą z obłędem na rzece naiwności, że w sercach waszych kryje się dość miłosierdzia i litości by przebaczyć ten jeszcze jeden raz.

Zgodnie z utrwalonym w tradycji cyklem prac nad OpenMW jak zwykle, po miesiącu wydajemy nową wersję programu. Tym razem nosi numer 0.16.0. W związku z tym już wkrótce internet zaleją posty niespełnionych bloggerów takich jak ja, a kultowy WeirdSexy przygotował już kolejny kultowy odcinek z kultowej serii filmików w których prezentuje nowości obecne w nowym wydaniu i okrasza je swoim komentarzem wyartykułowanym dźwięcznym głosem profesjonalnego spikera radiowego. Dotychczasowe prezentacje cieszyły się zaskakująco dużą oglądalnością i wydaje się, że rozpropagowały wiedzę o OpenMW wśród internautów skuteczniej nawet niż wszystkie artykuły razem wzięte.

Web 2.0, ot co.

Jeśli chodzi o aktualne wydarzenia nie związane z popychaniem numerków do przodu to muszę (tak! MUSZĘ!) wspomnieć o użytkowniku Myckel. Otóż dotarliśmy do punktu którego miało nie być. Zatrzymał nas brak znajomości morrowindowej matematyki, nie wiemy jak dokładnie obliczyć wiele parametrów używanych przez morrowinda. Odkrywanie formuł nie wymaga umiejętności programistycznych, ani znajomości C++ (wystarczy długopis, cierpliwość oraz wolny czas), a mimo to dotychczas nie było wielu osób które zdecydowały się tym zająć. Prawdę powiedziawszy to przytłaczająca większość zawartości naszej wiki w zakresie wzorów została dodana przez jednego tylko użytkownika. Oczywiście odwalił on niesamowicie wielki i potrzebny kawał roboty ale jednak nie całość.

Gdy więc dotarliśmy do punktu gdy nastała pora na jedynie doszlifowanie naszej alchemii okazało się, że Zini nie może wykonać choćby jednego kroku naprzód. Z pomocą przyszedł właśnie Myckel który dzielnie pomagał: notował sukcesy i porażki przy określonych wartościach parametrów, wyszukiwał znaczenie pewnych wartości zaszytych w bebechach esm.

Krótko mówiąc Myckel zawstydził nas, nie-programistów. A mnie chyba w szczególności.

Ponieważ Zini nie może posunąć się naprzód z Alchemią w międzyczasie rozpoczął kolejną rundę refaktoryzacji, tym razem w MW-subsystem. Wszystkie informacje które mogą być istotne z punktu widzenia dewelopera można znaleźć w tym wątku na forum.

Niestety prace na nowym systemem animacji opartym na tym co oferuje biblioteka OGRE3D, zamiast na rozwiązaniach manualnych znowu stanęły w miejscu. Miejmy nadzieję, że nie na długo.

Od kiedy pvdk jest znowu obecny w sieci ponownie możemy pochwalić się zmianami w launcherze. Dodane zostały nowe opcje konfiguracyjne, a dzięki nowym grafikom program olśniewa jeszcze bardziej serca i dusze estetów, swym nieśmiertelnym blaskiem piękna… No dobrze, autorem nowych, lepszych grafik jest serpentine.

Scrawl tym razem skupił się na paru błędach. Przykładowo w 0.16.0 jeszcze będzie obecna brzydka regresja dopadająca użytkowników którzy używają DX (wine lub windows) przy renderowaniu: wszystkie tekstury są czarne. Co prawda rozwiązanie jest gotowe, ale gotowe zbyt późno by trafić do tego wydania…

Eli2 który poprzednio zyskał sławę swoimi zabawami z goglami 3D i OpenMW tym razem eksperymentuje z edytorem OpenMW. Długo oczekiwanym edytorem, jeśli pozwolicie, że to podkreślę… Wspaniale byłoby mieć w końcu edytor, a przynajmniej jego zaczątek przed OpenMW 1.0.0.

Wyślij się, proszę. 2012-07-08 - sir_herrbatka

Jak pewnie (mam cichą, nieśmiałą i taką śmietankową nadzieję, że ktoś to właściwie czyta) część z was zauważyła, że strona openmw.org była niedostępna. Wynikała to z nagłego, gwałtownego i skokowego wzrostu ilości odsłon strony po tym, gdy na slashdot.org pojawił się news z linkiem.

Czytelnicy klikali link, przechodzili na naszą stronę, a ponieważ były ich istne hordy wkrótce jedyne co mógł zrobić admin zalogowany na serwer to bezradne obserwować z sercem zdjętym trwogą sforkowane procesy apache.

Po chwili strona była całkowicie zablokowana skuteczniej niż w następstwie ataku anonimowych, ale mimo tej niedogodności zespół programistów kontynuował prace po staremu.

Zini w ramach oczyszczania kodu niespodziewanie odkrył, że w źródłach OpenMW znajduje się wiele niepotrzebnych include co niestety przekłada się na czas kompilacji aplikacji. Wielu spośród użytkowników marudzi, że zbudowanie OpenMW zajmuje wieczność i choć są to w większości posiadacze tych mniej potężnych procesorów (oraz być może zbyt skromnych pokładów cierpliwości) to nie ma sensu ukrywać, że przyśpieszenie kompilacji nie powinno nikomu zaszkodzić.

Usunięcie zbędnych include ograniczyło czas potrzebny do skompilowania OpenMW o blisko połowę.

Następnie Zini przystąpił do pracy nad właściwą implementacją rozwoju umiejętność. Co prawda jak na razie zestaw umiejętności które można zobaczyć w grze zawiera jedynie Alchemię (a i ta zdolność nie jest ukończona) ale wkrótce ulegnie to zmianie. Nastała pora przygotowań dla nadchodzących funkcji.

Scrawl majstruje przy shaderach, i co ciekawe odkrył iż użycie GLSL do pisania shaderów skraca czas kompilacji dwadzieścia jeden razy. Ponieważ asortyment shaderów OpenMW można określić co najwyżej jako „skromny” przełożenie na całkowity czas kompilacji jest znikome, ale sądzę, że mogło to was zaciekawić.

jhooks1 wciąż szarpie się z animacjami, a równolegle Chris poznaje szczegóły nifload by móc dołączyć rozwoju.

Rozszyfrowanie formuł z morrowind nareszcie nabrało rozpędu i posuwa się do przodu tak, jak powinno było od samego początku. Myckel dzielnie pracuje nad alchemią, do roboty zabrali się także nowi koledzy z forum i zapewniam was, że ten wysiłek nie pójdzie na marne.