Programmering

3D-grafikkprogrammering i Java, del 1: Java 3D

For å bygge en ekte Java-plattform, innså Sun tidlig at den trengte å fylle ut API-bildet utover den begrensede funksjonaliteten som er tilgjengelig i Java 1.0-kjerneplattformen. Sun har vokst kjernen mye med 1.1 og forestående 1.2 utgivelser, men det mangler fortsatt noen brikker i Java-puslespillet.

Sun og dets partnere utviklet Java Media and Communication API-er for å tilby de manglende multimedia-programmeringsbitene. To av de største brikkene, 2D og 3D-grafikk, er målrettet med henholdsvis Java 2D og 3D APIer. Java 2D er en kjerneplattform-API som begynner med Java 1.2, mens Java 3D vil bli utgitt som et utvidelses-API kort tid etter at 1.2-plattformen blir tilgjengelig. Vi har nylig avsluttet en serie kolonner på Java 2D; nå retter vi oppmerksomheten mot Java 3D.

Java 3D er ment å gi Java-utviklere muligheten til å skrive appletter og applikasjoner som gir tredimensjonalt, interaktivt innhold til brukerne. Sun har litt sterk konkurranse fra andre 3D-grafikkteknologier på denne arenaen, og Java 3D har en oppoverbakke kamp foran seg hvis det er å beseire den sittende grafiske standarden, OpenGL.

En forespørsel om leserkommentarer på 3D-grafikk-API-er for Java indikerte alvorlig interesse for Java 3D- og Java OpenGL-bindinger, så jeg har bestemt meg for å konsentrere meg om disse teknologiene de neste månedene.

En mer begrenset interesse ble uttrykt i VRML. Derfor skal jeg håndtere VRML ved å demonstrere bruken i Java 3D med VRML97 innholdslastere og Suns Java 3D VRML97-nettleser. Direct3D fikk veldig liten interesse, så jeg har bestemt meg for ikke å følge denne veien, bortsett fra å nevne hvor en av de andre teknologiene kan støtte eller samarbeide med den.

Fordeler og ulemper med Java 3D

Denne måneden begynner vi vår tur til API-er for 3D-grafikk for Java ved å utforske Java 3D. Vi begynner med å diskutere noen av APIens viktigste styrker og svakheter. 3D-grafikk kan til tider virke ganske stump og kan derfor være vanskelig å forklare. Hvis du har noen dvelende forvirring om eksemplene mine eller forklaringene mine, er du velkommen til å skrive meg med spørsmål eller kommentarer, så gjør jeg mitt beste for å ta opp dem.

Selger poeng for Java 3D:

  • Den gir en objektorientert visning av 3D-grafikk på høyt nivå. Java 3D oppnår dette delvis ved å bruke en scenegraf-basert 3D-grafikkmodell. (Vi vil diskutere dette konseptet mer detaljert senere i artikkelen.) Denne tilnærmingen er ment å hjelpe programmerere uten mye grafikk eller multimedia-programmeringserfaring med å bruke 3D i applikasjonene. I sterk kontrast til lavere nivå, prosessuelle 3D APIer som OpenGL, som er designet for å optimalisere for best mulig hastighet og gi programmerere størst mulig kontroll over gjengivelsesprosessen, er Java 3D ment å være grei nok til at enhver erfaren Java-programmerer kan lære.

  • Hvis du ikke trenger tilgang på lavt nivå til gjengivelsesoperasjoner, kan Java 3D være et alternativ. Gjengivelse av tilgang er begrenset til forespørsler via attributter og kapasitetsbiter, ligner i form og funksjon på Java 2Ds gjengivelsestips. (Se Ressurser for lenker til min forrige serie om Java 2D, som inkluderte diskusjon og eksempler på 2Ds gjengivelsestips).

  • Java 3D er optimalisert for hastighet der det er mulig. Kjøretiden bruker renderingskapasitetsbiter, faktisk for å optimalisere scenediagrammet for raskest mulig gjengivelse. Denne tilnærmingen gjør Java 3D mer anvendelig for interaktive grafiske miljøer (spill, simuleringer, situasjoner med lav latens) enn for frakoblede grafikkapplikasjoner av høy kvalitet (som gjengivelsesbruk).

  • Et stort og økende antall 3D-lastere er tilgjengelige for å importere innhold til Java 3D-kjøretiden. Sun har gjort en Java 3D VRML97-fillaster og nettleser fritt tilgjengelig med kode. Se etter neste måneds Medieprogrammering kolonne for å utforske Java 3D-lastere mer detaljert.

  • Java 3D krever vektormatematiske funksjoner som ikke er tilgjengelige andre steder i Java-plattformen. Disse matteoperasjonene ligger for tiden i javax.vecmath pakken og kan flyttes til kjerneplattformen i fremtiden.

  • Java 3D støtter en rekke eksotiske enheter (for eksempel wands, datahansker og headset). De com.sun.j3d.utils.trackers pakken som følger med Suns implementering, gir klasser for Fakespace, Logitech og Polhemus-enheter. Disse enhetene er imidlertid ikke mye brukt, så jeg vil ikke diskutere dem i detalj. Hvis du er interessert i å finne ut mer om enhetsstøtte, kan du se Suns Java 3D-nettsteder og Java 3D-adresselistearkivet (begge tilgjengelig fra de viktigste Sun Java 3D URL-ene som er inkludert i ressursene nedenfor).

