Projektstatistik 04/2009

30. April 2009

Puh! Das war was! Leider bin ich im Moment recht busy unterwegs. Zum Beispiel ziehen meine liebe Freundin Anna und ich gerade in eine neue Bude. Sehr geil! Nur leider finde ich da im Moment — wie so oft — nicht genug Zeit, um mich mit wirklich wichtigen Dingen auseinanderzusetzen: Die Weiterentwicklung des Spiels oder halt erstmal der zugrunde liegenden Engine. Daher lässt auch der zweite Teil über Shader- und Rendering-System noch auf sich warten. Aber jetzt gibt es wenigstens schon mal die monatliche Statistik. Der Mai ist mittlerweise ja schon fortgeschritten, was aber die Statistik nicht verfälscht. Denn ich habe ja eh in den vergangenen Tagen nix am Code ändern können.

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
108.066 46.503 33.773 2.881 24.909 83.157
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Ich hoffe, dass ich spätestens näxte Woche dazu komme den zweiten Teil über Shader- und Rendering-System zu verfassen. Ansonsten bin ich nun seit April dabei das Scripting-System aufzupolieren und fertigzustellen. Da liegt aber noch ein ganz schöner Brocken vor mir. Schubidu.

Ostereiersuche

01. April 2009

Ostern steht vor der Tür und in enger Zusammenarbeit mit dem Osterhasen haben meine Freunde Till und Tamer von Sonntagmorgen Kaffee sich wieder was Tolles einfallen lassen: Sie verlosen einen Kaffee-Jahresvorrat! Wie findet ihr das? Ich super! Insgesamt gibt es 24 Packungen Sonntagmorgen-Kaffee nach Wahl, alle 2 Monate ein 250g-Paket mit je vier Stück, und noch weitere Kaffeeaccessoires zu gewinnen.

Sonntagmorgen-Osterei

Hier und da im Netz sind Sonntagmorgen-Ostereier versteckt. Wie ihr nach Sonntagmorgen-Ostereiern sucht und vielleicht sogar selbst welche versteckt, könnt ihr im Sonntagmorgen-Tagebuch nachlesen.

Viel Spaß und viel Glück beim Suchen!

Projektstatistik 03/2009

31. März 2009

Ja heftig! Diesen Monat hab ich ja richtig was geschafft! Viel sagen möchte ich da jetzt gar nicht zu, lest euch lieber den ersten Teil über Shader- und Rendering-System durch. Bis demnächst.

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
105.514 44.977 33.283 2.869 24.385 81.129
100 % 43 % 32 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Shader- und Rendering-System (I/II)

30. März 2009

Puh! Das war was! Das Rendering-System ist nun auch fast fertig. Da es in letzter Zeit nicht allzu viel zu zeigen gab, möchte ich nun das Shader- und insbesondere das Rendering-System etwas genauer vorstellen. Schließlich habe ich mich ja genau damit in der letzten Zeit befasst. Damit der Rahmen hier nicht gesprengt wird und ich nicht alles Pulver auf einmal verschieße, mache ich mehrere Teile. Dieses ist der erste Teil. Ganz fertig ist das Rendering-System ja auch — wie gesagt — noch nicht, insofern ist eine Aufteilung ja ganz sinnvoll.

Struktur und Funktionalität des Rendering-Systems, was auf Teile des Shader-Systems zurückgreift, möchte ich anhand einer kleinen Grafik erklären:

Rendering-System

Kern des Rendering-Systems bilden Chain, Effect und Pass. Generell gibt es pro darzustellender Szene ein Chain-Objekt, dass die „Kette“ an Effekten (Effect-Objekten) repräsentiert, die letztlich das Bild sukzessiv aufbauen. Ein Effekt kann dabei wiederum aus mehreren Pass-Objekten zusammengesetzt sein. Für einen Cel-Shading-Effekt (Cel = Contour Enhancing Lines) werden beispielsweise vielleicht drei Durchgänge (Passes) benötigt, was ich gleich noch genauer erläutern und anhand von Screenshots verdeutlichen werde. Pro Chain- und Effect-Objekt werden verschiedene Render-Targets zur Verfügung gestellt. Schließlich soll ja im Falle von mehreren Effekten bzw. mehreren Durchgängen eines Effekts nicht direkt in den Bildschirmspeicher, sondern in weiterverwertbare Render-Targets in Form von Texturen gezeichnet werden. Diese Render-Targets werden also entsprechend von den Chain- und Effect-Objekten verwaltet und den Pass-Objekten zur Verfügung gestellt. Ein Pass-Objekt greift dann auf ein Paar von Pixel- und Vertex-Shadern zurück (Shader-Combo), um die Geometrie der Szene letztlich zu transformieren und als Farb- und Tiefeninformationen in die Render-Targets zu zeichnen. Welche Eigenschaften der Geometrie zum Zeichnen mit auf den Weg gegeben werden, ist in der Vertex-Declaration gespeichert.

