ChromeBlack Studios :: BlenderCorner

blender.chromeblack.com

Es ist Mal wieder so weit. Die Zeit des Friedens, der Ruhe und der Liebe.

Freundlich besinnliche Weihnachtsgrüße der Arbeitgeber werden begleitet von absatz- oder performancesteigernden Massnahmenempfehlungen über die Festtage. Urlaubsanträge und der Wunsch die Tage im Kreis der Familie zu verbringen weichen dem ungeheuren Druck der wunderschönen Weihnachtszeit.

Und ganz in diesem Sinne stellen wir uns bewust auf die Seite derer die sich über diese Tage dem Diktat der Marktwirtschaft beugen und unermüdlich freundlich zähneknirschend gerne unseren Bedürfnissen nach langen Ladenöffnungszeiten und günstigen Angeboten nachkommen, damit sich das Glück über wenigstens eine Woche im Jahr perfektionieren kann [...] Kr$!%/=rrch%§ (/=$&§ “?::: kh &^”§%)?(hie rc”!^)(=)k

Bitte denkt daran alles was noch wichtig ist, bis zum 21.12.2012 bzw. 23.12.2012 zu erledigen, denn an einem der Tage endet der Maya-Kalender der langen Zählung (je nachdem ob man die älteren Korrelationsergebnisse akzeptiert oder die neueren).

Es gibt Menschen die darin einen Weltuntergang vermuten, andere sehen einen Neubeginn der Schöpfung.

Tatsache ist allerdings das die Berechnungen der Maya nicht mit dem Kalenderende enden oder erst mit dessen Anfang beginnen. Gibt uns diese Erkenntnis SIcherheit?

Nun, besser vorsorgen. Wer noch was zu erledigen hat, gute Vorsätze tatsächlich Mal umsetzen will oder einfach aussteigen will. Dies ist das Jahr der Jahre.

Ganz in diesem Sinne wünschen wir Euch eine ruhige und angenehme Weihnachtszeit und ein gesundes und zufriedenes Neues Jahr 2012!

Euer ChromeBlack Studios Team

Das RiftRoamers Gameprojekt hat einen neuen Namen erhalten und nennt sich jetzt RiftRoamers – Nations of Orion. Es wird sich nicht um eine eigenständig entwickelte Game Engine und KI handeln sondern die Vega Strike Engine verwenden. Für die Entwicklung des Projektes haben wir einen temporären Gameserver eingerichtet der unter http://centaction.servegame.com bzw http://mmo.riftroamers.net(nahezu dauerhaft) erreichbar ist.

Nations of Orion – die Nationen des Orionarms – ist ein auf RiftRoamers basierendes Computerspiel.  Zeitlich setzt die Storyline gut 10 Jahre nach den Ereignissen des Rollenspiels RiftRoamers – Dystopia ein. Um dem Rechnung zu tragen gibt es einige Erweiterungen der Storyline. Der Spielfokus konzentriert sich auf den Orion Arm und einige wenige weiter entfernt liegende Regionen unserer Galaxis.

Vega Strike und RiftRoamers – Nations of Orion

Technisch betrachtet ist RiftRoamers – Nations of Orion ein Vega Strike Mod. Ohne Vega Strike und die unglaubliche Entwicklungsarbeit die dieses Entwickler-Team leistet wäre Nations of Orion nicht machbar.

Im Laufe der Zeit – das bedeutet wenn sich genügend Interesse zeigt und/ oder bevor die Motivation durchzuhalten erloschen ist – wird aus dem Mod idealerweise eine Total Conversion.

Damit nutzt RiftRoamers – Nations of Orion die technische Basis von Vega Strike, jedoch werden in der letzten Ausbauphase komplett eigene Inhalte verwendet.

Der Umfang eines solches Projektes ist enorm. Neben dem Austausch aller Modelle, Texturen und der Anpassung der dazu gehörenden Parameterdateien, müssen auch Planetensysteme und Beschreibungen, Raumstationen und Schauplätze, Spezies und Geschichtsdaten, Fraktionen und Politische Zusammenhänge, sowie Missionen und Neuigkeiten an die RiftRoamers – Dystopia Inhalte angepasst und das Look&Feel des User Interface individualisiert werden. Eine gewaltige Aufgabe.

