OpenGL - Grundsatzfragen

[stahli]

Ich habe mal ein bischen über OpenGL gelesen.

Infos findet man vor allem hier: http://www.delphigl.com/
Und in der DP habe ich einen alten Kurs gefunden: http://www.delphipraxis.net/5347-opengl-kurs.html
(Nachträglichen Dank an Mr_T!)

Zur Klärung einiger Fragen habe ich das Konzept aber noch nicht verstanden. Ich werde am Wochenende noch einige Turorials lesen, aber vielleicht kann ja wer schon mal kurz und knackig zu etwas Erleuchtung beitragen?


1) Rendern im Mainthread
Das Rendern wird über Timer oder OnIdle laufend erledigt und das fertige Abbild mit SwapBuffers auf das Formular geklatscht.

In der Renderfunktion wird ein Würfel gezeichnet, gestretcht und gedreht und wird somit dargestellt. Alles paletti.

Wenn ich aber eine riesige Welt habe kann ich doch nicht in der Renderfunktion alle Objekte berechnen. Prüft man daher erst, ob sich das Objekt oder Würfel nah genug an der aktuellen Kamera befindet?

2) Maus
Kann man (ähnlich der VCL) ermitteln, über welchem Objet und an welcher Position genau sich die Maus befindet? Ich stelle mir das schwer vor, da ein Objekt ja gedreht, gekippt und scaliert sein kann.
Kann man mit vertretbarem Aufwand irgendwie ein Drag&Drop realisieren und kann ich einem Objekt beibringen, dass es unter Umständen für die Maus transparent sein soll (dass also z.B. ein DragOver vom dahinter liegenden Objekt verarbeitet würde)?

3) Tastatur + TextCursor
Wenn man so eine Art Edit oder Memo basteln wollte ... ist so etwas denkbar bzw. gibt es bereits grundlegende Funktionalitäten, die dabei unterstützen? In GLScene gibt es ja solche Komponenten, aber könnte man das mit vertretbarem Aufwand auch selbst realisieren?

4) Businesslogik und Threads
Einen Würfel zeichnen und über Timer drehen lassen ist ja schön und gut. Aber für eine echte Anwendung ist das m.E. kein schlüssiges Konzept.
Wenn meine Drehfunktion z.B. 1 Minute brauchen würde, dann würde meine Anwendung 1 Minute hängen, genau wie in diesem Fall die VCL.
Ich dachte - so meine bisherige Unterstellung - in einer Grafikengine würde ein anderes Konzept vorliegen, dass also die Darstellung auf der Zeichenfläche vom Ablauf der Anwendung (Businbesslogik) stärker entkoppelt wäre.
Wenn ich mit meiner Figur eine Mauer einrenne und ein paar Feuerkugeln werfe, fallen ja die Mauersteine runter und die Feuerkugeln vernichten alle Monster. Wie wird so etwas denn dann i.d.R. verarbeitet? Läuft dann ein MauereinsturzThread bis alle Steine unten liegen und währendessen kann ich im Mainthread meine Figur weiter steuern? Müsste man also aufwendigere Aktionen auch immer in eingenen Threads ausführen damit das Formular nicht einfriert? (Wenn ich gerade so drüber nachdenke wird es wohl so sein, da Windows sonst ja sicher schon selbst das Formular als inaktiv erkennt - oder?).

Insofern ist mein Versuch hier vom Ansatz her wahrscheinlich doch nicht so falsch gewesen - wobei die VCL dafür nicht wirklich taugt.

[Der schöne Günther]

Da ich mir dein Projekt selbst noch nicht genau angesehen habe kann, hier nur ganz konkret auf die Fragen:

1) Wenn es dir um die Performance geht fängt man entweder an, Objekte vom Rendering auszuschließen und/oder in einem niedrigeren Level of Detail darzustellen. Bei reinen Sprites macht das heute keinen wirklichen Sinn, für "richtige" 3D-Szenen mit viel Geometrie und komplexen Shadern kann man hier aber viele tolle Dinge anstellen, mehr als meist tatsächlich getan wird. Beispielsweise könntest du Cluster bilden und wenn der Großteil der enthaltenen Objekte nicht wichtig ist (bsp. sich nicht vollständig im View Frustum befindet oder die Entfernung von der Kamera hoch ist), sie alle durch eine vereinfachte Cluster-Repräsentation ersetzen.

