Ja, ich gib’s zu, ich bin ein Minecraft Fan!

Da ich mir für diverse Bauprojekte gerne eine Blaupause herstelle, hab ich mir ein Workflow überlegt, wie man ein normales (High-Poly)Mesh in diesen klassischen Block-Voxel-Style umwandeln kann.

Im Grunde gibt es dazu zwei verschiedene Herangehensweisen: die einzelnen Voxel mit (A) üblichen Polygon-Boxen herstellen oder (B) mit einem Partikel-System.
Beide habe ich ausprobiert und bin zum Entschluss gekommen, dass die Partikel-Variante schneller und vor allem flexiebler ist. Gerade bei einem hohen Voxel-Count ist das Partikel-System von grossem Vorteil.
Verwendet habe ich dabei Particle-Flow und etwas Max-Script.

Meine Lösung funktioniert in etwa so:
1. Fülle ein Bereich/Box mit Voxel/Partikel
2. Entferne alle Voxel/Partikel die nicht innerhalb des Objektes sind
… klingt einfach und das ist es auch

Und das ganze jetzt Schritt für Schritt:

Partikel System erstellen

1. “PF Source” in der Szene erstellen

2. Icon Type der PF-Source auf “Box” stellen und die Dimensionen so eingeben dass sie das Objekt umschliesst welches wir in den Voxel-Haufen umwandeln möchten (in meinem Beispiel ist das Objekt ein Torus Knopf).
Später werde ich “Logo Size” etwas zweckentfremden, dieser Wert steht dann für die Grösse der Voxel-Boxen (bzw. den Abstand des 3D-Rasters)
Nicht Vergessen: Bei “Quantity Multiplier” Viewport auf 100% stellen (damit man später auch wirklich alles sieht)

Voxel generieren

3. “Particle View” öffnen

4. Da es keinen Operator gibt der ein 3D-Raster mit Partikel füllt muss man sich hier mit etwas MaxScript aushelfen. Darum erstell ich im ersten Event mal ein “Birth Script” Operator.

5. Das Script soll ein 3D-Raster erstellen (mit den Dimensionen der Particel-Source) und dieses dann mit Partikel füllen. Dazu könnt ihr folgendes Script einfach kopieren:

on ChannelsUsed pCont do
(
	pCont.useAge = true
	pCont.useTime = true
	pCont.usePosition = true
)
 
on Init pCont do
(
	global ps = pCont.getParticleSystemNode()
	global RasterSize = ps.logo_size
	global RasterSegments = [floor(ps.emitter_width/RasterSize+.5) as integer,floor(ps.emitter_length/RasterSize+.5) as integer,floor(ps.emitter_height/RasterSize+.5) as integer]
	--print RasterSegments
)
 
on Proceed pCont do
(
	t = pCont.getTimeStart() as float
	if t < 0 do (
		for x = 0 to (RasterSegments.x-1) do (
		for y = 0 to (RasterSegments.y-1) do (
		for z = 0 to (RasterSegments.z-1) do (
			pCont.AddParticle()
			pCont.particleIndex = pCont.NumParticles()
			pCont.particleAge = 0
			pCont.particlePosition = ps.center + ([x*RasterSize,y*RasterSize,z*RasterSize]-(RasterSegments-[1,1,1])*RasterSize*.5)
		)))
	)
)
 
on Release pCont do
(
 
)

Voxel filtern

6. Mit Hilfe des “Group Selection” Operator werden alle Partikel herausgefiltert, die sich (nicht) im Objekt befinden.
Dazu einfach den Operator in das selbe Event schieben und als “Inside Object” unseren Torus Knopf auswählen. Zusätzlich “Reverse Selection” aktivieren.

7. Mit “Split Group” und einem “Delete” Operator können wir nun alle überflüssigen Voxels löschen

Voxel Form festlegen

8. Jetzt noch mit dem “Shape” Operator die gewünschte Voxelform und -grösse auswählen und fertig ist unser “Voxel-Generator”

.. das ist das Grundkonzept. Wenn man jetzt noch etwas tweaked kann man so ziemlich alles damit machen. Z.B. auch animierte Voxel:

Wem die Partikel-Technik nicht geheuer ist kann auch gerne dieses Script “Block Creator” verwenden:
Download

Zum Installieren das Script einfach per Drag-and-Drop ins Fenster schieben. Das Tool findet man in der Kategorie “GSTools”.

dazu noch ein kurzes Tutorial:

Beschreibung

