OpenGL 3.0 wydane, zimno przyjęte przez programistów
Khronos Group ogłosiła na konferencji SIGGRAPH 2008 publikację specyfikacji API OpenGL 3.0 API, a także języka GLSL 1.30. Mimo szumnych zapowiedzi i prawie rocznego opóźnienia ze względu na “sprawy techniczne”, zmiany okazały się nie być rewolucyjne.
OpenGL jest specyfikacją uniwersalnego API do generowania grafiki, wykorzystywany często przez gry komputerowe i wygaszacze ekranu, spełnia rolę analogiczną do konkurencyjnego Direct3D (część DirectX) w systemie Windows firmy Microsoft.
Środowisko deweloperskie wyraziło już swojeniezadowolenie z najnowszej specyfikacji OpenGL. Serwis Phoronix nie zajmuje się jednak tym co nie zostało zrobione, a koncentruje się na zmianach między specyfikacją 2.1 a 3.0.
Jednym z celów OpenGL 3.0 było uproszczenie API z punktu widzenia deweloperów implementujących standard. Jeśli chodzi o nowe funkcje, to mamy między innymi:
obiekty tablicy wierzchołków (Vertex Array),
obiekt bufora ramki,
32-bitowe zmiennoprzecinkowe tekstury (textures) i bufory renderowania (render buffers),
renderowanie warunkowe, bazujące na testach przesłonięć (occlusion queries) — chodzi o to, żeby nie renderowac obiektów, o których będzie wiadomo, że zostaną zasłonięte przez coś innego
dodatkowy, mniej precyzyjny typ danych zmiennoprzecinkowych, do informacji o pikselach i wierzchołkach o połowę mniejszy od typu float (compact half-float vertex and pixel data) — dodany w celu zaoszczędzeniu magistrali pamięci,
Khronos Group zapowiedziała też pracę nad integracją z OpenCL, stworzonym przez Apple językiem ułatwiającym programowanie współbieżne między jednostkami CPU i GPU (GPGPU computing).
Jeśli ktoś z nas siedzi w grafice i OpenGL, bardzo proszę o korektę polskich tłumaczeń. Niestety ja nie jestem ekspertem w tej dziedzinie, stąd niektóre rzeczy z changelogu zostawiłem w oryginale, inne przetłumaczyłem na chłopski rozum, przydałaby się tu weryfikacja.
"occlusion queries" zamienilbym na "testy przesloniec" – chodzi o to, zeby nie renderowac obiektow, o ktorych bedzie wiadomo, ze zostana zasloniete przez cos innego.
Framebuffer nie stał się w pełni obiektowy. Tak się po prostu to rozszerzenie (dotąd) nazywało "Frame Buffer Object".
Objektowość i usunięcie przestarzałej funkcjonalności (w sensie podejscia do obsługi potoku graficznego – nie użycia języka/metodologii), jest wielkim, przez wszyskich wyczekiwanym, nieobecnym i głównym sprawcą całego tego niezadowolenia.
Jak ktoś słusznie zauważył, ta wersja zasługuje co nawyżej na oznaczenie 2.2, a nie 3.0.
Co ciekawe wersja GLSL, w której zmiany wydają się bardziej dopracowane i przemyślane od zmian w interfejsie C otrzymała kolejne oznaczenie 1.30, a nie 2.0, mimo iż bardziej już na nie zasługuje (chociaż mnie osobiście ten preprocesor trochę drażni, w współczese języki wydają się już kończyć z etapem manipulacji na tekście programu przed właściwym parsingiem)…
"Frame Buffer Objects" (FBO) to "Obiekty Bufora Ramek", sa to po prostu powierzchnie do ktorych mozna renderowac zamiast do standardowego bufora ekranu, uzywane np w XGL do implemetacji XVideo. Oficjalnie nie jest to standardem, ale od lat bylo to zaimplementowane w zamknietych sterownikach nVidii i ATI (a teraz takze otwartych Intela), oraz uzywane w grach. Podobnie bylo z Buforami Pixeli (PBuffer), ktore nie mam pojecia czy weszly do specyfikacji OpenGL.
Obiektowość API ma swoje wady i to poważne – nie patrzcie na obiektowość przez pryzmat zbioru ładnych klas QT, bo jest to przykład bardzo ryzykowny z punktu widzenia trwałości, stabilności, wersjonowania i przyrostowego rozwoju obiektowego API, tylko patrzcie na obiektowość uktytą za interfejsami (virtual abstract base class w C++), tak jak to robi np.: COM np.: w DirectX, lub XPCOM w Mozilla Firefox/etc.
W podejściu które oferuje np.: COM/XPCOM można w kolejnych wersjach biblioteki po prostu definiować nowe interfejsy, które rozszerzają funkcjonalność istniejącego już obiektu i dla przykładu: biblioteczna klasa SolidLineImpl może imlementować Line, SolidLine, a w nowej wersji biblioteki może dodatkowo implementować SolidLine2, SolidLine3, … . Stary kod kliencki w sosunku do biblioteki, pyta się czy obiekt implementuje SolidLine, rzutuje sobie go i używa, a nowy kod kliencki może zapytać czy obiekt impelementuje też interfejs SolidLine2 i też go użyć, jeśli biblioteka i klasa go implementuje. Za to gdy się eksportuję z biblioteki zwykłe klasy C++ to jest się zmuszonym do dostarczenia wszystkich opublikowanych wersji biblioteki, w których zmieniał się layout klas, lub linkowania statycznego.
Z drugiej strony, COM nie jest przykładem obiektowości, którą się superłatwo używa – chyba że wygeneruje się fatwiejsze w użyciu klasy proxy lub używa się języka wyższego poziomu (np.: w VB bardzo łatwo pisało się coś co używa COM/AxtiveX).
Konstuowanie API jako zbioru zwykłych funkcji C i uchwytów na niejawne struktury/obiekty (np. GTK, WinAPI) jest bardzo bezpieczne i … mądre i lepiej przy tym pozostać.
"współczese języki wydają się już kończyć z etapem manipulacji na tekście programu przed właściwym parsingiem"
I tak i nie. Preparsing umożliwia wzbogacenie sybkiego i efektywnego języka o cechy które sprawiają że pisze się w nim łatwiej/szybciej, a razie problemów można łatwo dokonać ręcznych poprawek w wygenerowanym kodzie. Przykład: język Vala dla GNOME.
Przejście na współczesne języki, to podróż w jedną stronę (zupełnie nowy runtime, biblioteki, mechanika i zasada działania) i dostaje się "cały inwentarz na raz" – i to co dobre i to co złe.
Jeszcze raz powtórzę: obiektowość w OpenGL nie dotyczyła języka ani nowej metodologii, a jednynie innej abstrakcji potoku graficznego, która pozwalała na lepsze współdzielenie i zarządzanie różnymi obiektami w potoku graficznym (nie klasami!) typu tekstury, shadery/programy, bufory pikseli/wierzchołków, itp. Sterownik nie musiał by się martwić o wiele rzeczy, o które obecnie się martwi przy zarządzaniu zasobami, gdyż robili by to sami programiści, dostosowując je do potrzeb swojej aplikacji w sposób dla niej najbardziej odpowiedni.
Obecne podejście, w którym wszystko znajduje się gdzieś w przepastnych czeluściach implementacyjnych sterownika i pracować można jedynie na zbindowanych w danym monencie obiektach jest bardzo nieeefektywne, zarówno ze względu na narzut związany z wywołaniami API (choć tu i tak jest znacznie lepiej niż w DirectX), jak i kontrolę nad samym procesem renderingu.
Co do preprocesora, chciałbym wiedzieć jakie to cechy czynią preprocesor tak bardzo wyjątkowym w stosunku np. do parsowanych dyrektyw języka tworzących konkretne makra i spójnie integrujących się ze składnią języka (patrz np. język D) – szczególnie, że akurat ten preprocesor z GLSL jest dość mocno ograniczony w stosunku do swojego pierwowzoru.
No i dalej nie ma obiektowego API. Zrobili tylko nowe opakowanie na stare gówno. Pisanie pod DXa jest o niebo wygodniejsze. Mam obiekty i wygodnie zdefiniowany dla nich zestaw operacji, który nawet IDE mi podpowiada. Pod OpenGLem jak zwykle trzeba uczyć się nazw funkcji na pamięć oraz szukać, do czego która funkcja pasuje.
Pod OpenGLem jest masa durnowatych extów, które trzeba sobie sprawdzać czy istnieją. Jeśli chcemy czegoś użyć, to trzeba się bawić w pobieranie adresów procedur.
Bzdura, API OpenGLa jest bardzo wygodne a nazwy funkcji sa intuicyjne i latwe do zapamietania.
Nie zrozumialem co masz na mysli "szukać, do czego która funkcja pasuje" ?
Co do extow, to jak zaleta moze byc wada? Nie chcesz, nie musisz ich uzywac, ale jesli sa, mozesz uzyc nowych funkcji, ktore nie zdazyly jeszcze wejsc do standardu.
W zasadzie nie. Brakuje choćby shaderów geometrii, choć jest możlowość zrzucenia geometrii po jej przetworzeniu przez vertex shader (ta funkcjonalność jest akurat szczegółnie przydatna właśnie z shaderami geomtrii).
W ogóle to co zaprezentowano to jakiś dziwny kompromis między wieloma sprzecznymi dążeniami, który na dobrą sprawę nie zadowala nikogo. Jak to się mówi jak coś próbuje być do wszystkiego to zazwyczaj jest do niczego.
Jedyną nowością na dłuższą metę jest wprowadzenie możliwości oznaczania poszczegółnych części specyfikacji jako przestarzałe i ich usuwania w kolejnych wersjach, oraz możliwość tworzenia kontekstu jedynie z nieprzestarzałymi funkcjami. To daje podstawę do dalszej ewolucji OpenGL-a w lepszym kierunku, ale czy rzeczywiście będzie sensownie ewoluował, to po tym co się dotychczas wydarzyło można mieć pewne wątpliwości.
Skoro uzasadnieniem dla obecnego stanu rzeczy była chęć zaspokojenia wielu sprzecznych rządań, to czy te rządania przestaną być sprzeczne w przyszłości? Szczerze w to wątpię.
Póki co pozostają nam jedynie tłumaczenia:
http://www.opengl.org/discussion_boards/ubbthread…
Czy usuwanie starych funkcji jest dobre, to bym nie powiedzial… IMHO wsteczna zgodnosc powinna byc zawsze priorytetem.
IMHO jesli chcieliby cos strasznie przebudowac, powinni zostawic stare funkcje w spokoju, za to dodac mase nowych, powiedzmy zaczynajacych sie od gl3 (np. gl3Begin(), gl3LoadIdentity(), itp.)
Wtedy stare programy by sie kompilowaly po staremu i bylaby mozliwosc unowoczesnienia calego API.
Krótko: albo pełna wsteczna kompatybilność, albo szybkość i efektywność sterownika.
API OpenGL-a było projektowane w czasach gdy nikt nie myślał o tym, że trzeba będzie zarządzać pamięcią katy graficznej podobnie jak zarządza się wirtualną pamięcią komputera, albo, że rendering będzie odbywał się na 2/3/4 kartach graficznych równocześnie. W istniejącym modelu nie ma w ogóle wsparcia dla wielowątkowego renderowania, a jego próby wprowadzenia (obiekty synchronizacji, współdzielenie zasobów) nastręczają ogromnych trudności. Heurystyka współcesnych sterowników, próbujących odgadnąć "co program ma na myśli" i idpowiednio przygotowywać do tego sprzęt graficzny jest ogromnie rozbudowana, i nikogo nie dziwi optymalizowanie ich pod konkretne tytułay gier czy wersje programów.
Wielu z tych problemów można uniknąć zmieniając API OpenGL-a tak, aby programiści mieli większe możliwości decydowania o tym, nie tylko co ma być wyświetlone, ale także w jaki sposób powinno się to odbywać, aby było efektywne. Wówczas całe to obecne hokus-pokus w sterownikach mogło by zniknąć, twórcy sterowników mieli by dużo mniej roboty, a programiści grafiki większy wpływ na to jak działa ich program.
Zyskują wszyscy, z wyjątkiem tych, którzy musieli by przystosować obecne oprogramowanie do nowego API, a którym się to nie opłaca, czyli np. twórcy części programów typu CAD.
Próbuje się temu obecnie zaradzić tworząc tzw. profile, czyli zestawy funkcji, które będzie wspierał sterownik, a które nie muszą występować jako obligatoryjne w najnowszej wersji OpenGL.
Czas pokaże czy zda to egzamin, być może tak, jeśli mocno rozwinie się rynek alternatywnych akceleratorów graficznych (a rozwija się już od dawna) dedykowanych do rozwiązań profesjonalnych, w istocie różniących się głównie firmwarem i sterownikiem optymalizowanym pod konkretne aplikacje.
Ponoć 10 jest łatwiejsza ale jak kupiłem książkę do 9 to kod dołaczony nawet się nie kompilował. Jakoś nie miałem siły przebijać się przez cały kod dotyczący COM – prościej było użyć 3-5 funkcji SDL/GLUT i mieć już okno. OpenGL było jak C/C++ w prownaniu do assemblera 😉
Dx10 nie miałem okazji spróbować i niestety w nalbliższym czasie nie będę miał.
PS. Czy do poważniejszych gier nie lepiej użyć specialistycznych bibliotek?
Odnośnie DirectX – mam takie same odczucie, ale używałem głównie operacji 2D (DirectX7 + później Graphics z DirectX8, ale tam głównie operacje na sprajtach). Pierwsze co musiałem zawsze robić z DirectX to opakować to co jest w jakieś ładne klasy, bo inaczej używanie było niewygodne.
Z tego co widziałem kod z OpenGL wygląda czytelniej.
pewnie ktos nie zrozumial co napisales i uznal, ze obrazasz "to cos co ma Open w nazwie, wiec musi byc otwarte, a jak otwarte, to jest dobre a linux jest super" 🙂
nie oczekuj, ze te plusy i minusy tutaj maja sens…
Każda krytyka "Open" na tym portalu spotyka się z minusami. Właściwie to nie ma się co tym przejmować, bo przecież nie piszemy komentarzy dla punktów (prawda? 🙂 ). Inna sprawa, że pewnie punkty inaczej by się rozkładały gdyby każdy był zalogowany i punktował, ale na szczęście większość ma to gdzieś i woli pisać "od tak" pseudo anonimowo (z ukrytym prawdziwym mailem).
To, jak je nazywasz, ,,stare gówno'' to API używane w wielu istniejących produktach. Tak się składa, że gra (nawet AAA) żyje najwyżej 3 lata. A aplikację CAD/CAM/CAE naście. Pozbywanie się zgodności w imię walki z DX10 na poletku gier to strzał we własną stopę.
tu nie chodzi o walke z directx (o tym tylko grajace dzieci wkolo krzycza) – tu chodzi o przejrzystosc api/wydajnosc zarowno po stronie sterownika, jak i po stronie aplikacji.
to, ze specjalistycznych aplikacji poprostu nie chce sie modyfikowac (je sie tylko z czasem poprawia – ich sie nie rozwija…) – to inna sprawa. taniej wychodzi łatać starocia, niz napisac cos od nowa, nawet jesli by to mialo oznaczac calkiem nowa jakosc…
Źle. Nie ,,grające dzieci'' bo gamedev to bardzo duży rynek — więc nie deprecjonuj. Tylko, że nie jedyny w który celuje OGL. O sterownikach napisałem poniżej — to nie zadziała. A co do czystości aplikacji: dla jednego typu czyste to będzie glVertex3f() i glBegin(), glEnd(). A dla innych VBO i Geometry Shaders. Tylko, że nie warto rezygnować z żadnego z rynków. Dlatego mają powstać profile — część dla zwolenników fixed pipeline, część dla gamedev. Dopiero to może poprawić dolę autorów sterowników, bo będą mogli oddzielić od siebie ścieżki. Ale w żadnym wypadku nie da się części z nich wyeliminować.
@bies: Idac tym tropem nalezaloby dwadziescia lat temu, zamiast wymyslac OpenGL, nadal ciagnac PHIGS. W koncu byl otwarty, ustandaryzowany przez ISO, przenosny i w ogole, w przeciwienstwie do owczesnego OpenGL.
Czasami trzeba wyrzucic zabytek i zrobic cos od poczatku.
A co do rewolucyjnosci zmian – nie mialy byc rewolucyjne 🙂 Dopiero wersja 3.1 ma przyniesc rewolucje, 3.0 miala byc tylko posprzataniem i przygotowaniem nowego API…
Czyli numeracja podobnie jak w KDE4 :)Tez niektorzy po zainstalowaniu KDE 4.0 narzekali na brak rewolucji…
W przypadku KDE4 było inaczej. KDE 4.0 było rewolucyjne, ale zabrakło niektórych funkcji z linii 3.0 lub pewne funkcje były niedopracowane. W moim odczuciu, autorzy OpenGL poszli w dobrą stronę. Najpierw poszukali rzeczy, które można wyrzucić(duży projekt, duża odpowiedzialność). Z tego powodu tyle to trwało. Teraz powciskają jakieś przydatne funkcje.
Problem w tym, że bałagan pozostał a nawet się powiększył (vide pomieszanie w specyfikacji ze sobą przestarzałej funkcjonalności i nowych rozwiązań), a nowego API jak nie było tak nie ma…
To faktycznie ciężko zwięźle przetłumaczyć. Chodzi o dodatkowy mniej precyzyjny typ danych zmiennoprzecinkowych do informacji o pikselach i wierzchołkach o połowę mniejszy od typu float. Jak pisze w źródle, po to aby zaoszczędzić magistralę pamięci.
ATSD: ja bym nigdzie nie pisał "wsparcie" tylko "obsługa" – zresztą tutaj też to poprawiłem. Chyba że chodzi o wsparcie techniczne (w sensie serwisu dla klientów) albo finansowe (np. wsparcie jakiejś fundacji FLOSS przez firmę).
Równie dobrze można powiedzieć "obsługa" w sensie obsługa klienta. Tutaj mamy wparcie technologii przez oprogramowanie. Poza tym we wszelkich materiałach w języku angielskim w takich wypadkach pisze "support" (wsparcie), nie spotkałem się, żeby pisało "handling" (obsługa).
Po polsku "wsparcie" to tyle co "pomoc", "wspomagać":
http://sjp.pwn.pl/lista.php?co=wsparcie
Oczywiście masz rację z użyciem "support" w angielskim. Ponieważ jednak mamy dobry odpowiednik po polsku (obsługa), to nie widzę powodu żeby na siłę rozszerzać zakres znaczenia polskiego słowa "wsparcie".
kocio: dzięki za podpórkę – teraz będzie mi łatwiej tłumaczyć ludziom, dlaczego pewna technologia nie jest "wspierana" (bezpośrednie tłumaczenie z j. ang. jest w tym przypadku po prostu nie na miejscu), a najnormalniej implementowana, tudzież obsługiwana.
Ale to jest FBO, a w angielskim natłok wyrażeń wcale nie wskazuje jak poszczególne wyrazy są ze sobą powiązane logicznie – czy to można przełożyć jako "obiekt bufora ramki"?
Frame Buffer? Jest to ciekawe. Nigdy o takim czymś nie słyszałem, a jedyne skojarzenie pewnie jest błędne, bo na myśl przychodzi bufor akumulacji(powielania). Mógłby ktoś mi to wyjaśnić?
bufor ramki to po prostu zbior pikseli ekranu, dzieki temu masz bezposredni dostep do tego co bedzie wyswietlone i ewentualnie mozesz tam cos zmienic bez tego calego kosztownego etapu renderowania w potoku.
E zaraz, bufor ramki to włąśnie wyjście renderingu! To, że można je robić poza ekranem nie ma tu nic do rzeczy. Bufor akumulacji to stare rozwiązanie jeszcze z czasów gdy potok graficzny nie był programowalny. Obecnie FBO zastępuje go z nawiązką.
w tym przypadku – oczywiscie to wlasnie wyjscie z renderingu (a wlasciwie obiekt je reprezentujace) – stilgar najwyrazniej tlumaczy czym jest FB (ogolnie), a nie FBO (szczegolny przypadek z ogl).
o ile karakarowski "bufor klatek obrazu" wydaje sie bardzo ladnym tlumaczeniem, o tyle "obiekt bufora ramki" wydaje sie byc duzo lepszym, chocby ze wzgledu na uzycie tlumaczenia stosowanego od okolo 1/4 wiecza (no moze nieco dluzej), jak i uwzglednienie tego, ze nie o sam bufor chodzi, a o sterujacy nim obiekt…
Ahh…. Frame Buffer! Coś podobnego zastosowano przecież w jądrze Linuksa. Częściowy zanik funkcji myślowych. Trochę sugerowałem się wypowiedzią katara: "bufor ramek obrazu". Dziwnie to brzmi, bo raczej chodzi o obecną ramkę. Przepraszam. Czyli Frame Buffer jest wynikiem wszystkich operacji przekształcania?
Jak narazie nie przybliża to gier do linuksa. Za artykułem z innej strony:
"wielu deweloperów otwarcie wyraża frustrację. Ich zdaniem biblioteki są mocno zacofane pod względem możliwości, zwłaszcza w kontekście wykorzystania ich jako platformy do rozwoju gier. OpenGL 3.0 pojawił się półtora roku po premierze DirectX 10, a ciągle jeszcze nie obsługuje wszystkich funkcji, jakie dawno temu zostały zaimplementowane przez Microsoft."
oraz:
"Pojawiły się również opinie, że opublikowana właśnie specyfikacja jest zacofana aż o siedem lat względem DirectX – a przepaść ma rosnąć z każdą chwilą. Co gorsza, na koniec bieżącego roku Redmond zapowiedziało premierę DirectX 11. "
No tak tylko ja np sie 'az tak dobrze' na tym nie znam, wiec zapytam bo nie wiem, czy OpenGL nie musi byc czasem wspierany tez 'przez sprzet'? Tzn ze np moja karta graficzna ma np takie a nie inne funkcje? Czy jak to wyglada w wielkim skrocie, bo srednio mam ochote zaglebiac sie w google.
Rozwój OpenGL jest kontrolowany przez Khronos Group, a w jej składzie są między innymi: 3Dlabs, ATI, Discreet, Evans & Sutherland, Intel, NVIDIA Corporation, SGI i Sun Microsystems.
Więc o wsparcie przez sprzęt bym się nie martwił.
Z resztą wystarczy popatrzyć na jej członków na ich stronie:
Wyglada to tak: biblioteka ma pewne funkcje. Programista z nich korzysta, chcac osiagnac jakis efekt. Najczesciej uzywane funkcje sa implementowane sprzetowo w kartach graficznych, zeby wykonywaly sie szybciej. Jesli jakas karta danej funkcji nie obsluguje, to w zaleznosci od tego co ta funkcja robi, albo jest przez OpenGL ignorowana, albo obliczenia wykonuje CPU.
Teoretycznie mozna w OpenGL renderowac obrazy w ogole bez karty graficznej, ale jeszcze nie widzialem, zeby ktos tak robil 🙂
Dawno się tym nie bawiłem, ale z tego co wiem to OpenGL definuje coś takiego jak "miniport" – w praktyce jest to pomost między uniwersalną i standardową mechaniką funkcji OpenGL a sprzętem – taki pluginowalny sterownik.
O OpenGL 3.0 słyszałem tyle, że ma być przede wszystkim znacznie uproszczony, przez co łatwiej będzie pisać sterowniki, a jeżeli łatwiej napisać sterownik, to istnieje duża szansa, że sterownik ten będzie dobrze napisany. Obecnie OpenGL zawiera masę funkcji, które są praktycznie nieużywane, dlatego też bardzo liczono na uproszczenie API. Nie dziwię się osobom, które krytykują to, co się stało. Po dwóch latach czekania tak niewielkie zmiany, a obietnice odnośnie specyfikacji nie zostały spełnione. Wiele osób na forach wypowiadało się bardzo krytycznie, wiele wspomniało, że po tym co zaszło, jedynym słusznym rozwiązaniem jest dla nich DirectX… oby się mylili.
Trick polega na tym, że to nie zadziała. Wyobraźmy sobie, że obcinamy rzadko używane funkcje i zostawiamy tylko szybką ścieżkę dla GPU (bez fixed pipeline). Tylko, że istnieje oprogramowanie, które z korzysta z tych funkcji. Jak myślisz który z producentów kart ogłosi najpierw: ,,Dobra panowie, kończcie flaszkę i do domu. Od wersji X nie wspieramy AutoCAD-a''?
Czy mi się wydaje, czy funkcjonalność Fixed Pipeline może być zaimplementowana software-owo w oparciu o shadery? Jeśli tak, to można cel (uproszczenia sterownika bez łamania wstecznej zgodności) rozwiązać tak, że zostawiamy API i rozbijamy warstwy (część "uczciwie hardware", a część "przenośnie")?
Ja jak zwykle pomarudzę: osobiście wiązałem kolosalne nadzieje z OpenGL 3.0 … liczyłem na wyrzucenie tych wszystkich bzdur, opisywanych w dostepnych w sieci tutorialach i masowo kopiowanych przez rzesze para-programistów. Liczyłem na to, że wreszcie skończy się wszechobecna dezinformacja i konieczność nurkowania w setkach plików PDF, żeby dowiedzieć się, jak daną rzecz robi się "współcześnie", bo książki/kursy/nagłówki z Windows dalej promują ciemnotę z epoki 1.0/1.1, co dziś jest po prostu SZKODLIWE. "Dzisiejszy" OpenGL to małe, zwarte API porównywalne z JSR184 (plus GLSL), tylko żeby je poznać potrzebny jest małki spryt i ogromna determinacja, bo nigdzie nie jest opisane w sposób wiarygodny i aktualny. Jeśli faktycznie 3.1 to będzie "ziemia obiecana" to ja z nadzieją patrzę w przyszłość.
to ja Ci proponuję jeszcze jedną erratę… takią gigantyczną. Ściągnij OpenGL w wersji 2.X na dysk, przeprogramuj go tak by był odpowiedni wg. Twoich oczekiwań (i zapewne większości) i opublikuj za miesiąc jako OpenClassicGL 1.0 – cały świat OpenSource będzie Twój.
Ale, ale – mi OpenGL 2.x jak najbardziej odpowiada, po prostu jestem zwolennikiem jak najszybszego usunięcia rzeczy, których i tak nikt (przemysłowo) nie używa.
Prościej jest wypełnić bufory vertexów i indeksów niż klepac glVertex
W każdym razie na pewno szybciej. Z resztą pozbycie się trybu bezposredniego już dano zostało zapowiedziane i jest jedynie kwestią czasu. OpenGL 2.0 ES już go nie posiada.
ofkorz, ze na buforach czy listach wierzcholkow jest szybciej, lepiej, wydajniej…
Ale, nie wiem jak wy, bo ja w trakcie pisania programow, czesto w miejsce jeszcze niezaimplementowanego obiektu wstawiam sobie "obrazek zastepczy", zwykle jakis trojkacik 🙂
Po prostu stosuje zasade, ze najpierw ma dzialac, a potem to sie zoptymalizuje, a znacznie szybciej jest dodac glBegin i kilka wierzcholkow, wstawic "@fixme zmienic to na bufory" i kodowac dalej cos bardziej istotnego…
Zreszta, czasem trzeba napisac banalnie prosty programik dla kogos, gdzie zastosowanie tego skraca kod…
Nie wiem co wam te funkcje przeszkadzaja – nie uzywacie ich, nie zwracajcie na nie uwagi… Mialbym przestac z tego korzystac, bo srodowisko devow uznalo, ze to jest passe? Phi…
IMHO to bardzo dobrze, ze w ogl jest wiele spobow na zrobienie tego samego (glBegin, listy wierzcholkow, bufory, itp.), przez analogie – nie oplaca sie wsiadac w samochod, zeby pojechac do sklepu po drugiej stronie ulicy, ale do innego miasta na piechote bym nie szedl 🙂
A wy zdajecie sie mowic "po co komu chodniki, i tak wszyscy jezdza samochodami, a taki chodnik, to zmniejsza szerokosc ulicy i zmniejsza ogolna wydajnosc jazdy samochodow." 🙂
Listy wyświetlania też są już passe ;), zresztą w OpenGL 3.0 oznaczone jako przestarzałe.
Ja z drugiej strony nie rozumiem ludzi, którzy "na szybko" klepią masę glVertex3f() w różnych miejscach, zamiast, po prostu zrobić sobie małą funkcję, która czy to na buforach czy to na czym kolwiek innym wrzuci im jakąś testową geometrię przy każdym wywołaniu…
Nie bo niewydajne, tylko bo emulowane, i do niczego nie potrzebne. Ponadto czyni krzywdę początkującym. Ewetualnie wyrzuciłbym do zewnętrzenje biblioteki, chociaż nie wiem po co, bo każdy rozwijany i zarazem na tyle złożony projekt, by był sens zabawy w zgodność w dół, już z tego wyrósł.
Czy moglbys odpowiadac pod komentarzem na ktory udzielasz odpowiedzi?
I w jaki sposob czyni krzywde poczatkujacym? IMHO to wlasnie wywalenie tego uczyniloby im najwieksza krzywde. Tak jak teraz, pierwszy przyklad na ktorym kazdy sie uczy ogla, kolorowy trojkacik, rysuje sie w 8 linijkach, ktore sa jasne i oczywiste. Kod przekazywania listy wierzcholkow jest mimo wszystko bardziej skomplikowany i odstraszajacy.
Jesli uwazasz, ze "krzywda" to fakt, ze potem niektorzy nie uzywaja wydajniejszych metod i przez to mamy niewydajne programy, to przy usunieciu tych funkcji mialbys mase ludzi, ktorzy ogla w ogole nie dotkneli, a po zobaczeniu tego pierwszego przykladu ich odrzucilo i teraz wszystkim opowiadaja, jaki to ten OpenGL jest trudny…
A ze czasem i glBegin jest potrzebny, napisalem w komentarzu wyzej.
I zakoncze tak jak tamten – jak ci nie potrzebny, to nie uzywaj, ale czego chcesz zabierac mozliwosc innym?
To nie takie proste. Gdyby istnienie tych funkcji nie wpływało na resztę to mogłyby pozostać, ale ich istnienie ma poważny wpływ na poziom skomplikowania sterowników.
Z drugiej strony po co ludzie mają się uczyć rzeczy, których w przyszłości nie będą wykorzystywali, zakładam tutaj, że OpenGL jest stworzony do pisania trochę większych rzeczy niż proste wygaszacze.
Szkoda, chciałem rozpoczac nauke OpenGL po wyjsciu 3.0, ale nie tego sie spodziewalem 🙁 W sumie nie dziwie sie tym ludziom co krzycza, ze opengl umarlo i przechodza na DirectXa. No nic, widze ze jak chce pisac wieloplatformowo to nie ma wyjscia, trzeba sie meczyc(?) z openglem. Bo na cos nowego to nawet nie ma co liczyc, a juz napewno nie w najblizszym czasie.
Hm, a to ilu ludzi pisze bezpośrednio w OpenGL? Nie stosuje się zazwyczaj jakichś gotowców, np. silników, widżetów i innych toolboksów? (Pytam bo nie wiem i się dziwię, a nie się kłócę).
Nie, w OpenGL generalnie pisze się dość wygodnie. Problem w tym, że w obecnym API jest mnóstwo niepotrzebnych rzeczy, których nikt z doświadczonych programistów już nie używa, a nowicjusze się w tym gubią bo nie wiedzą do końca co jest istotne a co nie oraz jak poprawnie i efektywnie implementować dotychczasowe rozwiązania, bo do wielu rzeczy trzeba sobie po prostu teraz napisac własny shader i trzeba wiedziec jak on powinien działać.
Między innymi, choć jest tego więcej. Części staroci nie oznaczono jeszcze jako deprecated bo wchodzi w zależności z innymi częściami w potoku i nie ma póki co lepszej alternatywy.
Co do nowicjuszy, to trzeba przede wszystkim zacząć pisać dobre tutoriale, które będą traktowały jedynie o nowej funkcjonalności, opisywały dokładnie środowisko shaderów, tłumaczyły ludziom na czym polegają transformacje (bo operacje macierzowe, obroty, przesumięcia realizowane przez OpenGL na poziomie komend też już są przestarzałe).
Nie ma się co czarować, te wszystkie rozwiązania są przede wszystkim do zastosowań profesjonalnych, i nikt nie będzie dla czyjejś wygody szedł na kompromisy, a obecny trend w kierunku programowalnego potoku z jednej strony daje większe możliwości, ale z drugiej wymaga wiekszej wiedzy nie tylko nt. obsługi samego API ale programowania grafiki w ogóle.
"Meczyc sie z OpenGLem" ? Odkad zaczalem uzywac tej biblioteki kilka lat temu, tworzenie grafiki stalo sie lekkie, latwe i przyjemne 🙂
Ja zupelnie nie rozumiem tych ludzi, co krzycza o smierci OpenGLa – to pewnie ci sami, co krzycza, ze na linuksa nie ma gier i robia to tylko w celu wzbudzania flejmow.
A zwykle ludzie, ktorzy cokolwiek krzycza o DirectX (chociaz maja na mysli Direct3D) i OpenGL, to ludzie, ktorzy poznali jedna z tych bibliotek i nie chce im sie uczyc drugiej :]
pbuffer – WGL_ARB_pbuffer. Ale wspolczesnie juz sie ich nie uzywa. Sa malo wydajne. Ich funkcjonalnosc ( i duzo wiecej ) oferuja FBOs. A co OGL 3.0? Tworcy DX 10 mogli sobie pozwolic na male szalenstwo – API Microsoftu w nowej wersji jest calkowicie przebudowane a zmiany sa wrecz rewolucyjne. OGL uwiera 'zgodnosc wstecz', dlatego nie moga np usunac calkiem stalego potoku grafiki ( co zrobiono w DX). Ale obiektywnie … DX 10 jest naprawde dobrze przemyslany ( i Vista only, ale to inna sprawa). To, co OpenGL 3.0 oferuje, to wykorzystanie mozliwosci nowyc h kart graficznym z innymi systemami operacyjnymi niz MS Windows Vista.
OpenGL przetrwa. Nie jest może najlepszym API, ale za to niespodziewanie rośnie mu grunt pod nogami w postaci lawinowo rosnącej popularności systemów typu free software, oraz urządzonek typu ipody, GPSy itd. Zamiast słuchać niestrudzonych futurologów i największych nawet guru (taki pan Carmack na przykład), wystarczy uważnie obserwować małolatów ;).
Dodaj komentarz