Java-Grafik #

Ich habe mir erlaubt, die Seite in Überschriften einzuteilen und umzusortieren sowie einiges auf JavaJNI und OpenGL auszulagern. Dabei habe ich versucht, an jeden umsortierten Absatz den Autoren dranzuschreiben, damit klar bleibt, welches Know-How wo schon vorhanden ist. Ich habe einigen erklärenden Text dazugeschrieben, allerdings in dieser Version keine echte neue Information eingefügt. Nach wie vor ist das hier eine Sammlung von Einstiegsversuchen und noch keine echte Hilfe, also bitte fleissig weiterkommentieren! -- ThomasBayen

Anlass #

Beim LUG-Treffen im Limericks am 15.01.09 diskutierten einige LUG-Mitglieder noch zu später Stunde über Spiele-Engines und warum es keine bekannten freien Spiele-Projekte gibt.

Dabei kam zum Vorschein, daß mindestens zwei LUG-Mitglieder Visionen von eigenen grafikintensiven Spielen im Kopf haben. Dann kam der Gedanke auf, mal zu eruieren, inwiefern man z.B. in Java eine Grafik-Engine programmieren könnte, die man dann für verschiedene Projekte nutzen könnte.

Anwesend waren insbesondere ThomasBayen und KaiEhlers und zwei neue LUGer, JanReitz und PatrickFabeck.

Diese Seite hier soll eigentlich nur als Sammlung dienen, um Gedanken und Links zum Thema zusammenzutragen.

Grundlagen #

3D-Grafik ist normalerweise eine sehr rechenintensive Angelegenheit. Aus diesem Grunde unterstützen fast alle Grafikkarten besondere Beschleunigungen. Um auf diese zugreifen zu können, gibt es den plattform- und sprachübergreifenden Standard OpenGL. Hiervon gibt es - im Zuge der selbstverständlich fortschreitenden technischen Entwicklung auf diesem Gebiet - mehrere Versionen. Falls man eine Grafikkarte hat, die OpenGL nicht unterstützt (oder den "optimalen" Treiber nicht eingebunden hat), gibt es auch eine Software-Implementation namens "Mesa", die z.B. in XOrg eingebunden ist. Diese soll jedoch um einen Faktor von 20-200 langsamer sein! 3D-Grafik in Java ist also zuerstmal die Frage: Wie kann ich auf OpenGL zugreifen?

Welche Möglichkeiten gibt es #

Die Seite http://j3d.org/ ist eine sehr gute Einstiegsseite für verschiedene Java-3D-Projekte.

Alle Lösungen verwenden native Teile (sind also keine reinen Java-Libs). Dies ist ja auch logisch, weil wir ja direkt auf die API des X-Servers bzw. von Windows bzw. direkt auf die Hardware zugreifen wollen (zur Installation siehe JavaJNI) und dazu dann aus der Java-VM heraus müssen. --ThomasBayen

Gibt man in Google <OpenGL Java> ein findet man einige interessante Seiten. Z.B. im Wiki-NJH findet man einen Beitrag wie jogle zur Java-Bücherei hinzugefügt werden kann. Es gibt auch eine Artikel in PDF, der die Programmierung eines Springbrunnens in JAVA mit jogl beschreibt. Auch dort wird beschrieben wie die zwei jogl-Dateien in Java eingefügt werden müssen. --KaiEhlers--

Java3D #

Auf der Sun-Seite wird man auf Java3D verwiesen. Das ist eine 3D-API, die von Sun (mit-)entwickelt wurde. Man soll das Paket in sein JRE hineininstallieren (siehe JavaJNI). Java3d ist wohl eine ganz eigene API, also kein echtes OpenGL, greift aber natürlich intern immer auf OpenGL zurück. Inzwischen gibt es wohl alternativ noch einige direkte OpenGL-Implementationen. Irgendwo habe ich gelesen, daß Java3D von der Funktionalität etwas hinterherhinkt und deshalb wohl der OpenGL-Weg der bessere sei. Das würde auch das Know-How vereinfachen, weil es zu OpenGL genug Tutorials aus anderen Programmiersprachen gibt. Der Vorteil kann natürlich sein, daß die API evtl. höher abstrahiert, besser in Java integriert und evtl. höher entwickelt ist. Um das zu entscheiden, habe ich jedoch noch nicht genug Ahnung von beiden Methoden. Die Homepage von Java3D ist http://java3d.j3d.org/

