Development-Blog von Florian Oeser

MensaApp Berlin (Windows Phone 7.5)

admin — Mon, 08 Oct 2012 12:58:28 +0000

Das Semester ist nun zwei Wochen alt. Da fragen sich bestimmt viele Berliner Studenten, welche ganz nebenbei stolze WindowsPhone-Besitzer sind, was es in ihren Mensen so zu Essen gibt!

Abhilfe kann hier die von mir mit entwickelte „MensaApp Berlin“ schaffen. Mit dieser App kannst du die Speisepläne aller Mensen des Studentenwerks Berlin abfragen.

Hier noch eine Auflistung ausgewählter Kern-Features:

Speiseplan für die nächsten 5 Tage
Angaben zu Zusatzstoffen
Öffnungszeiten
Suchfunktion
BingMaps – Integration
„Lieblings-Mensa“ auf Startseite pinnen

Also downloaden was das Zeug hält und Guten Appetit!

Wissenschaftliches Arbeiten (Updated: 03.07.13)

admin — Thu, 04 Oct 2012 13:14:53 +0000

Blog-Eintrag zum Modul Wissenschaftliches Arbeiten an der Beuth Hochschule für Technik im Semester SS13.

Allgemeine Informationen

Name: Florian Oeser
Matrikelnummer: 780586
Gruppe: B
eMail: florian.oeser(at)gmail.com

Gewählter Artikel

Wolfinger, Reinhard, et al. „Adding genericity to a plug-in framework.“ ACM SIGPLAN Notices.Vol. 46. No. 2. ACM, 2010.

Abstract

Im Bereich der Softwareentwicklung spricht man von einem Plug-in, wenn eine oder mehrere Softwarekomponenten eine bestehende Anwendung um eine bestimmte Funktionalität erweitern (ohne Neustart). Dadurch lassen sich Anwendungen optimal und kosteneffizient skalieren.

Im Kern basiert das Paper auf einem Plug-in Framework für Microsoft .NET, welches ebenfalls von einem Teil der Autoren entwickelt wurde. Das Plux.NET getaufte Framework ermöglicht Software-Kompositionen durch eine Art „Plug & Play“-Mechanismus.

Plux.NET definiert ein Kompositionsmodel und führt dabei die „Slot & Plug“-Metapher ein. Ein Slot spezifiziert einen Vertrag (Interface) und eine Liste von Parametern mit deren Namen und Typen. Dies geschieht deklarativ über .NET-Attribute (Metadaten), welche später zur Laufzeit über Reflection ausgelesen werden können. Ein Plug stellt eine konkrete Implementierung des korrespondierenden Slot-Interfaces dar. Die Angabe des passenden Slots sowie die Angabe konkreter Parameterwerte, geschieht wieder deklarativ.

Plux.NET selbst ist Plug-in basiert. Das bedeutet, das die eigene Anwendung ebenfalls als Plug-in implementiert werden muss. Das Framework definiert einen entsprechenden Slot (Interface), welcher mit einem passenden Plug in der eigenen Anwendung implementiert wird. Wird nun Plux.NET gestartet, sucht dieses nach eben solchen Plug’s und startet seinerseits die eigentliche Anwendung, da diese den besagten Slot implementiert hat. Weiterhin muss die Anwendung einen Slot definieren (öffnen), welches wieder einen konkreten Plug aufnehmen kann. Findet nun das Plux.NET-Framework zur Runtime ein entsprechendes Plug, welches zu dem definierten Slot passt, wird dieses geladen und der Anwendung übergeben. Der Anwendung wurde also ein Plug-in hinzugefügt.

Zusammenfassend besitzt Plux.NET ein Kompositionsmodel, welches eine Anwendung aus Komponenten zusammenfügt, welche wiederum aus einer definierten Anforderung (Slot) und einer passenden Implementierung (Plug) bestehen. Das Framework verbindet diese automatisch anhand der deklarierten Metadaten.

