Netrix's devBlog

Tym razem będzie mały update dotyczący silnika. Niby nic, ale można się pochwalić.

Po pierwsze Environmental mapping, czyli proste przybliżenie zjawiska odbicia światła na powierzchni ciała oraz załamania światła na granicy dwóch ośrodków. Wymaga dostarczenia tylko dodatkowej tekstury sześciennej (cube-mapa) oraz skorzystania z dwóch dodatkowych funkcji HLSL: refract i reflect. Można go wzbogacić dodatkowo o efekt Fresnela i rozszczepienie chromatyczne. Całość wygląda jak na screenie obok. Efekt ten nie jest trudny do zaimplementowania, więc szczegółów implementacyjnych nie będzie, zresztą są one w książce CG Tutorial.

Kolejną rzeczą jest skybox. Jak nazwa wskazuje, jest to pudełko z tłem nieba, które powoduje, że scena z obiektami nie wygląda po prostu pusto. Poniżej przedstawiam trzy kroki rysowania skyboxa:

1. Potrzebne jest pudełko wraz z teksturą, którą jest już wspomniana wcześniej cube-mapa. Biblioteka D3DX posiada do tego odpowiednią funkcję: D3DXCreateBox(), która jako parametry przyjmuje wymiary pudełka. Najlepiej jest stworzyć sześcian 1:1:1.
2. Pudełko powinno obracać się razem z kamerą, ale nie może zmieniać swojej pozycji. Aby to osiągnąć należy użyć tylko macierzy widoku i projekcji. przy czym ostatni wiersz tej pierwszej powinien mieć takie wartości: (0, 0, 0, 1).
3. Skybox powinien być pierwszym elementem rysowanym na scenie, a dodatkowym warunkiem koniecznym by był on tłem całej sceny jest wyłączenie zapisu do ZBuffera. Dzięki temu każdy kolejny obiekt sceny będzie rysowany zawsze przed skyboxem. Aby odczytać kolor tekstury zamiast funkcji tex2D należy wykorzystać funkcję texCUBE, do której jako współrzędne tekstury przekazuje się pozycję danego pixela.

Jak widać nie jest to skomplikowane, a dzięki temu scena wygląda o wiele lepiej.

Tym razem postawiłem napisać o czymś, czym się aktualnie zajmuję na uczelni czyli programowaniem w Javie, a konkretniej programowanie interfejsu graficznego w Swingu. Java Swing jest w pełni obiektową (jak sam język) biblioteką graficzną służącą do majstrowania okienkowego GUI (podobnie jak QT, czy też Windows Forms). Korzystanie z tej biblioteki jest bardzo proste, niestety ma ona jedną podstawową wadę (oprócz bycia w Javie) – domyślnie okienko posiada własny style, więc nie wykorzystuje systemowego, dlatego może się wyróżniać.

Tworzenie okienek w Swingu jest bardzo proste, przykładowo wyświetlenie pustego okienka wygląda następująco:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import javax.swing.SwingUtilities;
import javax.swing.JFrame;
 
public class Okienko
{
   public static void main(String[] args)
   {
      SwingUtilities.invokeLater(new Runnable()
      {
         public void run()
         {
            JFrame f = new JFrame();
            f.setTitle("Hello World!");
            f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            f.setSize(290, 250);
            f.setVisible(true);
         }
      });
   }
}

Ten krótki kod tworzy prostą formatkę JFrame, a następnie ustawia jej tytuł, rozmiar, akcje zamnięcia i na końcu pokazuje okienko. Wszystko to jest wykonywane w funkcji run() anonimowej klasy wewnętrznej po interfejsie Runnable (swoją drogą najpiękniejszy mechanizm w Javie :)), która działa w osobnym wątku biblioteki Swing. Jak widać jest to bardzo proste.

