Funktionsweise einer 3D Engine

[DarkDragon]

Ray Traycing - Was ist das eigentlich?

´

Da wird das zu rendernde Bild durch Strahlen(meist rekursive Strahlen) berechnet. Damit kannst du solche Grafiken wie in Shrek/Toy Story/Final Fantasy(der Film) erzeugen.

[Hades]

Ok, noch mal etwas ausführlicher.

Von einem virtuellen Auge vor dem Bildschirm aus wird ein Strahl durch jedes Pixel des Bildschirmes geschossen.
Für jeden dieser Strahlen wird dann überprüft ob und welches der Objekte in der Szene er trifft. Die Farbe die das Objekt an der Stelle hat wird dann auf das Pixel übertragen.

Um die Farbe des Objektes zu bestimmen muss man allerdings einige weitere Dinge berechnen. Wenn das Objekt z.B. eine reflektierende Oberfläche hat schickt man einen Strahl in die entsprechende Richtung und schaut welches Objekt er als nächstes trifft.
Ist das Objekt transparent, dann wird der Strahl evtl. gebrochen, und durch das Objekt hindurch geschickt.
Weiterhin werden Strahlen von dort aus in Richtung der Lichquellen geschickt um zu schauen ob sie von anderen Objekten verdeckt werden. Dadurch erhält man dann Schatten.
...

Auf diese Weise kann man unglaublich realistische Bilder erschaffen, und das mit viel weniger Programmieraufwand als mit den heutigen Rasterizern.

[Danilo]

Danke für die vielen Links und Infos. Mal sehen... Ich denke, dass ich mir dieses Buch kaufen werde.

Ich hatte gestern nicht mehr so viel Zeit, aber nachdem ich jetzt
nochmal in mein Bücherregal geschaut habe, möchte ich Dir noch
diese Links zeigen:

- 3D Game Engine Design von David H. Eberly
(Neue Version kommt wahrscheinlich 2006: 3D Game Engine Design)

Diese Buch von Eberly ist quasi der Standard für 3D-Engine-Coder.
Es ist nicht wie die DX-Bücher wo auch meist eine kleine Engine
entwickelt wird, sondern hier wird unabhängig von der Schnittstelle
(DX, OpenGL, etc..) direkt auf die Engineentwicklung eingegangen.

Kapitel sind dabei: Geometrical Methods (Grundlagen wie Transformations,
Quaternions, Euler Angles, uvm.), The Graphics Pipeline, Hierarchical Scene
Representations (Scene Graph), Picking, Collision Detection, Curves,
Surfaces, Animation of Characters, Geometric Level of Detail, Terrain,
Spatial Sorting, Special Effects.

Vom gleichen Author gibt es auch noch:
- Geometric Tools for Computer Graphics
Dieses 1000-Seiten Buch ist vollgestopf mit Theorie, Formeln,
Codes, Problemlösungen zur 2D und 3D-Grafikprogrammierung.

Die 2 folgenden von Eberly kenne ich allerdings nicht selbst:
- 3D Game Engine Architecture
- Game Physics

Wenn es Dir ernsthaft um 3D-Engines geht, und nicht nur mal
um eine kleine DirectX-Engine für ein Game, dann solltest Du
Dir den Name Eberly auf jeden Fall merken.


Hier noch mehr Spezialbücher:
- Real-Time Rendering von Tomas Akenine-Möller und Eric Haines
- Real-Time 3D Terrain Engines Using C++ and and DirectX 9
- Real-time 3D Character Animation with Visual C++

Du kannst auch mal direkt bei den Verlagen und bei den
englischen Büchern auf amazon.com schauen.
Dort findet man meist noch mehr Informationen, Beispiel-
kapitel, usw.
Wie Du schon siehst: Bei guten Spezialbüchern muß man
sich meist auf dem englischen Markt umschauen. Und die
Preise siehst Du ja selbst...


Zu einer 3D-Engine gehört schon bissl mehr als ein paar Funktionen
zur Kollisionserkennung, Picking und ein paar Meshes an die
GraKa zu übergeben.
Diese Funktionen gehören natürlich dazu, da die Engine diese
ganzen Objekte ja eh schon verwaltet.