Sollen nun aber Komponenten an unterschiedlichen Stellen oder zu unterschiedlichen Zwecken in der Anwendung zum Einsatz kommen (wiederverwendet werden), bräuchte man verschieden ausgeprägte Metadaten. Beispielsweise könnte man sich zwei Grids in zwei verschiedenen Views vorstellen, welche beide wiederum an zwei verschiedene Datenquellen gebunden werden sollen. Implementiert man die Grid’s als Slot’s und die Datenquellen als Plug’s, würde das Kompositionsmodel automatisch beide Datenquellen an beide Grid’s binden. Dies ist nicht gewünscht, schließlich sollte das Grid in einer bestimmten View auch nur an die für es vorgesehene Datenquelle gebunden werden.

Die Plug’s müssten also selektiv mit den Slot’s verbunden werden. Ohne einen generischen Ansatz müssten die Kompositionen programmatisch definiert werden. Es wäre auch denkbar die Metadaten anzupassen und für jede View ein spezifisches Grid (Slot) zu definieren, zu welchem dann nur genau eine Datenquelle (Plug) implementiert ist. Beide Wege wären mit dem Plux.NET-Framework möglich, sind aber aus vielen Gründen ungeeignet. Beispielsweise würde das Anpassen der Metadaten immer auch zur Folge haben, das neue Subklassen (für die jeweiligen Slots/Plugs) angelegt werden müssten, obwohl eben eine Änderung der Metadaten hinreichend wäre.

Die Autoren beschreiben in ihrem Paper einen Template-basierten Ansatz für die Metadaten, welcher ebenfalls im Plux.NET-Framework implementiert wurde. Die entsprechenden Slot- und Plugnamen und die Parameterwerte werden mit Platzhaltern ersetzt. Die Metadaten sind somit unvollständig und werden erst zur Laufzeit parametrisiert, sobald eine Komponente verbunden wird und deren konkrete Ausprägung bekannt ist. Die Informationen darüber können aus einer externen Quelle wie einer Konfigurationsdatei stammen.

Ausarbeitung Beta

Adding genericity to a plug-in framework (.pdf, 438KB)

Ausarbeitung Final

Adding genericity to a plug-in framework (.pdf, 325KB)

Präsentation

Link zur Präsentation in Google Docs

Adding genericity to a plugin framework_Präsentation_Florian Oeser (.pdf, 527KB)

Lösungen VL: Real-Time-Rendering (Updated: 07.01.13)

admin — Mon, 23 Apr 2012 22:07:03 +0000

In diesem Post werden alle Lösungen zu den Übungen aus der VL: Real-Time-Rendering verlinkt.

Name: Florian Oeser; Matrikelnummer: 780586; eMail: florian.oeser(at)gmail.com

Jump! – Update

admin — Mon, 26 Oct 2009 22:59:16 +0000

Es ist soweit, nach Monaten mal wieder ein Update in Bezug auf die Entwicklung von Jump! Es hat sich einiges getan seit März diesen Jahres. Der wichtigste Punkt ist sicherlich das wir zu drei Testsessions geladen haben um Feedback zu Jump! von den Spielern zu bekommen. Die Anzahl der unterschiedlichen Testern war nicht umwerfend, jedoch war das Feedback quantitativ und qualitativ ausreichend um auf dieser Basis weiterzuentwickeln. Danke auch nochmal an dieser Stelle an alle Tester

Weiterhin habe ich auch die Jump!-Seite hier mal ein wenig überarbeitet. Gleiches gilt für die Bildersektion. Im Übrigen hat das Spiel nun auch seit geraumer Zeit eine direkte Homepage auf der es den Download gibt, Informationen zum Spiel und auch ein Forum um uns Bugs und Feedback mitzuteilen.