Co jednak gdy chcemy stworzyć coś bardziej wyszukanego? Wtedy najlepiej rozszerzyć (odziedziczyć) klasę JFrame. Mając własną klasę o wiele łatwiej wszystkim zarządzać wszystkimi komponentami, które znajdują się na formatce. Poniższy kod tworzy formatkę i wyświetla na niej przycisk i pole tekstowe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import java.awt.FlowLayout;
import javax.swing.*;
 
public class Okienko extends JFrame
{
   private JButton bPisz = new JButton("Pisz");
   private JTextArea textArea = new JTextArea(10, 20);
 
   public Okienko()
   {
      setTitle("Hello World!");
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      setSize(290, 250);
 
      setLayout(new FlowLayout());
      add(new JScrollPane(textArea));
      add(bPisz);
   }
 
   public static void main(String[] args)
   {
      SwingUtilities.invokeLater(new Runnable()
      {
         public void run()
         {
            new Okienko().setVisible(true);
         }
      });
   }
}

Powyższy kod jest już troszkę dłuższy, a jego zadanie polega na wyświetleniu na formatce przycisku oraz pola tekstowego. Pojawiły się tutaj dodatkowe komponenty takie jak: JButton, JTextArea, JScrollPane oraz funkcja setLayout(). Dwa pierwsze są oczywiste, bo jest to wspomniany przycisk i pole tekstowe, natomiast JScrollPane jest dodatkowym komponentem dodającym do JTextArea paski przesuwania (to wszystko przez proste opakowanie go). Funkcja setLayout() ustawia sposób rozmieszczenia kontrolek. Domyślnym układem jest BorderLayout, który kontrolki układa jedna na drugiej, natomiast FlowLayout ustawia je w taki sposób aby wszystkie były widoczne (po szczegóły zapraszam do dokumentacji :)).

No cóż mamy przycisk, ale teraz co zrobić, aby po jego naciśnięciu coś się stało. Obsługa akcji na kontrolkach opiera się na zdarzeniach, czyli w przypadku naciśnięcia przycisku wywoływana jest odpowiednia funkcja, która to zdarzenie potrafi obsłużyć. W takim razie jak obsłużyć akcję wciśnięcia przycisku? W tym celu należy dodać do przycisku odbiorcę zdarzenia za pomocą funkcji addActionListener(). Funkcja ta przyjmuje referencję do interfejsu ActionListener, z którego należy zaimplementować funkcję actionPerformed(). Właśnie ta funkcja zostanie wywołana w momencie wystąpienia zdarzenia.

Wynikowy kod:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

import java.awt.FlowLayout;
import javax.swing.*;
import java.awt.event.*;
 
public class Okienko extends JFrame
{
   private JButton bPisz = new JButton("Pisz");
   private JTextArea textArea = new JTextArea(10, 20);
 
   public Okienko()
   {
      setTitle("Hello World!");
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      setSize(290, 250); 
 
      bPisz.addActionListener(new ActionListener()
      {
         public void actionPerformed(ActionEvent e)
         {
            textArea.append("Hello World ");
         }
      });
 
      setLayout(new FlowLayout());
      add(new JScrollPane(textArea));
      add(bPisz);
   }
 
   public static void main(String[] args)
   {
      SwingUtilities.invokeLater(new Runnable()
      {
         public void run()
         {
            new Okienko().setVisible(true);
         }
      });
   }
}

Już trochę czasu temu postanowiłem napisać konwerter wspomnianego formatu .sdkmesh do .x i w końcu dopiąłem swego. Mimo tego, że jak już wcześniej wspomniałem, format ten nie nadaje się do modeli animowanych (posiada informacje o animacji, ale nie ma informacji o kościach), można ostatecznie wyciągnąć z niego model statyczny.

To właśnie robi poniższa aplikacja. Wystarczy tylko przeciągnąć plik .sdkmesh na plik aplikacji i w katalogu mesha źródłowego pojawia się wygenerowany plik w formacie .x.

Pobierz