Beim Entwickeln von Flash Applikationen und Seiten benötigt man oft Konfigurationen die aus mehren Quellen aus zusammengesetzt werden. Als Beispiel könnte man hier die Kombination von FlashVars und einer XML Datei die später geladen wird, anführen. Guave Studios versucht hier immer wieder generalisierte Abläufe zu finden um den individuellen Testaufwand zu reduzieren.

Beide enthalten Konfigurationsparameter und müssen an einem Punkt zusammengefügt werden. Wichtig ist hierbei aber, dass die Konfigurationseinträge in den richtigen Formaten und Reihenfolgen und IDs aufeinander abgestimmt werden.

Fcfg bietet hier eine ganz einfachen Ansatz. Es gibt verschiedene Reader, die je nach Datenquelle die Konfigurations IDs und Werte einlesen. Der zuletzt eingefügte Reader überdeckt sozusagen die unteren Reader und bildet somit einen Stammbaum. Die originalen Werte bleiben dadurch bestehen.

var cfg:Fcfg = Fcfg.getUniqueInstance();
cfg.addReader( { config:1} );
cfg.addReader( { config:2} );
 
trace("config: "+cfg.g("config"));
//Output: config 2

Mehrere Quellen

Konfigurationen von mehreren Quellen. Derzeit integriert sind:

• Flash Objects (Stage parameters, objects)
• XML Dateien

Als Beispiel eine Normale Applikation die default Values hat, Parameter über FlashVars übergeben bekommt und nachträglich eine XML Config ladet:

var cfg:Fcfg = Fcfg.getUniqueInstance();
//initialize application default values
cfg.addReader( {
	config:"default value"
});
 
//add stage parameters as values FlashVars: config:"flashvar value"
cfg.addReader( stage.loaderInfo.parameters );
 
trace("config: " + cfg.g("config")); //long version: cfg.getSetting
//Output: config: flashvar value
 
//....
//Later on an xml get loaded
var xml:XML = new XML("&lgt;root><setting id='config'>xml value</setting><root>");
cfg.addReader(xml);
 
trace("config: " + cfg.g("config"));
//Output: config: xml value

Ändern zur Laufzeit

Die Konfiguration kann zur Laufzeit verändert werden ohne die originalen Daten zu verändern.

var cfg:Fcfg = Fcfg.getUniqueInstance();
//initialize application default values
cfg.addReader( {
	config:"default value"
});
 
cfg.s("config", "overriden value"); //long version: cfg.setSetting
trace("config: " + cfg.g("config"));
//Output: config: overriden value
 
//now lets remove the setting
cfg.r("config"); //long version: cfg.removeSetting
trace("config: " + cfg.g("config"));
//Output: config: default value

Kettenstruktur

Im den vorigen Beispielen sieht man, dass die Konfiguration eine Strutkur von mehreren Readern/Writern ist.

Aufbau:

1. Default Value Reader (Object Reader/Writer)
2. Stage Params Reader (Object Reader/Writer)
3. XML Config Reader (XML Reader)
4. Default Modifier (Object Reader/Writer)

cfg.setSetting(“config”,”value”); hat hier den vierten Punkt editiert. Die Kette wir von Unten (4) nach Oben(1) abgearbeitet. Das Value des ersten Readers, der die Config ID (“config”) beinhaltet, wird genommen.

Beim editieren wird der defaultModifier genommen. Dieser ist mit einer gewissen Priorität (20) gespeichert. Bei einem Modifier kann man Werte editieren und löschen.

Der Object Reader/Writer kann dies standardmässig.

Events

Bei Änderungen an Konfigurationseinträgen werden Events dispatched. Fcfg selbst ist ein IEventDispatcher und unterstützt damit die gänigen AS3 Events.

public function sample4():void {
	var cfg:Fcfg = Fcfg.getUniqueInstance();
	cfg.addEventListener(FcfgEvent.SETTING_CHANGED, cfg_changed);
 
	cfg.setSetting("config", "modified setting");
}
 
private function cfg_changed(e:FcfgEvent):void {
	trace("changed: ", e.id, e.newValue, e.oldValue);
	//Output changed: config,modified setting,null
}

Multiton

Um den Zugriff zu zentralisieren und vereinfachen steht ein Multiton in der Fcfg bereit. Somit ist der Zugriff auch auf statischer Ebene möglich.

var cfg:Fcfg = Fcfg.getUniqueInstance(); //unique generated name
cfg.configName; //stored name, can be recalled with this
 
var namedCfg:Fcfg.getInstance("myConfig");
var otherContextCfg:Fcfg = Fcfg.getInstance("myConfig");
//otherContextCfg and namedCfg reference to the same object

Links