Während der Testsessions habe ich immer mal wieder ein paar Videos mitgeschnitten. Das Ergebnis gibt es gleich hier zu sehen und kann als „90 seconds of Catch the Chicken“ deklariert werden, da es lediglich Szenen aus diesem Mode enthält.

In diesem Sinne viel Spass beim Schauen

This text will be replaced

simple RayTracer Part 2 (Refraction+NormalMapping)

admin — Tue, 23 Jun 2009 19:02:34 +0000

Es ist soweit. Heute möchte ich den vorerst letzten Part des Raytracers vorstellen und veröffentlichen. Nachdem mit Part 1 der Grundstein gelegt wurde hier nun erst einmal die Änderungen und Erweiterungen auf einem Blick:

Texturen auch für Spheren
NormalMapping
Refraction
einige Bugfixes
Performanceoptimierungen

Zunächst möchte ich zwei Bilder zeigen, welche den aktuellen Stand repräsentieren, bevor ich dann einzelne Punkte noch einmal kurz aufgreifen werde. Beide Bilder zeigen das Phong-Model mit Reflection und Refraction kombiniert mit NormalMapping.

NormalMapping

Das NormalMapping in diesem Raytracer unterscheidet sich vom gewohnten NormalMapping aus der 3D-RealTime Grafik in zwei Punkten. Zunächst ist der RayTracer statisch, sprich es gibt keine bewegten Lichtquellen bzw. Objekte. NormalMapping kommt erst dabei richtig zum Tragen bzw. entfaltet so eigentlich erst seine sichtbare Wirkung. Aus diesem Grund kann man den Effekt nur deutlich machen indem man zwei an sich identische Bilder direkt miteinander vergleicht.

Weiterhin sind für das NormalMapping in dem Raytracer keine Object- oder Tangentspace Berechnungen notwendig sondern lediglich die Berechnungen des Normalenvektors aus der NormalMap. Das sind dann üblicherweise so bzw. so ähnlich aus:

color normal = normalMap.getTexelBilinear( u, v, distance );
double x = (normal.add(color(-1,0,0))).mult(2.0f).r;
double y = (normal.add(color(0,-1,0))).mult(2.0f).g;
double z = (normal.add(color(0,0,-1))).mult(2.0f).b;

Dieser Normalenvektor ersetzt dann einfach, bei der Diffuseberechnung, den Normalenvektor der an dem Schnittpunkt des Rays mit der Plane bzw. Sphere errechnet wurden wäre.

Refraction

Bei der Berechnung von Refraction (Lichtbrechung) habe ich mich auf das hervorragende Tutorial von Jacco Bikker gestützt. Hier nocheinmal ein Bild vom Anfang:

Man kann deutlich einen unterschiedlichen Brechungsindex zwischen der linken, organgen und der rechten, lilanen Sphere erkennen. Der Brechungsindex eines Mediums ist die Angabe wie schnell die Lichtgeschwindigkeit in diesem Medium abnimmt. Sprich das Verhältnis zwischen der Phasengeschwindigkeit des Lichtes im Vakuum und der Phasengeschwindigkeit des Mediums. Die linke Sphere definiert eine Phasengeschwindigkeit von 1.33 welches Wasser bei 20° Celsius entspricht. Folglich verliert das Licht 25% (1/1.33) seiner Geschwindigkeit gegenüber der Geschwindigkeit im Vakuum. Über das Snelliussches Brechungsgesetz kann man dann, über die unterschiedlichen Brechungsindizes, die eigentliche Brechung berechnen.
Die rechte, lilane Sphere hat eine Phasengeschwindigkeit von 1.0 und ist folglich derer im Vakuum gleich. Daraus resultiert dann auch das die hintere, gelbe Sphere ohne Brechungen sichtbar ist. Im Übrigen hat die vordere, güne Sphere eine Phasengeschwindigkeit von 1.31 (Eis).
Jetzt noch zwei Bilder aus einer anderen Perspektive, welche nebenbei auch nocheinmal den NormalMapping Effekt gut verdeutlichen:

Performance

Auch im Bereich der Performance hat sich einiges getan. Dies aber lediglich über Implementierungsoptimierungen und nicht über Beschleunigungsansätze wie beispielsweise ein Spatial Tree. Trotzdem kann sich der Zuwachs sehen lassen. Ein Bild mit sieben texturierten Spheren und entsprechender Plane, bei 1000×1000, sechs Rekursionen für Reflection ist mehr als doppelt so schnell berechnet wie das selbe Bild ohne Texturen für die Spheren. Das ist in der Hinsicht imposant da die Berechnungen der entsprechenden UV-Koordinaten und das eigentliche fetchen des Texels einen nicht unerheblicher Mehraufwand darstellt. Die Optimierung rührt zum Großteil daher das die Materialklassen, welche relativ viel Speicher durch die Texturen in Anspruch nehmen, nun als Pointer gehandelt werden und so nicht jedes mal auf dem Stack hin und her kopiert werden müssen.

Download

Hier nun der Download. Zum einen ein reiner Release-Build und weiterhin der komplette Source (VS bzw. VC++Express Solution). Das .NET 2.0 Framework wird vorrausgesetzt.

Release (.rar, 3.3MB)
sGUIRayTracer-Solution (.rar, 3.3MB)

Interessante Links/Quellen

Tutorialreihe auf Flipcode (sehr zu empfehlen!)

The math behind NormalMapping

Und natürlich all die anderen Tutorials die in Part 1 zu finden sind!

Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!

Businessplan für eine Spieleentwicklungsfirma

admin — Tue, 16 Jun 2009 09:59:02 +0000

Im Zuge der Arbeit an dem QM-Handbuch wurde ich an den Businessplan für eine Spieleentwicklungsfirma, welchen ich zusammen mit Michael Palmer erarbeitet hatte, erinnert. Da Michael damals schon darüber berichtete möchte ich mir die Arbeit sparen und direkt auf seinen Eintrag verlinken. Dort findet ihr den Businessplan und den Foliensatz der uns bei der Präsentation unterstützte.

Buisnessplan für ein Spieleentwicklungs-Studio

Qualitätsmanagement-Handbuch: Spieleentwicklung && Softwaremetriken

admin — Mon, 15 Jun 2009 23:07:42 +0000

Für die Lehrveranstaltung Qualitätsmanagement habe ich zusammen mit vier weiteren Kommilitonen ein minimales (und bei weitem nicht vollständiges) Qualitätsmanagement-Handbuch für eine fiktive Spieleschmiede geschrieben.

Inhalt dabei ist zunächst ein Firmenprofil welches die Firma und deren Entwicklungen, in unserem Fall CasualGames, beschreibt. Danach gehen wir auf die in der SE allgemein üblichen Qualitätssicherungsmaßnahmen, wie beispielsweiße den Betatest, ein. Folgend versuchen wir drei, für die Spieleentwicklung wichtige, Qualitätsmerkmale zu operationalisieren: DDD (Detailed Design Document), Spielspaß u.A. mit Hilfe eines Questionnaires und zu guter Letzt das allgemein hin bekannte QM-Merkmal Korrektheit.

QM-Handbuch (.pdf, 652KB)

Der zweite Übungsteil bestand darin verschiedene Softwaremetriken auf ein Code Snippet anzuwenden und hat nix direkt mit dem Handbuch zu tun. Wer sich aber auch dafür interessiert oder eine Vorlage braucht ist mit Folgendem gut beraten. Untersucht wurden LOC (Lines of Code), die Halstead-Metrik, Zyklomatische Komplexität nach McCabe und verschiedene Codeüberdeckungsgrade.

Metriken (.pdf, 1.284MB)

Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!

simple RayTracer Part 1

admin — Tue, 05 May 2009 13:34:43 +0000