Zum Glück ist Vega Strike auf einfaches Modding ausgelegt worden, so das es kein unüberwindbares Hindernis sein dürfte die Updates nach und nach zu integrieren. Wir werden zunächst mit den Raumschiffen und Storylines dreier Fraktionen starten und nur deren Raumgebiete und Inhalte bereit stellen. Zudem beschränken wir uns auf wenige Schiffstypen je Fraktion und nutzen eine einzelne modular veränderbare Raumstation je Fraktion. Zug um Zug erweitern wir dann den Mod einzeln um weitere Fraktionen nebst deren Raumgebieten.

Dieses Mal möchte ich hier einen Charakter für unser Game-Projekt vorstellen. Als Basis diente hier das UniHuman Charakter-Framework. UniHuman ist ein LowPolygon Derivat des MakeHuman Charakters. Der UniHuman Charakter stellt ein Basis-Mesh für die freie 3D Animationssoftware Blender dar, das mittels ShapeKeys auf vielfache Weise verändert werden kann, um so einen einmaligen und individuellen Charakter zu erhalten.

Aufgrund der äußerst geringen Polygonzahl eignet sich das Mesh hervorragend für Computerspiele, in denen viele Charaktere gleichzeitig ddargestellt werden sollen.

DAs Bild zeigt die erste Alpha-Version unserer UniHuman-Adaption. DIe Kleidung wurde aus dem Basismesh heraus extrudiert und angepasst.

Nachdem unsere kleine BlenderFarm nun lauffähig ist und zudem die neuesete Version des externen Renderers Yaffray (0.1.1) nebst aktuellster BugFix Version von Python (2.6.2) auf den beteiligten Systemen installiert wurde, wurde es Zeit das für mich undurchsichtigste Thema in Blender anzufassen.

UV-Mapping

Grundsätzlich ist UV-Mapping nicht mehr und nicht weniger als jedem Vertex des 3D-Modells (Mesh) einen bestimmten Pixel einer 2D-Textur zuzuweisen.

Je nach komplexität und Form des 3D-Modells klappt dies problemlos (Hohlzylinder, Quader) oder nicht (Kartoffel/ Asteriod, Landscape, Auto, Mensch, etc.).

Die UV-Map ist das abgewickelte 3D-Modell. Die Art der Abwicklung bestimmt dabei wie gut oder schlecht das Modell am Ende bemalt werden kann. Ganz ähnlich wie bei einer Orange, deren Schale man stallenweise einschneidet und dann in einem Stück abwickelt, wird auch ein 3D-Modell abgewickelt. Die UV-Map wird im .blend-File des 3d-Modells gespeichert.

Die meisten Abwicklungsfunktionen versuchen anhand der Größe des Winkels zwischen zwei Flächen zu ermitteln an welcher Stelle das Modell eingeschnitten wird. Dies klappt Mal gut und Mal nicht. In Blender können einzelne Edges (Kanten) selektiert und mittels CTRL+EKEY (Menüaufruf) und “Mark Seam” als Schnittkanten definiert werden.

Diese Schnitte nennt man auch Saum (Seam) und sie erfordern evtl. ein aufwendiges angleichen der Übergänge wenn beispielsweise linien einein Saum kreuzen.

Mittels UKEY wird das Unwrap-Menü aufgerufen und der oberste Eintrag “Unwrap” wickelt das Mesch  ab.  Jede neue Abwickung (UKEY) verwirft die vorherigen UV-Koordinaten und erstellt eine neue Meshabwicklung (UV-Map).

Als erstes PRojekt hatte ich mir ein einfaches Raumschiffmodell aus dem RiftRoamers-Universum gegriffen und einfach Mal angefangen (dann kann doch nicht so schwersein).

Hier ein Screenshot des Modells:

Ich habe etwa acht Wochen benötigt um das Materialsystem einigermaßen in den Griff zu bekommen. Naja. Um erhlich zu sein haben Familie, Job und Haus natürlich einen signifikanten Einfluß auf die Verfügbare Zeit. Und der Faktor LEbensalter spielt wohl auch noch eine Rolle. Mit der heutigen Rechenleistung als Schüler wüste ich genau wohin die Reise geht. realistisch im Rahmen eines “Erwachsenenhobbys” muß ich mich wohl daran gewöhnen das die meißten Schritte kleine Schritte sind.

DIe ursprüngliche Idee war eine einzige UV-Textur auf das gesamte Modell zu mappen. Das würde bestimmt funktionieren bei dem Modell, aber ich habe noch nicht alles durchblickt was dazu gehört.

