Autor Wątek: OpenGL - książka, potok, nauka.  (Przeczytany 2447 razy)

Offline bedekiedysoga...

  • Użytkownik

# Luty 05, 2016, 00:32:05
Cześć wszystkim. Chciałbym zająć się trochę poważniej programowaniem grafiki. I mam do was kilka pytań. Ogólnie programuje od 5-6 lat, rok zawodowo (głównie python i technologie webowe), pisałem też jakieś proste platformówki, węże, tetrisy w SFML/Allegro - C++, proste silniczki fizyczne (grawitacja, kolizje, Newton :>) Więc jakieś minimalne pojęcie o mechanice gier mam. Chciałbym teraz zaznajomić się ogólnie z programowaniem grafiki. Poznać te smaczki i może napisać jakąś gierkę w oparciu oto. Ale w głównej mierze, chodzi mi o samo programowanie grafiki. W niedalekim czasie będę potrzebował napisać kilka efektów/gadżetów 3d, więc najlepsza pora żeby zacząć coś w tym kierunku robić.

Dobra, koniec przynudzania. Przejdę do konkretów.
Szukając materiałów o OpenGL, trochę mnie to wszystko przytłoczyło. I nie wiem już od czego mam zacząć.
1) Od której wersji zacząć?
2) Programowalny potok, to jest to co teraz jest na topie? Mam rozumieć, że teraz samemu 'programuje się potok' a wcześniej dostępne były gotowe funkcję, które robiły wiele rzeczy za nas?
3) Szukam jakiejś książki, która opiszę zarówno OpenGL'a jak i teoretyczne podstawy w stylu co po czym, jak i dlaczego. Objaśni dobrze różne zagadnienia. Może być w języku angielskim, jednak nie ukrywam, że lepiej czuję się w j.polskim. :) Ta księga eksperta do OpenGL jest coś warta?

Pozdrawiam.

Offline Mr. Spam

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

Offline hashedone

  • Użytkownik

# Luty 05, 2016, 11:33:31
1) OGL3+, profil core. Nie ma znaczenia czy 3.0, 3.3, czy 4.1 - generalnie tam są dodawane nowe rzeczy, ale nie trafisz na nic, co jest złe, najwyżej będzie Ci czegoś brakować (a wtedy minimalnym kosztem przejdziesz na wyższą wersję).
2) I tak i nie. Sam potok wygląda zawsze z grubsza tak samo - najpierw przekształcenia wierzchołków, później interpolacja i rasteryzacja, później przekształcenia fragmentów, później wyświetlenie tego (to jest w bardzo dużym skrócie). Do tego jest jeszcze dodaktowe opcjonalne kroki - np. przekształcenia geometrii, teselacja, poza tym wyjście z przekształcenia wierzchołków/fragmentów, może iść w różne miejsca (tzn. przekształcone wierzchołki mogą iść gdzieś indziej niż rasteryzer, a przekształcone fragmenty nie muszą iść do tylnego bufora ekranu). Różnica między kiedyś a dzisiaj była taka, że kiedyś, to co się działo na przykład w przekształcaniu wierzchołków, było ściśle zdefiniowane i nie dało się tego zmienić - dzisiaj się da. Dawniej można było po prostu przesłać do GPU jakieś parametry na podstawie których on przeprowadzi obliczenia, dzisiaj, można napisać mu program który on uruchomi żeby te obliczenia przeprowadzić. Niewątpliwie powoduje to większy koszt wejścia, ale tak na prawdę jest dzięki temu łatwiej i można więcej.

Na ostatnie pytanie nie odpowiem, bo nie znam takiej książki (nigdy nie szukałem, więc nie sugeruję, że takiej nie ma). Bardzo fajnie oceniam jednak materiały ze strony Janusza Ganczarskiego - przynajmniej na początek, dobrze mi się z nich uczyło.

Offline Mergul

  • Użytkownik

# Luty 05, 2016, 16:00:44
Właściwie, różnice między OpenGL2 a OpenGL3-4 to głównie różnice w wydajności. Czyli np. w OpenGL2 miałeś GL_MODELVIEW_MATRIX, ustawiałeś ją sobie w kodzie odpowiednimi funkcjami, a następnie OpenGL "sam" wysyłał Ci tą macierz na kartę i mogłeś na niej operować w shader-ach, chociaż też dało się i bez shader-ów, co było może prostsze do ogarnięcia dla początkujących programistów. W OpenGL3 sam wysyłasz sobie taką macierz do shader-a. Doszło wiele buforów. Wszystko głównie po to by całość działała szybciej. OpenGL2 mocno ograniczał, tym że większość rzeczy robił za nas, przez co po prostu był wolny. Ale i w OpenGL2 dało się pisać programy cieniujące i całkowicie zmieniać to co działo się z wierzchołkami i fragmentami. W zasadzie główną i największą zaletą OGL3 jest to, że jest po prostu szybszy, przy czym również i trudniejszy do nauczenia się ;) Jeżeli dasz radę to najlepiej zaczynać od OGL3+ :)