• Projektseite: http://code.google.com/p/fcfg
• Getting started: http://code.google.com/p/fcfg/wiki/GettingStarted

Like it?

Mit Guave Studios einen Blick auf Adobe AIR

Da wir bei Guave Studios daran intressiert sind, in den verschiedensten Kanälen interaktive Inhalte bereitzustellen, beschäftigen wir uns intensiv mit den Möglichkeiten, die uns mobile Endgeräte bieten. Ein wichtiger Faktor für uns ist eine möglichst plattformunabhänige Lösung, um keinen unnötigen Aufwand zu generieren. Unter Plattformunabhänig verstehen wir nicht “Eine generelle Lösung für alle” sondern “Eine Lösung für den Einzelnen basierend auf der Lösung für alle”.  Adobe AIR bietet einen gemeinsamen Nenner. Ich denke, dass für viele Applikationen – vorallem im promotionalen Bereich – Adobe AIR ausreicht. Sollte dies nicht der Fall sein, kann eine spezielle Lösung in betracht gezogen werden.

AIR for Android

AIR gibt es für den Android Emulator und auch die Devices mit Android 2.1 (7) oder 2.2 (8). Derzeit befindet sicht AIR noch in der Entwicklung (Beta). Benötigt wird ebenfalls das Android SDK.

Flash CS5

Nachdem man die Vorraussetzungen (AIR auf dem Device/Emulator, Android SDK) installiert und konfiguriert hat (weiter unten) kann man relativ schnell mit der Entwicklung loslegen.

Der Workflow gestaltet sich recht einfach. Unter File -> AIR Android Settings kann man die Parameter für die Erstellung anpassen. Hier hat man die Möglichkeit einen Schlüssel zu generieren der danach zum signieren verwendet wird. Beim Veröffentlichen wird die APK generiert und automatisch bei angschlossenem Device oder Emulator direkt auf dem Endgerät gestartet. Somit kann auch sofort getestet werden.

Nur: Wer codet denn in CS5 ?

Flash Develop

(Tutorial)

Wir hätten auch die Möglichkeit mit Flash Develop über CS5 zu publishen. Ich zeige hier aber die Lösung ohne CS5 benützen zu müssen.

Mit ein paar Einstellungen und einem Template bekommen wir das auch auf Flash Develop oder anderen IDEs zum laufen. Der ganze Worklfow kann per Kommandozeile nachgebaut werden. Selbst debugging direkt in Flash Develop wird möglich.

Hierfür brauchen wir aber noch folgendes:

• Flash Develop
• AIR Android Template for Flash Develop
• AIR 2.5 SDK (register at the prerelease programm)
• Flex SDK 3.5 oder 4.0
• Flashplayer 10.1 playerglobal.swc
• Android SDK

Dann einfach die Flex SDK entpacken. In denselben Ordner können dann die AIR 2.5 Dateien entpackt werden. Dann noch die playerglobal.swc in den Ordner flex40sdk\frameworks\libs\player\10.1 entpacken.

Android SDK entpacken und Setup ausführen. Die aktuellen APIs updaten. Um testen zu können benötigen wir hier jetzt den Emulator. (USB weiter unten).  Hier wird Android 2.1 oder 2.2 erstellt. Auf der Seite AIR 2.5 SDK muss man noch die APK Datein für den Emulator und eventuell für das Device runterladen. Ich würde empfehlen, den AndroidSDK/tools Pfad zu den Umgebungsvariablen hinzuzufügen (Rechtsklick auf Computer->Erweiterte Systemeinstellungen -> Umgebungsvariablen-> PATH)

Wir können jetzt in der Kommandozeile einen Sever starten mit adb start-server. Wenn wir jetzt den Emulator per emulator -avd [EmulatorName] starten. Mit “adb devices” sehen wir ob unser Emulator erkannt wurde. Sonst nochmal per “adb kill-server” und “adb start-server” probieren.

Wenn wir jetzt das air.apk für den Android Emulator ausgepackt haben, können wir per adb install Runtime_Emulator_Eclair_20100517.apk (Eclair ist Android 2.1)

Flash Develop (ab 3.1.1) normal installieren und mit dem Flex SDK verbinden (über Einstellungen->AS3 Context->Path to Flexsdk)

Das Flash Develop Template airandroid.fdz kann jetzt ausgeführt werden. Dies ist standardmässig auf Windows mit Flash Develop verlinkt und wird dann automatisch installiert. Alternativ kann man auch die Datei auf .zip umbenennen und in den Flash Develop/Projects Ordner entpacken.

