Praėjo šiek tiek laiko nuo paskutinės šios serijos dalies, susijusios su 3D grafikos programavimu „Java“ (daugiau apie tai šio stulpelio pabaigoje). Čia yra greitas atnaujinimas apie tai, ką paskutinį kartą aptarėme ir kur palikome.
Ankstesniuose dviejuose stulpeliuose (žr. Ištekliai) tyrėme „Java 3D“. Aptarėme statinį turinį ir mažas scenas, tada panaudojome didesnius scenų grafikus ir integravome interaktyvumą į kai kuriuos pagrindinius 3D pasaulius.
Dabar, kai šiek tiek žinote apie „Java 3D“ naudojimą, laikas palyginti ir palyginti „Java 3D“ požiūrį į 3D grafiką su pagrindiniu grafikos API varžovu: „OpenGL“.
Atkreipkite dėmesį, kad šis straipsnis iš pradžių buvo skirtas daug kodų reikalauti, tačiau dėl vėluojančio „Arcane Technologies“ sprendimo dėl mago įrišimo (žr. Toliau) reikėjo pašalinti kodų pavyzdžius. Tikiuosi, kad šio straipsnio turinį bus galima pritaikyti būsimam „Java-OpenGL“ įrišimui, kurio dar negalima gauti iš „OpenGL Consortium“.
Bet kokiu atveju aš stengiausi pateikti visas svarbias ir naudingas su „OpenGL“ susijusias nuorodas ir URL šio stulpelio pabaigoje esančiuose šaltiniuose. Jei norite gilintis į „Java-OpenGL“, labai rekomenduoju peržiūrėti šias nuorodas.
„Java-OpenGL“ palyginimas su „Java 3D“
Ankstesnėse „Java 3D“ dalyse pateikiau „Java 3D“ naudojimo grafikos programoms privalumų ir trūkumų sąrašą. Pakartokime šį sąrašą iš naujo, bet darykite tai ne „Java 3D“, o „Java-OpenGL“ pagrįstų sprendimų stipriąsias ir silpnąsias puses.
Stiprybės naudojant „OpenGL“ (ir išplėtus ir kur pažymėta, „Java-OpenGL“ susiejimus):
„OpenGL“ pateikia procedūrinį grafikos modelį
Tai labai atitinka daugelį algoritmų ir metodų, kuriuos grafikos programuotojai naudojo istoriškai. Procesinis modelis daugeliui 3D grafikos mėgėjų yra intuityvus ir paprastas.
„OpenGL“ suteikia tiesioginę prieigą prie atvaizdavimo dujotiekio
Tai pasakytina apie bet kurį iš įvairių kalbos įrišimų, įskaitant daugumą „Java“ susiejimų. „OpenGL“ suteikia programuotojams galimybę tiesiogiai nurodyti, kaip turėtų būti atvaizduojama grafika. Vienas ne tik užuomina ir prašymą kaip ir „Java 3D“, vienas numato.
„OpenGL“ yra optimizuojamas visais įmanomais būdais
„OpenGL“ yra optimizuota aparatinėje ir programinėje įrangoje bei tikslinėse platformose, pradedant pigiausiais asmeniniais kompiuteriais ir žaidimų konsolėmis bei baigiant aukščiausios klasės grafikos superkompiuteriais.
Visų rūšių 3D grafikos aparatūros pardavėjai palaiko „OpenGL“
„OpenGL“ yra
standartas, pagal kurį aparatūros gamintojai matuoja savo grafikos technologiją, nėra juostos. Kai „Microsoft“ prisijungė prie SGI įgyvendindama „Fahrenheit“ iniciatyvą, daugeliui tapo vis akivaizdu, kad tai iš tikrųjų yra „Microsoft“ netiesioginis pripažinimas, kad „OpenGL“ laimėjo API karus dėl 2D ir 3D grafikos.
Kita vertus, niekas nėra tobulas. „OpenGL“ ir, be abejo, „Java-OpenGL“ susiejimai, turi keletą reikšmingų trūkumų:
Procesinio požiūrio į grafikos programavimą stipriosios pusės yra daugelio „Java“ programuotojų silpnybė
Santykinai naujiems programuotojams, iš kurių daugelis galėjo gauti savo pirmąją oficialią programavimo instrukciją „Java“ sistemoje, naudodami objektu pagrįstas metodikas, „OpenGL“ procedūrinis metodas nėra tinkamas objektiniam požiūriui ir gerai inžinerijos praktikai.
Daugelio pardavėjų „OpenGL“ optimizavimas skirtas sumažinti aparatūros pasirinkimą
Kiekvieno pardavėjo interesas yra sukurti nuosavų plėtinių kūrimą ir patentuotą optimizavimą, kad būtų galima parduoti daugiau savo aparatūros. Kaip ir visuose aparatūros optimizavimuose, turite naudoti specifinius greitintuvų „OpenGL“ optimizavimus, suprasdami, kad kiekvienas vienos platformos optimizavimas sumažina keleto kitų perkėlimą ir našumą. „Java 3D“ bendresnio pobūdžio optimizavimais daugiausia siekiama maksimaliai padidinti „Java 3D“ programų perkeliamumą.
Nors C sąsajos su OpenGL yra visur, „Java“ sąsajos dar nėra standartizuotos ir nėra plačiai prieinamos
„Arcane Technologies“ „Magician“ produktas dar neseniai buvo rinkoje, kad pakeistų šią perkeliamumo problemą, tačiau, žlugus, bent jau šiuo metu didžioji dalis „Java-OpenGL“ platformos yra „platformos“ istorija. Daugiau apie tai žemiau.
„OpenGL“ atvaizdavus vidines atvaizdavimo proceso detales, gali gerokai pasunkėti šiaip paprastos 3D grafikos programos
Galia ir lankstumas kainuoja sudėtingumo kainą. Greitame šiuolaikinio technologijų pasaulio vystymosi cikle sudėtingumo savaime reikia vengti, jei įmanoma. Senas posakis apie klaidas yra teisingas: kuo daugiau kodo eilučių, tuo daugiau klaidų (apskritai).
Kaip matote iš „OpenGL“ pagrįstų metodų privalumų ir trūkumų, „Java-OpenGL“ yra stipri daugelyje sričių, kuriose „Java 3D“ yra silpna. „OpenGL“ suteikia programuotojams žemą prieigą prie atvaizdavimo proceso, kurio „Java 3D“ aiškiai vengia, o „OpenGL“ šiuo metu yra daug daugiau platformų nei „Java 3D“ (be mago). Tačiau šis lankstumas susijęs su potencialia kaina: programuotojai turi daug vietos optimizavimui, o tai, atvirkščiai, reiškia, kad jie turi daug vietos viską išspręsti. „Java 3D“ turi daugiau integruotų optimizavimo galimybių ir lengvesnį programavimo modelį, kuris gali pasirodyti ypač naudingas programuotojams, naujiems „Java“, 3D grafikos darbams ar tinklo ir paskirstytam grafikos programavimui.
