Dziś wpadł mi w ręce PhysX Visual Debugger firmy NVidia. Aplikacja ta zdalnie debuguje scenę stworzoną przy użyciu silnika Physx. Wizualizuje ona zarówno aktorów (obiekty, z którymi liczone są kolizje) jak i wiele innych parametrów, w tym:

• bryły otaczające – bryły, z którymi przeprowadzane są uproszczone testy kolizji
• wektory prędkości
• stan obiektu – pokazuje, czy obiekt jest uśpiony, czy występuje kolizja z innym obiektem itd.
• itd.

Dodatkowo debugger pokazuje wszystkie parametry aktorów, dzięki czemu możemy w łatwy sposób wychwycić błąd.

Dzięki tej aplikacji udało mi się zauważyć błąd w tworzonej obecnie grze backgammon, którego nie dało się zauważyć inaczej, a który powodował dziwne zachowywanie się pionków.

Poniżej krótkie wideo z testowania gry z wykorzystaniem Physx Visual Debugger.

PhysX Remote Debugger dostępny jest do ściągnięcia na stronie: http://developer.nvidia.com/object/pvd_home.html

Share on Facebook

Share on Facebook

Po kilku miesiącach przerwy zasiadłem do pracy ponownie. Zacząłem bawić się silnikiem Physx firmy NVidia, aby gra była bardziej realna. Jak to bywa, co chwilę napotykam na problemy, z którymi męczę się przez kilka godzin, a rozwiązanie okazuje się banalne Poniżej 2 filmiki z etapów tworzenia gry To dopiero sam początek, więc za bardzo nie ma czym się zachwycać, ale pokazują one mniej więcej, jak będzie wyglądać gra.

Poniższe filmiki pokazują działanie silnika fizycznego do obsługi kostek. Na razie nie są brane pod uwagę kolizje z planszą, a jedynie pomiędzy kostkami. Kolejnym etapem są kolizje z planszą oraz z pionkami.

Etap 1

Etap 2

Nie wiem kiedy powstanie etap 3, ale mam nadzieję, że niedługo..

Share on Facebook

Projekt oparty został o bibliotekę QT w wersji 4.5. Komunikacja odbywa się za pomocą socketów TCP.

Architektura tego rozwiązania opiera się o 3 elementy:

• Klient – program, w którym operuje użytkownik chcący wygenerować obraz metoda ray tracing.
• Serwer zarządzający – który rozsyła części obrazu do generowania przez serwery robocze
• Serwery robocze – pracujące nad generowaniem poszczególnych części obrazu.

Jak to bywa w projektach studenckich, także i ten jest napisany obecnie dość chaotycznie i zawiera na pewno wiele błędów. Będą one jednak usuwane z biegiem czasu, a w chwili obecnej istotne jest raczej to, że projekt mniej więcej działa

Na początek jeden screen klienta:

Projekt został wrzucony na code.google.com i znajduje się pod adresem: http://code.google.com/p/distributedraytracing/.

Sama biblioteka ray tracera jest osobną dll’ką i jest nieco niedopracowana. Postaram się, bliżej wakacji, poprawić wszystkie błędy w niej zawarte i wprowadzić obsługę standardowych formatów scen (obecnie stosowany jest system niestandardowy, lecz dorzucone są przykładowe sceny).

Postaram się w przyszłości opisać niektóre fragmenty tego rozwiązania.

Share on Facebook

Khronos Group (twórca specyfikacji) chwali się tym, iż język ten ma zapewnić pełną niezależność języka od wykorzystanej technologii, a lista firm zaangażowanych w projekt, czyli: 3DLABS, Activision Blizzard, AMD, Apple, ARM, Barco, Broadcom, Codeplay, Electronic Arts, Ericsson, Freescale, HI, IBM, Intel, Imagination Technologies, Kestrel Institute, Motorola, Movidia, Nokia, NVIDIA, QNX, RapidMind, Samsung, Seaweed, Takumi, Texas Instruments i Umeå University uspokaja mnie, jeżeli chodzi o powodzenie tego projektu

Wcześniej zajmowałem się stricte technologią CUDA, ale z racji tego iż gdzieś na półce kurzy się moje PS3, to technologię tą zacznę wykorzystywać z jeszcze większą chęcią.

W najbliższym czasie postaram się opisać szerzej język OpenCL (jak tylko przeczytam specyfikację ), a także sprawdzę na ile język ten jest wygodny, elastyczny i.. czy działa.

A jeżeli zadziała, może być ciekawie

Share on Facebook

Dodawanie kolejnych par wektorów odbywa się na karcie graficznej. Odpowiada za to funkcja vecAdd z kwalifikatorem __global__.
Kwalifikator ten oznacza, że funkcja może być wykonywana zarówno jako host (CPU) jak i device (GPU).

Prosty kod odpowiadający za dodawanie 2 wektorów

#include <stdio.h>
#include <cutil.h>
__global__ void vecAdd (float3 a[10], float3 b[10]) {
int i = threadIdx.x;
a[i].x += b[i].x;
a[i].y += b[i].y;
a[i].z += b[i].z;
}

int main(int argc, char** argv) {

CUT_DEVICE_INIT(argc, argv); // inicjalizacja GPU

float3 *a_h, *b_h, *a_d, *b_d, *result;
int arraySize = 10;
int sizeInBytes = arraySize * sizeof(float3);
a_h = (float3*)malloc(sizeInBytes); // inicjalizacja tablic (na hoscie)
b_h = (float3*)malloc(sizeInBytes);
result = (float3*)malloc(sizeInBytes);

CUDA_SAFE_CALL(cudaMalloc((void**)&a_d, sizeInBytes)); // inicjalizacja tablic na GPU
CUDA_SAFE_CALL(cudaMalloc((void**)&b_d, sizeInBytes));

for(int i = 0; i < arraySize; i++) { // przykładowe dane
a_h[i].x = 100.0f + i;
a_h[i].y = 200.0f + i;
a_h[i].z = 300.0f + i;
b_h[i].x = 50.0f + i;
b_h[i].y = 50.0f + i;
b_h[i].z = 50.0f + i;
}

CUDA_SAFE_CALL(cudaMemcpy(a_d, a_h, sizeInBytes, cudaMemcpyHostToDevice));
// kopiujemy tablicę z hosta do GPU
CUDA_SAFE_CALL(cudaMemcpy(b_d, b_h, sizeInBytes, cudaMemcpyHostToDevice));

vecAdd<<<1, arraySize>>>(a_d, b_d); // wykonujemy dodawanie
CUDA_SAFE_CALL(cudaMemcpy(result, a_d, sizeInBytes, cudaMemcpyDeviceToHost));
// kopiujemy z powrotem

for(int i = 0; i < arraySize; i++){
printf("Wartość %d.elementu %f, %f, %f \n", i, result[i].x,
result[i].y, result[i].z); // wyswietlamy 
}

CUT_EXIT(0, NULL); // koniec
}

Wydaje się proste

W przyszłości postaram się opisać po kolei wszystkie szczegóły.

Share on Facebook