OpenGL - Grundsatzfragen

[Zacherl]

Von 3D würde ich dir abraten. Ich bastele selbst momentan an einem eigenen GUI Framework, welches sich neben GDI+ auch per DirectX und OpenGL rendern lassen soll. Das Projekt ist schon recht fortgeschritten und das Grundgerüst inklusive Standardcontrols (Form, Button, Label, PageControl, etc.) funktioniert schon sehr gut.

Bisher ist nur der DirectX Renderer implementiert und bereits für reine 2D Darstellung (primär gefüllte und nicht-gefüllte Rechtecke und Grafiken / Icons) ist der Aufwand schon enorm hoch (mehrere 1000 Zeilen Code). An kreisförmige Objekte oder sonstige nicht rectanguläre Polygone möchte ich im Moment noch gar nicht denken.

Wenn du doch kleine 3D Effekte haben willst (z.b. beim Click auf einen Button), kannst du das wunderbar durch Farbänderungen vortäuschen, ohne dass deine Engine im Hintergrund mit irgendwelchen 3D Matrizen und unterschiedlichen Z Werten hantieren muss.

[Namenloser]

Sehe ich auch so. 2D ist kompliziert genug...

[stahli]

Sehe ich - inzwischen - auch so.

[Mavarik]

Zitat von Zacherl:

Bisher ist nur der DirectX Renderer implementiert und bereits für reine 2D Darstellung (primär gefüllte und nicht-gefüllte Rechtecke und Grafiken / Icons) ist der Aufwand schon enorm hoch (mehrere 1000 Zeilen Code). An kreisförmige Objekte oder sonstige nicht rectanguläre Polygone möchte ich im Moment noch gar nicht denken.

...mehrere 1000 Zeilen Code...

Was machst Du den in diesen Zeilen alles...

"Mein 2D GUI auf DirectX" mit animierter Maus, Labels, Checkbox, Combobox und Button, welches ein 2D GUI im 3D Adressraum für mein Spiel rendert ist nur 1200 Zeilen lang. Es erhebt zwar nicht den Anspruch an die Funktionalität der VCL, aber funktioniert.

Mavarik

PS.: Ohne die Diskussion anzufangen ob es Sinn mach ein eigenes Framework zu schreiben, wofür die Arbeit? Um sich damit zu beschäftigen und etwas zu lernen, OK! Um damit Geld zu verdienen? Doch eher nicht, oder?

[Zacherl]

Zitat von Mavarik:

Mein 2D GUI auf DirectX" mit animierter Maus, Labels, Checkbox, Combobox und Button, welches ein 2D GUI im 3D Adressraum für mein Spiel rendert ist nur 1200 Zeilen lang. Es erhebt zwar nicht den Anspruch an die Funktionalität der VCL, aber funktioniert.

Da unterscheiden sich wohl einfach unsere Anforderungen. Bei mir ist der Renderer (Abstrakte Klassen + konkreter DirectX Renderer) alleine halt schon über 1500 Zeilen lang. Beinhaltet allerdings auch noch Funktionen zum Zeichnen von Icons / Grafiken und hat einen gewissen Overhead, der dem abstrakten Konzept geschuldet ist.
Grundklassen wie "TDXComponent" und "TDXControl" fallen nochmal mit 2200 Zeilen ins Gewicht. Dazu muss ich allerdings sagen, dass ich bestimmte (umfangreichere) Funktionalitäten der VCL (wie z.b. Aligning) durchaus nachgebaut habe.

[Mavarik]

Zitat von Zacherl:

Dazu muss ich allerdings sagen, dass ich bestimmte (umfangreichere) Funktionalitäten der VCL (wie z.b. Aligning) durchaus nachgebaut habe.

OK, Dann verstehe ich das.

[blackfin]

Auch wenn das meiste bereits beantwortet wurde, hier noch mein Senf dazu :

zu 1)
Wenn du eine konstante Animationsgeschwindigkeit willst, google mal nach "Framerate independent movement / animation". Die Lösung per Timer ist meistens ungenau, da man kaum sagen kann, wann der Timer wirklich getriggert wird, selbst bei einem MMC-Timer.
Das Prinzip basiert einfach darauf, dass der Animations-Fortschritt bei jedem "OnIdle" o.Ä. neu berechnet wird und somit bei jedem Frame die Zeitdifferenz zwischen dem letzten gerenderten Frame / Event und dem aktuellen genommen wird und dort interpoliert wird, wie weit die Animation bei der aktuellen Zeitdifferenz "weiterbewegt" werden muss. Als Ergebniss erhälst du eine konstante Animationsgeschwindigkeit, die unabhängig von der aktuellen Framerate ist. Dieses Prinzip solltest du von Anfang an berücksichtigen, da bei "Vergessen" die nachträgliche Implementation durchaus schmerzhaft sein kann

