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

För att bygga en riktig Java-plattform insåg Sun tidigt att den behövde fylla i API-bilden utöver den begränsade funktionaliteten som finns i Java 1.0-kärnplattformen. Sun har växt kärnan mycket med 1.1 och kommande 1.2-utgåvor, men det finns fortfarande några bitar som saknas i Java-pusslet.

Sun och dess partner utvecklade Java Media and Communication API för att tillhandahålla de saknade multimedia-programmeringsbitarna. Två av de största delarna, 2D- och 3D-grafik, riktas mot Java 2D- och 3D-API: erna. Java 2D är en kärnplattform API som börjar med Java 1.2, medan Java 3D kommer att släppas som ett Extension API strax efter att 1.2-plattformen blir tillgänglig. Vi har nyligen avslutat en serie kolumner på Java 2D; nu riktar vi oss mot Java 3D.

Java 3D är tänkt att ge Java-utvecklare möjlighet att skriva applets och applikationer som ger tredimensionellt, interaktivt innehåll till användarna. Sun har viss hård konkurrens från andra 3D-grafiktekniker på den här arenan, och Java 3D har en uppförsbacke före sig om det är att besegra den befintliga grafikstandarden, OpenGL.

En begäran om läsarkommentarer om 3D-grafik-API: er för Java visade ett stort intresse för Java 3D- och Java OpenGL-bindningar, så jag har beslutat att koncentrera mina ansträngningar på dessa tekniker de närmaste månaderna.

En mer begränsad mängd intresse uttrycktes i VRML. Följaktligen ska jag ta itu med VRML genom att demonstrera dess användning i Java 3D med VRML97-innehållsladdare och Suns Java 3D VRML97-webbläsare. Direct3D fick väldigt lite intresse, så jag har beslutat att inte följa den här vägen, förutom att nämna var en av de andra teknikerna kan stödja eller samverka med den.

För- och nackdelar med Java 3D

Den här månaden börjar vi vår rundtur i 3D-grafik-API: er för Java genom att utforska Java 3D. Vi börjar med att diskutera några av API: s stora styrkor och svagheter. 3D-grafik kan ibland verka tråkigt och kan därför vara svårt att förklara. Om du har någon förvirring kring mina exempel eller förklaringar, är du välkommen att skriva till mig med dina frågor eller kommentarer, så gör jag mitt bästa för att ta itu med dem.

Sälja poäng för Java 3D:

  • Det ger en objektorienterad vy på hög nivå av 3D-grafik. Java 3D åstadkommer detta delvis genom att använda en scengrafbaserad 3D-grafikmodell. (Vi kommer att diskutera detta koncept mer detaljerat senare i artikeln.) Detta tillvägagångssätt är avsett att hjälpa programmerare utan mycket grafik eller multimedia-programmeringserfarenhet att använda 3D i sina applikationer. I skarp kontrast till lägre nivå, procedurella 3D-API: er som OpenGL, som är utformade för att optimera för bästa möjliga hastighet och ge programmerare störst möjliga kontroll över renderingsprocessen, är Java 3D tänkt att vara enkelt för alla erfarna Java-programmerare att lära sig.

  • Om du inte behöver åtkomst på låg nivå till rendering kan Java 3D vara ett alternativ. Återgivningsåtkomst är begränsad till förfrågningar via attribut och kapacitetsbitar, liknande form och funktion som Java 2D: s renderingstips. (Se Resurser för länkar till min tidigare serie om Java 2D, som innehöll diskussion och exempel på 2D: s renderingstips).

  • Java 3D är optimerat för hastighet där det är möjligt. Körtiden använder renderingskapacitetsbitar, i själva verket för att optimera scengrafen för snabbast möjliga renderingar. Detta tillvägagångssätt gör Java 3D mer tillämpligt på interaktiva grafikmiljöer (spel, simuleringar, situationer med låg latens) än för offline, högkvalitativa grafikapplikationer (som render gårdar).

  • Ett stort och växande antal 3D-laddare är tillgängliga för att importera innehåll till Java 3D-runtime. Sun har gjort en Java 3D VRML97-filladdare och webbläsare fritt tillgänglig med kod. Leta efter nästa månads kolumn för medieprogrammering för att utforska Java 3D-laddare mer detaljerat.

  • Java 3D kräver vektormatematiska funktioner som inte finns någon annanstans på Java-plattformen. Dessa matematiska operationer finns för närvarande i javax.vecmathpaketet och kan flyttas till kärnplattformen i framtiden.

  • Java 3D stöder ett antal exotiska enheter (t ex trollstavar, datahandskar och headset). I com.sun.j3d.utils.trackerspaketet ingår med Suns genomförande ger klasser för Fakespace, Logitech och Polhemus enheter. Dessa enheter används dock inte så ofta, så jag kommer inte att diskutera dem i detalj. Om du är intresserad av att ta reda på mer om enhetsstöd hänvisar du till Suns Java 3D-webbplatser och Java 3D-e-postlistaarkivet (båda tillgängliga från de viktigaste Sun Java 3D-webbadresserna som ingår i resurserna nedan).