Im Nachgang habe ich entdeckt das es sinnvoll sein kann bestimmte zusammenhängende Flächen des Meshes einem eigenen Material mit einer UV-Map zuzuordnen. Das ganze ist für Anfänger aufgrund der Vielzahl der MAterialien möglicherweise Fehleranfälliger, aber da jede Fläche ein genau definiertes Material hat, dem ich zweckmäßigerweise einen passenden Namen verpasse ist die Zuordnung des Material zur beeinflußten FLäche leichter nachzuvollziehen. Das bedeutet: solange ich mir sicher bin das richtige MAterial in der MAche zu haben, kann ich mich drauf verlassen, das ich nur die Flächen verändere die ich gerade bearbeite. Ein Verändern der UV-Koordinaten macht mir nicht das Mapping des gesamten Modells zunichte.

Hier ein Screenshot eines Modells mit multiplen Materialien:

Bei diesem Rendering sind die Fenster und die Wände als Prozedurale Materialien ausgeführt, die Tore hingegen sind als UV-Texturen ausgelegt. Je ein Material für die großen Tore und für die kleinen Tore. Der Boden ist eine Mesh mit einer leichten Erhöhung und plateauartiger Stellfläche, die ein eigenes prozedurales Material enthält. Der Himmel ist ein blendereigenes Hintergrundobjekt mit einem mehr oder weniger geglücktem Farbverlauf.

Updates (am selben Abend)

Tja, da mir das mappen einfacher Körper nun zumindest nicht mehr ganz fremd ist und um die Abläufe zu üben und zu vertiefen, hier noch ein Container für Maddock Krug.

Der Container hat RiftRoamers Maße ist also 14,6m (48ft) lang, 2,48m breit und knapp 2,9m hoch. Das entspricht einem Domestic High Cube aus Noramerika. Das BLEND-File Paket stelle ich auf RiftRoamers.net im Develloper Forum  online.

Happy Blending!

Was hat ein kürzlich havarierter PC mit einer RenderFarm für Blender (eben einer BlenderFarm) gemeinsam? Neben der Antwort auf diese Frage behandelt dieser Artikel auch die Inbetriebnahme unserer kleinen Farm.

Die Idee

Es existieren mehrere betriebsbereite PCs mit halbwegs modernen Betriebssystem (Windows ab 2000 SP4, Mac OS X ab 10.4.11, Linux mit 2.6er Kernel) in einem funktionierenden LAN untätig herum. Warum nicht diese knechten und dazu zu verdonnern die zeitaufwendige Renderarbeit einzelner Bilder oder ganzer Animationen mit zu tragen?

Mittlerweile gibt es ein engl. PDF zum Download (nicht von mir) das die Einrichtung einer Renderfarm mit Blender und FarmerJoe beschreibt!

Die (einfache) Lösung

Eben! Warum nicht. Folgende Zutaten werden benötigt:

• Blender (ab 2.4.2): http://www.blender3d.org
• Farmerjoe: http://blender.formworks.co.nz
• Imagemagick: http://www.imagemagick.org

Einrichten der RenderFarm

Als Erstes benötigt man einen Server. Bei mir ist dies der langsamste PC (AMD Athlon 800 MHz mit 392MB RAM und Win2k SP4). Welcher Rechner dies am Ende ist ist eigentlich egal. Man sollte jedoch bedenken, das ggf. noch zusätzlich Blender als Modeller darauf läuft und genutzt wird. Entsprechende Ressourchen sollten also berücksichtigt werden.

Als nächster Schritt wird Blender installiert (es ist besser einen Pfad zu wählen in dem keine Leerzeichen vorkommen). Auf unserer kleinen Fram ist dies:

C:\Programme\Blender_2.49a

Danach wird das im /bin-Verzeichnis des Farmerjoe Paketes enthaltene script” farmerjoe_submit.py” in das Skriptverzeichnis von Blender kopiert. In unserem Fall haben wir Blender “Standalone” installiert und daher gilt folgendes Verzeichnis:

C:\Programme\Blender_2.49a\.blender\scripts

Das Skript kann dann unter dem Menüpunkt “Render” und “Farmerjoe Submit Render” gestartet werden. Siehe folgender Screenshot:

Beim Start des Blender Render Farmers “Farmerjoe” erscheint im Anschluß folgender Dialog:

Jetzt folgt Imagemagick. Man klickt sich einfach durch den Installer und kann die vorgeschlagenen Optionen einfach übernehmen. Wichtig ist, das die Option Imagemagick mit in den Windows Suchpfad aufzunehmen angeklickt bleibt. In unserem Fall liegt Imagemagick (convert.exe) letztendlich unter:

C:\Programme\ImageMagick-6.5.4-Q16

Als letztes wird Farmerjoe in ein geeignetes Verzeichnis entpackt. Auf unserer kleinen Farm ist dies:

C:\Farmerjoe

Im zweiten Step wird dieses neue Verzeichnis im LAN freigegeben und auf allen Client-Rechnern unter dem gleichen Laufwerksbuchstaben eingebunden.

Der Rechner auf dem Farmerjoe sich aufhält heißt in unserem Windows-Netzwerk “Freeport” und hat die IP-Adresse “192.168.1.252″. Alle Rechner im LAN haben übrigens RiftRoamers-Bezeichnungen. Die Freigabe lautet demnach \\Freeport\Farmerjoe und erhält auf unserer kleinen Farm den Laufwerksbuchstaben R: (R wie Rendern).

Die Slaves

Auf jedem Client (Farmerjoe nennt diese Slaves) steht Farmerjoe nun unter dem Pfad R: (z.B. “R:\Farmerjoe.exe”) zur Verfügung. Es werden nun Verknüpfungen zu Farmerjoe erstellt und zwar wie folgt:

Jeder Slave startet Farmerjoe mit der normalen Verknüpfung. Die Befehlszeile lautet also:

R:\Farmerjoe.exe

Der Master

Der Master startet Farmerjoe mit einem Parameteraufruf. Die Befehlszeile lautet hier:

R:\Farmerjoe.exe –master

Und das Steuerungsprogramm für die Renderfarm wird mit einem anderen Parameter gestartet. Die Befehlszeile lautet:

R:\Farmerjoe.exe –appserver

Die Slaves versuchen sich nach Verbindungsverlust alle 30 Sekunden automatisch erneut mit dem Master zu verbinden. Es ist also wenig problematisch ob der Master bereitsgestartet ist wenn die Clients hochfahren (falls der Client per Autostart mitgestartet wird).

Der Appserver

Der Webserver (oder AppServer) sollte nach dem Master gestartet werden. Wird der Master beendet und erneut gestartet verliert der Appserver den Kontakt. Auch er mußte in unserem Fall dann neu gestertet werden.

Der Blender Render Farmer (aka Webserver oder AppServer )wird über einen Browser gesteuert. Er wird unter der URL dach dem Schema: “http://master-hostname:portnummer” aufgerufen. In unserem Fall ist dies

http://freeport:3050

“http://192.168.1.252:3050″ wäre jedoch auch korrekt.

All diese Informationen müssen in der Konfigurationsdatei “farmerjoe.conf” berücksichtigt werden:

Oben werden Port und IP des Masters konfiguriert. Darunter folgen die Einstellungen der Clients (Slaves) für Linux, Windows und Mac OS X.

Wie man erkennen kann haben wir hier die vollständigen Pfade zu Blender (windows_blender) und Imagemagick (windows_composite) auf dem Server eingetragen. Das Laufwerk R: wird unter dem “windows_root = R:” berücksichtigt.

Ganz unten wir der Application Server (appserver) konfiguriert. Hier muß lediglich ein anderer freier Port angegeben werden.

ACHTUNG: Denkt an die Firewall! Komplexe Systeme wie Norton, McAfee, Kaspersky oder auch ZoneAlarm fragen bei Start von Farmerjoe ob dieses “unbekannte” Programm auf das Web zugreifen darf und empfehlen dieses nicht zu gestatten. Hier ist es wichtig einen klaren Kopf zu behalten und nicht einfach OK zu klicken. Dieser Vorgang muß natürlich erlaubt werden damit Farmerjoe seiner Arbeit nachgehen kann