Offline hashedone

  • Użytkownik

# Luty 05, 2016, 18:47:27
Przy czym również i trudniejszy do nauczenia się ;)
Zgadzam się z tym, że koszt wejścia jest nieco wyższy przy OGL3, ale tylko pierwszych programów w stylu "Hello World" - pierwsze 2, 3 dni nauki są prostsze. Fakt, OGL3 od samego początku wymaga napisania podstawowych shaderów. Fakt, niemal od początku trzeba zrozumieć czym jest macierz i jak działają przekształcenia w matematyce (ale potrzebna wiedza jest bardzo podstawowa - są bardzo dobre biblioteki które wykonują te przekształcenia za programistę, trzeba tylko wiedzieć o co chodzi z tym mnożeniem macierzy i wektorów). Natomiast na tym ułatwienia w OGL2 się kończą. Kiedy tylko chce się zaimplementować normal mapping, texture splatting, że nie wspomnę o ciutkę tylko bardziej skomplikowanych rzeczach jak cienie, okaże się, że OGL2 wymaga bardzo dużo pracy i nauki - nie tylko trzeba się nauczyć jak to powinno działać, ale jeszcze jak trzeba oszukać GPU żeby zrobiło to tak jak my chcemy (a nie tak, jak chce "wbudowany shader"). Kwestia buforów - argument totalnie nie trafiony, w OGL2 używało się dokładnie tak samo buforów, tyle że jako rozszerzenie ARB (używanie trybu bezpośredniego "wyszło z mody" długo długo przed pojawieniem się OGL3 - jest to po prostu skrajnie niewydajna metoda, ponad to nie do wykorzystania w normalnych aplikacjach ze względu na swoją składnię). Jestem w każdym razie na 100% pewien, że przeciętny programista dużo więcej zrobi po miesiącu nauki OGL3, niż po miesiącu nauki OGL2. Zupełnie pomijam fakt, że większość API OGL2 jest deprecated (w tym tryb bezpośredni), więc nauka go jest całkiem bez sensu.

Offline Mergul

  • Użytkownik

# Luty 05, 2016, 20:29:09
Masz błędne dane ;) Po pierwsze primo w OpenGL2 można używać shader-ów tak samo jak w OpenGL3, po drugie primo z mojego doświadczenia (ponieważ tłumaczyłem OGL nie jednej osobie) wychodzi, że większość ma problemy z OGL3, nie ze względu na to ze jest tyle trudniejszy od OGL2, co z tym jak wiele trzeba zrobić, w porównaniu do OGL2 żeby w ogóle cokolwiek wyświetlić na ekranie, a większość zniechęca się właśnie tym, że na początku nic im nie działa ;)

Chociaż fakt, że lepiej uczyć się OGL3-4, bo 2 po prostu się nie opłaca już

Offline DanielMz25

  • Użytkownik

# Luty 06, 2016, 11:47:19
Haha. Z tego co zrozumiałem. To zgadzacie się ze sobą, tylko nadajecie na różnych falach :D Koszt wejścia z tego co zrozumiałem to jest nakład pracy potrzebny do nauczenia się technologii, ale gdyby nie drugi post, to pomyślałbym że sugerujesz, iż OpenGl3 działa wolniej niż 2 ale ma większe możliwości, podejrzewam że to z tego powowdu to nieporozumienie. Koszt wejścia kojarzy mi się bardziej z kosztem wysłania instrukcji do GPU, a ten w OGLu 2 był większy, bo sterownik wysyłał wszystko i jeszcze trochę. Ale jeśli koszt wejścia to bariera jaką stawia api początkującemu prkgramiście, to rzeczywiście w OGLu 3+ jest większy.

W OGLu 2 można zrobić wszystko to co w OGLu 3. Z tym że narzut na CPU będzie dużo większy.

Offline bedekiedysoga...

  • Użytkownik

# Luty 06, 2016, 15:49:10
A polecacie coś ciekawego co nie zaprzęga do obługi okna WinApi, tylko coś bardziej wysokopoziomowe. Nie znam WinApi i strasznie zaciemnia mi on odbiór samego OpenGL'a.

Offline Xender

  • Użytkownik

  • +1
# Luty 06, 2016, 15:59:33
Jasne.

Okno: GLFW / SFML / SDL2
Macierze: GLM
Ładowanie właściwej wersji/rozszerzeń: glLoadGen

Wszystkie te mają dodatkowo tę cechę, że są wieloplatformowe.
Czyli, jeśli nie schrzanisz tego w innym miejscu, Twoja gra/program też będzie.

Offline hashedone

  • Użytkownik

  • +1
