Autor Wątek: Pytanie o tok szkolenia.  (Przeczytany 5850 razy)

Offline pomnikozerca

  • Użytkownik

# Lipiec 26, 2012, 01:12:33
http://januszg.hg.pl/opengl/index.html
Przeglądam ten kurs i zastanawia mnie czy zaczynać od Kurs OpenGL 1.X/2.X czy odrazu brać się za wersję 3.2, niekrótych rzeczy nie ma w 3.2 i nie wiem czy nie ma ich bo autor nie zrobił czy poprostu akurat te rzeczy nie różniły się zbytnio w wersjach.
Ogólnie to słyszałem, żeby unikać fixed pipeline, a reszta jest podobna, jak to z tym jest? Brać się od 1/2 a potem przejsć na nowsze wersje?

Offline Mr. Spam

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

Offline SnowyMan

  • Użytkownik

  • +2
# Lipiec 26, 2012, 01:26:33
Zacznij od 3.2, jest z nim sporo więcej roboty ale i tak prędzej czy później będziesz się musiał tego nauczyć. Polecam ci od razu używać glm do obsługi macierzy.

W 3.2 nie ma aż tylu rzeczy co w 2.1 bo... nie są właściwie potrzebne, shadery sprawiają, że wszystko możesz napisać sobie sam :P

Offline Xender

  • Użytkownik

# Lipiec 26, 2012, 02:17:10
OpenGL 3.2 na początek, potem ficzery z 4.2 żeby poznać wszystkie najnowsze bajery. Oczywiście tylko profil core, żadnego compatibility!
GLFW do obsługi kontekstu OpenGL i interakcji z użytkownikiem.
GLEW do ładowania funkcji OpenGL. (Standardowy header gl.h zatrzymuje się na wersji bodajże 1.1, nowy gl3.h na 3.X, ale żeby wczytywać nowsze rzeczy lub rozszerzenia potrzeba manualnie ładować dynamicznie funkcje. GLEW to automatyzuje.)
GLM do obsługi macierzy.

No i polecałbym do nauki znaleźć / sukcesywnie pisać jakąś "biblliotekę" prostych shaderów - podstawowe wyświetlanie trójkątów w danym kolorze, z teksturami, z oświetleniem - w przeciwieństwie do starych wersji (1.X, 2.X) lub profilu compatibility, w core bez shaderów nic nie wyświetlisz.

Offline Veldrin

  • Użytkownik

  • +1
# Lipiec 26, 2012, 03:17:41
A mnie takie podejście lansowane w wielu bliźniaczych tematach zupełnie nie przekonuje.

To tak jakby uczyć człowieka jeździć sportowym samochodem. Co tam wspólne zasady - niech od razu się ściga! Bo inaczej to strata czasu! To jest błąd. Podstawy to podstawa.

Szkolimy nowego programistę? Niech zaczyna od zaawansowanych sztuczek metaprogramowania w Cpp, co tam ify, pointery.

Brak solidnych fundamentów z zakresu programowania(szczególnie, ja wiem że często to dzieci), algebry, teorii grafiki komputerowej, zrozumienia co właściwie robi to duuużo % głupich tematów zalewających "Szkółkę" i co gorsza "Programowanie grafiki" na tym forum.  Potem człowiek pisze zaawansowane cieniowanie, światła, bajery, a nie ma pojęcia dlaczego to się kręci, albo wygląda jak wygląda.

Ja naukę zacząłem od wersji 1.X i krok po kroku szedłem przez 2.X kończąc na 4.X. Tak polecam każdemu nowego programiście.  Pisząc silnik na 2.X, na którym kilka gier powstało poznawałem wszystko dokładnie krok po kroku i czerpiąc z tego w następnych projektach. Robiąc w 2.X przecież można zacząć olewać gotowe funkcje. Zacząć korzystać z VBO, poznać działanie. Dodać własne operacje na macierzach zrozumieć istotę. Efekty? Ruszały shadery. Coś więcej? Jest i FBO itd.

A profil compatibility to wbrew pozorom całkiem dobre źródło wiedzy dla osoby początkującej(ale i dużo pułapek)

Podstawowa teoria grafiki nie zmieniła. Skoro zaczyna naukę to prawdopodobnie nie wiem NIC. Zamiast porządnej nauki o co właściwie w tym wszystkim chodzi(niezależnie od języka, biblioteki, platformy) skończy na durnych pytaniach tworzenia kontekstu, przesyłania macierzy do shaderów, a co to VBO/VAO jak i dlaczego.

