Thema: Delphi OpenGL - Grundsatzfragen

Einzelnen Beitrag anzeigen

blackfin
(Gast)

n/a Beiträge
 
#17

AW: OpenGL - Grundsatzfragen

  Alt 19. Jan 2014, 18:12
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.

Geändert von blackfin (19. Jan 2014 um 18:17 Uhr)
  Mit Zitat antworten Zitat