# Luty 08, 2016, 11:58:10
Masz błędne dane ;)
Nie mam błędnych danych. W OpenGL2 można używać shaderów pod warunkiem, że karta graficzna wspiera odpowiednie rozszerzenie. Oczywiście nie jest to żaden problem z punktu widzenia technologicznego, jest jednak problem z API, otóż core API OGL2 nie ma w sobie shaderów - trzeba użyć odpowiednich rozszerzeń (ok, można je pobrać jakąś biblioteką). Fakt, że wszystko się da, ale jeśli się robi wszystko to i tak robi się to albo tak jak w OGL3, albo trudniej (nie znam na pamięć wszystkich rozszerzeń i nie wiem czy któreś pozwalają robić to tak jak w OGL3 czy nie). W każdym razie - ucząc się OGL2 bez rzeczy typu shadery, VBO, uczysz się rzeczy które są przestarzałe, niewspierane, a co najważniejsze: wolniejsze na dzisiejszych kartach graficznych. Jest tak dla tego, że OGL2 był przystosowany do kart graficznych które miały nieprogramowalny potok, z bardzo ograniczoną liczbą jednostek teksturujących, czasem bez własnej pamięci na bufory. Z czasem karty graficzne zyskały więcej pamięci, potok zaczął być programowalny, doszły nowe etapy pracy GPU, doszły nowe możliwości. Oczywiście trzeba było dalej wspierać stary sprzęt, więc zdecydowano, że do OGL2 doda się rozszerzenia - programiści jeśli chcieli użyć czegoś dostępnego tylko na nowym sprzęcie musieli sprawdzać, czy GPU klienta to udostępnia i jeśli nie, pisać przebiegi alternatywne. Karty graficzne się rozwijały, producenci stwierdzili, że natywnie nie ma sensu wspierać takich rzeczy jak np. tryb bezpośredni i okazało się, że teraz na nowych kartach jest on bardzo wolny - bo jest na siłę symulowany przez VBO (dzisiejsze karty graficzne pracują tylko iterując przez wierzchołki w buforze). Ostatecznie ktoś stwierdził całkiem nie dawno (bo jeszcze to pamiętam a zim za mną niewiele), że trzeba odciąć się od starego sprzętu, bo nowe produkcie i tak na nim nie banglają, a tego sprzętu już na prawdę nikt nie używa. Tak powstało OGL3, którego API jest zgodne z tym, jak działają współczesne karty graficzne (OGL4 jest jego rozwinięciem - dodaje nowe rzeczy, nie usuwa nic ze starego). Konkluzja: używając OGL2 używasz czegoś, co jest niezgodne z tym jak działają dzisiaj karty graficzne i jeśli nie włożysz w to wysiłku, część rzeczy będzie na nich specjalnie symulowana - OGL3 Core jest zgodne z działaniem nowoczesnych GPU i choćby dla tego nie powinno się używać starszych wersji jeśli nie ma się jakiegoś dobrego powodu (np. nie jesteś pewien, że ktoś spróbuje używać twojej aplikacji na GeForce2).

Jeszcze apropo posta Xendera - odradzam od siebie SDL2. Jak z niego ostatnio korzystałem, był dużo mniej wygodni niż GLFW/SFML
« Ostatnia zmiana: Luty 08, 2016, 12:02:43 wysłana przez hashedone »

Offline Kos

  • Użytkownik
    • kos.gd

# Luty 08, 2016, 22:45:05
Oczywiście trzeba było dalej wspierać stary sprzęt

Yy, myślałem że to przez lobby ludzi z Autodesk, którzy chcieli dostępu do nowych rzeczy, ale bez przepisywania wszystkiego na nowe API :P

Offline Xender

  • Użytkownik

# Luty 09, 2016, 09:58:09
Yy, myślałem że to przez lobby ludzi z Autodesk, którzy chcieli dostępu do nowych rzeczy, ale bez przepisywania wszystkiego na nowe API :P
Huh? To by było grube.

Jakiś link, czy plota? :P

Offline Kos

  • Użytkownik
    • kos.gd

# Luty 10, 2016, 08:57:39
100% plota, nawet nie pamiętam skąd słyszałem. :)

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Luty 10, 2016, 16:38:01
Yy, myślałem że to przez lobby ludzi z Autodesk, którzy chcieli dostępu do nowych rzeczy, ale bez przepisywania wszystkiego na nowe API :P
Nie wiem czy plota, nie wiem czy konkretnie Autodesk, ale ogólnie to ma sens - w końcu OpenGL jest rozwijany przez konsorcjum Khronos (a nie tak jak DirectX - przez jedną firmę), w którym każdy z członków ma swoje interesy. Poza tym OpenGL zawsze był bardziej popularny w takich właśnie zastosowaniach profesjonalnych typu CAD/CAM, podczas gdy DirectX w grach. Dlatego nic dziwnego, że ciągle zachowuje wsteczną kompatybilność.