OpenGL - Grundsatzfragen

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