Stwierdziłem, że wypadałoby się wreszcie odezwać po kolejnej długiej nieobecności. W końcu udało mi się zaimplementować Skinning w silniku, oczywiście bazując na przykładzie SkinnedMesh z DX SDK. W praktyce zrobiłem  to co było w ów sample’u, a jedyną różnicą jest miejsce położenia kości, które u mnie znajdują się w hierarchii zaraz za modelem. Samą hierarchię tworzą modele (zwykłe drzewo, które ustanawia hierarchię na podstawie której tworzone są wynikowe macierze świata dla tych modeli). Póki co mam tylko dwa rodzaje modeli: StaticMesh i SkinnedMesh, ale bez problemu można do niej wstawić innego rodzaju obiekty, które występują na scenie.

Kolejną sprawą są stosowane przeze mnie formaty. Otóż w poprzedniej notce napisałem jakoby format .x był bardzo prostym formatem. Nic bardziej mylnego, jest on bardziej złożony niż myślałem (chodzi mi tylko o format modeli, nie o system zapisu danych). W standardowym pliku .x może znajdować się więcej modeli, które są ułożone w hierarchię, a do ich załadowania służy funkcja:

D3DXLoadMeshHierarchyFromX(…);

Funkcja ta ładuje nie tyko wspomnianą hierarchię meshy, ale również informacje o kościach i  animacji. Niestety format materiałów dalej nie zawiera nic więcej poza strukturą D3DMATERIAL9 i nazwą tekstury diffuse.

Natomiast format SDKMesh jest jeszcze gorszy (mimo jednej zalety, że posiada nazwy dla tekstur normal i specular), ponieważ nie posiada on żadnych informacji o kościach mimo, że są informacje o animacji. Po prostu wczytywany mesh jest już przekonwertowany i gotowy do wyświetlenia (co blokuje możliwość prostego użycia ID3DXSkinInfo, którym mógłbym software’owo przekształcić model np. do kolizji per vertex).

Pisząc różne efekty graficzne, w pewnym momencie możemy stwierdzić, że potrzebujemy jakiegoś innego modelu. Wtedy nasuwa się również pytanie „skąd wziąć taki model?”. Tutaj przychodzi z pomocą DirectX SDK, które posiada dużą ilość różnych modeli w formacie .x oraz .sdkmesh. Z formatem .x można sobie poradzić funkcją

D3DXLoadMeshFormX

Funkcja ta wczytuje i parsuje model, zwracając wskaźnik, z którego można już korzystać.

Niestety format .x jest bardzo prosty, ponieważ zawiera on tylko jeden zestaw materiałów i teksturę diffuse na subset. Problem ten rozwiązano tworząc nowy format z rozszerzeniem .sdkmesh. Powstał on i jest wykorzystywany na potrzeby przykładów Direct3D 10. Pliki tego formatu mogą zawierać kilka modeli, podzielonych na kilka subsetów. Materiały zostały rozszerzone o tekstury normal i specular. Dodane zostały również informacje o klatkach animacji, natomiast szczegóły danej klatki zawiera osobny plik z rozszerzeniem .sdkmesh_anim. Więcej szczegółów dotyczących tego formatu znajduje się w dokumentacji pod hasłem „Overview of the SDK Mesh File Format”.

Postanowiłem się zainteresować tym formatem nie tylko z powodu tego, że część modeli jest w nim zapisana, ale potrzebowałem modeli, które mógłbym wykorzystać do mojej zabawy z animacją opartą na klatkach kluczowych. Właśnie z tego powodu napisałem aplikację, którą tu zamieszczam. SDKMeshInfo jest programem do podglądu bebechów plików .sdkmesh. Nie posiada on opcji ich wyświetlania, ale pokazuje pełne dane z nagłówków zawartych we wskazanym pliku.

Download

Postanowiłem wreszcie zająć się wyświetlaniem grafiki opartej na shaderach. Stworzyłem sobie prosty framework oparty na moim „silniku”, który jest aktualnie tylko szkieletem aplikacji. Framework składa się z kilku klas, których zadaniem jest uprościć wykonywanie różnych rzeczy. Aktualnie w zestawie jest kamerka FPP, prosty system cząsteczek oraz klasy do wczytywania modeli i zarządzania efektami.

