= 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.

*''(Java als Gameengine finde ich eine interessante Idee, \\und auch z.B. [FrozenBubble|http://de.wikipedia.org/wiki/Frozen_Bubble] als freies Spiel und [Crystal Space|http://www.heise.de/newsticker/meldung/83843/from/rss09]/[PyGame|http://de.wikipedia.org/wiki/Pygame] als Spieleframeworks mit Java-/Python-Bindung -- MarkusMonderkamp)''

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|http://java.sun.com/docs/hotspot/gc1.4.2/] oder auch [deutscher Artikel zur Java 5-GC|http://www.zdnet.de/builder/program/0,39023551,39147079,00.htm] 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|http://opengl.j3d.org/tutorials/helloworld.html] 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:
** '''Vierecke''' wollte eigentlich keiner haben. Obwohl sie natürlich am besten auf den Bildschirm abzubilden sind, gilt dieses Argument bei 3D-Ansichten, wo sowieso alle Linien durch die Perspektive verzerrt werden, nicht mehr. Man muss sich entscheiden, ob man 4 oder 8 Bewegungsrichtungen zulassen will. Nimmt man vier, werden Bewegungen zu Zielen, die diagonal liegen, unverhältnismäßig teuer, nimmt man 8, sind diagonale Bewegungen eigentlich zu billig, weil man ja eine um wurzel(2) längere Strecke zurücklegt. -- ThomasBayen
** '''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
** Eine '''Zwischenform''', die mir eingefallen ist, ergibt sich, wenn man sich Sechsecke als aus jeweils sechs gleichseitigen Dreiecken bestehend denkt. Die Figuren stehen nicht auf einem Feld, sondern auf den Schnittpunkten der Feldränder. Es gibt sechs Bewegungsrichtungen, man kann dreieckige Geländetypen vergeben. Unschön finde ich es, wenn Figuren immer auf dem Rand eines Geländetypen stehen. Das hängt davon ab, ob man den Rand wirklich durch den Rand des Feldes führt (s.u.); eine solche Lösung wäre aber auf jeden Fall aufwendiger (vielleicht auch nicht, wenn eine "Bewegung" immer über zwei Schnittpunkte geht, womit man dem Benutzer gegenüber wieder näher an Sechsecken wäre). -- 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
* Für mein Spiel ist es wichtig, daß die Welt keinen '''Rand''' hat. Bisher habe ich dazu den linken und rechten und den oberen und unteren Rand jeweils verbunden. Das ergibt im Ergebnis eine "torusförmige" Welt. Das ist für mich eine Voraussetzung, ergibt aber keine wirklich schöne Lösung für eine "Gesamtübersicht". Noch schöner wäre es allerdings, wenn man es schaffen würde, eine '''kugelförmige Welt''' zu bauen. Das Gesicht eines Spielers, wenn eine Kamerafahrt sein "Reich" aus der Satellitenperspektive auf einem Planeten zeigt, wäre den Versuch wert... Deren Projektion hat allerdings schon die Autoren von Atlanten seit Jahrhunderten in die Verzweiflung getrieben. Vieles von dem, was ich oben über Feldformen gesagt habe, wäre dann wohl obsolet. Außerdem ginge es dann endgültig nicht mehr ohne 3D-Projektion. Eine Idee hätte ich, dazu müsste man es jedoch schaffen, ein Sechseck (oder zum Anfang ein Viereck) passgenau auf eine Halbkugel zu projizieren. Wie geht das? -- 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
* Für mein Spiel ist es wichtig, daß die Karte schwarze Flecken (also unerforschte Gebiete) haben kann. Dies sollte man irgendwie darstellen können. Ob dabei über die Randtextur oder eine Geländeneigung ein Hinweis auf das nächste schwarze Feld gegeben wird oder nicht sollte in der Grafik-Engine variabel sein. -- ThomasBayen

Siehe auch SpielProjekte von StefanGaffga

= Links: =
* Grundblibliotheken für 3D-Grafik
** http://j3d.org/ - Java 3D Community Site
** http://java3d.j3d.org/ - Java3D von Sun
** http://opengl.j3d.org/ - JOGL (auch von Sun unterstützt)
** https://jogl.dev.java.net hier kann man die jogl-Dateien herunterladen.
** https://jogl-demos.dev.java.net/ - JOGL Demos (einige laufen bei mir, einige nicht - je nach "Requirements")
* Seiten zu freien Anwendungen und Spielen in Java- die 3D-Grafik nutzen
** [http://bytonic.de/] -- 3D Spiel in Java Quake2 Clone
** [http://icculus.org] Einige 3D Engines/Spiele als OpenSource (auch sehr Fortgeschrittene ala Quake 3 oder Decent)
* [Crystal Space|http://www.heise.de/newsticker/meldung/83843/from/rss09] 3D-Engine für z.B. [Planeshift|http://de.wikipedia.org/wiki/Planeshift], auch mit Java-Anbindung
** [https://lg3d.dev.java.net/de/index.html] - Glass Desktop
*** [http://www.oszine.de/Article6232.html]
*** [http://www.pro-linux.de/berichte/LG3D-Tutorial/LG3D-Tutorial.html]
* Tutorials
** [http://wiki.delphigl.com] enthält hervorragende Tutorials zu OpenGL aber auch zu wichtigen, grundlegenden Grafikalgorithmen.
** [http://www.geometrictools.com] enthält Basis- und Fortgeschrittene Algorithmen für die Grafikprogrammierung. (Unter "Documentation" schauen!)
** [http://nehe.gamedev.net] OpenGL Tutorials in etlichen Sprachen ([Java Version|http://pepijn.fab4.be/?page_id=34]) Unter jedem Kapitel stehen Links zu Versionen in allen Programmiersprachen: Ich empfehle "JOGL" (und nicht "Java", das ist umständlicher gemacht).
** http://www.mh1.de/Papers/ParticleSystems/Particle_System_Tutorial.pdf - Tutorial über Partikelsysteme (am Beispiel einer Wasserfontäne)
* verwandte Links, die aber andere Programmiersprachen betreffen
** [PyGame|http://de.wikipedia.org/wiki/Pygame] Spiele-Framework der Flying-Circus-Sprache
** [FrozenBubble|http://de.wikipedia.org/wiki/Frozen_Bubble] - Beweis, dass auch mit Perl grafisch ansprechender Zeitvertreib möglich sein kann.

;Kategorien:KategorieJava