Grundlagen 3D Programmierung Vektorgrafiken

Wenn du die 3D mathe drau hast, dh Transformationen & Rotationen, Euler 
und Quaternionen, dann kann eigentlich nicht mehr viel schief gehen. Um 
mit OpenGL effektiv arbeiten zu koennen, sollte man das auch drauf 
haben. OpenGL ist eine Zwischenschicht, die einen Haufen brauchbarer 
konzepte integriert. Wenn man von null anfaengt sollte man nicht 
vergessen gleich mit Objekten zu arbeiten. Das ist das Paradebeispiel 
fuer objektorientierte Programmierung.

Du brauchst nur den Satz von Pythagoras. Dann musst du dir sowas wie 
eine zentrische Streckung in 3D vorstellen können das wars. Am 
einfachsten machst du die Darstellung mit Z-Buffering. Drehen, Strecken 
und Schieben kann man nicht auf einmal sondern muss es nacheinander 
machen. Also ein Sechseck wird zunächst auf den Ursprung bezogen, dann 
rotiert (sin/cos) und gestreckt (multipliziert) und dann an die richtige 
Stelle geschoben (addiert). Das geht mit allen Objekten dann so. Spielt 
auch keine Rolle ob es 3 oder 10 Dimensionen sind.

Wenns nicht mehr ist ;-) Pytagoras kenne ich natürlich und bei den 
Vektoren war ich auch schon. Dann hab ich ja schon ne fast das nötige 
Wissen. Trotzdem fehlt da noch etwas z.B. um eine Pyramide in Gitterform 
auf ein Display zu bekommen.

@ sechszweisechs : OpenGL wollte ich ja gerade nicht.

Gibts es da vielleicht irgendwo Tutorials für den Einstieg ?

Oder Bücher wären auch interessant.

Als ich vor einigen Jahren etwas mehr Zeit für 3D-Programmierung übrig 
hatte, gab es ein Buch von Stefan Zerbst indem die Grundlagen sehr gut 
erklärt waren. Zunächst so Dinge wie Vektorrechnung, Matrizenrechnung 
und Transformationen und später dann auch wie man das ganze in D3D 
programmieren kann. Leider find ich jetzt keine ISBN, dafür aber was 
neues von ihm:

ISBN: 978-3-8272-6400-8

Wenn er seinen Stil beibehalten hat, sollte das ganze recht brauchbar 
sein. ;)

Die Gitterform ... Das ist der Weg, wie die Pyramide gespeichert ist. 
Als Satz von Dreiecken, die an den passenden Kanten verbunden sind. Das 
nennt sich Displayliste. Du kannst nun einen Konverter schreibend, der 
einen Flaeche in diese Dreiecke zerlegt, oder die Dreiecke gleich selbst 
eingeben.

Der Satz von Pythagoras ist meines erachtens nicht genug. Man sollte mit 
Rotations- und Transformationsmatrizen vertraut sein. Wenn man die 
gepackt hat benoetigt man auch kein Tutorial mehr.

http://ndef.triebtaeter.de/ erklärt zumindest die wichtigsten Grundzüge 
für die 3D-Projektion.

Damit kann man zumindest schonmal Wireframes darstellen.

Hab zu Schulzeiten mal mit zwo andren n 3D-Hack'n'Slay mit 
selbstgebautem Softwarerednerer gebastelt. Blos das die Performance 
davon nicht so ganz das war, was wir uns erdacht hatten. (Das biest hat 
jedes einzelne Pixel mit SetPixel() gemalt) - auf nem P2-350 machte das 
immerhin 0,5-1fps.
Aus heutiger Sicht war da viel Crap drin, aber wir ham auch viel dabei 
gelernt.

Wenn es dich dann irgendwann zu OpenGL zieht, dann kann ich die 
NEHE-Tutorials nur empfehlen.

Ein Einstiegstutorial in OpenGL und C++ (nicht VC++, sondern GCC) suche 
ich für den Anfang auch noch...