Mit Flash Develop kann jetzt ein Projket vom Typ “Air Android AS3″ erstellt werden. Der Parameter Name ist Pflicht und sollte wenn möglichst klein und ohne Leerzeichen geschrieben werden. Der Package Path kann ich auch empfehlen auszufüllen, da die erstellte Android ApplikationsID sich dann aus packagepath.projectname zusammensetzt.

Wir können das Projekt jetzt anlegen.

Im src Ordner kann jetzt die Datei Main.as editiert werden. Ein kleines trace(“Hello World”); sollte für unseren ersten Test reichen.

Im Projektordner scripts sollte man noch die settings.bat anpassen um individuelle Keys zu generieren. Es kann auch hier direkt ein Key hinterlegt werden. (CERTIFICATE_FILE). Es kann hier auch ein Passwort spezifiziert werden. Dies ist dann aber während der ganzen Zeit in der Datei gespeichert. Ich würde empfehlen während des Entwicklungsprozesses den SelfSigned Key zu verwenden und erst beim Release auf den richtigen Code Signingkey zu verwenden. Derweilt wird das Passwort automatisch beim Debuggen aus der settings.bat gelesen.

Endlich testen!

Jetzt können wir das Projekt direkt per F5 oder dem Run Button testen.

Ablauf:

1. .swf File wird gebuildet
2. key wird gecheckt und evtl generiert
3. IP Addresse wird ermittelt um den Debugger zu connecten (Erste IPv4 im ipconfig)
4. Das APK wird gebuildet und mit dem Key gesigned
5. Die Applikation wird auf dem verbundenen Device deinstalliert (falls installiert)
6. Die Applikation wird auf dem verbundenen Device installiert
7. Die Applikation wird auf dem Device gestartet
8. Der Debugger connected zum Debugger auf der hinterlegten IP
9. Hello Android müsste in der Console auftauchen

Anmerkungen zum Device USB Debugging

Das heikelste war es, mein HTC Desire mit Android 2.1 für die Entwicklung zu präparieren. Ich habe viele Informationen im Internet gefunden, jedoch nur wenige waren erfolgreich.

Was ich speziell zum HTC Desire sagen kann ist, den Treiber der auf der SD Card ist zu benutzen. Dieser wird mit HTC Sync installiert. Aktiviert man auf dem Device das USB Debugging, sieht das Device mit “adb devices”.

Für das Flash Debugging wird WLAN Access benötigt. Mit einer zugewiesenen IP (DHCP zb) kann man das Device zum Debugger verbinden.

Und voila, viel Spass beim Applikationen schreiben.

Links

• Android SDK
• Flash CS5
• Flash Develop
• AIR Android Template for Flash Develop
• AIR 2.5 SDK (register at the prerelease programm)
• Flex SDK 3.5 oder 4.0
• Flashplayer 10.1 playerglobal.swc

Die Flash Version Information ist ein Development und Deployment Tool für Flash Anwendungen.

Implementierung

Die einfache Implementierung erfordert eine Zeile Code.

Fnfo.initialize(this);

Mit BuildInformation Plugin

Fnfo.initialize(this, {versioninfo:FnfoVersion_fnfo.VERSION_FILE } );

Das Resultat ist dieses untere Flash. (Rechts in das Flash klicken und den Context Menüpunkt fnfo anklicken)

Um die Information zu schliessen einfach nochmal Rechtsklick und fnfo anklicken.

Der Output wäre wie folgt:

Version: 0.0.1
ProjectName: fnfo
VersionNumber: 0.7.0.5-32
BuildTime: 07.04.2010 12:09:00.44
BuildComputer: MARTIN-WORK/martin
PlayerVersion: WIN 10,0,42,34
PlayerDebug: true
PlayerType: PlugIn
PlayerAudio: true
PlayerMp3: true
SystemOs: Windows 7
ScreenResulution: 1680/1050
ExternalInterface: true
ExternalInterfaceObject: null
ReportTime: Wed Apr 7 16:10:20 GMT+0200 2010
ReportExecution: 00:00:04:293
LastError: none
LoadUrl: http://www.guavestudios.com/blog/fnfo-07.swf
SwfVersion: 9
BytesTotal: 14933
StageParam: test1Param = Hello
StageParam: test2Param = World

Die angezeiten Informationen helfen ein Problem genauer zu klassifizieren. Besonders wenn der Kunde eine Fehlermeldung tätigt, kann dieser mit einem Rechtsklick auf einfache Art und Weise wichtige Infos übermitteln. Die wichtigsten Informationen sind oben aufgelistet, können aber beliebig erweitert werden.

Weitere Beispiele finden sich unter: GettingStarted

