Moin! Ich habe ein Grafik-Display zum Rumspielen ohne konkrete Anwendung. Genauer ein DOGM128 mit 128x64 Pixeln. Da man das Teil nicht auslesen kann verwende ich einen Puffer von 1 KB. Momentan spielt das Gerät eine Animation mit 4 Bildern ab. Das Display sitzt auf einem Board mit einem 90CAN32 der auf 16 MHz läuft. Jetzt würde ich gerne sowas nettes wie einen rotierenden Würfel machen. So Effekte eben wie sie mit dem C64 schon vor 20 Jahren gemacht wurden. Ein rotierendes 2D-Object wäre ja auch schon nett. Nur, wie geht sowas überhaupt? Und vor allem, wie geht sowas effizient und in C? Wenn ich im Netz nach Grafik-Effekten suche bekomme ich haufenweise Photoshop Seiten...
Ist alles nur Mathematik ;-) Hier gibt es Quelltext dazu, ist zwar für einen PIC aber der Code ist in C: http://www.base32.de/3dengine.html Gruß daniel
Ein uC mit 16MHz und RISC-Architektur ist mehr als 20mal schneller als ein C64, d.h. einfache rotierende Objekte sollten ohne Probleme möglich sein. Dazu: Punkte als 3D-Vektoren (fixpointed integers) per 3D-Matrizen drehen etc., dazu Linien- und Clipping-Algorithmen und eine Speicheranbindung. Das ganze ist in einem kleinen kompakten Programm möglich. Gruss Jörg
Diese 3D Routinen sind ja mittlerweile schon fast Standard, aber wie macht man gefüllte Objekte wie z.B. einen sich drehenden Trichter oder sowas, der nicht aus einem Wireframe besteht, sondern aus einem Schachbrettmuster? So in der Art wie hier ab 1:10 http://www.youtube.com/watch?v=rcfs3RXV9O8 Auch interessant: Ab 1:20 Eigentlich sind alle Effekt interessant...
@Benedikt K., gefüllte Dreiecke sind eigentlich auch ganz einfach: Ein modifizierter Linienalgorithmus erzeugt aus den 3 Eckpunkten für jede Pixelzeile Anfangs- und Endpunkte, ein weiterer Linienalgorithmus erzeugt dann für jedes Punktepaar eine Linie. Eine kleine Schwierigkeit ist nur die, das die Linien zu den drei Eckpunkte nur bestimmte Punkte als Anfangs- und Endpunkte erzeugen dürfen, und das in Abhängigkeit des Umlaufsinns und der Lage der Eckpunkte. Einfach mal mehrere verschiedene Dreiecke durchprobieren sollte den Sachverhalt verdeutlichen. Gruss Jörg
Der Quellcode ist ja ganz nett, mir ist auch klar, dass das nur Mathematik ist - nur eben nicht, was da überhaupt passiert. Aber ich hatte mehr auf einen Link auf ein Tutorial gehofft in dem erklärt wird, was man da überhaupt machen muss. Nach sowas wie Grafik und Effekten oder auch Demo zu suchen bringt einen vielleicht zu Photoshop und OpenGL... Sicherlich ist interessant zu wissen, was man machen muss, damit das mathematisch 100 Prozent korrekt ist. Aber eben auch was man alles tun kann, um sowas zu beschleunigen. Lookup-Tables für Sinus-Werte sind sicher nur der Anfang.
Und wie findet man raus, welcher Bereich sichtbar bzw. verdeckt ist ? Man könnte eine Liste alle Objekte machen, diese nach der Tiefe sortieren und dann von hinten nach vorne Zeichnen usw. Aber es geht mit Sicherheit effizienter.
@Benedikt: da ich die Demo z.T. mit programmiert habe, kann ich dir bissl was dazu erzählen. Die ganzen Effekte sind extrem vorberechnet. Viel Speicher wurde für Lookup-Tabellen verwendet. Das 3D logo am Anfang und der 3D Flug am Ende sind nur vorberechnete Sequenzen. Das Wurmloch bei 1:10 stammt von mir. Das Wurmloch selbst ist am PC vorgerendert, aber die Textur habe ich am PC noch nicht rauf gelegt. Die Textur wird in Echtzeit auf das Wurmloch gelegt und dann einfach versetzt dargestellt. Eine Bewegung der Kamera ist so natürlich nicht möglich. Ab 1:20 ist eine voxel landschaft, stammt nicht von mir, kann ich nicht viel zu sagen ausser das die Auflösung halt sehr gering ist und die kamera nicht gedreht werden kann. Dadurch wurde schon viel rechenzeit gegenüber eines konventionellen Voxelrenderers eingespart. Was ich mir auf einem µC ganz gut vorstellen könnte sind Voxellandschaften und Raytracer (wie in DOOM). Für aufwändigere 3D Effekte wird man nicht um Polygone (Dreiecke) rum kommen. Und gefüllte Dreiecke, womöglich noch mit Texturen, zu rendern ist nicht ganz ohne. Das würde ich erst einen ARM7 zutrauen (siehe Gameboy Advance demos). Für die Sache mit der Tiefe gibt es verschiedene Methoden. Erstmal rendert man die der kamera abgwandten Dreiecke nicht. Bei modernen 3D Systemen hat man einen Z-Buffer welcher dafür sorgt, dass vorne liegende Pixel nicht überzeichnet werden können. Außerdem kann man mit BSP Trees (Binary Space Partitioning) einzelne Objekte der Reihe nach rendern. Ich habe vor Ewigkeiten mal einen Renderer für Quake3 maps in VB geschrieben... steck da aber nicht mehr so drin.
Marius S. wrote: > da ich die Demo z.T. mit programmiert habe, kann ich dir bissl was dazu > erzählen. Na dann weiß ich ja jetzt wen ich bei solchen Sachen fragen kann... > Was ich mir auf einem µC ganz gut vorstellen könnte sind > Voxellandschaften und Raytracer (wie in DOOM). DOOM auf nem AVR würde mir für den Anfang reichen ;-) Kennst du dazu irgendwelche Internetseiten oder sonst irgendwelche Lektüre die einem beim Einstieg in sowas hilft? Anscheinend gab es dazu nie Infos im Netz oder das meiste ist schon wieder verschwunden, zumindest konnte ich bisher nichts derartiges finden. PS: Was steckt da eigentlich für ein µC drin?
Das sieht z.B. ganz brauchbar aus: http://de.wikipedia.org/wiki/Raycasting http://student.kuleuven.be/~m0216922/CG/raycasting.html http://www.permadi.com/tutorial/raycast/ Hab einfach mal nach raycasting gegoogelt. Problematisch ist beim AVR eher die Grafik-Hardware. Also die Schnittstelle zum Display. Wenn der schon 50% der Zeit damit beschäftigt ist die Daten zum Display zu schicken dann kannst auch nicht mehr viel raus holen. Im Pokemon Mini steckt eine spezielle Nintendo CPU (auf der Platine vergossen). Weil das keiner bekannten Architektur entspricht gibt es auch keinen C compiler (bisher hat's noch keiner gepackt mal einen zu portieren) sondern nur einen selfmade assembler.
Marius S. wrote: > Hab einfach mal nach raycasting gegoogelt. Danke, raycasting ist also das Zauberwort. Unter Voxel war die Ausbeute sehr bescheiden. > Problematisch ist beim AVR eher die Grafik-Hardware. Also die > Schnittstelle zum Display. Wenn der schon 50% der Zeit damit beschäftigt > ist die Daten zum Display zu schicken dann kannst auch nicht mehr viel > raus holen. Ich denke das sollte ich ganz gut hinbekommen. Notfalls kommt ein etwas größerer µC dran, der die Daten per DMA ans Display schiebt. Wie ist das beim Pokemon Mini? Ist da der LCD Controller direkt integriert, so dass die Daten nur ins RAM geschrieben werden müssen?
> Für aufwändigere 3D Effekte wird man nicht um Polygone (Dreiecke) rum > kommen. Und gefüllte Dreiecke, womöglich noch mit Texturen, zu rendern > ist nicht ganz ohne. Das würde ich erst einen ARM7 zutrauen (siehe > Gameboy Advance demos). Ohne Texturen (bzw. in Grenzen) reicht dafür ein 68k @ 8 MHz im ST Als Demo z.B. http://www.youtube.com/watch?v=-X8mD76W4F0 Spiele mit reiner 3D-Grafik waren z.B. der Port von Zarch aka Virus oder Carrier Command. Edit: Ein ARM7 ist bei gleichem Takt ca. acht mal schneller.
Es gibt eine Grafik Hardware im PM, man kann einfach in einen RAM buffer schreiben und die Hardware schiebt die Daten dann ins Display. Es gibt auch eine "Grafikkarte" die Maps und Sprites rendern kann. Man kann das Display aber auch byteweise per software ansprechen (direkt den Controller ansprechen). Ja klar, einen gefüllten Würfel bekommst wohl auch noch mit nem AVR hin. Aber daraus wird kein ganzes Spiel/demo/was auch immer.
Wollen mal nicht übertreiben. Ich habe ein MonoChrom-Display mit 128x64 Pixeln welches per SPI angebunden ist und aktualisiere das Display mit momentan etwa 5 Hz. Ich habe in der Bucht erstmal ein Buch gekauft, das nach der Beschreibung auf Amazon zu schliessen weit genug unten anfängt und eben nicht auf OpenGL oder DirectX aufsetzt.
Computer Graphics: Principles and Practice Addison-Wesley Systems Programming Series Sprache: Englisch ISBN-10: 0201848406 ISBN-13: 978-0201848403 Amazon ab ca. 30,- Es gibt nur DIESES EINE Buch zum Thema. Sonst keins. Ist schon mindestens 20 Jahre alt, letzte Ausgabe 1995, aber beeinhaltet alle Grundlagen und zwar nicht oberflächlich, sondern bis in das ALLERletzte Detail. Das ist sowas wie die Bibel, das wird Dir jeder (jeder!) Insider bestätigen. Jedes andere Buch zum Thema baut letzlich darauf auf und von dieser Regel gibt es keine einzige Ausnahme. Aber unbedingt beachten: NIEMALS die deutsche Übersetzung kaufen, die lässt die Hälfte (ungelogen) weg. Ich habe beide, kann das also beurteilen. Jochen Müller
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.