Sta raditi sa nedostajucim ekstenzijama u OpenGL-u???

Koja je fora sa ekstenzijama u OpenGL?
Da li su one hardverski podrzane ili su to softverska resenja za neke od efekata u GL-u (npr. Bump mapping )?
Sta raditi kada nekom programu nedostaje ekstenzija? Ogoogleovati ili...?
Kako je koristiti? Probao sam da skinem neke fajlove (glext.h na primer) ali nista se ne desava kada kompajliram prog?

Potpis

EOF

To da li su hardverski ili softverski ili uopšte podržane zavisi od implementacije, najčešće su te funkcije hardverski podržane od strane opengl drivera za tvoju video karticu. E sad, nije ih dovoljno kako sam zaključio da misliš iz tvog posta samo "uključiti" i voila - bumpmapping :) , potrebno je malo više poznavanja i programiranja da bi se uz željene ekstenzije napravio i efekat koji želiš. Savetujem da pogledaš neke tutorijale, pre svega uopše o ekstenzijama (kako se koriste, kako saznati da li neka ekstenzija postoji u implementaciji koju koristiš i sl.), a zatim i neki tutorial o konkretnoj ekstenziji koju želiš da koristiš.

Potpis

Lepota je u jednostavnosti.

Cis.

Mehanizam sa extenzijama u OpenGL-u je napravljen da bi proizvodjaci grafickih kartica mogli da omoguce programerima da koriste nove mogucnosti grafickih kartica. To znaci da extenzije podrzava OpenGL implementacija (tj. driver), a korisnik ne moze da sam napise extenziju, vec samo moze da koristi postojece.

SGI je svojevremeno osnovao ARB (Architectural Review Board) grupu koja vodi racuna u evoluciji OpenGL API-a. Oni odlucuju koji se od novih efekata standardizuju i vremenom ubacuju te efekte u OpenGL core i najzad objave specifikaciju nove verzije OpenGL-a.
Verzije su: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.5.1, 1.5.2 i uskoro 2.0.

Zivotni put neke extenzije pocinje od proizvodjaca graficke kartice. U tom trenutku extenzija u svom imenu ima oznaku proizvodjaca SGI, ATI, NV,... Kasnije, razni proizvodjaci prihvataju extenzije od drugih proizvodjaca i tada extenzija dobija u imenu EXT. Kada ARB grupa prihvati extenziju i standardizuje je onda se u imenu doda ARB.

Kako se koriste extenzije? Na zalost, pod Windowsom M$ ne zeli da objavi novu verziju OpenGL32.lib i podrzan se samo OpenGL 1.1. Medjutim moguce je koristiti i v1.5.2 mapiranjem novih gl funkcija pomocu wglGetProcAddress. Malo je dosadno pisati sva ta mapiranja pa su ljudi poceli da pisu male cpp programe koji se samo ukljuce u projekat i ceo code za mapiranje je gotov. Potrazi GLEW na googlu ili skini moju verziju iz poruke i procitaj uputstvo.

Ima jos jedna sitnica... Ako zelis da koristis neku extenziju onda kartica na kojoj radis mora da podzava tu extenziju. Znaci.. ako zelis da se igras sa pixel shaderima onda moras da imas najmanje npr. FX5200.

glext.h je samo header file u kome su opisani prototipovi novih gl funkcija. impementacija je zakopana negde duboko u driveru...

yooyo

Yooyo, ako nisi znao da te obradujem izašla je 2.0 specifikacija.

Potpis

Lepota je u jednostavnosti.

Cis.

Znam.. znam.. samo jos driver da izadje...

yooyo

A najzanimljiviji feature OpenGLovog extension mehanizma je to sto je implementiran u drajveru tako da funkcionalnost i bagovi zavise od proizvodjaca i od revizije drajvera. Jos je lepse kada pocnes da radis sa stvarima koje su iole komplikovane (recimo shaderi) i kada kompajler krene da zavisi od konkretne verzije drajvera koja je instalirana kod klijenta. Mmmm, cudo jedno za support.

To je otprilike i razlog zasto danas postoji samo jedan jedini komercijalni engine za OpenGL - kako bi inace hardware vendori radili support? ;)

Salu na stranu, poenta je da se pazis kod ekstenzija - na milosti i nemilosti si puno razlicitih firmi, i ono sto radi ovde ne znaci da ce da radi i tamo.