Um das noch ein bisschen zu verdeutlichen, kommt jetzt mein Cel-Shading-Beispiel:

Cyber E-Razor ist ja eine Comicfigur. Eine Comicfigur wird natürlich in gewissem Comicstil gezeichnet. So mit schwarzer Umrandung und wenigen (aber dafür umso markanteren) Farbabstufungen und so. Im Folgenden geht es darum, wie ich an diese schwarzen Konturlinien komme. Das endgültige Resultat zeige ich ein andermal. Im Moment geht es nur um die Konturlinien. Zur Extraktion der gewünschten Linien verfolge ich einen Ansatz von Mitchell et al., „Real-Time Image-Space Outlining for Non-Photorealistic Rendering“, den ich natürlich meinen Bedürfnissen angepasst habe. Dabei werden die Konturlinien aus drei „Informationen“ der darzustellenden Objekte zusammengestellt: Die Farbe, der Normalenvektor (die Ausrichtung der Objektoberfläche) und die Tiefe (die Entfernung zur Kamera). Dafür wird die gesamte Szene erstmal in zwei Texturen gezeichnet: Eine soll die Farben enthalten. Die andere soll die Normalenvektoren in den drei Farbkanälen Rot, Grün und Blau sowie die Tiefenwerte im Alphakanal enthalten. Mit der zweiten Textur schlagen wir also zwei Fliegen auf einen Streich. Wie diese Texturen dann aussehen, ist in folgenden zwei Screenshots zu sehen:

Color-Map

Normal-Depth-Map

Ich habe zwar extra eine Perspektive gewählt, bei der Cyber seine heftige Gun Richtung Kamera streckt, damit die Tiefeninformationen möglichst stark zur Geltung kommen. Der rechte Screenshot ist aber trotzdem nicht so ganz aussagekräftig, daher hier noch mal zwei Screenshots, die die Normalenvektoren und die Tiefeninformationen getrennt voneinander beinhalten:

Normal-Map

Depth-Map

Sau geil! Die Normalenvektoren werden ja in den Rot-, Grün- und Blaukanälen der Textur gespeichert, insofern sieht Cyber auf dem linken Screenshot derbe bunt aus. Die XYZ-Komponenten der Normalenvektoren werden hierfür einfach als RGB-Farbwerte in die Textur geschrieben. Das passt ja ganz gut, sind ja schließlich jeweils drei Werte, XYZ oder halt RGB. Daher wird man aus der gegebenen Perspektive auch niemals die Farbe Blau sehen, weil die blauen Pixel alle in die andere Richtung „zeigen“, von der Kamera weg. Im rechten Screenshot sind die Tiefeninformationen gespeichert, je heller desto größer die Entfernung zur Kamera. Diese Informationen waren im oberen rechten Screenshot ja im Alphakanal der Textur gespeichert. Dort erscheinen die Farben daher etwas dunkler, weil sie wegen der „Transparenz des Alphakanals“ mit dem schwarzen Hintergrund gemischt werden. Auch hier gilt wieder: je „heller“ desto größer die Entfernung zur Kamera, wobei „hell“ einen höheren Alphawert und demnach geringere Transparenz bedeutet.

Ballert man das alles nun zusammen und lässt noch einen weiteren entsprechenden Shader drüber laufen, kommt etwas Schönes bei raus. Nämlich Folgendes: Aus den drei Informationen, Farbe, Normalenvektor und Tiefe, bauen wir uns nun die Konturlinien. Und zwar soll an jeder Pixelposition des resultierenden Bildes eine Konturlinie gezeichnet werden, wenn die drei gegebenen Informationen relativ stark von den jeweiligen Werten benachbarter Pixel abweichen. Das bedeutet also:

  • Weicht die Farbe stark von den Farben benachbarter Pixel ab: Konturlinie zeichnen.
  • Hat der Normalenvektor einen weitaus anderen Winkel als die Normalenvektoren benachbarter Pixel: Konturlinie zeichnen.
  • Ist der Tiefenwert heftig näher an oder weiter entfernt von der Kamera als die Tiefenwerte benachbarter Pixel: Konturlinie zeichnen.
  • Ansonsten: Keine Konturlinie zeichnen.

Das führt dann als Resultat zu richtig schönen Konturlinien, die so ziemlich alle Eigenschaften besitzen, wie man sie von Comicbildern erwartet:

Color-Map

Sehr schön! Gut zu erkennen ist, dass einige Linien dicker sind als andere. Welche das sind, ist noch nicht völlig optimal, aber tendenziell sieht das schon ganz gut aus: Die tatsächliche Umrandung der Figur ist weitestgehend dick gezeichnet, während die Linien „innerhalb“ der Figur (hach, dafür gibt es doch auch einen Begriff?) meistens dünner erscheinen.