Java 3D har mange fordeler, men hva med ulempene? De inkluderer:

  • Java 3D er et standardutvidelses-API. Java-plattformlisenser får muligheten til å implementere API hvis de vil, men de er ikke pålagt å implementere det. Java 3Ds posisjonering som en standardutvidelse risikerer å redusere bærbarheten til Java 3D-kode på tvers av plattformer - de fleste leverandører må slite med å holde tritt med endringer og tillegg til kjerneplattformen alene.

  • Java 3D har alvorlige tilgjengelighetsbegrensninger. Dette er resultatet av Java 3Ds status som utvidelses-API. Den eneste store leverandøren som for øyeblikket leverer en Java 3D-implementering, er Sun med implementeringene for Solaris og Win32. Sammenlignet med OpenGL, som er tilgjengelig for alle smaker av Unix, Windows og mange andre operativsystemer, ser den plattformsmessige bærbarheten av Java 3D-kode tvilsom ut.

  • Sammen med tilgjengelighetsproblemer med programvare kommer dokumentasjonsunderskudd. Sun gjør en tøff innsats for å gi utvikleropplæring og støtte for Java 3D, men den kommer fortsatt til kort sammenlignet med resten av bransjens innsats for å dokumentere OpenGL og bruken av den. OpenGL Consortiums nettsted er langt dypere og bredere enn noe Sun har klart å sette sammen for Java 3D så langt. Dette er ikke et mindre poeng: den relative kompleksiteten til 3D-grafikk-API-er gjør god dokumentasjon til en nødvendighet.

  • Java 3D gjemmer gjengivelsesrørledningsdetaljer fra utvikleren. Fordi Java 3D er et API på høyt nivå, skjuler det med vilje detaljer om gjengivelsesrørledningen fra utvikleren, noe som gjør den uegnet for et betydelig antall problemer der slike detaljer er viktige. (Vi diskuterer OpenGLs modell på lavere nivå og tilgang til gjengivelsesrørledningen senere i denne 3D-serien.)

  • Java 3D-komponenter er tunge. Det vil si at de har en innfødt (ikke-Java) jevnaldrende som faktisk gjør gjengivelsen. Dette kan komplisere GUI-utviklingen din hvis du bruker Java Swing og dets komponenter som er Java, eller lette. Det er noen spesielle løsninger, men generelt blandes ikke lette og tunge komponenter ikke godt i de samme containerobjektene og vinduene. Mer informasjon om problemer med lette og tunge komponenter er tilgjengelig fra ressursene på slutten av denne artikkelen.

Installere Java 3D