Ma da.. DX rulez... samo sto moras da za svaku novu verziju DX-a bacis stari code i sve ponovo napises, radi samo na Windows-u i XB-u, cak ako imas novi driver to ne znaci da ces moci da koristis sve DX9 efekte,...
Ono sto cenim kod OpenGL-a je sto neke efekte mogu da izvedem na nekoliko nacina dok u DX-u za iste efekte postoji jedan jedini nacin.

@Reljam
Ajde da ne zapocinjemo flaming...

yooyo

Ja sam radio sa OpenGL i Direct3D i još uvek koristim oba. Sada OpenGL koristim u za prototip projekte, kada neću previše da se cimam sa grafikom, nego mi samo treba nešto da se crta na ekranu. D3D je mnogo bolji za komercijalne projekte posebno kada se dođe do rešavanja problema oko kompatibilnosti. Takođe izdavači više vole kada developer koristi D3D, jer na taj način imaju manje problema oko customer service-a. Sve igre koje sam radio (osim FSW) su imale podršku za OpenGL, ali zbog izdavača i problema oko kompatibilnosti smo morali da podržavamo i Direct3D.

Inače DX je postao mnogo bolji što se tiče bacanja koda, i razlika između DX8 i DX9 je beznačajna (DX8 kod se prebaci u DX9 u roku od par sati).

Branimir

Potpis

https://github.com/bkaradzic/bgfx

Upravo tako. Sa svima sa kojima sam pricao na GDCu i E3u (dobro, i Meltdownu, ali oni su biased ) su ispricali istu pricu. Kompatibilnost je najbitnija stvar za komercijalne projekte. Uostalom, to se vidi i po trzistu

A sto se tice bacanja koda, pa to jeste nazalost nezgodno, ali je uglavnom i potrebno - svaki put kada se promeni API to se radi sa dobrim razlogom, i uvek se dobije neki % brzine zauzvrat. Ideja je da:

1) Layer koji prica da D3Dom u bilo kom ozbiljnijem engineu je dovoljno mali da nije veliki problem promeniti ga ako treba.

2) Nema potrebe DX8 engine prebacivati na DX9 ako je taj engine namenjen za tu generaciju video kartica. Samo zato sto izadje nov DX ne znaci da svi treba da predju na njega odmah, pogotovu projekti koji su vec u razvoju.

3) Ako je to neki engine koji treba da se koristi na duze vreme, onda vazi ono pod jedan. Samo enginei koji imaju dugorocnu upotrebnu vrednost treba da se prebacuju na novu verziju DXa.

Naravno, posto ce se graficke kartice od 2005. toliko radikalno promeniti, bice neophodno i radikalno promeniti API.

@yooyo
Fallback na softverski rendering je neprihvatljiv za komercijalne projekte, tako da to sto GL to moze da uradi ne znaci ama bas nista za igre.

@Reljam:
Fallback na softverski rendering je neprihvatljiv za komercijalne projekte, tako da to sto GL to moze da uradi ne znaci ama bas nista za igre.

