Det har gått en stund siden vår siste del i denne serien om 3D-grafikkprogrammering i Java (mer om det på slutten av denne kolonnen). Her er en rask oppdatering på hva vi sist diskuterte og hvor vi slapp.
I de to foregående kolonnene (se Ressurser) utforsket vi Java 3D. Vi diskuterte statisk innhold og små scener, og brukte deretter større scenediagrammer og bygget interaktivitet i noen grunnleggende 3D-verdener.
Nå som du vet litt om bruk av Java 3D, er det på tide å sammenligne og kontrastere Java 3D-tilnærmingen til 3D-grafikk med den ledende grafikk-API-konkurrenten: OpenGL.
Vær oppmerksom på at denne artikkelen opprinnelig var ment å være kodekrevende, men den avgjørende avgjørelsen fra Arcane Technologies angående Magician-bindingen (se nedenfor) nødvendiggjorde fjerning av kodeeksemplene. Jeg håper innholdet i denne artikkelen kan tilpasses for en fremtidig Java-OpenGL-binding, ennå ikke tilgjengelig fra OpenGL Consortium.
I alle fall har jeg forsøkt å oppgi alle relevante og nyttige OpenGL-relaterte referanser og URL-er i ressursene på slutten av denne kolonnen. Hvis du vil grave nærmere i Java-OpenGL, anbefaler jeg sterkt at du går gjennom disse referansene.
Java-OpenGL sammenligning med Java 3D
I tidligere avdrag på Java 3D ga jeg en liste over styrker og svakheter ved å bruke Java 3D til grafiske applikasjoner. La oss gjenta den listen, men gjør det ved å se på styrker og svakheter ved Java-OpenGL-baserte løsninger i stedet for Java 3D-baserte løsninger.
Styrken ved å bruke OpenGL (og i forlengelse av Java-OpenGL-bindinger)
OpenGL gir en prosessuell modell av grafikk
Dette samsvarer nøye med mange av algoritmene og metodene grafiske programmerere har brukt historisk. Prosedyremodellen er samtidig intuitiv og grei for mange dyktige 3D-grafikere.
OpenGL gir direkte tilgang til gjengivelsesrørledningen
Dette gjelder med noen av de forskjellige språkbindinger, inkludert de fleste Java-bindinger. OpenGL gir programmerere muligheten til direkte å spesifisere hvordan grafikk skal gjengis. Man gjør ikke bare hint og be om som med Java 3D, en fastslår.
OpenGL er optimalisert på alle tenkelige måter
OpenGL er optimalisert innen maskinvare og programvare og målrettede plattformer, alt fra de billigste PC-ene og spillkonsollene til de mest avanserte grafiske superdatamaskiner.
Leverandører av alle slags 3D-grafikkrelatert maskinvare støtter OpenGL
OpenGL er
de
standard som maskinvareleverandører måler grafikkteknologien mot, sperrer ingen. Ettersom Microsoft har sluttet seg til SGI i Fahrenheit-initiativet, har det blitt stadig tydeligere for mange at dette faktisk er Microsofts indirekte erkjennelse av at OpenGL vant API-krigene for 2D- og 3D-grafikk.
På den annen side er ingenting perfekt. OpenGL, og absolutt Java-OpenGL-bindinger, har noen betydelige mangler:
Styrken i den prosessuelle tilnærmingen til grafisk programmering er samtidig en svakhet for mange Java-programmerere
For relativt nye programmerere, hvorav mange kan ha mottatt sin første formelle programmeringsinstruksjon i Java ved hjelp av objektorienterte metoder, passer ikke OpenGLs prosessmetode godt med en objektorientert tilnærming og god ingeniørskikk.
Mange leverandørers OpenGL-optimaliseringer er ment å redusere maskinvarevalget
Det er i hver leverandørs beste interesse å bygge proprietære utvidelser og foreta proprietære optimaliseringer for å selge mer av sin egen maskinvare. Som med alle maskinvareoptimaliseringer, må du bruke akseleratorspesifikke OpenGL-optimaliseringer med den forståelse at hver optimalisering for en plattform reduserer bærbarhet og ytelse for flere andre. Java 3Ds mer generelle optimaliseringer har som mål å maksimere bærbarheten til Java 3D-applikasjoner.
Mens C-grensesnitt til OpenGL er allestedsnærværende, er Java-grensesnitt ennå ikke standardiserte og er ikke allment tilgjengelige
Arcane Technologies Magician-produkt hadde til nylig vært i markedet for å endre dette bærbarhetsproblemet, men med sin død går mye av den plattformsberettigede historien for Java-OpenGL, i det minste i dag. Mer om dette nedenfor.
OpenGLs eksponering av de indre detaljene i gjengivelsesprosessen kan komplisere ellers enkle 3D-grafikkprogrammer betydelig
Kraft og fleksibilitet koster kompleksiteten. I de raske utviklingssyklusene i dagens teknologiverden er kompleksitet i seg selv noe som skal unngås der det er mulig. Det gamle ordtaket om feil er sant: jo flere linjer med kode, jo flere feil (generelt).
Som du kan se fra fordeler og ulemper for OpenGL-baserte tilnærminger, er Java-OpenGL sterk i mange av områdene der Java 3D er svak. OpenGL gir programmerere tilgang på lavt nivå til gjengivelsesprosessen som Java 3D eksplisitt unngår, og OpenGL er for tiden tilgjengelig på langt flere plattformer enn Java 3D (Magician til side). Men denne fleksibiliteten kommer med en potensiell pris: programmerere har mye rom for å optimalisere, noe som omvendt betyr at de har mye plass til å skru opp tingene. Java 3D har mer innebygd optimalisering og en enklere programmeringsmodell som kan være spesielt nyttig for programmerere som er nye for Java, 3D-grafikkarbeid eller nettverksbasert og distribuert grafikkprogrammering.
