Programmering

3D-grafikprogrammering i Java, del 3: OpenGL

Det er et stykke tid siden vores sidste rate i denne serie om 3D-grafikprogrammering i Java (mere om det i slutningen af ​​denne kolonne). Her er en hurtig opdatering på, hvad vi sidst diskuterede, og hvor vi slap.

I de to foregående kolonner (se Ressourcer) udforskede vi Java 3D. Vi diskuterede statisk indhold og små scener, brugte derefter større scenegrafer og indbyggede interaktivitet i nogle grundlæggende 3D-verdener.

Nu hvor du ved lidt om brug af Java 3D, er det tid til at sammenligne og kontrastere Java 3D-tilgangen til 3D-grafik med den førende grafik-API-konkurrent: OpenGL.

Bemærk, at denne artikel oprindeligt var beregnet til at være kodeintensiv, men den sene beslutning om Arcane Technologies vedrørende Magician-bindingen (se nedenfor) nødvendiggjorde fjernelse af kodeeksemplerne. Jeg håber, at denne artikels indhold kan tilpasses til en fremtidig Java-OpenGL-binding, som endnu ikke er tilgængelig fra OpenGL Consortium.

Under alle omstændigheder har jeg bestræbt mig på at levere alle de relevante og nyttige OpenGL-relaterede referencer og URL'er i ressourcerne i slutningen af ​​denne kolonne. Hvis du gerne vil grave videre i Java-OpenGL, anbefaler jeg stærkt, at du gennemgår disse referencer.

Java-OpenGL sammenligning med Java 3D

I tidligere afdrag på Java 3D gav jeg en liste over styrker og svagheder ved at bruge Java 3D til grafiske applikationer. Lad os gengive listen igen, men gør det ved at se på styrker og svagheder ved Java-OpenGL-baserede løsninger i stedet for Java 3D-baserede løsninger.

Styrkerne ved at bruge OpenGL (og i forlængelse af Java-OpenGL-bindinger, hvis det er angivet):

  • OpenGL giver en proceduremodel af grafik

    Dette stemmer tæt overens med mange af de algoritmer og metoder, som grafikprogrammerere har brugt historisk. Den proceduremodel er på en gang intuitiv og ligetil for mange dygtige 3D-grafik entusiaster.

  • OpenGL giver direkte adgang til gengivelsesrørledningen

    Dette gælder med nogen af ​​de forskellige sprogbindinger, inklusive de fleste Java-bindinger. OpenGL giver programmører mulighed for direkte at specificere, hvordan grafik skal gengives. Man gør ikke bare antydning og anmodning som med Java 3D, en bestemmer.

  • OpenGL er optimeret på alle tænkelige måder

    OpenGL er optimeret til hardware og software og målrettede platforme lige fra de billigste pc'er og spilkonsoller til de mest avancerede grafiske supercomputere.

  • Leverandører af enhver form for 3D-grafik-relateret hardware understøtter OpenGL

    OpenGL er

    det

    standard, mod hvilken hardwareleverandører måler deres grafikteknologi, spær ingen. Da Microsoft har tilsluttet sig SGI i Fahrenheit-initiativet, er det blevet mere og mere åbenlyst for mange, at dette faktisk er Microsofts indirekte anerkendelse af, at OpenGL vandt API-krige for 2D- og 3D-grafik.

På den anden side er intet perfekt. OpenGL og bestemt Java-OpenGL-bindinger har nogle betydelige mangler:

  • Styrken ved den proceduremæssige tilgang til grafisk programmering er samtidig en svaghed for mange Java-programmører

    For relativt nye programmører, hvoraf mange måske har modtaget deres første formelle programmeringsinstruktion i Java ved hjælp af objektorienterede metoder, åbner OpenGLs proceduremetode ikke godt sammen med en objektorienteret tilgang og god teknisk praksis.

  • Mange leverandørers OpenGL-optimeringer er beregnet til at mindske valg af hardware

    Det er i hver leverandørs bedste interesse at oprette proprietære udvidelser og foretage proprietære optimeringer for at sælge mere af sin egen hardware. Som med alle hardwareoptimeringer skal du bruge acceleratorspecifikke OpenGL-optimeringer med den forståelse, at hver optimering til en platform mindsker bærbarhed og ydeevne for flere andre. Java 3Ds mere generelle optimeringer har hovedsagelig til formål at maksimere bærbarheden af ​​Java 3D-applikationer.

  • Mens C-grænseflader til OpenGL er allestedsnærværende, er Java-grænseflader endnu ikke standardiserede og er ikke bredt tilgængelige

    Arcane Technologies Magician-produkt havde indtil for nylig været på markedet for at ændre dette bærbarhedsproblem, men med dets død går meget af den platformshistorie for Java-OpenGL, i det mindste i øjeblikket. Mere om dette nedenfor.

  • OpenGL's eksponering af de indre detaljer i gengivelsesprocessen kan komplicere ellers enkle 3D-grafikprogrammer betydeligt

    Kraft og fleksibilitet koster kompleksiteten. I de hurtige udviklingscyklusser i nutidens teknologiverden er kompleksitet i og for sig noget, der skal undgås, hvor det er muligt. Det gamle ordsprog om bugs er sandt: jo flere linjer med kode, jo flere bugs (generelt).

Som du kan se fra fordele og ulemper ved OpenGL-baserede tilgange, er Java-OpenGL stærk i mange af de områder, hvor Java 3D er svag. OpenGL giver programmører den lave adgang til den gengivelsesproces, som Java 3D eksplicit undgår, og OpenGL er i øjeblikket tilgængelig på langt flere platforme end Java 3D (tryllekunstner til side). Men denne fleksibilitet kommer med en potentiel pris: programmører har meget plads til at optimere, hvilket omvendt betyder, at de har meget plads til at skrue op. Java 3D har mere indbygget optimering og en lettere programmeringsmodel, der kan vise sig særlig nyttig for programmører, der er nye til Java, 3D-grafikarbejde eller netværksbaseret og distribueret grafikprogrammering.