blender.chromeblack.com

ChromeBlack Studios :: BlenderCorner

Dieser Artikel beschreibt eine Möglichkeit ein in DAZ Studio 3 verfügbares Modell nach Cinema 4D CE+ zu portieren.

[Fortsetzung folgt]

Dieser Artikel beschreibt eine handhabbare Methode zur Portierung eines in Cinema 4D CE+ erstellten Modells nach Blender 2.49b.

[Fortsetzung folgt]

Hier folgen ein paar wirklich rudimentäre Tipps wie es gelingt ein Poser oder DAZ3D-Modell so zu exportieren das beim Import in Blender möglichst alle Materialien erhalten bleiben und nur geringe Korrekturen notwendig sind.

Die größte Herausforderung bei der Verwendung von mehreren Programmen in der 3D Visualisierung ist meines Erachtens nach die Materialsysteme zueinander kompatibel zu gestalten. Eine berüchtigte Einschränkung von Blender ist die Limitätion auf 16 MAterial-Slots pro Objekt. In einigen Programmen ist deutlich mehr möglich. Doch wie wird man dieses Objekteres Herr? Eine einfache Methode zeigt dieser Artikel auf.

Ein Hinweis zu Materialsystemen vorab: Prozedurale Texturen sind nicht übertragbar! Ihr könntet eine prozedurale Textur rendern und als Image Textur laden, das geht, aber die Vorteile der prozeduralen Textur gehen verloren. Stencil-, Bump-, Reflective- oder Alpha-Maps die Mittels eine Graustufen-Textur die Wirkung des Kanals zwischen 0% und 100% steuern sind bei einigen Programmen invertiert. Dies muß beim Portieren berücksichtigt werden.

[fortsetzung folgt]

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?

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

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

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

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

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

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

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.

In den nächsten Wochen werden wir an dieser Stelle erste Konzeptzeichnungen und Modellierungsansätze vorstellen. Dabei werden wir versuchen möglichst viele Resultate in Blender selbst und zudem unter dem Gesichtspunkt Echtzeitrendering in der Blender GameEngine diskutieren.
Primär geht es uns um ein Proof-of-Concept und nicht im fertige Produkte.

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.