Plugins

Derzeit sind die meisten Plugins integriert. Eine Plugin Struktur ermöglicht es aber eigene Plugins selbst hinzuzufügen.

Unter anderem arbeite ich derzeit an einem Screenshot Plugin, dass per Knopfdruck einen aktuellen Screenshot der Applikation mit den gesammelten Informationen und einen Zusatztext an einen Server schicken kann. Dies ist besonders hilfreich, um während der Entwicklung schnell und präzise Fehlerinformationen zu sammeln. Seit Flashplayer 10.1 gibt es zudem die Möglichkeit den zuletzt aufgetretenen Fehler zu melden.

Integration in bestehende IDEs

Die einfachste Integration bietet derzeit ein Prebuild Command. Jede IDE die dies unterstützt kann aktuelle Buildinformationen dem SWF beifügen. Zusätzlich generiert das Script (version.bat) eine Versionsklasse in der die Versionsdatei eingespeichert ist. Diese wird, wenn nicht vorhanden direkt im src Ordner erstellt. Damit kann man diese schnell und einfach anbinden.

Prebuild command in Flash Develop:

scripts/version.bat $(OutputName) $(ProjectName) src

Die Buildnummer setzt sich derzeit aus:

{major}.{minnor}.{build}.{svnrevision}-{localbuild}
{major}.{minnor}.{build} gelesen aus {projectswf}.productversion
{svnrevision} wird mit dem WCRev Utilty aus TortoiseSVN ermittelt
{localbuild} erhöht sich jedes mal bei einem lokalen Build und wird in  {projectswf}.buildnr gespeichert

Status

Derzeit befindet sich das Tool in Entwicklung. Vorallem mit dem Flashplayer 10.1 mit Global Errorhandling werden wir eine komfortable “Fehler melden” Möglichkeit einbauen.

Meinen Dank an Guave Studios, dass dieses Projekt ebenfalls Open Source ist.

Links

• http://code.google.com/p/fnfo
• http://code.google.com/p/fnfo/wiki/GettingStarted

Der übliche Workflow für einen Zeitraffer ist im Grunde ja ganz einfach: mit einer Fotokamera Serienbilder aufnehmen. Je nach Geschwindigkeit des Videos stellt man den Zeitabstand zwischen den Aufnahmen ein. Das geht entweder mit einer speziellen Remote Control oder man schliesst die Kamera an einem Laptop an und verwenden ein spezielles Programm (Die meisten Hersteller bieten eine solche Software an).

Das Problem bei einem Sonnenaufgang (oder -untergang) ist folgendes:
Es ist so gut wie unmöglich die Kamera so einzustellen, dass die Nacht nicht unterbelichtet, bzw. der Tag nicht überbelichtet ist. Die einzige Möglichkeit, um das Problem zu lösen, ist mit Automatik zu fotografieren (entweder Shutter- oder Apertureautomatik). Da ergibt sich aber gleich ein neues Problem, nämlich dass der Zeitraffer dann extrem flimmert bzw. flackert. Das liegt daran, dass die Shutter- bzw. Apertureeinstellungen nicht stufenlos sind. Eine Möglichkeit das Flimmern etwas zu verringern ist, wenn man die Belichtungsmessung auf ein Objekt stellt, das sich nicht bewegt. Darum sollte man nicht den Himmel messen, da immer wenn eine Wolke vorbeisaust, das Bild kurz dunkler und dann wieder heller wird. Trotzdem verändern sich mit der Zeit die Lichtverhältnisse und speziell in dem Moment wo die Sonne aufgeht, wird das Video extrem flackern. Und genau dieses Flackern wird sich rein fototechnisch nicht wirklich verhindern lassen.

Es gibt allerdings eine Technik, mit der sich das flackernde Bildmaterial ausgleichen lässt. Nämlich Tone Mapping (bei HDR Bilder).
Das Problem ist allerdings, dass die Fotos die man geschossen hat keine HDR Bilder sind. Wenn man die Fotos aber als RAW speichert, lässt sich daraus recht gut ein “Fake HDR” erzeugen.
Hierbei hilft uns die Software “Photomatix”. Mit einem “Batch Process” (in Photomatix gibt es die Option “Batch Single Files”) lässt sich aus allen Fotos ein Pseudo-HDR erzeugen. Das alleine hilft natürlich noch nicht. Schlussendlich wird uns hier das Tone Mapping das flackern ausgleichen.
Warum? Ganz einfach, weil (einfach ausgedrückt) Tone Mapping in einem Bild die besten “Kontrastverhältnisse” sucht. Wenn ein Foto also etwas heller oder etwas dunkler ist, ist das Optimum meist irgendwo dazwischen.
Hier kann man wieder einen Batch Prozess über die gerade eben erstellten HDR Bilder laufen lassen, aber dieses mal mit Tone Mapping.

