Názory k článku
Standard OpenGL 3.1 byl zveřejněn
-
masi (neregistrovaný)Hmmm, prave. To Open tam neznamena "open source" ale to, ze si do te knihovny muze kde kdo pridavat svoje funkce (extensions), bez toho, ze by tyto extensions byly nejak centralne spravovane. Takze pokud napr. chcete ulozit a obnovit obsah offscreen bufferu (coz je dost zasadni vec treba u ruznych 3D editoru), tak v zakladu OpenGL na to funkce neni, ale mate asi pet extensions od ruznych implementatoru (wgl, argb, nvidia a ja nevim co jeste) a pro co nejvetsi kompatibiiltu musite implementovat vsechny (5x vic prace, 5x vic testovani) a stejne nemate zaruceno, ze to pojede uplne vsude. Takze zrovna tady to OPEN zadna vyhra neni... Mimochodem, celkem by me zajimalo jestli zrovna toto uz resi verze 3.
-
Hlavně OpenGL a Direct3D (část DirectX) nemají stejné uplatnění. OpenGL je přehledné a standardní rozhraní pro profesionální grafické aplikace. Funguje na velkém množství platforem.
Oproti tomu Direct3D má vhodné využití u počítačových her, kde opravdu poskytuje více funkcionalit než obecněji zaměřené OpenGL. Direct3D je ale proprietární technologií Microsoftu a trpí tedy tradiční platformní omezeností. Podobně jako u jiných technologií sází Microsoft na využití jejího potenciálu běžnými uživateli. Z pohledu profesionála je ale DirectX jakousi hračkou využitelnou pouze na herních konzolích Microsoftu. -
masi (neregistrovaný)Hmmm, ja si teda takto navrzene rozhrani pro "profesionalni" aplikace nepredstavuji. Je sice docela prehledne a snadno pouzitelne, ale ma dost znamych nedostatku a ja nechapu, proc za ta leta uz nejsou opravene.
Dam priklad. Chci udelat v OpenGL jednoduchy 3D editor (cehokoliv). Nejakou slozitou 3D scenu vykreslim do backbufferu a pri tahu mysi chci, aby se pres tuto scenu za mysi vykreslil "selectovaci" ramecek. Je jasne, ze kreslit tu slozitou 3D scenu pri kazdem pohybu mysi je blbost, kdyz se meni prave jenom ten 2D rameckem. Takze vas napadne myslenka si pred kreslenim 2D ramecku tu vyrenderovanou scenu ulozit nekam do pomocneho bufferu a pri pohybu mysi pouze obnovit tento buffer a nakreslit pres nej 2D ramecek. Myslenka hezka, logicka a primocara, myslim, ze temer kazdy 3D cad ji nejak implementuje. Ovsem, zkuste si toto v OpenGL, rozhrani pro "profesionalni" aplikace implementovat a budete si rvat vlasy a tlouct hlavou do zdi. Duvod jsem pospal zde:
http://www.root.cz/zpravicky/standard-opengl-3-1-byl-zverejnen/261232/
P.S: V OpenGL 3.1 je zminka o pridani neceho cemu rikaji "CopyBuffer API". Hmm, jestli je to konecne ono, vsechna cest. Melo to tam byt uz tak pred 20lety... -
OpenGL má mnoho existujících implementací, za kterými stojí velké firmy, a tak se jakákoliv úprava standardu prosazuje celkem těžko. Skutečnost, že se zdánlivě primitivní věc jako je kopírování bufferu musela doteď řešit pomocí nestandardních a vzájemně nekompatibilních rozšíření může zřejmě tato nepružnost standardu vysvětlit. Ale jako člověk, který si před pár lety pročetl jen pár tutoriálů od NeHe Productions a zkoušel si programovat v OpenGL jen nějaké velmi primitivní věci k tomu asi víc neřeknu. "CopyBuffer API" by toto měl nejspíš řešit. Zdá se, že prosazení této věci do OpenGL 3.1 asi výrazně pomohlo očekávané využití OpenCL. Tam bude sdílení bufferů hrát základní roli a představa, že by se to nadále řešilo přes různá rozšíření by asi v praxi neobstála.
-
masi (neregistrovaný)To je. Chcete poradit?
Ne vazne, pokud opravdu mate elegantni reseni vyse popsaneho problemu, sem s nim, velice rad se priucim. Ale obavam se, ze jenom hloupe placate a vubec nevite o cem. Kdyby to opravdu bylo tak jednoduche, nevytvarely by se ty vzajemne nekompatibilni extensiony a nemely by s timto problemy i profesionalni CADy. -
Tak dnes už elegantní řešení existuje — framebuffer objekty (FBO). Ty jsou součástí OpenGL od verze 3.0 (a pro starší verze lze použít standardní rozšíření GL_ARB_framebuffer_object).
Dříve šlo pro tyto účely použít pbuffery, což ale, máte pravdu, bylo problematičtější, např. kvůli tomu, že standardní rozšíření existuje pouze pro Windows (WGL_ARB_pbuffer). -
masi (neregistrovaný)Vidite, dekuji za informaci, je to uz asi ctyri roky, co jsem se tim zabyval, specifikaci opengl 3 jsem necetl. Tak aspon ze neco vyresili.
Ovsem ted je na vas, jestli kvuli tomu budete pro svou aplikaci vyzadovat opengl3.0, ktere je extremne mlade (napr. ATI jej ma pod linux snad 2 mesice, nvidia jen o chvilku dele) a defaultne neni snad v zadne distribuci.
GL_ARB_framebuffer_object rozhodne neni standardni rozsireni (resp. je, ale neni spoleh, ze bude vzdycky k dispozici), alespon zde pisou, ze treba do nvidiackych driveru bylo pridano az s prichodem opengl 3.0, tzn. v driverech (180.x). Predtim tam bylo jedno nestandardni (GL_EXT_framebuffer_object). Takze to taky nic neresi(ne elegatne).
http://www.nvnews.net/vbulletin/showthread.php?t=125396
Tzn. ano, jde to udelat, ja jsem netvrdil ze ne, ale je to silene, protoze kdyz si ty extensiony spocitate, mate jich uz aspon pet a vsechny musite implementovat a odladit na konkretnim hw protoze nevite, ktere na cilovem hw zrovna bude. A od API pro "profesionalni" aplikace bych teda cekal vetsi komfort. Alespon ze to ta verze 3 resi standardne (jen skoda ze prisla tak o osm let pozde). -
masi (neregistrovaný)Prave ze neslo. OpenGL (alespon verze 2) zadne takove kompozitovani bufferu neumoznuje (resp. ne bez nejake vendor-specific extensions, je mozne ze nejake kresleni primo do textury existuje, ale protoze je to zase zavisle na konkretni implementace, nic to neresi) a po provedeni glSwapBufefers() je obsah backbufferu znicen a musi se cely vytvorit znovu. Pokud si ho teda nezazalohujete, coz je to, prave to co me tak chybi (a rozhodne nejen me).
-
beer (neregistrovaný)neni to omezeni pouze pro staticke sceny? pokud je rendering sceny tak narocny, ze ji nelze vykreslovat pri kazdem snimku, nestacilo by pouze nacist buffer pres glReadPixels, vygenerovat texturu pres glTexImage2D, nasledne vykreslit billboard a uz jen si hrat? je to nastrel z hlavy, ale mohlo by to fungovat..
-
masi (neregistrovaný)Zkousel jsem to, ale to z nejakeho duvodu neslo. Myslim, ze protoze, ze glReadPixels je neunosne pomaly. A celkem logicky i musi, protoze timto postupem budete presouvat data z RAMy GPU do RAMy CPU a pak zase zpet. Ted me neberte uplne vazne, tento problem jsem resil asi pred ctyrmi roky a tuhle metodu jsem musel zavrhnout, protoze byla pomalejsi, nez znovu vykresleni cele sceny. Treba se to zmenilo, ale moc bych na to nesazel. A i kdyby, zase muze byt vendor-specific (tzn. OpenGL od nvidie to ma rychly, od ATI ne), tzn. nic to neresi.
ČLÁNKY DO MAILU