Może warto na początek, korzystając z  1.X/2.X, freegluta co nieco poznać? Krok po kroku. Nic się nie przyśpieszy jeżeli chce to zrobić dobrze.

Można posadzić świeże mięso pokazać mu wysokopoziomowy język i nauczyć programować. Można tok nauki poprowadzić inaczej np. C->asm->C++->Java/Sharp. Programista nie znający architektury komputera to nie programista. A jest jeszcze dużo ciekawych rzeczy po drodze ;).

PS. Oczywiście ktoś powie, że nabierze złych po funkcjach zawartych w Compatibility. Bo to będzie gotowe. Ale CO to jest i DLACZEGO używamy tak a nie inaczej to czy Compatibility/Core nie ma żadnego znaczenia.

Dane będą danymi. Potok się nie zmienia, przekształcenia również.

Offline Oti

  • Użytkownik

  • +2
# Lipiec 26, 2012, 03:48:20
To tak jakby uczyć człowieka jeździć sportowym samochodem. Co tam wspólne zasady - niech od razu się ściga! Bo inaczej to strata czasu! To jest błąd. Podstawy to podstawa.
Kiepskie porównanie. Mam trafniejsze: pisanie w starym OGL to tak jak nauka prawa jazdy od bryczek konnych. Koń wio, koń stop. Mniej zachodu, mniej możliwości. Tylko po co uczyć się starożytnych już metod, skoro i tak się do niczego nie przydadzą?

Nie ma większego sensu uczyć się fixed pipeline tylko po to, by później przesiąść się na shadery. Można zacząć od razu od nich i poznająć samo API graficzne jechać na najprostszych shaderach, np. z internetu.

Offline socket

  • Użytkownik

# Lipiec 26, 2012, 04:00:48
Chyba chodzi mu o to by poznać jak co działa - by posługiwać się narzędzami, które rozumiemy jak działają. Dlatego mówi o nauce opengl od początku.

To jest trochę jak rozwiązywanie równań kwadratowych nie znając metody skróconego mnożenia...
« Ostatnia zmiana: Lipiec 26, 2012, 04:02:39 wysłana przez socket »

Offline Xender

  • Użytkownik

  • +3
# Lipiec 26, 2012, 04:49:57
Słowo na dziś dla co to niektórych: "deprecated".

Twórcy OpenGL uznali, że fixed pipeline jest deprecated.
Dla tych co nie rozumieją - to takie wołanie: "nie ucz się tego człowieku, w ogóle nie powinieneś z tego korzystać".

OpenGL od wersji 3.1 w profilu core definitywnie przeszedł na shadery i uprzątnął burdel zwany fixed pipeline.
Burdel, bo fixed pipeline ma o wiele bardziej skomplikowane API niż shadery i o wiele mniejsze możliwości. Uczenie się go przed shaderami może spowodować jedynie dalszą konfuzję. Bo delikwent mając doświadczenie z fixed, jest zorientowany na drogę, która była właściwa w fixed pipeline. Nie będzie myślał kategoriami przetwarzania dowolnych danych - będzie myślał, że niektóre atrybuty wierzchołków mają jakieś "magiczne" właściwości.

To ma sens taki, jak studiowanie alchemii przed nauką chemii. NIE należy odtwarzać historii nauki, aby dobrze ją poznać. Należy zacząć od *aktualnych* podstaw.

//EDIT: @down, poprawione, chodzi o core.
« Ostatnia zmiana: Lipiec 26, 2012, 12:11:19 wysłana przez olo16 »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Lipiec 26, 2012, 08:56:08
Cytuj
OpenGL od wersji 3.1 definitywnie przeszedł na shadery i uprzątnął burdel zwany fixed pipeline.
Definitywnie to przeszedł DirectX 10 i OpenGL ES 2.0. Jeżeli cały smród pod spodem został jako deprecated, to jest to przejście takie jak żadne.

Offline nembutal

  • Użytkownik

  • +1
# Lipiec 26, 2012, 10:23:15
Burdel, bo fixed pipeline

