Eine kleine Szene mit Diffuser Beleuchtung und Spiegelung

Ihr dürft euch nun zu Recht fragen, was das hier ist? Nun auf diesem Bild ist eine Szene aus meinem kleinen mini-Raytracer zu sehen, den ich in den letzten Tagen, ein bisschen aus Langeweile, aber auch, da ein wenig Abwechslung sicher nie schadet, geschrieben habe. Er kann bisher nur Diffuse Beleuchtung, und Reflexionen, doch ich werde ihn jetzt immer wenn mir Langweilig ist ein wenig weiter vorantreiben. Das ganze ist in C++ realisiert worden.

Ja, ansich nichts besonderes, doch ihr wollt hier ja auch wieder ein bisschen neues sehen, nicht

Tipp: Wer einen guten und schnellen einstieg sucht, dem kann ich diese Tutorials Empfehlen.

E333

Wir haben es jetzt Winter bzw. Weihnachtszeit, d.h. ich verbringe allgemein nicht soviel Zeit vor dem Computer.

Zudem, (Augen scharfstellen, der interessante Teil beginnt erst^^), war ich in letzer Zeit auch mit einem Schulischen Projekt beschäftigt, und bin es immernoch. Es geht darum, den USB-Anschluss für die Kommunikation zwischen Software und Hardware (ja, zu was auch sonst) zu benutzen. Dieses Tutorial half mir dabei sehr. Wie man daraus herauslesen kann, ist das ganze mithilfe der libFTDI und einem Board von Sparklefun gemacht. Nach anfänglichen Startschwierigkeiten (und ein bisschen Nachgefrage)  konnte ich mich weitgehend an dem Tutorial orientieren, wobei ich das ganze unter Windows umsetzte. So war es kaum verwunderlich, das ich die USB-Ampel schnell nachgebaut hatte. Nun beschäftige ich mich gerade mit Input.

Euer E333

Bald gibt es hier auch ordentlich was  zu sehen, und freut euch: Auch live auszuprobieren

Euer E333

HIER geht es zur Projektseite mit dem Download

Viele Menschen (auch ich vor 1 oder 2 Jahren) benutzen bei ihrem ersten grafischen 2D-Spiel die SDL. (Auch wenn ich das nicht mehr empfehlen würden ). Dabei taucht oft das Problem mit der Rotation auf, die bei der SDL nur unzureichend mitgeliefert wird. Der Ausweg aus dieser Kriese lautet SDL_Gfx, das mit der Rotozoom-Bibliothek eine kleine aber feine Funktionssammlung bietet. Der Wermutstropfen bei der Sache: Die Rotation findet nur um den Linken oberen Eckpunkt statt, was für viele Anwendungen sehr ungeschickt ist. Deshalb habe ich diesen kleinen – aber Feinen – Artikel geschrieben, um euch näherzubringen, dass es eigentlich ganz einfach ist, ein SDL_Surface mit SDL_Gfx zentriert rotieren zu lassen.

Die Theorie

Ein Bild sagt mehr als Tausend Worte:

Danke an saru-online.com für die Grafik