Stell Dir mal ein Level vor mit einem Terrain und einem großen
Schloß, also ein Indoor-Teil.
Die Engine verwaltet nun intern all diese Daten. Bei der Terrain-
Darstellung kümmert sich die Engine ums LOD (Level of Detail),
also das näher liegende Dinge mit mehr Details dargestellt werden
als weiter entfernte.
Unnötige (nicht sichtbare) Bereiche sendet die Engine garnicht
erst an die Grafikkarte, d.h. die werden rausgeclippt. Es muß
also berechnet werden was sichtbar ist und was nicht.
Wenn Du vor einem Hügel/Berg im Terrain stehst, dann braucht
man die Hinterseite dieses Hügels auch nicht darstellen, da Du
das eh nicht siehst.

Indoor ist es genauso. Dein Schloß hat z.B. 35 Räume, aber
Du hältst Dich immer nur in einem Raum auf und brauchst
somit nicht alle 35 Räume darstellen.
Die Übergänge zwischen den Räumen kann man z.B. über
Portale machen.
In dem Raum, in dem Du Dich befindest, muß aber auch nur
das für Dich sichtbare dargestellt werden. Also braucht man
das was hinter Dir ist nicht mit darstellen.

Die Engine verwaltet also alle Sachen (Kamera, Objekte/Figuren,
Terrain, Räume usw.) und stellt zur Steuerung Funktionen dafür
zur Verfügung. Du sagst dann letzendlich nur "MoveCamera(x,y,z)"
oder "AnimateObject("laufen") im Programm.
Das da haufenweise spezielle Formeln und Techniken benötigt
werden ist klar. Kollisionserkennung, Picking usw. sind aber
nur ganz kleine Teilgebiete einer Engine.

Ich vermute mal das DarkDragon da den Fehler macht und
"nur" einzelne Funktionen gemacht hat. Von Scene Graph,
BSP usw. habe ich von ihm jedenfalls noch nie was gehört.
Das was er so sagt hört sich aber nicht nach einer richtigen
3D-Engine an.
Wenn man ein großes Level hat, dann kann man ja nicht einfach
alle Daten des Levels an die Karte schicken. Von Geschwindigkeit
würde man dann nichts sehen, aber genau das gehört bei einer
Engine auch dazu.

Der Nutzer sagt einfach LoadWorld() und MoveCamera() und
bekommt dabei garnicht mit was dabei alles gemacht werden
muß.
Die ganzen Texturen müssen z.B. auch verwaltet werden, so
wie eben auch die oben genannten Dinge.

Da sind schon einige Berechnungen nötig. Was wird bei einer
bestimmten Kameraposition wie und mit welchen Texturen
dargestellt. Dazu kommen dann später noch mehr Verwaltungs-
aufgaben, z.B. wenn Objekte bestimmte Shader benutzen usw.
Da es auch noch performant sein soll, berechnet die Engine
auch noch in welcher Reihenfolge alles ausgegeben werden
soll. Wenn 5 von 50 Objekten in einem Raum die gleiche
Textur verwenden, dann sollte man diese Objekte beim Rendern
wenns geht zusammenfassen, anstatt einfach Objekt 1 - 50
nacheinander darzustellen (und dabei immer wieder die
Textur wechseln).


Interessantes Thema - aber ganz so einfach, wie sich das
manche Leute vorstellen, ist es dann auch wieder nicht.


Was Dir dabei klar sein sollte: Diese Bücher benutzen fast
immer C und C++ wenn es um Code geht. Einige (ältere)
Bücher auch schonmal ASM.
Damit solltest Du Dich schon ein bissl anfreunden. Jedenfalls
solange bis PB sich durchgesetzt hat und dann der Standard
auf dem Markt und somit auch in Büchern sein wird.

Du kannst das Gelernte zwar auch mit PB umsetzen, aber für
eine richtige 3D-Engine ist OOP mit z.B. C++ schon sehr
sinnvoll. So kannst Du sehr schön voneinander unabhängige
und strukturierte Klassen für alles entwickeln.
Kann man nur empfehlen - entscheiden wirst Du das selbst.

[Spirit]

Ich hab mal noch 'ne Frage zu Ray Traycing. Bestehen da die Objekte immer noch aus Polygons?

[Zaphod]

raytracing ist von der art der datenverwaltung unabhängig, will heißen, die objekte können aus polygonen bestehen, müssen es aber nicht.

[Spirit]

Aus was können sie denn noch bestehen?

[Zaphod]

alles was eine oberfläche definiert, von der man den ort eines schnitpunktes mit einem strahl berechnen kann.
also zb kugeln, nurbs, metaballs etc

[Hades]

http://www.realstorm.com/ finde ich auch sehr interessant.