Java 3D har många fördelar, men hur är det med nackdelarna? De inkluderar:

  • Java 3D är ett standardtilläggs-API. Java-plattformslicensinnehavare ges möjlighet att implementera API om de vill, men de är inte skyldiga att implementera det. Java 3D: s positionering som en standardutvidgning riskerar att minska portabiliteten för Java 3D-kod över plattformar - de flesta leverantörer måste kämpa för att hålla jämna steg med förändringar och tillägg till kärnplattformen ensam.

  • Java 3D har allvarliga tillgänglighetsbegränsningar. Dessa är resultatet av Java 3D: s status som ett tilläggs-API. Den enda stora leverantören som för närvarande tillhandahåller en Java 3D-implementering är Sun med dess implementeringar för Solaris och Win32. Jämfört med OpenGL, som är tillgängligt för varje smak av Unix, Windows och många andra operativsystem, ser portabiliteten över Java 3D-kod tvivelaktigt ut.

  • Tillsammans med programvarutillgänglighetsproblem kommer dokumentationsunderskott. Sun gör ett tappert försök att tillhandahålla utvecklarutbildning och support för Java 3D, men det saknar fortfarande jämförelse med resten av branschens ansträngningar för att dokumentera OpenGL och dess användning. OpenGL Consortiums webbplats är mycket djupare och bredare än vad Sun hittills har lyckats sätta ihop för Java 3D. Det här är inte en mindre punkt: den relativa komplexiteten hos 3D-grafik-API: er gör god dokumentation till en nödvändighet.

  • Java 3D döljer rendering-pipeline-detaljer från utvecklaren. Eftersom Java 3D är ett API på hög nivå, döljer det avsiktligt detaljer om rendering pipeline från utvecklaren, vilket gör det olämpligt för ett stort antal problem där sådana detaljer är viktiga. (Vi diskuterar OpenGL: s lägre nivåmodell och tillgång till rendering pipeline senare i denna 3D-serie.)

  • Java 3D-komponenter är tunga. Det vill säga, de har en infödd (icke-Java) kollega som faktiskt gör rendering. Detta kan komplicera din GUI-utveckling om du använder Java Swing och dess alla Java- eller lätta komponenter. Det finns några speciella lösningar, men i allmänhet blandas inte lätta och tunga komponenter i samma behållarobjekt och fönster. Mer information om lätta och tunga komponentproblem finns i Resurserna i slutet av den här artikeln.

Installera Java 3D

Nu när vi förstår de viktigaste funktionerna och begränsningarna i Java 3D, låt oss göra oss redo att prova någon exempelkod.

Java 3D är tillgängligt i beta för Win32 och Solaris. Den mer mogna av Suns implementeringar av Java 3D byggs ovanpå OpenGL. En alfa-kvalitet Direct3D-implementering är också tillgänglig för Win32. Alla kräver Java 1.2, med den senaste Java 3D-beta som motsvarar Java 1.2 Beta 4. Sun har lovat att släppa den slutliga Java 3D-implementeringen strax efter att Java 1.2 släpps, som för närvarande är planerad till december 1998.

Lite förvirrande åt sidan: Sun släppte Java 3D 1.0 alfa-implementeringar, vilket motsvarade Java 3D 1.0 API, men det släppte aldrig något utöver alfa för 1.0 API. Sun modifierade sedan API: et och släppte den modifierade versionen som Java 3D 1.1 API. Denna version följdes med utgåvor av vad den kallade 1.1 beta-implementeringar, två hittills. Sun har lovat att släppa ett slutligt API och implementering strax efter den slutliga versionen av Java 1.2-plattformen. Förhoppningsvis har API: n stabiliserats och kommer inte att återupptas, ännu en gång, medan världen fortfarande väntar på en slutgiltig släpp av en implementering.

Eftersom vi kommer att täcka Java OpenGL-bindningar i en framtida kolumn har jag beslutat att spara och använda OpenGL-versionen av Java 3D i dessa installationsinstruktioner också. Om du installerar OpenGL-versionen för att använda med dessa Java 3D-exempel, har du de renderingsbibliotek du behöver för att Java-OpenGL-exemplen ska komma senare.

Programvarukomponenterna du behöver för att använda Java 3D är:

  • Java 3D-körtid, tillgänglig från Sun (gratis Java Developer Connection-inloggning krävs). Var noga med att välja OpenGL-versionen av Java 3D för din plattform (jag använder Win32). Från och med nu är den senaste Win32 Java 3D för OpenGL 1.1 Beta 2, i java3d11-beta2-win32-opengl.exe, och väger cirka 1,7 MB.

  • OpenGL 1.1, medföljer Windows NT 4.0 och Windows 95 OSR 2. Om du har OSR 1-versionen av Windows 95 kan du dock ladda ner OpenGL-support. Den senaste Windows 95-OpenGL 1.1-implementeringen är tillgänglig från Microsoft som opengl95.exe och är cirka 0,5 MB.

  • Java 1.2, tillgänglig från Sun. (Observera att när jag skriver detta har Sun släppt en ny Java 1.2 - Release Candidate 1. Exempel kommer att uppdateras för den senaste versionen så snart som möjligt.) Java 3D är kopplad till 1.2-plattformen och Sun har sagt på e-postlista med java3d-intresse att det inte har något intresse av att koppla från API: et och försöka göra det tillgängligt med tidigare plattformsreleaser.