Wie gesagt: Bisher handelt es sich hier nur um die Konturlinien. Für das fertige Bild können noch Beleuchtung und Schatteneffekte oder sonst was Verwendung finden. Die Konturlinien werden dann zum Schluss quasi über das eigentliche Bild drübergelegt, um den Comicstil zu realisieren.

Hui, jetzt brennen mir aber wieder die Finger! — Als näxtes werde ich das Rendering-System noch um die Funktionalität eines so genannten Szenegraphen erweitern, der u.a. für eine geeignete Sortierung der darzustellenden Objekte zuständig ist. Dabei sollen die verschiedenen Geometrieeigenschaften gruppiert und somit der Rendering-Prozess beschleunigt werden. Wenn das soweit ist, kommt der zweite Teil zur Vorstellung von Shader- und Rendering-System. Dann wird es natürlich wieder neue Screenshots geben. Tschau!

Projektstatistik 02/2009

28. Februar 2009

Irgendwie frickel ich immer noch am Rendering-System herum. An einigen Stellen weiß ich nicht, ob das so sinnvoll ist, wie ich das mache. Mein Problem dabei ist, einen geeigneten Mittelweg zwischen Flexibilität und Komfortabilität zu schaffen. Halte ich das System einfach und leicht überschaubar, werden vielleicht nicht ausreichend Features unterstützt, die zu einer späteren Zeit aber benötigt werden. Aufgrund der Einfachheit wäre es aber komfortabel einsetzbar. Mache ich das System hingegen flexibler, stellt es im Endeffekt vielleicht nur eine Art „Wrapper“ der eigentlichen Direct3D-Klassen und -Funktionen dar. In diesem Fall hätte ich nix gewonnen, sondern nur unnötigen Programmieraufwand in das System gesteckt, das im Bezug auf die Direct3D-Klassen und -Funktionen womöglich sogar eine ungeeignetere Benutzerschnittstelle bietet. Ich weiß es nicht. Heiliger Bimbam!

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
96.009 41.244 30.119 2.575 22.071 73.938
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

„Write in C“

20. Februar 2009

Heute habe ich einen genialen Cover-Song von „Let it be“ von den Beatles im Internet gefunden: „Write in C“. Ein junger Knabe singt und begleitet sich selbst am Klavier. Zieht es euch rein und genießt:

Get the Flash Player to see the wordTube Media Player.

(Link zum originalen YouTube-Video.)

Hach, ist das schön. Leider ist die tolle Performance des Knaben eine relativ kurze. Denn der Song geht eigentlich noch länger. Daher lest euch doch einfach den kompletten Text durch, wie ich ihn mir aus verschiedenen Quellen zusammengesucht habe. Wer den Text ursprünglich verfasst hat, konnte ich leider nicht herausfinden.

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
„Write in C.“

And as the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
„Write in C.“

Write in C, write in C,
Write in C, oh, write in C.
LOGO’s dead and buried,
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

And if you’ve just spent nearly 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
Only wimps use BASIC.
Write in C.

Write in C, write in C,
Write in C, oh, write in C.
PASCAL won’t quite cut it.
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
Don’t even mention COBOL.
Write in C.

And when the screen is fuzzy,
And the editor is bugging me,
I’m sick of ones and zeroes.
Write in C.

A thousand people swear that T.P.
Seven is the one for me.
I hate the word PROCEDURE,
Write in C.

Write in C, write in C,
Write in C, oh, write in C.
PL1 is 80’s,
Write in C.

Write in C, write in C,
Write in C, yeah, write in C.
The government loves ADA,
Write in C.

Projektstatistik 01/2009

31. Januar 2009

Etwas produktiver als im Dezember war ich dann ja doch. Das mag daran liegen, dass ich das Rendering-System vorher nicht sonderlich geplant habe, sondern einfach mal drauflos geproggt habe. Eines Nachts habe ich davon geträumt und brauchte den Code dann am näxten Tag nur noch runterzutippen. Das ist natürlich immer das Geilste. Zusammen mit dem fertiggestellten Shader-System sind dann ca. 2.000 Zeilen reiner Code hinzugekommen:

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
92.745 39.805 29.181 2.447 21.312 71.433
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Erster einfacher Test-Shader

27. Januar 2009

Wie ich bereits vermerken ließ, hatte ich auch diesen Monat nicht die meiste Zeit, das Projekt voranzutreiben. Das Shader-System ist nahezu fertig. Es ist lediglich noch ein bisschen Funktionalität geplant, die den Komfort bei der Verwendung des Shader-Systems steigern soll. Nebenbei habe ich das Fundament für das Rendering-System gelegt. Jedoch bin ich mir da noch nicht ganz sicher, wie ich das genau aufbauen soll. Ist aber auch nicht ganz so schlimm, denn das Rendering-System dient eigentlich rein der Steigerung des Komforts. Insbesondere verschiedene Render-Targets sollen darüber verwaltet und zur Verfügung gestellt werden. Für einfache Techniken (z.B. die simple Beleuchtung mit einem Phong-Shader) wird so eine Funktionalität gar nicht benötigt.