In der Praxis
Das ganze wird in der Praxis wie folgt implementiert. Wie immer hier kommt zuerst der Code, und anschliessend die Erklärung dazu. Der Folgende Source befindet sich in dem Teil eures Quellcodes, in dem ihr euer Objekt rendert, und wird in jedem Frame aufgerufen.
(Hinweis: Ich gehe hier davon aus, dass schon Grundkenntnisse im Umgang mit der SDL vorhanden sind.

 // Vorher Deklarierte Variablen:
 // pTestImg (SDL_Surface*)    Das Surface für das Ausgangsbild
 // TestRect (SDL_Rect)        Das Rect, mit der Eigentlichen Position unseres Objekts
 // Temporäres Surface, auf dem das Rotierte ausgangsbild abgebildet ist
 SDL_Surface* tmp = rotozoomSurface (pTestImg, RotationAngle , 1, 0);
 // Die Positionsverschiebung bei der Rotation ausgleichen
 // Erst an dieser Stelle wird bewirkt, dass die Rotation zentriert aussieht
 SDL_Rect tmprect = TestRect;
 tmprect.x -= tmp->w/2 - pTestImg->w/2;
 tmprect.y -= tmp->h/2 - pTestImg->h/2;
 // Das Surface schlussendlich auf den Screen blitten
 SDL_BlitSurface (tmp, NULL, pScreen, &tmprect);
 SDL_FreeSurface (tmp);

Hinweis: Wenn das Surface Colorkeying verwendet, muss der Colorkey auf ‘tmp’ nochmal angwendet werden !

Doch was geschieht hier eigentlich? Der Funktion rotozoomSurface (aus SDL_Gfx) übergeben wir unser Ausgangssurface, und sie gibt uns eine um Rotation Angle gedrehte Version im Rückgabewert zurück.
In den darauffolgenden Zeilen nehmen wir die nötige Verschiebung der Koordinaten des Objektes vor, wie im Abschnitt 'Theorie' Besprochen.
Danach können wir das temporäre Rotierte Surface einfach auf den Bildschirm blitten (dabei natürlich die temporäre Position angeben), und tata, wenn ihr alles richtig in euer Projekt eingegliedert habt, dann seht ihr jetzt ein Zentriert Rotierendes Surface. Wenn nicht, und ihr glaubt, es liegt an dem Hier stehenden Code, oder etwas ist unzureichend erklärt, scheut euch nicht, euch in den Kommentaren auszulassen.
Kleiner Tipp noch: Wenn sich euer Bild nicht in jedem Frame neu rotiert, kann es Performancetechnisch schneller sein, einfach das Bild zwischenzuspeichern

Euer E333

Quellen

SDL_Gfx Dokumentation

SDL Multimedia Library

Dank gehört zusätzlich ICH1994 für einige wichtige Hinweise. (s. Kommentar #1)

Theory

A Picture tells you more than one thousand words.

Thanks to saru-online.com for the Image

Implementation
First of all you need to link and include SDL_gfx onto your project, but that could you do at your own well .
Now i’ll give you my implementation for that, and after the Code i will explain it. The following source will be in the part of your code, in wich you’ll render your Object, being called every frame.
[Hint: I act on the assumption that you're alredy got a little bit of experience with dealing the SDL library.]

 // Variables declared out of this Scope:
 // pTestImg (SDL_Surface*)    The Surface for our Startup Image
 // TestRect (SDL_Rect)        The Rect saving the Position of our Object
 ///////////////////////////////////////
 // Rotate the Image (with RotationAngle as angle) and store the resulting pointer in 'tmp'
 SDL_Surface* tmp = rotozoomSurface (pTestImg, RotationAngle , 1, 0);
 // Equalize the Positionchange from the Rotation
 // The next 3 Lines of code are making our Object  (seem) rotating around the Center and not around the Top Left Corner
 SDL_Rect tmprect = TestRect;
 tmprect.x -= tmp->w/2 - pTestImg->w/2;
 tmprect.y -= tmp->h/2 - pTestImg->h/2;
 // Blit the Temporal Surface onto the Screen (don't forget to place tmprect instead of TestRect in your Blit function Call  )
 SDL_BlitSurface (tmp, NULL, pScreen, &tmprect);
 SDL_FreeSurface (tmp);

Note: If you’re using colorkeyed transparency, you have to set the Colorkey again for ‘tmp’.

So let’s me explain me what happens in this code. The rotozoomSurface Function (from SDL_Gfx) gets our Startup-Surface (the one with the original image of our Object on) and returns us a version which is rotated as much Degrees as in ‘RotationAngle’ Stored around the Top-Left-Corner. Now we have to get them looking like a rotation around the Center of our Object. The next three lines implement the Principle we’ve discussed above in the ‘Theory’ Part.
Finally we blit the temporary and rotated image on the Screen-Surface.
It will be easy to integrate the Above code into your project (hope so^^)
And if you and me did our jobs well, you’ll get an image rotating around his own Center-Point. If not, maybe someone of us made a mistake. (could be mine too), so don’t worry and let me a comment here in which there is the part of your code and a description what happens, and i’ll give my best to help you getting that running. If you find some Translation mistakes or will place grammatical correction or simply will give me your opinion about this article don’t be shy, let me a comment

Your E333 (with his first English Article)

References (German):

SDL_Gfx Dokumentation

SDL Multimedia Library

Special Thanks to ICH1994.

Im Ernst, diese Umstellung des Layouts wird vorraussichtlich dann auch die Endgültige sein, das alte hatte einige Nachteile. Spätestens Morgen werden auch 2 Hilfreiche Tutorials folgen.

Euer E333

Ein neuer Screen

Ich erlaube mir jetzt einfach mal die Änderungen Aufzuzählen:

• Neuer Ansatz zum Angeben der Distanz

Ab jetzt wird die Distanz nicht Mehr in Metern angegeben, da das viel zu unflexibel ist/war. In Anbetracht dessen, dass die Sichtweite flexibel einstellbar ist, werden die Distanzen für die LOD’s nun in Prozent der Sichtweite angegeben. Wobei das die Sichtweite auch in einen gewissen Bereich eingeschränkt ist, unter andrerem durch die LOD’s. (Man stelle sich die – unsinnige – Sichtweite 1 Meter vor: 20cm vom Mesh weg, und schon erscheint ein Imposter !)

• Neue Leveltypen supported

• Imposter

Imposter - Bitte verzeiht mir die Schiefe. Seht es als Moderne Kunst

Bei einem Imposter handelt es sich um zwei Rechtecke, die gekreuzt in der Szene stehen, wie die Zeichnung anbei Verdeutlicht. Diese können wie alle anderen Level auch individuell Konfiguriert werden. Für den Imposter stehen hierbei zur Auswahl, ob er Automatisch Generiert oder Von einer Datei stammen soll. Wenn das Automatische generieren ausgwählt wird, generiert das Utility die Textur für den Imposter automatisch aus dem Mesh. Hierbei ist natürlich zu Beachten, den Lod-Bias der Ogre::Camera entsprechend zu setzen, damit auch wirklich der Ausgangsmesh auf dem Imposter landet, der im übrigen die Größe 256×128 Pixel hat. Ansonsten liegt der Knackpunkt hierbei auf der Kameraposition, der Imposoter soll ja im Endeffekt die Selbe Größe haben wie der Ausgangsmesh. Das geschieht durch einen (zu meiner Schande Try-and-Error) Algorithmus, der Einfach die Kamera etwas weiter entlang der Distanzachse bewegt, bis der Mesh vollständig auf der Textur zu erkennen ist. Das lässt sich (wie so vieles mit Ogre) mit Ogre::Camera::projectSphere feststellen. Leider hat dieser Anstatz mehrere Probleme:

• der Step-Wert für die Distanz muss gewählt werden, ist er zu groß erscheint das Objekt nachher unter Umständen zu klein auf der Textur, ist er andererseits zu groß wird kostbare Rechenzeit verschwendet.
• er ist einfach nicht das Gelbe vom Ei

Der Rest der Texturgeneration ist einfaches Render-To-Texture. Die Impostergeometrie selbst wird durch einfache Benutzung der Ogre::ManualObject Klasse erstellt.

• Andere Interne Realisierung des generierens

Nachdem ich in der letzten Version an dem Mix aus Manuellen und Generierten LOD-Levels gescheitert bin, musste diesmal ein neuer Ansatz her. Und nach (zu meiner Schande muss ich eingestehen – es war mehr als 1 Woche – ist dann endlich der Groschen Gefallen. Wieso nicht einfach eine Kopie des Originalmeshes mit generierten Indexdaten als Manuellen LOD-Level benutzen ? Das ganze bringt die Kehrseite mit, dass man alle Vertexdaten & Co. doppelt hat, und auch 2 Getrennte Dateien, aber das musste ich jetzt einfach in Kauf nehmen.

• Rewrite des Speicherns

Dadurch dass ja jeder Level mit Ogre::Mesh::createManualLodLevel hinzugefügt wurde, wird jetzt auch für jeden Level eine Eigene *.mesh-Datei benötigt. Die Namensgebung orientiert sich dabei weitgehend an dem Level

• UI überarbeitet

Ich habe nach längerer Überlegung und auch konstruktiver Kritik die UI nochmal überarbeitet und vereinfacht. Unnötige und teils auch Verwirrende/Falsche Dinge wurden gnadenlos rausgeschmissen, Beispiel dafür wäre z.B. die Basismeshstatistiken mit dem Trianglecount. Stattdessen sind einige Hilfreiche Dinge hinzugekommen, darunter:

• Inaktive LOD-Level werden in der Tabelle ausgegraut
• Wenn es Fehler beim Generieren gab, werden diese Ausgegeben, und deren Ursprungszelle rot eingefärbt
• Einige Vorbeugende Fehleranalysen
• Das Grid wurde auf Normalgröße gebracht (ich meine, 9 statt den ursprünglich 100 möglichen Leveln reichen doch ^^)
• Die Spaltenüberschrift passt sich jetzt individuell der Markierten Zelle und deren Level an. Steht dort bei Generieren z.B. „% der Vertices des Ausgangsmeshes“ so steht dort, falls man versucht ein Parameter für den Typ Manueller Mesh anzugeben „Dateiname des Meshes“ und es öffnet sich ein Dateiauswahldialog.

Euer E333

Speedhockey mit der SFML

Das ganze ist, wie man unschwer erkennen kann, ein Speedhockey-Klon. Da es ein recht kleines Nebenbeiprojekt ist, werde ich es wahrscheinlich in 1-2 Tagen abschließen, und dann gibts nen Download.

Neben Xrodon habe ich nebenbei noch ein bisschen mit der SFML herumgespielt, die doch so einen hervorragenden Ruf genießt. Und ich muss sagen, ich bin wirklich begeistert. Im Gegensatz zur SDL ist die Performance hier wirklich kein Problem, und es geht faszinierend einfach, Applikationen damit zu entwickeln. Das Interface ist einfach gehalten, doch es lässt wichtige Fortgeschrittene Funktionen auch nicht vermissen. Unnötiges ist jedoch gnadenlos weggelassen.