Nach längerer Pause hier möchte ich heute meinen Raytracer, den ich in der letzten Zeit erarbeitet habe, vorstellen und zum Download anbieten. Zunächst ersteinmal ein paar Bilder welche den aktuellen Stand aufzeigen. Eine Beschreibung und die entsprechenden Berechnungszeiten sind jeweils im Bildbeschreibungstext zu finden. Dazu muss man aber sagen das weder der RayTracer ansich optimiert wurde (z.B. über ein kd-Tree), noch der Sourcecode drumherum optimiert ist.

Der RayTracer ist komplett in C++ und die entsprechende GUI mit VC++ .Net auf WinForms Basis geschrieben. Im Moment ist das Phong-Beleuchtungsmodell implementiert und als kleinen Bonus kann man noch, zumindest für die Ebenen, Texturen laden, welche die Diffusefarbe ersetzen. Nun folgt noch eine kleine Bildergalerie welche Schritt für Schritt zeigt wie man von einfachem Ambient bis zur PerfectReflection mit Schatten kommt. Die einzelnen Schritte lassen mit frei wählbaren Einstellungen auch in der GUI simulieren.

Hier nun der Download. Zum einen ein reiner Release-Build und weiterhin der komplette Source(VS bzw. VC++Express Solution). Das .NET 2.0 Framework wird vorrausgesetzt.

Release (.rar, 187KB)

sGUIRayTracer-Solution (.rar, 258KB)

Da mir die Arbeit an diesem Raytracer sehr viel Spass gemacht hat und man viel dabei lernen konnte werde ich wohl noch ein wenig daran weiterarbeiten. Hier mal eine Liste was man überhaupt noch in einem Raytracer implementieren kann. Was ich davon noch wählen werde steht noch nicht fest. Es hat alles seinen Reiz und im Moment tendiere ich zu Normalmapping direkt über eine Map und/oder Bumpmapping über PerlinNoise.

kd-Tree oder spatial subdivision zur Geschwindigkeitsoptimierung
depth of Field
isosurfaces (blobs)
fresnel und Transparenz (refraction)
Bump/Displacement mapping
Normalmapping
fog
Soft-Shadows
Photon maps (global illumination)
weitere Geometrieobjekte (Cylinder, Box etc.)
Antialiasing
Photo exposure

Interessante Links/Quellen

Wikieintrag zu RayTracing

Mandelbrot’s RayTracing explanations

Tutorialreihe auf Flipcode (sehr zu empfehlen!)

Tutorialreihe auf Codermind

Tutorialreihe der DGL-Wiki

Tutorialreihe von Forrest Briggs

Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!

Jump! Development Video

admin — Fri, 20 Feb 2009 17:04:05 +0000

Dieses Video wurde von Thomas und mir produziert und zeigt verschiedene Sachen rund um die Entwicklung von Jump!. Unter anderem werden verschiedene Entwicklungsstadien aber auch Gameplay-Szenen vorgestellt. Mehr will ich gar nicht verraten seht einfach selbst

Alle anderen Videos gibt es weiterhin hier. Im Übrigen bräuchte ich mal eine Tipp wie man die Qualität der Videos auf Youtube erhöhen kann. Schon viel probiert aber nie mit einem ordentlichen Ergebniss. Ich denke aber ich werde kommende Videos auch wieder auf dem Webspace legen, da ich nun einen ordentlichen Player gefunden habe.

Nun gut viel Spass beim Schauen und danke nochmal an dich Thomas

This text will be replaced

Hilva PostProcessing Sample (updated: 29.05.09 Hilva v1.5)

admin — Fri, 20 Feb 2009 13:36:06 +0000

Für die Hilva Graphics Library habe ich ein kleines Sample geschrieben welches den Umgang mit der PostProcessing-Schnittstelle, dieser hilfreichen Bibliothek, verdeutlichen soll. Der Download dazu ist im Sample-Bereich zu finden oder alternativ gleich hier.

PostProcessingSample (.rar, 901KB)