Autor Wątek: JOGL - własna biblioteka macierzowa  (Przeczytany 1406 razy)

Offline seti

  • Użytkownik

# Czerwiec 12, 2011, 23:25:13
Witam wszystkich,

Jakiś czas temu rozpocząłem naukę OpenGL'a w w wersji 3.3 wykorzystując Jave, czyli tak właściwie uczę się JOGL'a. Z samym rozumieniem zagadnień czysto OpenGL'owych jak narazie nie mam problemu.  Chciałbym podejść do próby napisania własnej małej biblioteczki w której znajdowałyby się klasy wektorów, macierzy, operacji na nich itd itp...

W JOGL'u wiele funkcji przyjmuje jako parametr wejściowy bufory: FloatBuffer, DoubleBuffer ...
Mój problem polega na tym że nie wiem w jaki sposób zaprojektować zwykłą macierz, by jednocześnie była ona wygodna w użyciu oraz można było ją przekazać do funkcji przyjmujących powyższe bufory.
Jak narazie do głowy przychodzą mi takie rozwiązania:

1. Macierz to klasa opakowująca zwykłą tablice i to na niej wykonywane są wszystkie operacje. Dodatkowo posiada metodę która konwertuje powyższą tablice na odpowiednik buforowy.

2. Drugi sposób polega na utworzeniu klasy macierzy opakowującej FloatBuffer i od razu na nim wykonywaniu wszystkich potrzebnych operacji, oraz nie potrzebna dodatkowa konwersja.

Zastanawiam się który sposób jest wydajniejszy ?
Czy ktoś ma jakieś doświadczenie w tym temacie i mógłby mi coś poradzić ?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline vashpan

  • Użytkownik
    • Strona

# Czerwiec 12, 2011, 23:44:13
Tu nie trzeba miec doswiadczenia akurat w tym temacie zeby stwierdzic ze drugi bedzie wydajniejszy :)

Offline ArekBal

  • Użytkownik

# Czerwiec 13, 2011, 03:36:41
Doczyatj o co chodzi z tym FloatBufferem. Bo może akurat pierwsza opcja będzie szybsza.
W końcu do ogla tych macierzy tak dużo to wysyłać nie bedziesz, więcej będziesz liczył na procku, więc chcesz by te operacje na procesorze były możliwie jak najbardziej zoptymalizowane. A z buforami jak to z buforami... czasami trzeba otworzyć, zamknąc, przekazać, odczekać. Dlatego lepiej doczytaj jak to tam jest. W c++ to(przekopiowanie tej pamieci i ta tzw. konwersja) jest akurat dużo prostsze. :)

Offline owyn

  • Użytkownik

# Czerwiec 13, 2011, 10:12:58
W lwjgl jest już taka biblioteka. Wykorzystuje ona pierwszy sposób, z tym że przechowuje pola macierzy w normalnych zmiennych (m00, m01 itd.) w kolejności używanej przez OpenGL (kolumnami), a nie w tablicach. Zastanów się, czy warto wynajdywać koło drugi raz - chyba że robisz to dla ćwiczeń.
« Ostatnia zmiana: Czerwiec 13, 2011, 12:33:16 wysłana przez owyn »

Offline vashpan

  • Użytkownik
    • Strona

# Czerwiec 13, 2011, 11:54:00
FloatBuffer to po prostu wrapper na zwykla tablice floatow w sensie C, czyli ciag bajtow reprezentujacy n-floatow. Podobnie jak te inne *Buffer'y

Byc moze konwersje sa jakos zoptymalizowane, ale ja jakos specjalnie nie widze miejsca na takie sztuczki w Javie, operowanie na tym buforze nie powinno byc jakos specjalnie ciezkie.

EDIT: z drugiej strony patrze na dokumentacje owego FloatBuffer'a i wide tam taka metode jak "wrap", ktora opakowuje jakas tablice w ow bufor, zachowujac jej dane, bez alokacji i jej kopiowania. Byc moze to jest najwygodniejsze i dosc optymalne rozwiazanie - aczkolwiek kazde wywolanie metody "wrap" alokuje pamiec na sam obiekt bufora - ale w Javie chyba nie da sie uniknac takich rzeczy... W kazdym razie same dane macierzy nie beda musialy byc alokowane przy kazdym wywolaniu fukncji z GL...
« Ostatnia zmiana: Czerwiec 13, 2011, 12:01:15 wysłana przez vashpan »

Offline owyn

  • Użytkownik

# Czerwiec 13, 2011, 12:44:14
FloatBuffer to po prostu wrapper na zwykla tablice floatow w sensie C, czyli ciag bajtow reprezentujacy n-floatow. Podobnie jak te inne *Buffer'y

No, nie do końca. Nie jestem pewien czy tak jest w JOGL, ale LWJGL tworzy zwykły ByteBuffer z ustawionym natywnym 'orderem' bajtów, a następnie opakowuje to we FloatBuffer. Z tego co czytałem, takie coś zapewnia szybkie przekazywanie danych do C++ przez JNI.

// EDIT: Teraz, kiedy przeczytałem to jeszcze raz, chyba napisałem to samo co vashpan - sorry, chyba wcześniej źle to zrozumiałem.
« Ostatnia zmiana: Czerwiec 13, 2011, 13:04:52 wysłana przez owyn »