Einfache Engine für einfaches 3D gesucht

[Knuffi]

Erst mal ein kräftiges "Hallo" in die Runde, ich bin neu hier.

Ich habe mich ein wenig in Java eingearbeitet und habe nun vor, ein Programm für die Schule zu schreiben, das die Analytische Geometrie der Oberstufe umfasst (ich war schon lange auf der Suche nach sowas, bin irgendwann bei "Geo.exe" von www.emath.de gelandet, aber es gefällt mir von der Darstellung her nicht).

Also:
Punkte, Geraden, Ebenen und Kugeln erstellen, schneiden und dann natürlich auch in einem Koordinatensystem darstellen.

Die grundlegenden Sachen wie die Klassen für Punkt, Vektor, Gerade, Ebene und Kugel bekomme ich in den Griff, auch die Berechnung von eventuellen Schnitten sollte mich nicht vor unlösbare Probleme stellen.

Bei der Grafikdarstellung hapert es aber schon an der Frage: Was soll ich nehmen?

Nach einiger Recherchezeit läuft das ganze wohl auf OpenGL raus (was meint ihr dazu?).

Nur da gibt es ja auch nahezu abzählbar unendlich viele Möglichkeiten: JOGL LWJGL, jPCT, ...
Die meisten, die ich bisher gefunden habe, sind aber ziemlicher Overkill. Ich brauche keine Bewegung in meiner Darstellung und auch keine Physik-Engine.
Ich will nur die Objekte im Koordinatensystem ohne Texturen (Wireframe oder einfache Oberfläche, die vielleicht teildurchsichtig ist, damit man die anderen Objekte trotzdem sieht) darstellen und das Kosy mit der Maus drehen und eventuell mit dem Mausrad zoomen können.

Könnt ihr mir bei der Entscheidung helfen? Bitte in Erinnerung behalten, dass ich noch am Anfang der Lernkurve stehe. 😉

Edit: Noch was vergessen: Ich arbeite mit Swing und mein Editor ist Eclipse.

 

[Landei]

Warum nicht Java 3D? Das nimmt dir die ganzen Berechnungen ab, die du bei einem OpenGL-Wrapper selber machen müsstest, ist nicht auf Spiele spezialisiert und es gibt genug Tutorials und Dokumentation dazu.

Viel einfacher wird der Einstieg nicht werden, 3D ist nun mal ein komplexes Thema.

 

[Knuffi]

Ok, dann schaue ich mir Java 3D mal an. Ich hatte bisher nicht so viel darüber gelesen. Von den anderen Sachen gibt es irgenwie mehr Treffer bei Google ...

 

[Marco13]

Du arbeitest also an einem zweiten CLUCalc :joke:

Java3D war ursprünglich von Sun, und wird jetzt ("nur"?) noch von der Community weiterentwickelt. Ich habe schon eine Weile nicht mehr "aktiv" damit gearbeitet, und es ist schwer, einzuschätzen, wie gut es für deine Zwecke geeignet ist, solange man die Ziele nicht kennt. Du solltest dir ggf. mal die ganzen Alternativen ( Java und 3D-Grafik - it's engine driven [whoopsie's homepage] ) ansehen, also erstmal nur grob, und jeweils vielleicht ein einfaches Beispiel ansehen, und ggf. ein "Minimalbeispiel" erstellen, das deine Anforderungen widerspiegelt (Koordinatensystem, vielleicht ein paar Pfeile, eine halbtransparente Ebene, Text, Mausinteraktion,... ) und schauen, wie gut das eine oder andere passt. Sich von Anfang an "unabrückbar" auf eine Technologie festzulegen, könnte ungünstig sein. Ich weiß nicht, was du erreichen willst, aber.... wenn ich so ein GeoAlgebra-Ding schreiben müßte, würde ich vermutlich zuerst mal überlegen, ob und inwieweit man vom Renderer abstrahieren könnte (aber da muss man aufpassen, dass man nicht "versehentlich" die ganze Arbeit in die Abstraktion steckt und nicht mehr zu dem kommt, was man eigentlich machen will 😉 ). Der Grund dafür ist nicht zuletzt dass ja SEHR viel "Hirnschmalz" da reinfließen kann (eben alles was reine Modellbildung und Berechnungen sind), was nichts mit der eigentlichen Visualisierng zu tun hat.

 

[Knuffi]

Deswegen frag ich ja hier im Forum nach. 😉

Ich muss mich jetzt nicht auf eines festlegen, natürlich schau ich mir mal den Link und die dort angesprochenen Engines an.
Ein Engine, bei der ich nicht alles selber übernehmen muss, ist mir sogar wesentlich lieber.

 

[Knuffi]

So, nach längerer Zeit hatte ich wieder Gelegenheit, mich mit der Grafik auseinander zu setzen ... :rtfm:

Alles andere hab ich nun eigentlich im Griff, aber mit der Grafik hapert es gewaltig:

Problem 1: Ich suche eigentlich nur was "einfaches", das in einer Swing-Komponente läuft - und letzteres ist anscheinend schon sehr problematisch.
Problem 2: Die oben angeführten Dinger sind ziemlich "overdressed" und die Beispiele, Tutorials, Dokus laufen meist nicht auf das hinaus, was ich suche.

Ich habe mir JMonkey, Xith, jPCT, und sogar LWJGL und JOGL angeschaut (bei den beiden letzten bin ich nicht sehr weit gekommen :bahnhof: ). Meist scheitert es an der Integration in Swing, mit dem ich halt meine restliche GUI zusammensetze und die Grafik würde in einem Tab-Panel laufen.

Weiß denn keiner eine Schnittstelle zu 3D-Grafik (Direct3D oder OpenGL ist mir wurscht, die aktuellen Grafiktreiber können ja eh beides und die Performanz ist auch drittrangig, da ich ja keine 2000+ Triangles habe), die für meine Zwecke (Darstellung von Ebenen, Geraden und Punkten im Kosy mit Drehung des Kosys) geeignet ist?

 

[Marco13]

Ja, stimmt schon, die Integration in Swing kann manchmal fummelig sein. Aber ... welche der Bibliotheken erschien dir denn (abgesehen von der Integration) am geeignetsten für das, was du vorhast?

Es ist nunmal meisten so, dass Grafik IMMER zu langsam ist. Keine full-fledged 3D-Grafikbibliothek wird sich rühmen mit "Ja, Punkte und Linien in 3D gehen, aber bitte nicht mehr als 500 Dreiecke, sonst wird's zu langsam". Die Prioritäten sind da vielleicht üblicherweise andere, als du für dein Projekt setzt. (Deswegen auch der Vorschlag, zu überlegen, inwieweit man vom Renderer abstrahieren kann).

 

[Network]

Ich glaube du hast etwas zu hohe Anforderungen. Du willst eine möglichst Basic Grafikengine (OpenGL) die du aber möglichst schnell lernen kannst ohne Probleme (DirectX).

Die beiden Sachen schließen sich im Grunde schon aus.

Soweit ich weiss und korrigiert mich bitte, unterstützt Java3D sowohl OpenGL als auch DirectX je nach Platform. Jedenfals meine ich das gelesen zu haben.

Die einfachste Schnittstelle für OpenGL ist nunmal "LWJGL".

Auf der Website sind sogar Anfängertutorials die dir die Basics beibringen wie du LWJGL installierst und wie du deine ersten Objekte darstellen kannst!
Das ist am Anfang meist sehr verwirrend aber nach 2/3 Tagen weiss man schnell wies geht.

Das größte Problem wird wahrscheinlich die Kamera sein, mit der du dich durch die Welt bewegen kannst.
In LWJGL kannst du das mit 2 Zeilen Code machen und nie wieder darüber nachdenken. (Naja abgesehen von der Verarbeitung der Inputs). (Selbstverständlich gibt es solche einfachen Möglichkeiten auch in vielen anderen Schnittstellen.)

Raten würde ich dir erstmal dein "System" in 2D darzustellen. D.h. du schreibst ein Programm mit allen erforderlichen Mitteln, Berechnungen, Daten etc.... nur die Darstellung ist vorerst in 2D (Auch wenn man vieleicht nicht soviel sieht.)
Später kannst du dann immernoch das ganze mit einer 3D Anzeige austauschen, was schließlich der Vorteil von OO-Sprachen ist 😉
OpenGL bietet nebenbei natürlich auch eine 2D-Darstellung an. Das wäre natürlich geschickt wenn du erstmal OpenGL in 2D verwendest. Dann lernt man auch viel eher das Prinzip was dahinter steckt und man muss sich nicht gleich mit dem ganzen 3D Mist rumschlagen 😉

Gruß
Network

PS: @Marco13: 500Dreiecke sind aber eig. relativ wenig. Das entspricht weniger als 42 Würfel in OpenGL und weniger als 21 ohne BackfaceCulling 😉 Es sind schon um ein sehr großes Vielfaches mehr bevor ein heutiger Computer einknickt 😉

 

[Knuffi]

Prinzipiell gefällt mir jPCT am besten, da hatte ich zumindest schon die primitiven Objekte wie Box, Sphere, usw.
LWJGL finde ich sehr schwierig für den Anfang.
jME ist auch nicht so schwer, aber halt sehr überdimensioniert.

@Marco: Was meinst du mit "vom Renderer abstrahieren"?

 

[Marco13]

@Network: Bei den Low-Level-Bibliotheken, speziell eben JOGL und LWJGL, ist der Aufwand schon sehr hoch, und die Lernkurve am Anfang IMHO schon ZU steil - d.h. man kann praktisch nichts damit anfangen, außer Tutorials mit möglichst vielen Snippets suchen, aus denen man sich dann (mit viel Trial & Error und geradezu unerschöpflichem Frustrationspotential) dass zusammenklamüsert, was man eigentlich will. Das bezieht sich hauptsächlich auf GL >= 3.1. Früher konnte man ja noch das Redbook durcharbeiten und wußte dann grob, was Sache ist, aber seit 3.1 ist's IMHO schon arg unübersichtlich geworden (siehe auch http://www.java-forum.org/plauderecke/91305-meinung-opengl-3-1-a.html#post578325 ).
Das mit den 500 Dreiecken bezog sich darauf, dass man vielleicht eine schöne, intuitive, schlanke 3D-Lib bauen könnte, die genau den Anforderungen des Threaderstellers entspricht - aber solange man nicht mit VBOs, PBOs, RBOs und VAOs rumhantiert kann man nicht erwarten "die Maximale Performance" zu erreichen.
Zum Glück gibt es einige, die den Spagat zwischen Effizienz und einfacher Verwendbarkeit halbwegs schaffen.

@Knuffi: Mit "vom Renderer abstrahieren" meinte ich, dass man eben nicht in seiner Main-Klasse erstmal JPCT oder LWJGL mit seinem "Display" hochfährt. Und speziell auch, dass man NICHT in seine eigenen Modellklassen ("Line", "Point", "Arrow"...) Methoden einbaut wie "paintThisInSomeOpenGLContextUsingThisAndThatShader". Wie schon oben angedeutet, ist es schwer, zu sagen, wie weit man bei dieser Trennung/Abstraktion gehen könnte oder sollte. Aber statt sowas zu machen wie

class Line
{
    // Fields die Line eben so hat:
    Point p0;
    Point p1;

    // Fields, die höchst-spezifisch für den verwendeten Renderer sind
    JMonkeyEngineEntity lineEntity;
    JMonkeyEngineMaterial material;       

    // Methoden, die Line eben so hat
    Point intersect(Line other) {...}

    // Methoden die höchst-spezifisch für den verwendeten Renderer sind
    void renderThisInto(JMonkeyEngineRenderContext c) {... }
    void setMaterial(JMonkeyEngineMaterial m) {... }
}

könnte/sollte man versuchen, das zu trennen

class Line
{
    // Fields die Line eben so hat:
    Point p0;
    Point p1;

    // Methoden, die Line eben so hat
    Point intersect(Line other) {...}
}

class JMonkeyEngineLine
{
    private Line line; // Vielleicht ...

    // Fields, die höchst-spezifisch für den verwendeten Renderer sind
    JMonkeyEngineEntity lineEntity;
    JMonkeyEngineMaterial material;       

    // Methoden die höchst-spezifisch für den verwendeten Renderer sind
    void renderThisInto(JMonkeyEngineRenderContext c) {... }
    void setMaterial(JMonkeyEngineMaterial m) {... }
}

Um dann später eine Klasse zu haben, mit der man Linien rendern kann

class AbstractLineRenderer
{
    public abstract void renderAllLines();
    ...
}

Und sich aussuchen kann, welche genau man dort verwendet

class JMonkeyLineRenderer extends LineRenderer
{
    JMonkeyRenderContext context;

    @Override
    public void renderAllLines()  
    {
        for (Line line : lines)
        {
            JMonkeyEngineLine rendered = getFor(line);
            rendered.renderThisInto(context);
        }
    }
}

ACHTING: Das ist natürlich hyper-plakativ! In Wiklichkeit kann so eine Abstraktion ziemlich aufwändig sein. Aber sie könnte eben den Vorteil haben, dass deine eigentlichen "Kern-Klassen" nichts enthalten, was spezifisch für die Renderer-Bibliothek ist (und im Idealfall wirklich nicht wissen, OB und WIE sie dargestellt werden).

Allgemein ist so eine Trennung von Modell und Präsentation schon Standard und nie verkerhrt (Stichworte "Model-View-Controller" / "Model-Presenter"). Bei dem Programm, wie du es angedeutet hast, könnte es sein, dass das Aufwand/Nutzen-Verhältnis dieser Trennung zwischen "Modell" und "Rendering" geringer ist, als in anderen Fällen. Aber da keiner genau weiß, was du vorhast, solltest du auf jeden Fall überlegen, ob es dir (auch wenn es etwas aufändiger ist) nicht vielleicht eine Flexibilität und nicht zuletzt eine "Sauberkeit der Architektur" (im Hinblick auf klare Trennung von Rollen und Aufgaben der einzelnen Klassen, im Sinne einer "Separation of Concerns") bringt, die es wert ist.

 

[Knuffi]

Interessant 🙂

Genau das schwebte mir von Anfang an vor. Ich habe Klassen für Punkte, Vektoren, Geraden, Ebenen und Kugeln. Die haben erst mal gar nichts mit der Grafik zu tun. Eventuell baue ich noch ein paar Eigenschaften ein, die die Darstellung dann später vereinfachen (falls die 3D-Engine ein seltsames Kosy hat, muss man ja einiges würfeln), ansonsten sollte die Darstellung aber schon einer eigenen Klasse überlassen werden.

Dann weiß ich zumindest, dass ich auf dem richtigen Weg bin ... *seufz* ich vergrab mich dann halt mal in jPCT und oder JME