Das ist von der IDE unabhängig.
Wenn dir vertraut ist, wie du deinen Compiler/deine IDE benutzt, dann 
funktionieren die NEHE-Beispiele auch damit.
Der OpenGL-Kram ist auch auf anderen Systemen der gleiche.
Den windowsspezifischen Code kann man rauskürzen und evtl gegen anderes 
umtauschen.

Eventuell bietet sich hier Qt für das drumherum an.

Es gibt da noch ein Problem, wenn man "im Körper drin ist". Dabei kommt 
schon mal öfter eine Division durch Null vor. Das kann man über 
Exceptions (nicht strukturiert, oder auch strukturiert) abfangen oder 
vorher prüfen (Aufwand) oder eine Dummy-Dimension mehr zufügen (Aufwand) 
also immer mit 4 Dimensionen rechnen.

Für eine HighEnd Variante gibt es ein Buch vom Ottmann wo die Geometrie 
der Objekte beibehalten wird:

ad.informatik.uni-freiburg.de/lehre/ss99/geometrische-algorithmen/vorles 
ung/einleitung.ps.gz

Z-Buffering ist eine effektive Abkürzung für die Darstellung und 
auflösungsabhängig. Ab einer gewissen Komplexität rechnet es sich mit 
geschnittenen Objekten besser.

Kann Dir "Tricks of the 3d game programming gurus" von Andrê LaMothe 
(Der Typ wo auch die Hydra Propeller Gamestation Entwickelt hat) 
empfehlen. ISBN 0-627-31835-0 , leider nur schwer oder teuer (~40-100€ 
gebraucht) in D zu bekommen. Dafür bekommt man aber auch eine ziemlich 
komplette Erklärung der nötigen Mathematik und den Source Code aller 
Beispiele. Am Ende steht eine volle Software 3D Engine mit allen "Bells 
and Whistles" die Quake MD2 Models lädt. Die Anfänge von 3D Engines 
(Vektor Engines, Voxel/Raycaster etc) sind auch mit Beispielen 
beschrieben.

Gruß
Claude

PS: Darf man fragen wofür das ganze gedacht ist? Nur Grundlagen oder
    schon ein konkretes Ziel im Auge (PC/uC/FPGA..)?

> Es gibt da noch ein Problem, wenn man "im Körper drin ist". Dabei kommt
> schon mal öfter eine Division durch Null vor. Das kann man über
> Exceptions (nicht strukturiert, oder auch strukturiert) abfangen oder
> vorher prüfen (Aufwand) oder eine Dummy-Dimension mehr zufügen
> (Aufwand) also immer mit 4 Dimensionen rechnen.

Die 4 Dimensionen braucht man aus anderen Gründen. Sie sorgen vor allem 
dafür, daß man auch das Verschieben von Objekten als Multiplikation mit 
einer Matrix darstellen kann.

Die 3D-Engine kann man in zwei grundlegende Teile gliedern, nämlich die 
vektorbasierten Berechnungen im 3D-Raum und den Rasterizer, der dann 
nachher die transformierten und nach 2D projizierten Koordinaten 
verwendet, um dann konkret Pixels zu malen.
Diese beiden Teile kann man gesondert betrachten. Teil 1 kannst du auch 
mit OpenGL oder DirectX machen. Damit kommt man dann schneller zu einem 
Ergebnis, unter das du danach dann immer noch deinen eigenen Rasterizer 
hängen kannst. Man muß ja nicht gleich im ersten Schritt alles komplett 
selber machen.

>Die 4 Dimensionen braucht man aus anderen Gründen. Sie sorgen vor allem
>dafür, daß man auch das Verschieben von Objekten als Multiplikation mit
>einer Matrix darstellen kann.

Ich dachte es wäre wegen der Singularität -> homogene Koordinaten. Da 
habe ich mich wohl vom Trekkifieber anstecken lassen....

@Frager : Lies Dir mal was über Z-Buffering durch.