Das Ergebnis kann dann so aussehen und beispielsweise in Movies oder TV Spots eingesetzt werden.
(oben: normale JPGs der Kamera; unten: die bearbeiteten Pseudo HDR Bilder)

Pseudo HDR Timelapse Comparison from Guave Studios on Vimeo.

Wie man sieht ist das Flackern nicht 100 %tig entfernt, vor allem in den dunklen Bereichen, da diese recht stark erhellt wurden. Aber ansonsten kann sich das Ergebnis schon sehen lassen.
Ich denke, wenn man mit den Tone Mapping Einstellungen noch etwas spielt, verschwindet auch noch das bisschen Flackern.

Ich hoffe dieses Tutorial war halbwegs verständlich. Ich habe die einzelnen Arbeitsschritte nicht aufgezählt, da die meisten HDR Programme eigentlich sehr einfach zu bedienen sind. Der selbe Effekt lässt sich übrigens auch mit anderen Programmen erzielen, als mit Photomatix. Falls aber doch Unklarheiten bestehen sollten, könnt ihr gerne Fragen stellen.
Ansonsten wünsche ich viel Spass beim selber Probieren!

Die Flash Deployment Console ist für das Deployment in einem Game oder in einer Webseite gedacht, die während der Laufzeit direkten administrativen Eingriff in die Applikation oder Ablauf brauchen. Vergleichbar ist die fCon mit einer Development Console in einem Spiel. (Vielfach mit ^ aufrufbar).

Applikationskontrolle

Die fCon hat in der Console eine Eingabemöglichkeit (Kommandozeile). So ist es möglich Commands zu registrieren die beispielsweise den Benutzer in ein gewisses Level setzen.

Modifikation von Variablen

Die fCon bietet Möglichkeiten für das setzen von Variablen. Sie bietet vorallem mit Vervollständigung eine Navigation durch alle DisplayObjects.

Deployment Logging

Gerade bei Flash Online Applikationen befinden sich die Logs einer Applikation auf der Nutzerseite. Somit kann die Laufzeit der Applikation nicht überwacht werden. Natürlich kann man die Logstufen FATAL und ERROR  per Reports an den Server übermitteln, aber bei DEBUG und INFO wäre das mengenmässig ein absolutes Problem. Somit kann man als Entwickler direkt vor Ort in das Geschehen der Applikation Einblick nehmen und den aktuellen Fehler in den Logs suchen.

History

Die fCon bietet eine History mit UP and DOWN keys an. Diese kann mit einer Einstellung Lokal automatisch gespeichert werden. Weiteres kann man mit PAGE_UP oder PAGE_DOWN im Logviewer gescrolled werden. Drückt man zusätzlich SHIFT kann man nach ganz oben oder nach ganz unten.

Scripts und Variablen

Zusätzlich ist ein einfaches Scripting und Variablendeffinitionen möglich.

Sicherheit

Da wir nicht jedem auf einer Webseite den Zugriff auf die Console bieten wollen kann mit dem Lockmanager ein Passwort gesetzt werden. Das ganze funktioniert versteckt und ohne Visuelles Feedback. Somit ist es in einer gewissen Weise “geheim” das diese Applikation eine Console bietet. Das Passwort ist selbstverständlich gehashed und somit auch nicht auslesbar.

Ein paar kleine Beispiele

Einfaches Setup

package {
  import com.guavestudios.fcon.ConsoleImpl;
  import flash.display.Sprite;
  import flash.display.StageAlign;
  import flash.display.StageScaleMode;
  import flash.events.Event;
  import flash.text.TextField;
  import flash.text.TextFieldAutoSize;
 
  /**
   * fCon Sample
   * @author maze | guavestudios.com
   */
  public class Main extends Sprite {
 
    public var txt:TextField;
 
    public function Main():void {
      if (stage) init();
      else addEventListener(Event.ADDED_TO_STAGE, init);
    }
 
    private function init(e:Event = null):void {
      removeEventListener(Event.ADDED_TO_STAGE, init);
      // entry point
      stage.scaleMode = StageScaleMode.NO_SCALE;
      stage.align = StageAlign.TOP_LEFT;
 
      ConsoleImpl; //reference the console
      var config:XML=
 
         <![CDATA[crtl+Char.<]]></setting>
         <setting id="Console.trace">false</setting>
         <setting id="AutoCompletion.Key"><![CDATA[Char.<]]>
         true
         true
        ;
      Console.setStage(stage, config); //initialize console
 
      Console.trace("Hello World"); //sample trace
 
      //create a sample textfield
      txt = new TextField();
      txt.autoSize = TextFieldAutoSize.LEFT;
      txt.text = "Open with 'CRTL + &lt;' and completion with '&lt;'";
      addChild(txt);
 
      //register an sample command with textField
      Console.execute(["loadCommand",new SampleCommand(txt)]);
    }
 
    /**
     * sample function
     * @return testString
     */
    public function getString():String {
      return "this is a test String";
    }
  }
}