Nå som vi forstår de viktigste funksjonene og begrensningene til Java 3D, la oss gjøre oss klare til å prøve noen eksempler på kode.

Java 3D er tilgjengelig i beta for Win32 og Solaris. Den mer modne av Suns implementeringer av Java 3D er bygget på toppen av OpenGL. En alfa-kvalitet Direct3D-implementering er også tilgjengelig for Win32. Alle krever Java 1.2, med den nyeste Java 3D-betaen som tilsvarer Java 1.2 Beta 4. Sun har lovet å gi ut den endelige Java 3D-implementeringen kort tid etter at den lanserer Java 1.2, som for øyeblikket er planlagt til desember 1998.

Litt forvirrende til side: Sun ga ut Java 3D 1.0 alfa-implementeringer, som tilsvarte Java 3D 1.0 API, men den ga aldri ut noe utover alfa for 1.0 API. Sun modifiserte deretter API-en og ga ut den modifiserte versjonen som Java 3D 1.1 API. Denne versjonen ble fulgt med utgivelser av det den kalte 1.1 beta-implementeringer, to så langt. Sun har lovet å gi ut en endelig API og implementering kort tid etter den endelige utgivelsen av Java 1.2-plattformen. Forhåpentligvis har API-en stabilisert seg og vil ikke bli revidert, enda en gang, mens verden fremdeles venter på en endelig utgivelse av en implementering.

Fordi vi skal dekke Java OpenGL-bindinger i en fremtidig kolonne, har jeg bestemt meg for å spare og bruke OpenGL-versjonen av Java 3D også i denne installasjonsinstruksjonene. Hvis du installerer OpenGL-versjonen for bruk med disse Java 3D-eksemplene, vil du ha gjengivelsesbibliotekene du trenger for at Java-OpenGL-eksemplene skal komme senere.

Programvarekomponentene du trenger for å bruke Java 3D er:

  • Java 3D-kjøretid, tilgjengelig fra Sun (gratis pålogging for Java Developer Connection kreves). Sørg for å velge OpenGL-versjonen av Java 3D for plattformen din (jeg bruker Win32). Per nå er den siste Win32 Java 3D for OpenGL 1.1 Beta 2, i java3d11-beta2-win32-opengl.exe, og veier inn på omtrent 1,7 MB.

  • OpenGL 1.1, inkludert med Windows NT 4.0 og Windows 95 OSR 2. Hvis du har OSR 1-utgivelsen av Windows 95, kan du imidlertid laste ned OpenGL-støtte. Den siste implementeringen av Windows 95-OpenGL 1.1 er tilgjengelig fra Microsoft som opengl95.exe, og er omtrent 0,5 MB.

  • Java 1.2, tilgjengelig fra Sun. (Merk at når jeg skriver dette, har Sun gitt ut en ny Java 1.2 - Release Candidate 1. Eksempler vil bli oppdatert for den siste utgivelsen så snart som mulig.) Java 3D er koblet til 1.2-plattformen, og Sun har uttalt på postliste med java3d-interesse at den ikke har noen interesse i å frakoble API og prøve å gjøre den tilgjengelig med tidligere plattformutgivelser.

Eventuelt kan det også være lurt å laste ned Java 3D-dokumentasjonen og eksempelkoden. Begge er tilgjengelige fra samme lenke som Java 3D-kjøretid.

Vær oppmerksom på at du ikke lenger er pålagt å sette CLASSPATH-miljøvariablene for at java- eller appletviewer-kjørbare filer skal finne utvidelsesbiblioteker. Med Java 1.2 har Sun endelig opprettet en standard utvidelseskatalog. Denne katalogen ligger på / jre / lib / ext / i JDK-installasjonskatalogen. For eksempel, på mitt system er Java 1.2 Beta 4 installert på:

C: \ jdk1.2beta4 \

og standard utvidelseskatalog er på:

C: \ jdk1.2beta4 \ jre \ lib \ ext \