2) Such mal nach "Mouse Picking" und "Ray Casting". Das hier ist speziell für OpenGL und schaut lustig aus

4) So etwas hatten wir, meine ich, neulich schon einmal- Die Verarbeitung der Eingabe (Tastatur), die Rendering Pipeline und bsp. die Physik-Berechnung laufen in der Regel nicht synchron.

[Zacherl]

Zu 4:
Bei einer Animation merkst du dir in der Regel die Startzeit der Animation. Dann prüfst du in jedem Frame die aktuelle Zeit und berechnest den Fortschritt der Animation (z.b. der Winkel der Rotation) anhand der vergangenen Zeit.

Für eine linear ablaufende Animation wäre das z.b. ganz einfach:
360 * Round((CurrentTime - StartTime) / AnimationTime)

[stahli]

Ok, danke schonmal.

Wenn ich einen fallenden Zielstein darstelle, dann befindet sich nicht das fertige Objekt im Speicher und wird nur noch gedreht und verschoben, sondern der Stein wird bei jedem Frame abhängig von seiner Lage und Position neu "zusammengesetzt", dargestellt und als grafisches Objekt wieder "vergessen" - richtig?

Im Prinzip machen es die VCL und FMX ja genau so - nur dass dort noch ständige gegenseitige Neuzeichnungen ausgelöst werden, wenn ein Objekt verschoben wird.

In meinem oben verlinkten Versuch habe ich dagegen die "2D-Objekte" nur einmal gezeichnet und diese erzeugten Abbilder immer wieder beim Zeichnen des Formulars verwendet.

Es sind also völlig unterschiedliche Ansätze und ich tue mich derzeit schwer zu entscheiden, welcher für Fachanwendungen der bessere ist (3D ist ja normalerweise nicht erforderlich).


Die dritte Frage würde mich natürlich trotzdem noch interessieren. Wenn man ein Memo selbst aufbauen sollte, incl. Wortumbrüchen, Textcursor usw. das wäre ja ein echtes Mammutprojekt.

[Mavarik]

Hi!

OpenGL oder auch DirectX (ich habe lieber DirectX genommen)

Hat ja im eigentlichen nix mit der Logic zu tun, sondern bildet ja "nur" die Schnittstelle zur Grafikkarte und zur GPU.
Ob und welche Teile du in Thread auslagerst spielt eigentlich keine Rolle.

I.d.R. hast Du heute TFT's mit 60Hz also ist 60 FPS das Ziel. Wenn Deine Berechnungen schneller sind, Prima dann hast Du Zeit für andere Dinge.

Ich frage zwischen jedem Frame die Tastatur ab, weil es ich nicht leiden kann, wenn eine Tastenreaktion nicht sofort einen Effekt hat.
Wenn Deine 3D Scene zu aufwendig wird, musst Du also gemäß Deinem Kamerawinkel und der Entfernung der Objekte erst mal Deine 3D Objekte vor sortieren.
Dann über einen ZBuffer rausbekommen ob nicht ggf. eine Vielzahl von Objekten überhaupt nicht sichtbar sind. (Beispiel: Hinter der Wand stehen 1000 Bäume)

Ich habe vor meinem Snakeland 3D diese Buch gelesen und dann über ein 3D Forum und wöchentlichen Online-Teamspeak-Usertreffen den Rest gelernt.

Für bewegte Objekte z.B. ein Schuss oder ein sich bewegendes Objekt, rechnest Du ja nicht strikt alle Positionen der Bewegung nacheinander, sondern Du berechnest gemäß der Zeit an welcher Position das Objekt gerade seien soll. ggf. werden dann 20 Zwischenpositionen einfach weggelassen.
Für jedem Mauerstein hast Du also in Deiner Renderpipeline einen Eintrag. (Lassen wir mal die Kollisionen und Beeinflussungen durch andere Steine weg)
Bei Start von "Mauereinsturz" stehen also gemäß "soll 2 Sekunden dauern" schon alle Positionen fest. Wenn Du also den Aufruf für RenderSteinXY bekommst, musst Du berechnen wie viel Zeit seit dem Start vergangen ist und dann den Stein an der richtigen Position Rendern. Nur so bekommst Du Bewegungen die unabhängig von CPU,GPU Taktfrequenz und Dauer der Berechnung ist.