Może zacznijmy od tego, że OpenGL to nie jest biblioteka tylko do pisania silników - różne aplikacje na różne sposoby mogą z niego korzystać. Więc dla części osób usunięcie dodatkowej funkcjonalności wyższego poziomu, którą nazywasz "burdelem" znaczy mniej więcej tyle, że muszą sobie poszukać biblioteki macierzowej i czytać o pisaniu shaderów, których możliwości i tak nie wykorzystają. Po co? Po to żeby samemu sobie zaimplementować tą funkcjonalność i opakować ją we własne klasy? Tak robią pro, co nie?
Co dalej, może by zrobić nagonkę na gotowe dania w supermarketach bo przecież każdy samemu powinien sobie gotować?

Offline SnowyMan

  • Użytkownik

# Lipiec 26, 2012, 11:10:26
Tak robią pro, co nie?
Seriosly? No i tak właściwie zaprzeczasz samemu sobie bo jeśli 'tak robią pro' to jest to znak, że daje to w jakiś sposób większe korzyści niż alternatywna opcja.

Co dalej, może by zrobić nagonkę na gotowe dania w supermarketach bo przecież każdy samemu powinien sobie gotować?
Próbowałeś kiedyś gotowych dań z supermarketu? Nie polecam.

Sam zaczynałem od fixed i potem mi było ciężko przestawić się na shadery. I teraz ci powiem, że zdecydowanie wolę shadery. Poza tym jak raz to sobie opakujesz w klasy to nie musisz tego robić drugi a kontrolę nad wszystkim masz zdecydowanie większą.

Offline Xender

  • Użytkownik

  • +1
# Lipiec 26, 2012, 12:22:02
@membutal
OpenGL jest z założenia niskopoziomowym API. Po sieci krąży mnóstwo bibliotek, które dostarczają podstawowe shadery. Z biblioteką do obsługi macierzy bardzo dobrze - skoro to operacja po stronie CPU, a stos macierzy z fixed pipeline przestał mieć rację bytu, to zachowywanie tego nie miałoby sensu.

To takie straszne, że trzeba użyć jednej/dwóch bibliotek pomocniczych? Jak ktoś nie chce czytać o shaderach, to czyste OpenGL nie jest API dla niego.

Offline pomnikozerca

  • Użytkownik

# Lipiec 26, 2012, 13:22:40
A co do prymitywów, to nie wiem czy dobrze rozumiem, ale w wersji 3.2+ nie rysuje się ich już w sposób glbegin ... wierzcholki ... glend?

Offline SnowyMan

  • Użytkownik

  • +1
# Lipiec 26, 2012, 13:24:03
Nie, używasz VBO, więcej z tym zachodu ale jest znacznie szybsze.

Offline flexi

  • Użytkownik

# Lipiec 26, 2012, 14:06:21
Tez mialem sprory problem z przejsciem z 2 na 3, ale po pewnym czasie wszystko zrozumialem i wszystko moim zdaniem wydaje sie lepsze :).


Offline Veldrin

  • Użytkownik

# Lipiec 26, 2012, 15:38:22
Ja osobiście nie miałem problemów z przejście z 2.X na 3.X. Może dlatego, że z czasem zastępowałem gotowe API swoimi metodami. Jak już pisałem - krok po kroku. Może straciłem przez to cenny czas? Szczerze wątpię.

No właśnie, nie wszystko zostało zrozumiane. Może powiem w ten sposób.

Po pierwsze - wymagania funkcjonalne/niefunkcjonalne. CO będziemy chcieli zrobić. Nie wszystko wymaga ultra-wydajności i wsparcia shaderów. Nie każdy używa OpenGL do pisania ultra pięknych silników gier 3D. Ja nie dawno potrzebowałem prostego szablonu renderującego prymitywy, tekst i wsparcie shaderów. Do researchu i szybkich testów. Nie wymagającego kosmicznej wydajność tylko kilkadziesiąt linijek kodu + mega szybka kompilacja. Stosowanie OpenGL 3.X w tym momencie nie było niezbędne.

Po drugie: nauka API to nie nauka grafiki! Tylko i wyłącznie o to mi chodzi. Tak jak nauka programowania to nie nauka C++. To, że API jest depracated nie oznacza, że teoria którą wykorzystuje również! Jak ktoś ma problemy ze stosowaniem raz fixed, raz Core to już problem indywidualny.

Oczywiście, że OpenGL w momencie przejścia na Core stał się super. Wielbię go każdego dnia. Ale to nie oznacza, że najlepsza droga to zaczynanie NAUKI od niego.

PS. Ja wiem, że każdy chce szybko osiągać fajne efekty. Programowanie grafiki na to pozwala, świeci się, kręci. Ale chyba nie o to chodzi.