Alle utvidelsesbiblioteker bør plassere jararkivene sine i denne utvidelseskatalogen ved installasjonstidspunktet, og alle standard JDK-verktøy vet å søke her etter nødvendige klassefiler.

For Suns Java 3D inkluderer disse arkivene både offentlige (dokumentert i Java 3D API-spesifikasjonen) og private (Sun-implementeringsspesifikke) klasser. Offentlige klassearkiver inkluderer:

  • j3dcore.jar - Inneholder klassefiler for den offentlige Java 3D-pakken javax.media.j3d.

  • vecmath.jar - Inneholder klasser for javax.vecmath.

Private arkiver inkluderer:

  • j3daudio.jar - Arkiverer com.sun.j3d.audio klasser, som bygger støtte for romlig lyd på toppen av en tilpasset kopi av Java-delen av Java Sound, Headspace-basert lydmotor, som debuterer i Java 1.2.

  • j3dutils.jar - Innkapsler en rekke Sun-nytteklasser i 16 totalpakker og underpakker under com.sun.j3d. Jeg vil grave dypere inn i disse pakkene i neste måneds fortsettelse av vår Java 3D-diskusjon.

  • j3dutilscontrib.jar - Arkiverer nyttige verktøy bidratt av andre til Suns innsats. Det er syv pakker under com.sun.j3d hierarki, inkludert com.sun.j3d.utils.trackers koden nevnt ovenfor. Igjen vil kolonnen i neste måned gi mer informasjon om pakkene i denne krukken.

Vær oppmerksom på at i teorien kan du starte og ringe metoder på noen av klassene som tilbys i ikke-standardpakker som com.sun, men advarselstømmer: Det er ingen garanti for at de vil være tilgjengelige på plattformen koden din utfører på. I dagens praksis er Java 3D bare tilgjengelig fra Sun, så mange utviklere bruker faktisk klasser i Suns private arkiver. Du bør være oppmerksom på den potensielle avvekslingen av bærbarhet det innebærer når du velger å gjøre det.

Det er ingen magi i hvordan det offentlige og private Java 3D-klasser grensesnitt med systemressurser, heller. Sun installerer innfødte biblioteker i J3D.dll og j3daudio.dll under / jre / bin / katalog. Java 3D-klassene bruker innfødte metoder for å kalle disse DLL-ene og grensesnittet med Win32-plattformen og OpenGL-gjengivelsesbiblioteket. (Lignende biblioteker finnes for Solaris-implementeringer.)

En siste merknad om installasjon: OpenGL-gjengivelsesrørledningen er designet for å dra nytte av OpenGL-akselerasjonsmaskinvare for å øke hastigheten på grafikkapplikasjonene dine. I denne kolonnen bør du imidlertid kunne eksperimentere med eksemplene uten spesiell maskinvare. (Faktisk utvikler jeg alle eksemplene på en Pentium 150-MHz MMX-bærbar PC uten OpenGL-akselerasjonsmaskinvare.) Hvis du er interessert i akselerasjonskort, kan du se OpenGL-nettstedet eller Java 3D-adresselisten ( se Ressurser) for mer informasjon. Jeg planlegger å inkludere litt mer informasjon i neste måneds Java 3D-kolonne om akselerasjonsmaskinvare også.

Konstruerer utsiktsgrenen av scenen

Som jeg nevnte tidligere, en av de største styrkene til scenegraf grafikkmodellen er at den lar uerfarne grafikkprogrammerere legge til 3D i applikasjonene sine. Tradisjonelt har 3D-programmerere måttet spesifisere hvor og hvordan individuelle linjer eller andre grafiske primitiver skal tegnes. Ved å bruke et scenegraf oppretter imidlertid programmereren ganske enkelt en trelignende struktur som inneholder noder som representerer objekter som skal gjengis, samt gjengivelsesinstruksjoner (for eksempel hvor synspunktet som vises til skjermen er plassert, fysisk geometri i 3D-verdenen som programmereren bruker. er å skape, og relative avstander mellom ting).

$config[zx-auto] not found$config[zx-overlay] not found