Du kan också ladda ner Java 3D-dokumentationen och exempelkoden. Båda är tillgängliga från samma länk som Java 3D-körning.

Observera att du inte längre måste ställa in miljövariablerna CLASSPATH för att dina java- eller appletviewer-körbara filer ska hitta tilläggsbibliotek. Med Java 1.2 har Sun äntligen skapat en standardförlängningskatalog. Den här katalogen finns på / jre / lib / ext / i din JDK-installationskatalog. Till exempel, på mitt system är Java 1.2 Beta 4 installerat på:

C:\jdk1.2beta4\

och standardförlängningskatalogen är på:

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

Alla tilläggsbibliotek bör placera sina burkarkiv i den här tilläggskatalogen vid installationstid, och alla vanliga JDK-verktyg vet att söka här efter nödvändiga klassfiler.

För Suns Java 3D innehåller dessa arkiv både offentliga (dokumenterade i Java 3D API-specifikationen) och privata (Sun-implementeringsspecifika) klasser. Offentliga klassarkiv inkluderar:

  • j3dcore.jar- Innehåller klassfiler för det offentliga Java 3D-paketet javax.media.j3d.

  • vecmath.jar- Innehåller lektioner för javax.vecmath.

Privata arkiv inkluderar:

  • j3daudio.jar- Arkiverar com.sun.j3d.audioklasserna, som bygger stöd för rumsligt ljud ovanpå en anpassad kopia av Java-delen av Java Sound, Headspace-baserad ljudmotor, som debuterar i Java 1.2.

  • j3dutils.jar- Inkapslar en mängd olika Sun-klasser i totalt 16 paket och underpaket under com.sun.j3d. Jag kommer att gräva djupare in i dessa paket i nästa månads fortsättning av vår Java 3D-diskussion.

  • j3dutilscontrib.jar- Arkiverar användbara verktyg som andra har bidragit till Suns ansträngningar. Det finns sju paket under com.sun.j3dhierarkin, inklusive com.sun.j3d.utils.trackerskoden som nämns ovan. Återigen kommer nästa månads kolumn att ge mer information om paketen i den här burken.

Observera att i teorin kan du starta och anropa metoder på någon av de klasser som tillhandahålls i icke-standardpaket som com.sun, men varningstöm : Det finns ingen garanti att de kommer att finnas tillgängliga på plattformen som din kod kör på. I nuvarande praxis är Java 3D endast tillgängligt från Sun, så många utvecklare använder faktiskt klasser i Suns privata arkiv. Du bör vara medveten om den möjliga avvägningen mellan bärbarhet och att du väljer att göra det.

Det finns ingen magi i hur det offentliga och privata Java 3D-klasserna gränssnitt med systemresurser, heller. Sun installerar inbyggda bibliotek i J3D.dlloch j3daudio.dllunder /jre/bin/katalogen. Java 3D-klasserna använder inbyggda metoder för att anropa dessa DLL-filer och gränssnitt med Win32-plattformen och OpenGL-renderingsbiblioteket. (Liknande bibliotek finns för Solaris-implementeringar.)

En sista anmärkning om installation: OpenGL-rendering pipeline är utformad för att dra nytta av OpenGL-accelerationshårdvara för att påskynda dina grafikapplikationer. I den här kolumnen bör du dock kunna experimentera med exemplen utan någon speciell hårdvara. (Faktum är att jag utvecklar alla exempel på en Pentium 150-MHz MMX-bärbar dator utan OpenGL-accelerationshårdvara.) Om du är intresserad av accelerationskort bör du hänvisa till OpenGL-webbplatsen eller Java 3D-e-postlistan ( se Resurser) för mer information. Jag planerar att inkludera lite mer information i nästa månads Java 3D-kolumn om accelerationshårdvara också.

Konstruera utsiktsgrenen av scenen

Som jag nämnde tidigare är en av de största styrkorna med scengrafgrafikmodellen att den tillåter oerfarna grafikprogrammerare att lägga till 3D i sina applikationer. Traditionellt har 3D-programmerare varit tvungna att specificera var och hur enskilda linjer eller andra grafiska primitiv ska ritas. Med hjälp av ett scendiagram skapar programmeraren emellertid helt enkelt en trädliknande struktur som innehåller noder som representerar objekt som ska återges såväl som renderingsinstruktioner (till exempel var synvinkeln som visas för monitorn finns, 3D-världens fysiska geometri som programmeraren skapar och relativa avstånd mellan saker).