Na dole tej notki znajduje się link do aplikacji, która reprezentuje aktualny stan kodu. Aplikacja wyświetla 4 modele wczytane z plików w formacie .x, 1 model z formatu .sdkmesh oraz cząsteczki, których pozycja obliczana jest w shaderze. Światło użyte w scenie jest punktowe, a obliczenia są wykonywane w pixel shaderze. Materiały modeli pochodzą z ich plików, dlatego nie wszystko wygląda super ;).

Kamerkę obsługuje się za pomocą myszy i klawiszy WSAD, a światło za pomocą strzałek oraz klawiszy PG_UP i PG_DN.

Pobierz

Tym razem chciałbym przedstawić mój nowy program. NViDo jest to aplikacja do pobierania filmów z serwisów takich jak Youtube. Zaletą programu jest prostota obsługi, która może sprowadzić się do skopiowania linku do schowka i wciśnięciu skrótu klawiszowego „SHIFT + ALT + D”. Innymi funkcjami aplikacji są:

• odtworzenie filmu zaraz po ściągnięciu
• tworzenie historii pobranych plików wideo (z której można bezpośrednio odpalić dany plik)
• pobieranie również wersji HD jeżeli istnieje w serwisie

Aktualnie ilość serwisów, które NViDo obsługuje nie jest szałowa, ponieważ są to tylko (już wspomniany) Youtube i Vimeo (w przyszłości pewnie dodam więcej). Aplikacja jest w miarę odbugowana, jeśli wystąpią jakieś błędy to postaram się naprawić (choć nie obiecuję).

Pobierz

W tym miejscu chciałbym zareklamować również inną aplikację tego typu, a mianowicie jDownloader. Ten program, oprócz tego, że automatycznie pobiera pliki z takich serwisów jak rapidshare, potrafi ściągać filmy z większości znanych serwisów podobnych do Youtube.

Podczas dalszego kodowania mojego silnika natrafiłem na bardzo dziwny błąd kompilatora Visual Studio. Zaczynając od początku – mam oto taki kod:

enum
{
	// Rozmiary pól
	MAX_BITS_INDEX = sizeof(Size_t) * 4,
	MAX_BITS_MAGIC = sizeof(Size_t) * 4,
	// Maksymalne wartości pól (Przesunięcie 1 w dwóch operacjach, ponieważ inaczej kompilator nie daje rady)
	MAX_INDEX = ((1 << MAX_BITS_INDEX / 2) << MAX_BITS_INDEX / 2) - 1,
	MAX_MAGIC = ((1 << MAX_BITS_MAGIC / 2) << MAX_BITS_MAGIC / 2) - 1
};
/* ... */
 
// handle = 0x0000000400000006;   - przykladowo
// Size_t ma rozmiar wskaźnika (jest zależny od platformy)
Size_t value = handle & MAX_MAGIC;

Otóż problem z tym kodem jest taki, że gdy zostanie skompilowany na platformę x64, zostaje wygenerowany następujący kod w assemblerze:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
 
000000013FC96F94  mov         rax,qword ptr [handle]
000000013FC96F9C  mov         qword ptr [value],rax
 
    81:                         if(value == *it) return true; // Dalszy kod