Um die Console aufzurufen muss man zuerst das Flash aktivieren und CRTL + < drücken. Dieser Shortcut ist frei definierbar mit der Config.

Das kleine Tutorial zeigt einige Funktionen die die Console im jetztigen Status kann. Die ganzen Kommandos können nach der Reihe ausgeführt werden.
Die Console ist gleich darunter eingebettet und ist noch zugeklappt:
Console

• Ist die Console offen und das Eingabe Feld aktiviert kann man mit < alle verfügbaren Commandos anzeigen.
• mit pr und < vervollständigt die Console zu print Leertaste. Danach Hello World eingeben und Enter drücken
• align help eingeben um eine hilfe über den Align Command darzustellen
• align bottom eingeben um die Console ganz untem im Flash zu positionieren
• Wir befinden uns derzeit auf der Stage
• print $stage.@ und mit < vervollständigen um die verfügbaren Childs der Stage anzuzeigen (nummeriert)
• weiter schreiben mit 1. und vervollständigen mit <. Wir befinden uns jetzt in der Applikation und sehen die Eigenschaften.
• Die ganze Zeile kann jetzt weitergeschrieben werden auf print $stage.@0.txt.text und mit Enter ausführen
• Da wir das Textfeld nocheinmal brauchen können wir es in eine Variable speichern.
• set textField $stage.@0.txt
• Wir können jetzt eine Variable modifiziern mit modify $textField.name ‘myTextField’
• Die Vervollständigung kann auch auf Element Namen reagieren.
• print $stage.@0.# und mit < vervollständigen. Jetzt wird myTextField als benanntes Item angezeigt. (Listet alle DisplayObjects mit Namen auf)
• Fertigschreiben print $stage.@0.#myTextField.text
• Wir können das Textfeld umpositionieren mit modify $textField.y 50
• Wir haben bei der Initialisierung die Console um “SampleCommand” erweitert. Der Command ist sampleCommand
• sampleCommand $textField.x $textField.y

Wir haben die Flash Deployment Console mit unseren Applikationen weiterentwickelt und jetzt online verfügbar gemacht.
Im Trunk befinden sich derzeit noch mehr Plugins und Commands die ich bei Zeit vorstellen werde.

fCon on Googlecode.com

Sourcecode für Sample

Das ganze ist OpenSoure und unter MIT Lizenz. Wer mitentwickeln möchte kann sich gerne bei uns melden.

Es gibt diesbezüglich zwar schon ein Programm namens “CrazyBump” (www.crazybump.com), jedoch bin ich mit dessen Ergebnisen nicht immer ganz zufrieden, und deshalb habe ich selber ein bisschen geforscht, wie man Displacement Maps einfach selber generieren kann.

Beim Erstellen von Displecement Maps aus normalen Texturen gibt es ein Problem. Denn, wie es nicht anders sein könnte, stellen Texturen die Farbe und nicht die Tiefe einer Oberfläche dar. Gruben kann man allerdings trotzdem erkennen, da sie sozusagen im Schatten liegen. Diese erscheinen also dunkler als Erhebungen. Das gibt uns einen Hinweis, wie wir die Texturen auswählen sollten. D.h. gleichmässig beleuchtete Oberflächen, bei denen Gruben nicht wirklich dunkler erscheinen werden ein schlechtes Ergebnis geben.
Wenn man also eine Textur total desaturiert hat man im Grund fast schon eine Displacement Map, allerdings ist das Ergebnis viel zu „flach“ und diese Textur kann höchstens als Bump Map dienen.

