Warning: Constant ABSPATH already defined in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php on line 28 Development-Blog von Florian Oeser

MensaApp Berlin (Windows Phone 7.5)

8. Oktober 2012 – 13:58

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.

Icon der MensaApp Berlin App

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)

4. Oktober 2012 – 14:14

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)

23. April 2012 – 23:07

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

26. Oktober 2009 – 23:59

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.

jump

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)

23. Juni 2009 – 20:02

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.
Phong+Refraction+NormalMappingPhong+Reflection+Refraction+NormalMapping+SphereTextures

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.
NormalMapping on plane texturenormal diffuse texture map on plane (no normal texture)NormalMapping on plane; specular highlight (directional light)normal texture mapping without NormalMapping

Specular highlight through directional light and a normal map

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:

Phong+Refraction+NormalMapping

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:
refraction with normalmappingrefraction without normalmapping

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!