Das Shader-System habe ich bereits getestet. Im folgenden Video kommt hierfür ein Vertex-Shader zum Einsatz, der keine tollen Berechnungen vollzieht, sondern einfach nur die nötigen Matrixtransformationen durchführt und die korrekte Texel-Farbe der Textur extrahiert. Der verwendete Pixel-Shader ist noch primitiver; er gibt die (interpolierte) Farbe unverändert zurück. Das Resultat ist natürlich nicht besonders hübsch, aber zum Testen reicht es allemal.

Get the Flash Player to see the wordTube Media Player.

Ups, da habe ich aber lange gebraucht, um zu merken, dass sich der Mauszeiger mitten im Bild befindet. Einer rafft es nie! Witzig ist auch — was mir gerade erst auffällt —, dass das 3D-Modell spiegelverkehrt dargestellt wird (man beachte die Sieben auf Cybers Brust). Da findet anscheinend an irgendeiner Stelle ein ungeplanter Koordinatensystemwechsel statt. Das krich ich aber schon noch raus.

Projektstatistik 12/2008

29. Dezember 2008

Im Dezember habe ich nicht allzu viel geschafft. Das ist aber auch nicht verwunderlich, schließlich fanden jede Menge Ereignisse statt — einschließlich Weihnachten. Außerdem habe ich ein paar neue Computerspiele (z.B. Grand Theft Auto IV, tierisch geil), die ich erst mal ausführlich anzocken musste. Dazu komme ich in letzter Zeit nämlich nicht oft; ich habe hier noch zwei Jahre alte Spiele liegen, die ich nicht mal ansatzweise gescheit durchgezockt habe.

Nichtsdestotrotz* habe ich was geschafft: Das im vergangenen Monat angefangene Shader-System habe ich ein wenig weiterentwickelt. Fertig ist es jedoch nicht geworden. Vermutlich wird es das auch im Januar noch nicht, denn in den näxten Wochen werde ich ziemlich busy sein. An reinem Code sind diesen Monat knapp 1.000 Zeilen hinzugekommen:

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
88.000 37.732 27.633 2.344 20.291 67.709
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Und wieder sind die Verhältnisse von Code, Kommentaren und Leerzeilen (die Prozentzahlen in der Tabelle) nahezu identisch geblieben.

1.000 Zeilen Code sind für meine Verhältnisse ja nicht viel — wenn man sich mal die vorigen Statistiktabellen anschaut. Jedoch gibt es im Bereich Software Engineering eine Faustregel zur Aufwandsschätzung, für die angenommen wird, dass ein durchschnittlicher Programmierer monatlich ca. 350 Zeilen Code erzeugt. Da ich in C++ programmiere und C++ im Vergleich zu vielen anderen Programmiersprachen zu einem relativ hohen Teil aus Deklarationen besteht, die keinen ausführbaren Code darstellen, sollten meine 1.000 Zeilen nicht allzu hoch bewertet werden. Bedenkt man aber, dass ich längst nicht jeden Tag an dem Projekt arbeite und wenn, dann abends nicht mehr als zwei oder drei Stunden, wirft sich doch die Frage auf, was für Kackboons werden da bloß als durchschnittliche Programmierer angesehen? — Verzeiht mir bitte, ich möchte damit weder jemanden angreifen oder schlechtreden noch mich selbst in den Vordergrund stellen.

*: „Nichtsdestotrotz“ finde ich im Gegensatz zu manchen anderen ein ziemlich geiles Wort! Hihihi. Dazu gibt es auch eine mehr oder weniger lustige Geschichte, die jedoch ein andermal erzählt werden soll.

Sonntagmorgen.com in der WDR Lokalzeit Münsterland

16. Dezember 2008

Und wieder bin ich stolz auf meine Freunde Till und Tamer von Sonntagmorgen.com. Nachdem die beiden letztens den Gründerwettbewerb „Launch Pad 2008“ unseres Instituts für Wirtschaftsinformatik hier in Münster gewonnen haben, waren sie dieses Mal im Fernsehen zu sehen. Ein Kamerateam vom WDR hatte sie vor ein paar Wochen einen Tag lang begleitet und gestern wurde der Bericht ausgestrahlt. Ich habe ihn leider verpasst, aber meine Freundin Anna hat ihn zufällig sogar live gesehen. Zum Glück existiert bereits ein YouTube-Video eines Fans, das Till und Tamer auf ihrer Seite verlinken: Sonntagmorgen in der WDR Lokalzeit Münsterland