Warum ist das so? Ganz einfach, weil tiefere Ebenen (oder Gruben) im selben „schwarz-weiss-Bereich“ sind wie hohe Ebenen. Im Bild erscheinen sie zwar dunkler weil bei Gruben mehr dunklere Bereiche sind wie helle. Das Problem ist allerdings, dass kleine Erhebungen in tiefen Ebenen einen selben (oder ähnlichen) Weisswert/Helligkeit haben wie Erhebungen in hohen Ebenen. D.h. sie haben die selbe Höhe. Damit wir also mehr Tiefe in die Map bringen, muss alles was in einer Grube ist grundsätzlich dunkler sein wie alles was auf einer Erhebung ist. Sobald etwas die selbe Helligkeit hat, ist es auch auf der selben Höhe.

Da wir nun wissen was an dieser S/W-Map noch falsch ist bzw. fehlt stellt sich nun die Frage, wie wir das erreichen. Und die Lösung ist im Grunde ganz einfach. Wir filtern die Map nach Detailstufen. D.h. in der ersten und gröbsten Detailstufe interessieren wir uns nicht für die kleinen Grübchen und Kerben, sondern für die grossen „Täler und Berge“. Indem wir also die Map stark weich zeichnen (also z.b. mit einem Gaussian Blur) werden diese kleinen Details verwischt und nur die grobe Struktur bleibt übrig.

Vorher empfehle ich übrigens die ganze Komposition auf 16bit-Mode zu stellen, weil Displacement Maps grundsätzlich hohe Bit-tiefen benötigen.
Da mit diesem Effekt (Weichzeichnen) aber der Kontrast verringert wird, muss dieser wieder angepasst werden (d.h. 100% schwarz bis 100% weiss).
Am einfachsten macht man das mit „Auto Contrast“. Hier ist allerdings Wichtig, dass man vorher die Toleranzen auf 0,00% Stellt [1] (Levels… → Options… → Shadows-Clip und Highlights-Clip auf 0,00% Stellen).

Und nun bauen wir stufenweise mehr Detail in unsere Map. In meinem Beispiel habe ich 8 Stufen, wobei ich bei den höheren Detailstufen kleinere „Blur-Schritte“ gemacht habe [2] (somit werden die kleinen Details nicht ganz so spitzig). Bei der niedrigsten Detailstufe sollte der Blur so stark sein, dass die gröbsten Details gerade noch sichtbar sind (z.B. bei einer Mauer sollten die einzelnen Steine noch erkennbar sein). Bei jedem neuem Layer wird der Kontrast natürlich angepasst. Die Oberste stufe ist im Grunde das originale Bild, allerdings auch mit Kontrastanpassungen (falls überhaupt nötig).
Diese Layer müssen jetzt ineinander geblendet werden. Hierfür verwende ich als Layereffect „Screen“ [1], dabei muss aber die Opacity angepasst werden. Diese ergibt sich aus der Anzahl von Layer. In meinem Beispiel also 8 Layer. D.h. 100% / 8 Layer ergiebt 12.5 % für jeden Layer [3]. Der unterste wird natürlich nicht mitgezählt. Dieser bleibt auf 100% Opacity und hat „Normal“ als Layereffect.

Nun kann man alle Layer zusammenmergen und hat im Grunde schon die fertige Displacement Map. Diese kann man auch problemlos tweaken. Z.B. kann man die Gradationskurven bearbeiten.

Gerender sieht das dann so aus (3d Studo Max & VRay & VRayDisplacement):

Bzw. mit Diffusemap so:

Und hier noch zwei weitere Beispiele:

Es gibt sicherlich auch andere Möglichkeiten einen solchen Effekt zu erreichen, wichtig ist allerdgins nur das Prinzip das dahinter steckt.
Photoshop hat z.B. einen Filter namens “Surface Blur”, welcher einen sehr ähnlichen Effekt erzeugt, allerdings wird mit diesem Filter die Oberfläche meist sehr unruhig und rau. Bis jetzt sind mir die besten Ergebnisse mit diesem Workflow gelungen, da man relativ viele Kalibrierungsmöglichkeiten hat.

Ich hoffe dieses Tutorial war halbwegs verständlich. Falls aber doch Unklarheiten bestehen sollten, könnt ihr gerne Fragen stellen.
Ansonsten wünsche ich viel Spass beim selber Probieren!

edit:
Auf Wunsch von Joooo hab ich noch ein ganzes Beispiel gemacht. Das könnt ihr hier herunterladen. Im Zip-File enthalten sind:

• Orgiginale Textur / Diffuse Map (hab ich übrigens von www.cgtextures.com)
• psd-File mit den einzelnen Layer
• fertige Displacement-Map (bei der 2. version hab ich einfach nur den Kontrast mittels Curves bearbeitet)
• 3ds-Max-Szene mit dementsprechenden Material (ACHTUNG: VRay-Materials & VRay-Displacement)

Aussehen sollte das ganze dann ungefähr so: