Hallo, wo gibt es Grundlagen zur 3D-Programmierung von einfachen Vektorgrafiken, wie sie zB damals auf einen 64er gemacht wurden ? Was man so im Web findet bezieht sich meistens immer auf DirektX oder OpenGL.
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..)?
Ach ja, die gute alte Zeit :) Habe irgendwo noch ein Demo von mir rumfliegen - Rasterizer für beleuchtete Texturen auf 3D-Models in Assembler. Wie weit willst du denn in die Abgründe einsteigen? Letztendlich brauchst du eine Menge von Eckpunkten (vertex, mz. vertices). Jede darzustellende Fläche bekommt die Liste der sie begrenzenden Eckpunkte zugewiesen (im einfachsten Fall Dreiecke). Für Wireframe-Modelle treten Kanten an die Stelle der Flächen. Für jedes Bild musst du die Eckpunkte bewegen (Drehen, Strecken, Verschieben, ... siehe "Affine Abbildungen") und danach die sog. Szene neu zeichnen lassen. Für die möglichen Bewegungen verwendet man sog. Transformationsmatrizen (geht aber theoretisch auch ohne). Als Überblick, mit was man sich alles beschäftigen kann ist folgendes Dokument hervorragend: http://www.opengl.org/documentation/specs/version1.1/state.pdf Das kannst du gut als Checkliste nehmen. Unabhängig davon, dass es sich wieder um OpenGL handelt, finden alle wichtigen Verfahren für Echtzeit-3D Erwähnung. Zum Zeichen von Linien und Texturen eignet sich der Bresenham-Algorithmus - braucht keine Division und ist sackschnell. Wenn konkrete Fragen sind - gerne nochmal melden. Gruß Kai ps: Ach ja - würde auch gerne wissen, wo's hingehen soll
Angehängte Dateien:
-
SNK_c64_DEMO_1994.jpg
55 KB
> PS: Darf man fragen wofür das ganze gedacht ist? Nur Grundlagen oder > schon ein konkretes Ziel im Auge (PC/uC/FPGA..)? Also bei mir soll es erstmal ein kleines Gimmick für µC werden. Heutzutage muß man ja schon fast sowas im Menü damit es nach was aussieht. Ob es sinnvoll ist, stellen wir mal dahin. (Gut aussehen tut es ja) Am PC werde ich es vielleicht dann für mich noch ein bischen vertiefen. Die genannten Seiten und Bücher machen ja Lust auf mehr ;-) >Ach ja, die gute alte Zeit :) >Habe irgendwo noch ein Demo von mir rumfliegen - Rasterizer für >beleuchtete Texturen auf 3D-Models in Assembler. Meine "Demo"-Zeit war damals noch zur 64er Zeit. Schöne Starscroller, Rasterbars, Laufschriften und das ganze Zeugs, gehackt mit Turboassembler. Habe im Keller sogar noch die ganzen 5 1/4 Disketten herumliegen. Aber irgendwie hab ich es nie vertieft. Schade eigentlich
> 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....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.