Mavarik

[Uwe Raabe]

Zitat von stahli:

Die dritte Frage würde mich natürlich trotzdem noch interessieren. Wenn man ein Memo selbst aufbauen sollte, incl. Wortumbrüchen, Textcursor usw. das wäre ja ein echtes Mammutprojekt.

Deswegen gibt es ja solche Frameworks wie GLScene oder VGScene (aka FireMonkey). Wenn man jetzt nicht was komplett anderes braucht, macht es doch wenig Sinn das alles neu zu erfinden.

[Mavarik]

Zitat von stahli:

Es sind also völlig unterschiedliche Ansätze und ich tue mich derzeit schwer zu entscheiden, welcher für Fachanwendungen der bessere ist (3D ist ja normalerweise nicht erforderlich).


Die dritte Frage würde mich natürlich trotzdem noch interessieren. Wenn man ein Memo selbst aufbauen sollte, incl. Wortumbrüchen, Textcursor usw. das wäre ja ein echtes Mammutprojekt.

Ohh ich glaube ich habe Deine Frage völlig falsch verstanden...

[stahli]

Danke Euch! Das waren so schon sehr hilfreiche Antworten.

Mein Interesse ist schon eine Fachanwendung, kein Spiel.

Dennoch könnte man das ja mit einer 3D-Engine angehen, was sicher Vor- aber auch Nachteile hätte.

FMX ist m.E. leider nicht so ernst zu nehmen, dass man darauf dauerhaft setzen könnte. Teile sind sicher gut umgesetzt aber in der Gesamtheit ist das eher unbrauchbar. Dass sich daran noch etwas ändern wird ist wohl leider auch nicht zu erwarten.

Daher interessieren mich mögliche Alternativen. Aber es ist schon nicht einfach, die grundlegenden unterschiedlichen Ansätze zu verstehen.

In einer Spieleengine kann man ja m.E. z.B. ein Karussell schnappen und in die Landschaft packen. Ab sofort dreht sich das "eigenständig", ohne dass man sich drum kümmern muss.
Das würde ich mir auch von einem AniIndicator erwarten und von einer Progressbar, wenn deren Value geändert wird.

Ich hatte so etwas bei FMX erwartet. Inzwischen sehe ich, dass das gar nicht so einfach zu realisieren ist.

Das ändert aber nichts daran, dass FMX bei mir inzwischen (fast) aus der Wertung ist - vor allem auch wegen der Firmenpolitik von Emba.


Wegen möglichen Alternativen bin ich mir noch unsicher...

[Der schöne Günther]

Ich verstehe noch nicht ganz wo das 3D herkommt und was die Zielplattformen sind. Würdest du es auf Windows beschränken können/wollen? Könnte man perspektivisches 3D-Rendern nicht ausschließen?

[stahli]

Wenn ich das nur wüsste!

Ich versuche erst einmal nur, mir einen Überblick über die möglichen Ansätze und Konzepte zu verschaffen.

3D ist für Fachanwendungen i.d.R. ja nicht erforderlich. Man könnte sich aber u.U. auch neue Ansätze vorstellen (ich jedenfalls ). Z.B. wäre ein Effekt denkbar, dass die Controls leicht kippeln, wenn man mit der Maus drüber fährt.
Oder man könnte Kundenkärtchen hintereinander aufreihen, als Historie der letzten bearbeiten Adressen z.B.
FMX hat ja da auch bereits Lösungen (jedenfalls grundsätzlich).

Jedenfalls könnte eine Anwendung mit 3D-Inhalten optisch ansprechend und angenehm bedienbar sein. Natürlich braucht man dann keine 3D-Landschaften usw.
Statt dessen müssten die üblichen Controls angeordnet werden können, die aber mit einer Textur überzogen werden könnten.


Einiges wird einfacher, wenn man sich auf 2D beschränkt (geht ja auch mit OpenGL bzw. SDL.
Wenn man eine entsprechende Engine bauen wollte, würde man schon erst einmal vor der Frage stehen, ob 2D oder 3D.


Davon abhängig sind dann die weiteren Möglichkeiten, Aufwände und mögliche Plattformen.


Ich versuche nur herauszufinden was ich mir eigentlich wünsche, selbst wenn das dann nicht erfüllt wird.