JOGL (bisher "Empfehlung der Redaktion") #

Interessant sieht für mich auch Java OpenGL (JOGL) aus. Dieses Projekt wird auch von Sun unterstützt. Da eine einfaches Java3D-Beispiel bei mir nicht lief (siehe unten), habe ich es ausprobiert. Ein einfaches Beispiel mit einem einzelnen, bunten Dreieck ist mir gelungen. -- ThomasBayen

Die beste Implementation von OpenGL in JAVA dürfte das jogl-Projekt sein. --KaiEhlers--

Probleme mit OpenGL-Versionen #

Ich habe mir Java3D 1.5 installiert und ein Testprogramm aus dem Tutorial in Eclipse übersetzt. Beim Start meckert dieses nur, daß es GLX 1.3 braucht und ich nur 1.2 installiert habe. Kann das jemand erklären, der sich damit besser auskennt? Angeblich kann man mit "glxinfo" feststellen, welche Möglichkeiten ein X-Server hat. Kann mir da mal jemand mit einem aktuelleren System (insbes. X-Server) sagen, ob er da mehr als 1.2 angezeigt bekommt? Oder ist das von der Grafikkarte abhängig? Kann doch nicht angehen, daß unsere Anwendung hinterher auf manchen Grafikkarten einfach gar nicht läuft?!? Ich werde mal in Richtung JOGL weiterforschen; vielleicht bekomme ich dann raus, was der Unterschied zwischen 1.2 und 1.3 ist. -- ThomasBayen

In OpenGL 1.2 wurde z.B. das Multitexturing hinzugefügt, in 1.3 und 1.4 kamen dann noch Support für Vertex- und Fragmentprogramme sowie Support für Vertexbuffer-Objekte hinzu. -- StefanGaffga

NVidia 6600GT mit "nvidia" Treiber 

 # glxinfo |grep direct
 direct rendering: Yes

sollte "Yes" sagen, das heist das Hardwarebeschleunigung vorhanden ist. 

 # glxinfo |grep version
 server glx version string: 1.4
 client glx version string: 1.4
 GLX version: 1.3
 OpenGL version string: 2.1.0 NVIDIA 97.46

dabei ist wohl die letzte Zeile am interessantesten siehe: OpenGL

wer keine Hardwarebeschleunigung hat kann sich auf www.mesa3d.com (oder "emerge mesa" in gentoo) eine Software lösung holen. 

 Quote von www.mesa3d.com
 Mesa 6.x supports the OpenGL 1.5 specification.

-- JanReitz

Performance #

Ein rein in Java programmiertes 3D-Spiel dürfte keine befriedigende Performance liefern - das liegt nicht an dem interpretierten Java-Bytecode, sondern am Garbage-Collector den man nicht frei kontrollieren kann. Bereits nach einigen Sekunden Laufzeit beginnt dieser zu arbeiten und verursacht unangenehme Ruckler im Spielablauf. Eine Lösung hier wäre es möglicherweise in C/C++ über das JNI-Interface das Rendering und die Behandlung von Kollisionserkennung zu implementieren?! -- StefanGaffga

Laut Tuning Java GC oder auch deutscher Artikel zur Java 5-GC kann man die GC genau einstellen (kommt allerdings auf einen praktischen Test an). -- ThomasBayen
Anm. zum Java-GC: Ich habe mal mit dem Tao-Framework unter Mono rumprobiert, und hatte keine probleme mit abfallender Performance, vieleicht kann man die GC soweit unterdrücken das es erträglich ist. -- JanReitz

Nachdem ich mir einige der Beispiele aus der Linkliste unten (z.B. Jake2) auf meinem Laptop (1.4 GHz, freier ATI-Treiber) angesehen habe, ist für mich der Beweis erbracht, daß es geht. Bleibt die Frage, ob wir das auch schaffen... ;-) -- ThomasBayen

Ich kenn mich in Java garnicht aus, aber ich habe gesehn das keine Structs unterstützt werden, und deshalb wird wohl eine native Java lösung flachfallen müssen, da ich für eine halbwegs schoene Umgebung oder Modelle mehrere 10k Punkte brauche (und Objekte zuviel overhead haben) Hier sind einige Punkte aufgelistet die Java als "schlecht/bedingt tauglich" für 3D Programme zeigen http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062 und auch eine mögliche Lösung hab ich dort gefunden, die ich aber nicht einschätzen kann: http://javolution.com/ -- JanReitz

Einstieg in die Programmierung #