Nisam ni mislio na fallback u sw render... Mislio sam npr na crtanje jednostavne grafike, tipa GUI ili nekakav prost model. U D3D-u se za svaku sitnicu mora koristiti VB, dok u GL-u moze da se koristi stari metod vertex po vertex.
U svakom slucaju programer mora pisati razlicite nacine renderinga (codepath's) ako zeli da mu igrica radi na skoro svim karticama. Ako korisnik ima instaliran DX90c to ne znaci da ce moci da njegov hw moci da izvrsava sve DX90c efekte.

Generalno.. vise bih voleo da je MS iskoristio sve prednosti COM-a i napravio API koji ima mehanizam slican extenzijama.
Npr... p_D3DDevice->QueryInterface(IID_NekiNoviFeature,...) i ako implementacija podrzava feature dobice interface na nove funkcije ili NULL ako nema. Na taj nacin programeri mogu da zadrze stari code a istovremeno da koriste i nove efekte. Ne vidim razlog zasto ovako nesto nisu planirali.

I jos nesto...

Poll na NV developer site-u:
API usage:
OpenGL - 46.31%
DirectX - 38.42%
Both OpenGL and DirectX - 15.27%


yooyo

Yooyo, koliko novih openGL igara znas koje nisu bazirane na id-ovom engineu? GL ima jako mali deo trzista.

A za ovo sto si rekao sa QIom i ekstenzijama mnogo gresis. MS ima mailing listu koja sluzi za savete prilikom stratesih odluka, na njoj je who's who grafike. Ljudi hoce upravo suprotno od toga sto ti pricas - oni ne zele da imaju razlicite code pathove u igrama, a IHVovi zele da diferenciraju proizvede po necemu drugom. Vise code pathova je stetno za ISVove, a to je onda lose i za IHVove i za MS.

Dakle, toga vise nema. Ako imas priliku pogledaj WGF API spec, videces gde se krece grafika.

Apropos GLa: Naravno da GL nije los ili neupotrebljiv. Jako je dobar ako hoces da sa 3 jednostavne komande rotiras kocku na ekranu, ili ako hoces da uradis nesto kompleksnije prototipa radi sto ce da se vrti na tvom hardveru. GL drajveri su takodje optimizovani za line drawing i tu blistaju, znaci CAD aplikacije i slicno. Takodje je jako dobar ako si hardware vendor i ako zelis da eksperimentises sa najnovijom generacijom kartica koja nije podrzana u D3Du - to onda mozes da ekstendujes ekstenzijama i to super radi. To i objasnjava zasto na nVidia.comu imas 46% GL programa. Ali za komercijalne igre, GL dovoljno praktican. Problem je u implementaciji.

A inace u igrama se za sve koristi VBovi, zasto bi zeleo da saljes podatke za bilo sta preko AGPa? Ako vec pravis celu igru - covek-godine rada i tako to - nije tesko incijalizovati VB da bi imao lokalne podatke.

Do ovoga zaključka dođe svako ko je ikada trebao da objašnjava trade off za podršku nekih mogućnosti igre izdavaču. I igre i grafika u mnogome pate zbog ovoga. Bilo je mnogo jednostavnije u Glide danima, kada si tačno znao šta igrač ima u kompjuteru.

Ja sam jedan od zagovornika ukidanja i D3D CAPS-ova i strožije certifikacije proizvođača hardware-a. Tako da ne mogu da zalepe DX9 na kutiju i marketing materijal ukoliko im grafička kartica ne zadovoljava ceo standard (NE minimum, nego kompletno sve). Tako bi proizvođači igara znali čime raspolažu i ne bi morali da se lomatamo da smislimo način kako da podržavamo sve od DX7 do DX9 sa svim verzijama shadera između te dve verzije. Takođe grafička kartica bi trebala da ima minimum performansi koje mora da zadovoljava da bi ušla u željeni standard. Jer se do sada događalo da neko hackuje mogućnost da bi rekli da ih imaju, a u principu je neupotrebljiva. Ovakva strožija kontrola je praktično nemoguća sa otvorenim standardom tipa OpenGL.

OpenGL je zbog raznih ekstenzija postao previše haotičan... Iako je dizajn osnovnog API-ja bio daleko bolji od D3D (glavni deo OGL se nije menjao godinama, a D3D se menjao skoro svake godine). Mada u sadašnje vreme OpenGL pokazuje svoje godine.

Branimir

Potpis

https://github.com/bkaradzic/bgfx

Branimir je po obicaju potpuno u pravu. Kao da cita buducnost. Scary. :)

Najbolje bi bilo da Microsoft napravi svoju karticu i tako resi sve probleme...

yooyo

A kako ti mislis da se odredjuje feature set novih kartica? Da hardware vendori rade svako sta im dune?

Vidi, nikome u industriji nije u interesu da se ponove gluposti sa kraja proslog veka - gde svako pravi svoje, i onda posle igre moraju da imaju desetak code pathova da bi bilo sta uradili. To nije dobro za industriju kao celu, a ni za njene ucesnike.

Evo kako to funkcionise (barem po mom licnom iskustvu): MS napravi dizajn za feature set za novu generaciju hardvera, i onda se kroz seriju sastanaka sa vendorima ta specifikacija sredjuje sve dok se ne dodje do onoga sto bi oni mogli realisticno da urade. Onda oni rade na toj verziji, a proizvode diferencijaru po cemu god hoce ali ne i rendering featurima. Naravno sama implementacija je do vendora, i tu mogu itekako da se takmice.

Ono sto steti softver vendorima steti i hardver vendorima - jer ko ce da kupuje najnoviju karticu ako moze da igra igre na konzolama? Svima je u interesu da se ovakve stvari srede sto pre, i da softver vendori mogu da sa sto manje problema targetuju sto veci deo trzista.