Um Objekte auszuschliessen, die gerade in einer "riesigen" Welt nicht berechnet werden müssen und um die Performance zu optimieren, verwendest du am besten ein vierstufiges Verfahren:

1. Frustum Culling
Das bedeutet, alle Objekte, die sich gänzlich nicht im Bereich des aktuellen Viewport / Frustum befinden, werden komplett ignoriert / nicht gerendert.

2. Z-Buffer Culling
Das bedeutet, im Bereich des Frustums werden Objekte, die gänzlich von anderen verdeckt werden, nicht gerendert.

3. Z-Buffer LOD
Das bedeutet, im Bereich des Frustums werden sichtbare Objekte, die weiter von der aktuellen Kameraposition entfernt sind, mit geringerer Detailstufe / Polygonanzahl gerendert.

4. Texture Mip-Mapping
Das bedeutet, im Bereich des Frustums werden sichtbare Objekte, die weiter entfernt sind, mit einer kleineren Texturauflösung / mit weniger Details gerendert.


zu 2)
Verwendest du OpenGL, vergiss ganz schnell die implementierten "Picking-Funktionen". Diese sind, gelinde gesagt, extrem langsam.
Viel schneller bist du mit Raycasting, das heisst, du prüfst einfach anhand des Aussendes eines "Strahls" und des Z-Buffers, welches Objekt bei deiner Mausposition an vordester Front liegt (oder überhaupt vom Vektor geschnitten wird).

zu 3)
Hier wird es aufwändig. Da 3D-Apis so etwas wie "Schrift" an sich nicht wirklich kennen und alles meist über Bitmap-Fonts und Texturen gelöst wird, musst du die vollständige Funktionalität eines Memos o.Ä. selbst in Code giessen, wenn du keine Komponenten benutzen willst. Das ist durchaus machbar, aber extrem langwierig zu implementieren und aufwändig. Macht aber Spaß Ansonsten kannst du ggf. auch auf solche Nettigkeiten wie "ScaleForm" zugreifen, falls du ein wenig Geld dafür ausgeben willst.

zu 4)
siehe 1). Eine 3D-Anwendung arbeitet nie eine Animation "als Ganzes" ab, so dass eine Anwendung während einer Animation nie hängt, sondern nur immer Schrittweise per Frame mit den entsprechenden Berechnungen und Anpassungen weitergeht.
Willst du Physik implementieren, dann machen separate Threads durchaus Sinn, das Ganze dann aber Event-gesteuert und nicht linear / strikt funktional.

[stahli]

Ja danke!

Inzwischen habe ich ein paar Dinge auch schon besser verstanden.

In meiner kleinen Demo (http://www.delphipraxis.net/1244209-post52.html) habe ich jetzt einen kleinen "AniIndikator" und eine kleine "PrograssBar" (eigentlich nur Ansätze davon), die ihren Fortschritt zeitangepasst aktualisieren.

Und ich bin zu dem Schluss gekommen, dass 3D eher keinen Sinn macht.

Eine gute 2D-Alternative zur VCL und FMX würde mir aber sehr gefallen - unabhängig mal, wo die her kommt...
Man müsste sich nicht mit Altlasten (VCL) und Problemen (FMX) herumschlagen und könnte auf schlanke Basiscontrols aufbauen.
Träume darf man ja haben!

[blackfin]

Zitat:

Eine gute 2D-Alternative zur VCL und FMX würde mir aber sehr gefallen - unabhängig mal, wo die her kommt...

Vielleicht solltest du dir mal QT ansehen (kann man direkt aufs OpenGL / DX rendern), oder OpenGL mit CEGUI verbinden...
Als "intermediate Layer" gibt es auch noch die SDL mit ihren diversen GUI-Frameworks.

[Namenloser]

Jap, Qt ist echt cool. Vor allem weil es durch das Signal-Slot-System so leicht ist, mit mehreren Threads zu arbeiten und die GUI z.B. asynchron zu updaten.