Mein erster Schritt #

Ich habe JOGL in Eclipse installiert (wie auf JavaJNI beschrieben) und dann das JOGL Helloworld Tutorial abgearbeitet. Dabei ist mit aufgefallen, daß es offensichtlich eine Änderung in der API zur Erzeugung eines GLCanvas gibt. Statt der Factory 

  GLDrawableFactory fac = GLDrawableFactory.getFactory();
  GLCanvas canvas = fac.createGLCanvas(caps);

benutze ich folgende Zeile: 

  GLCanvas canvas = new GLCanvas(caps);

Ansonsten läuft das Beispiel, ist gut erklärt und erzeugt ein buntes Dreieck. Juhu! :-)

Eclipse-Besonderheiten #

Integration von JOGL in ein Eclipse-Projekt siehe JavaJNI.

Eclipse scheint ein kleines Problem mit der GL-Klasse zu haben. Diese enthält lt. Doku wohl über tausend Methoden, was dazu führt, das der "Content Assist", wenn er automatisch aufgeht, mehrere Minuten brauchen kann. Am Anfang hielt ich das für einen Absturz... Wer das gleiche Problem hat, kann in den Preferences unter "Content Assist" die Einstellung "Enable Auto Activation" abstellen. Man kann den Assistenten dann immer noch mit "Strg-Leertaste" aktivieren, wobei er dann auch das Problem nicht mehr hat (man kann ihn also für GL dann auch benutzen).

Überlegungen zu unserem Projekt #

Die Überlegungen auf dieser Seite fingen an, als KaiEhlers und ThomasBayen merkten, daß sie gerne Spiele schreiben würden, die ähnliche Grafikprobleme beinhalten. Ich notiere hier mal unseren gemeinsamen Nenner (vorerst aus meiner Sicht), um vielleicht eine ergiebige Diskussion anzuregen. :-)