Zum Test wurde das blend-File des Nebula-Tutorials von Colin Litster (http://www.cogfilms.com) gerendert. Die zehnsekündige Animation besteht aus 250 Frames mit 640×320 Pixel per Frame. Die gesamte Renderzeit betrug in der Farm gut 49,8 Minuten, wohingegen der schnellste Rechner allein etwa 195,7 Minuten benötigt hätte (im Schnitt 47 Sekunden je Frame). Die Farm war also um den Faktor 3,9 schneller als der Einzelrechner. Das ist doch schon mal etwas.

Der erste Test lief zunächst mit Faktor 2,8 ohne den in der folgenden Liste mit dem Namen Vega4 bezeichneten Rechner zufriedenstellen. Der zusätzliche Rechner wurde nachfolgend mit geringem Zeitaufwand (Installation, Kopieren der Konfiguration, einbinden des Netzlaufwerks) hinzugefügt. Ein Anzeichen wie einfach und unkompliziert sich die Farm skalieren läßt. Unter Blender ist dieses zusätzliche System allerdings schneller als das bisherige “Referenzsystem” Altara.

Nachtrag (10. März 2010): Dank weiterem Knoten “Arcturus” und temporärem zur Ruhe setzen des Knotens “Starship2″ ist der Performance Faktor der Farm gemssen am Referenzsystem “Altara” nun 4,1.

Die Rechner der kleinen BlenderFarm:

ALTARA: Singlecore Pentium P4 2,67 GHz, 2 GB RAM, 1 GB Radeon 4650 Grafik, Geekbench: ?

VEGA4: Singlecore Pentium P4 2,8 GHz HT, 1,5 GB RAM, 256 MB GeForece 7600GS Grafik, Geekbench: 724

ARCTURUS:Singlecore Celeron 2,66 GHz HT, 512 MB RAM, OnBoard Grafik (64 MB Shared), Geekbench: ?

STARSHIP2: Singlecore Pentium P4 1,7 GHz, 2 GB RAM, 128MB Radeon Mobility X600 Grafik, Geekbench: ?

CETI-PRIME: Singlecore Pentium P4 2,4 GHz, 512 MB RAM, 128MB GeForce4 Ti4200 Grafik, Geekbench: ?

SOLARIS: Dualcore Pentium 4 2×3,0 GHz, 1024 MB RAM, 1024 MB ATI Radeon 5450 Grafik, Geekbench: 2090

FREEPORT: Singlecore Athlon 600MHz @800MHz, 392MB RAM, 32MB GeForce2 MX400 Grafik (als Server), Geekbench: ?

POWERMAC: PowerPC G4 466MHz, 1584 MB RAM, 32MB ATI Rage128 Pro Grafik (geplant: Upgrade auf: 256MB ATI Radeon X1950 Grafik), Geekbench: ?

Die Animation

Und zum Schluß noch die Animation selbst für WebDarstellung optimiert (verkleinert): 640 x 320 (5,5 MB):

Die originale Größe 640 x 320 AVI uncompressed (164MB) folgtauf Anfrage.

Tja, was hat denn nun ein kürzlich havarierter PC mit einer BlenderFarm gemeinsam?

Und die Frage?

Aufgrund eines BIOS-Fehlers auf ALTARA hatte ich bei einem bekannten Online-Auktionshaus namens eBay ein Mainboard nebst CPU und Grafikkarte als Ersatzteil für den havarierten PC ersteigert. Zwischen Auktionsende und Lieferung habe ich allerdings das BIOS erfolgreich flashen können (man glaubt es kaum aber ich habe 3 Floppy-Laufwerke, vier Kabel und mindesten 17 Disketten durchprobiert bis ich eine funktioierend Konstallation hatte.

Kurze Rede langer Sinn: Am Ende war ein Mainboard nebst CPU und Grafikkarte übrig. Etwas RAM hatte ich noch, ein alter Athlon 600MHz bettelte sowiso schon länger für seinen Ruhestand und dessen Gehäuse, Netzteil und Festplatte bildeten nun einen weiteren funktionsfähigen Rechner der genutzt werden mußte. Geboren war die Idee zu Renderfarm.

Moin Allerseits!

Dieses zugegeben nicht unbedingt sehr individuelle Theme (LightWord; bzw. mittlerweile pixel) ist der Übergang zu unserem neuen BlenderBlog “ChromeBlack Studios :: BlenderCorner”.

Wie es der Name schon vermuten läßt werden wir hier sozusagen unser Leben mit der 3D Modelling, Animation, Sequencing und Rendering Suite Blender3D skizzieren.

Was Ihr erwarten könnt: NoobTutorials für Blender3D (wir sind schließlich selbst auch noch Noobs), Work in Progress (WIP) Impressionen, Projekte für das freie Rollenspiel “RiftRoamers” und dieverse Workflow-Prozesse die wir für uns erarbeitet haben.

Dabei beleuchten wir auch Berührungspunkte mit anderen Software-Produkten, wie z.B. GIMP oder OpenOffice, und Tests neuer Skripte und Funktionen die wir in den jeweiligen Applikationen entdecken.

Mit etwas Glück ist für Euch etwas dabei.