Jak widać problem polega na braku kluczowej instrukcji and, której zadaniem jest odcięcie najstarszych 32-bitów. Dla porównania kod assemblera wygenerowanego dla platformy x86 jest następujący:

    79:                 {
    80:                         Size_t value = handle & MAX_MAGIC;
00DC9DDC  mov         eax,dword ptr [handle]
00DC9DDF  and          eax,0FFFFh
00DC9DE4  mov         dword ptr [value],eax
    81:                         if(value == *it) return true; // Dalszy kod

Tutaj instrukcja ta występuje.

Błąd ten jednak nie występuje gdy samemu sprecyzuję stałą, tj.:

Size_t value = handle & 0xffffffff;

W tym przypadku zostanie wygenerowany poprawny kod.

Wniosek jest taki, że kompilator widząc operację and zmiennej ze stałą typu enum (który przechowuje wartości 32-bitowe), traktuje tą zmienną jako typ 32-bitowy. W tym przypadku stwierdza, że instrukcja and nie ma sensu, bo wartość MAX_MAGIC zawiera maksymalną wartość (0xffffffff). Według mnie jest to ewidentny błąd i nie powinno takie coś wystąpić.

// Edit :)
Problemem oczywiście jest to, że enum jest tak naprawdę typem int, więc się dokładnie tak zachowuje.

Postanowiłem przekompilować aktualnie pisany framework pod platformę x64. Jest to już trochę napisanego kodu, więc objawiło się to trzema problemami, z których najważniejszym jest ten komunikat:

LNK1112: module machine type 'X86' conflicts with target machine type x64''

Zostaje on wyrzucony wtedy, gdy podczas składania programu x64 Linker napotka bibliotekę skompilowaną pod target x86.

Przyczyną tego konfliktu są błędne wpisy ścieżek do bibliotek statycznych, które znajdują się w opcjach Visual Studio. Niestety wpisy dla platformy x64 są po prostu kopiowane z platformy Win32 (nie wszystkie, bo jest ich mniej). Należy je poprawić tak aby wskazywały na foldery z bibliotekami x64. Obok jest obrazek z poprawnymi ustawieniami mojego Visual Studio.

Drugim, ale już mniej znaczącym problemem jest ostrzeżenie

conversion from 'size_type' to 'int', possible loss of data

powodowane rozrzeszeniem rozmiaru typu ‘size_type’ z 4 do 8. Typ ten jest zwracany przez funkcje size() w kontenerach biblioteki standardowe. W tym przypadku rozwiązaniem jest po prostu zamiana powszechnie używanego (unsigned) int na size_type bądź własny odpowiednik zdefiniowany w klauzulach #ifdef/#endif :).

Ostatnim problemem jest brak inline’owych wstawek assemblerowych. W moim przypadku za ten błąd odpowiadało makro NAssert, w środku którego jest wykorzystana konstrukcja:

__asm 
{
   int 3 
}

Powoduje ona wywołanie Breakpointa w miejscu asercji. Okazuje się, że rozwiązanie tego jest bardzo proste, ponieważ Visual Studio posiada następującą funkcję typu intrinsic:

__debugbreak()

Powoduje ona dokładnie tę samą akcję co podana wyżej wstawka w assemblerze.

A poniżej wynik całego procesu przenoszenia :).

Dzisiaj postanowiłem spróbować skompilować coś pod platformę 64-bitową. Jako że dysponuję teraz już odpowiednim sprzętem, systemem, więc nic nie stało na przeszkodzie aby to uczynić. Ze znalezionych w internecie informacji dowiedziałem się tyle, że wystarczy przestawić docelową platformę z Win32 na x64 i już można przystąpić do próby kompilacji.

Niestety tu pojawił się problem, ponieważ jedynymi dostępnym platformami oprócz Win32 są platformy ARM. Po kolejnym skorzystaniu z wyszukiwarki Google dowiedziałem się, że winę za to ponosi nieodpowiednia kolejność instalacji Windows SDK 7, Visual Studio oraz braku odpowiedniego dla niego Service Packa. Poprawna kolejność instalacji jest następująca:

1. Visual Studio 2008
2. Service Pack 1 dla Visual Studio 2008
3. Windows SDK 7

Oczywiście nie miałem ochoty robić reinstalacji VS i WSDK, dlatego poszukałem innego rozwiązania. Oto ono:

1. Deinstalacja „Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x64″ oraz „Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x86″
2. Naprawa instalacji Visual Studio (Przez funkcję Repair)
3. Instalacja Service Packa

Należy zaznaczyć, że użycie funkcji Repair na instalacji WSDK7 usunie tę poprawkę.

Tutaj znajduje się oryginalna stronka z opisem naprawy.