Uns geht es beiden um eine "Weltkarte", auf der Figuren herumlaufen. Diese Welt hat verschiedene Geländeformationen (Wälder, Flüsse, Meer, etc.) und unterschiedliche Höhenstufen. Das Ganze soll somit ungefähr aussehen wie Siedler, Populous, o.ä. Die Grafik soll in einer schrägen Ansicht von oben dargestellt werden, so daß die Höhenunterschiede auch sichtbar sind. Folgende Überlegungen sind uns dazu bereits eingefallen:

  • Eine Frage ist, ob das überhaupt ein 3D-Problem ist. Die alten Siedler-Versionen z.B. auf dem Amiga haben das bestimmt nicht mit OpenGL gemacht. Eine echte 3D-Ansicht hat hingegen den großen Vorteil, daß man die Ansicht auch variieren kann (Kamerafahrten, etc.). Evtl. brauchen wir beides: 2D für das schnelle und detailreiche Spiel und 3D für Übersichten, Drehungen und Kamerafahrten. Dann ist die Frage, ob es sinnvoll ist, 2D extra zu programmieren oder ob OpenGL in 2D genauso schnell ist wie die 2D-APIs und ob diese auch hardwarebeschleunigt sind. -- ThomasBayen
  • Es gab verschiedene Meinungen zur Grundform, die ein einzelnes Feld hat:
    • gleichseitige Dreiecke waren Kais Favoriten. Dreiecke sind die Grundform jedes Polygons und jeder OpenGL-Engine. Damit keine teureren oder billigeren Bewegungen entstehen, müsste man gleichseitige Dreiecke nehmen. Es gibt nur drei Bewegungsrichtungen - das könnte evtl. irgendwie kompensiert werden, z.B. indem man die Position unabhängig von den Kacheln bestimmt (man also nicht immer genau auf einem Feld steht) oder indem man auch "diagonale" Richtungen erlaubt (was sechs Richtungen ergäbe, aber evtl. ähnliche Probleme ergibt wie Vierecke mit 8 Richtungen). Gleichseitige Dreiecke ergeben keine geraden Kanten, also keine geraden Meeresküsten oder Waldränder Das kann hübsch wirken, kann aber auch lästig sein. -- ThomasBayen
    • rechtwinklige Dreiecke haben einige Vor- und Nachteile mit den gleichseitigen Dreiecken und einige mit den Vierecken gemein. Sie ergeben gerade Kanten. Dafür ist eine "gerechte" Bewegung generell unmöglich, außer man koppelt die Positionen der Figuren von den Feldern komplett ab. -- ThomasBayen
    • Sechsecke sind Thomas' Favoriten. Ich habe bereits ein Spiel mit Sechsecken geschrieben und habe gute Erfahrungen. Man hat sechs Bewegungsrichtungen, was ausreicht. Felder, die außerhalb der direkten 6 Richtungen liegen, werden nicht zu sehr benachteiligt. Da Sechsecke ja eigentlich aus sechs gleichseitigen Dreiecken bestehen, müssen sich Sechsecke und Dreiecke nicht grundsätzlich ausschließen. Sechsecke ergeben keine geraden Kanten. Tests auf meinem Thin Client haben ergeben, daß das Zeichen eines Sechsecks ca. 2,5 mal so lange dauert wie das Zeichnen eines Dreiecks, aber das kann bei entsprechender Hardware bis auf Faktor 1 zurückgehen. -- ThomasBayen
    • Natürlich wäre es auch möglich, Gebiete als beliebige Polygone zu definieren, die dann aneinanderpassen. Dort könnte man dann eine gekachelte Textur auftragen und fertig. Die Position von Spielfiguren wäre dann frei wählbar. Zu so einer Lösung habe ich mir selber bisher noch nicht viele Gedanken gemacht. -- ThomasBayen
  • Die Felder brauchen eine vom Geländetyp abhängige Textur. Dies sieht IMHO viel besser aus, wenn die Texturen von Nachbarfeldern sauber ineinander übergehen. So bekommt ein "Ebene"-Feld, das an ein "Meer"-Feld grenzt, einen schmalen Strand verpasst. (Damit kann man evtl. sogar wieder "gerade Kanten" bekommen?!?) Nun muss man aber für jedes Nachbarfeld den entsprechenden Rand anpassen. Das heisst bei einem Sechseck, das man bei z.B. 4 Geländetypen 5 hoch 6 = 15625 verschiedene Texturen benötigt... Also muss man stattdessen das Sechseck in sechs Teile zerlegen (die obige "Zwischenform" ruft gerade laut Hallo!), was die Texturen auf 4*4 = 16 reduzieren würde. Die nächste Frage ist, ob, wenn man sechs Dreiecke zusammensetzt, in der Mitte (wo ja eigentlich der wichtigste Teil der Textur, z.B. ein Baum sitzt) noch ein sauberes Bild herauskommt oder ob man eine siebte Textur für das Zentrum des Sechsecks benötigt. Alternativ lässt man alle diese Überlegungen weg, verkleinert die Felder und lässt den Kartendesigner entsprechend "Strand" u.ä. einfügen, wo Geländegrenzen sind. Dann würde ein "Schritt" für den Spieler natürlich auch über mehrere Felder (incl. Zwischenfelder) gehen. Von der Grafikausgabe her ergibt sich da jedoch eigentlich kein Unterschied. -- ThomasBayen
  • Erste Tests lassen in mir die Erkenntnis reifen, daß eine Live-Erzeugung der Welt mit vielen Feldern und Texturen sehr lange dauern würde. Wir brauchen also definitiv eine Cache-Strategie, um die Weltansicht irgendwie zu cachen (und dann nur die beweglichen Teile wie Figuren neu zu zeichnen) bzw. für schnelle Kamerafahrten die Qualität harabzusetzen. Da die Fähigkeiten von Hardware sehr unterschiedlich sein können, brauchen wir auch eine Detail-Strategie, um den Rechenaufwand (dynamisch) der Hardware anzupassen. Bewegungen auf den Grundfeldern (z.B. wippende Baumwipfel oder schäumendes Meer) sind wünschenswert, sollten aber wohl nur sporadisch und nicht bei allen Feldern des Typs erscheinen und könnten daher auch auf die gecachte Version "aufgesetzt" werden wie die Spielfiguren. -- ThomasBayen

Siehe auch SpielProjekte von StefanGaffga

Beispiel #

Aus obigen Überlegungen ist inzwischen ein Projekt geworden, das seit letztem Montag sogar einen Namen hat: JEmpire! Es gibt eine Webseite unter http://jempire.javaproject.de , die alles enthält, was man so braucht, um einzusteigen. Insbesondere gibt es dort eine JavaWebStart-Demo. Ich bitte alle geneigten Leser, das auszuprobieren und (Miss-)Erfolge zu melden, da das mein erstes Webstart-Programm ist. :-)

Kategorien
KategorieJava
This particular version was published on 06-Feb-2007 19:50 by ThomasBayen.  Top