Hochauflösender Export aus vvvv

Bitte beachten Sie, dass die HTML Version vor allem dazu dient, die indizierbarkeit des Inhals durch Suchmaschinen zu erleichtern. Eine wesentlich lesbarere Version enthält dieses pdf.

a| Anhänge

A|1| Writer Tutorial

A|1|1 Zu exportierendes Bild

Abb. 24

A|1|2 Bildgenerierungspatch vorbereiten

Abb. 25

A|1|3 Writer hinzufügen

Abb. 26

A|1|4 Connections ziehen

Abb. 27

A|1|5 Steuerknoten und Grundeinstellungen

Abb. 28

A|1|6 GO klicken und schon werden die Bilder in den Zielpfad gespeichert

Abb. 29

A|2| Stitcher Quellcode

Der vollständige Quellcode kann zusammen mit dem ausführbaren Programm
hier heruntergeladen werden. Die Datei ist 275 kb gross.

A|3| Erweiterungen

A|3|1| Qualitätsverbesserungen

Sollen Treppen vermieden werden, sollte jedes exportierte Bild in doppelter Grösse gerendert werden und dann mit einem Bildbearbeitungsprogramm um 50% verkleinert werden.
Die meisten Bildbearbeitungsprogramme können dabei die Qualität der Bilder beträchtlich steigern indem alle Kanten geglättet werden.

Abb. 30

A|3|2| Batch export

Auf dem beiliegenden Datenträger befindet sich das „Batch Export Render Template“, welches noch schneller als im Tutorial von Anhang 1 gezeigt, mit einem vorhandenen Bildgenerierungspatch kombiniert werden kann. Zudem besitzt es die Fähigkeit, nach jedem Exportvorgang ein anderes Verzeichnis auszuwählen. So können sehr schnell hintereinander viele Bilder in Einzelteilen exportiert werden.

Abb. 31

A|3|3| Um nicht quadratische Bilder zu exportieren

Durch eine kleine Änderung im Writer (EX9.Texture Grid) könnten nicht-quadratische Seitenverhältnisse auch direkt an dessen Renderer (DX9) Knoten eingestellt werden.

Allerdings bietet diese Methode keine zuverlässige Vorschau der Einstellungen, was zu unerwünschten Resultaten führen kann. Die in Abbildung A|10 verwendete Methode zur Kontrolle des Bildausschnittes ist sicherer.

Abb. 32

A|4| Private E-Mail Korrespondenz
.... mit vvvv Entwicklern

A|4|1| Von: joreg [mailto:joreg@meso.net]

Gesendet: Freitag, 14. Oktober 2005 20:41

halo thomas.

ich probier mich mal stichwortartig in einer erklärung:
die 2048x2048 als beschränkung für die maximale grösse einer textur sind eine reine hardware-beschränkung und treffen so auch nur für ati-karten zu. die meisten nvidia karten scheinen eine maximale auflösung von 4096x4096 zu haben. vielleicht gibt es noch andere grafikkarten hersteller, die andere beschränkungen in ihre produkte einbauen. schwer herauszufinden. sowas steht kaum bei den tech specs im internet. es handelt sich dabei um den wert den die graphikkarten/treiber für die “caps” (=capabilities) MaxTextureWidth und MaxTextureHeight zurückliefern.

in der neuen vvvversion siehst du den wert deiner graphikkarte am zweiten pin eines
Device (Auto) knotens.

die antialiasing problematik ist die: in directx funktioniert das antialiasing nicht mit rendertarget-textures (so heisst das directx-intern, wenn man einen dxtextureknoten anlegt.) also auch hier erstmal eine directx-beschränkung. irgendeinen umständlichen trick gab es da aber...ich denke in einer zukünftigen version würden wir uns das nochmal anschaun.. erstmal doppelt so gross rendern und dann 50% verkleinern. wird auch alles smoother...

die 2er-potenz sache ist eine historische. irgendwie scheint das speichermanagment leichter zu sein, wenn man immer nur mit solchen einheiten zu tun hat. heute können die meisten graphikkarten in vielen fällen auch mit texturen beliebiger grösse umgehen.

sonst noch wer?
alles gute.
joreg.

A|4|2| Von:Sebastian Oschatz [mailto:oschatz@meso.net]

Gesendet: Sonntag, 16. Oktober 2005 19:13

Hallo thomas,

Ja hier auch nochmal eine ergänzung zu joregs antwort. Alles natürlich
ein riesiges thema, zu dem es uferlos viel literatur gibt. Beste
grüsse s.

Da hardware ja immer mit einer endlichen anzahl von transistoren umgehen muss, gibt es immer ganz klare begrenzungen in der anzahl der dinge, die man dann softwaretechnisch unterscheiden kann.

Ein 6502 (wie im C64) verwendet hat 16 Adressleitungen, kann also 65536 Bytes adressieren.
Ein 8086 hat 2?? Adressleitungen kann also XX Bytes adressieren (recherchieren)
640k should be enough for everybody (bill gates; recherchieren)

Ein Pentium hat 32 Adressleitungen, kann also 4294967296 (4GB) adressieren. (auch wenn windows sich eine klaut, und man daher nur die hälfte benutzen kann)
Für jedes Bit, das gleichzeitig bearbeitet werden muss, braucht man eine eigene Leitung und eigene Schaltkreise, was sich in erhöhter komplexität niederschlägt.

Da die grafikkarte ja nur so schnell ist, weil die bits kurze und breite wege auf der karte zurücklegen gibt es eine natürliche limitierung in der anzahl an pixeln, die man sinnvoll bewegen kann. 4096x4096 scheint das zu sein, was heutige hersteller maximal zulassen. Immerhin 16MB bilddaten, die in jedem frame bewegt werden müssen, wenn man mit der textur arbeitet. 8192x8192 sind dann schon 64MB -- kein spielehersteller glaubt, dass sich mit den damit erzielbaren frameraten ein blumentopf gewinnen liesse. Also spart man die leitungen, zählwerke und adressierungslogiken ein.
Alles wertvolle transistoren.

Lagert man speicher auf das motherboard aus, hat man verloren (viele laptops tun das ja) Die geschwindigkeiten die man über den grafikkartenstecker übertragen kann (sei es auch ein superschneller pci-express bus) sind um grössenordungen niedriger, als die, die man direkt auf der grafikkarte zurücklegen kann.
Im wesentlichen eine konsequenz der für heutige belange zu niedrigen lichtgeschwindigkeit (übungsaufgabe: in wievielen centimetern muss man seine logik unterbringen, wenn man z.b. mit 3.6GHz Taktfrequenz arbeiten will)
Die Dinge eng zusammenzurücken ist die eine möglichkeit (die andere ist parallelisieren)
Deswegen sind auch cache-speicher so extrem wichtig. Sie rücken diejenigen bytes, die man häufiger braucht näher an den prozessor ran. Wenn der cache speicher voll ist, bricht die geschwindigkeit rapide ein. Das könnte man vermutlich ganz gut in vvvv untersuchen: mal messungen durchführen, wieviele polygone einer bestimmten texturgrösse man mit einer bestimmten framerate anzeigen kann. Ich tippe es ergibt sich eine treppenstufenkurve. Jede treppenstufe weist darauf hin, das irgendein cache vollläuft.
Zweierpotenzen sind in der hardwaretechnik wichtig, weil sie die zahlen beschreiben, die mit einer *minimalen* anzahl von leitungen eindeutig adressiert werden können. Also eine technische optimierung. Mit 9 leitungen kann ich 512 pixel adressieren (2^9=512). Will ich 513 pixel adressieren, brauche ich 10 leitungen. Mit gleichem aufwand könnte ich also auch 1024 benutzen. Relativ gesehen, sind also 513 teurer als 1024.

Wäre aber spannend zu wissen, wie sich das mit der geschwindigkeit verhält.
Ich hätte immernoch die vermutung, dass 513x513 genauso schnell ist wie 1024x1024.

Beste grüsse,
sebastian oschatz

w w w . m e s o . n e t

t ++49 69 24 000 321
f ++49 69 24 000 330
niddastrasse 84hh . 60329 frankfurt main de

A|5| Literaturverzeichnis

ADOBE, Creative Team (2004): Classroom in a Book: Adobe Illustrator CS2. Berkeley, CA: Adobe Press.
BAEZA-YATES, Ricardo (2005): Visual Programming.
URL: http://www.dcc.uchile.cl/~rbaeza/cursos/vp/todo.html (06.11.2005)
BECK, Ernst-Georg (2005): Einführung in die Mikroskopie, Mikroskopische Übungen. Breisach: Becsoft. URL: http://www.biokurs.de/skripten/bs11-3.htm (06.11.2005)
BEGEL, Andrew (1996): LogoBlocks: A Graphical Programming Language for Interacting with the World. (unveröffentliche Bachelor-Arbeit. Cambridge, MA: Epistemology and Learning Group, MIT Media Laboratory). URL: http://www.cs.berkeley.edu/~abegel/mit/begel-aup.html (06.11.2005)
BRUCKMANN (1981): Bruckmann’s Handbuch der Drucktechnik. München: Verlag F. Bruckmann KG.
BURNETT, M. | GOLDBERG, A. | LEWIS, T. (1994): Visual Object-Oriented Programming: Concepts and Environments. Upper Saddle River, NJ: Prentice-Hall.
FERNANDO, R. | KILGARD, Mark (2003): The CG Tutorial. The Definitvie Guide to Programmable Real-Time Graphics. Boston: Addison-Wesley.
EUKLID | THAER, Clemens (2003): Die Elemente, Buch 1-13: Frankfurt am Main: Harri Deutsch.
GOLIN, E. J. | REISS S. P. (1990): The Specification of Visual Language Syntax. In: Journal Of Visual Languages and Computing. 1(2):141--157, 1990. Amsterdam: Elsevier.
JAKOB, Tanja (2004): Illustrator CS. München: Hanser Fachbuchverlag
MESO (2005a): Propaganda. URL: http://vvvv.meso.net/tiki-index.php?page=Propaganda (06.11.2005)
MESO (2005b): vvvv : Spreads. URL: http://vvvv.meso.net/tiki-index.php?page=Spreads (06.11.2005)
MYERS, B. A. (1990): Taxonomies of Visual Programming and Program Visualization.
In: Journal Of Visual Languages and Computing. 01(2): 97--123, 1990. Amsterdam: Elsevier.
WOLFRAM Research, Inc (2005a): Point. URL: http://mathworld.wolfram.com/Point.html (06.11.2005)
WOLFRAM Research, Inc (2005b): Line. URL: http://mathworld.wolfram.com/Line.html (06.11.2005)
TESCHNER, Helmut (2003): Druck & Medien Technik. Fellbach: Fachschriften-Verlag.
THOMPSON, Robert | FRITCHMAN T., Barbara (2003): PC Hardware in a Nutshell, 3rd Edition. Sebastopol, CA: O’Reilly Media, Inc.

A|6| Abbildungsverzeichnis

Mit Ausnahme von Abbildung 23, die eine Collage von 4 Grafiken von unbekannten Urhebern ist, wurden alle Abbildungen vom Autor angefertigt.

Abb|1: Auflösungsdialog von Adobe Photoshop.
Abb|2: Ein vvvv Programm mit verschiedenen Knoten zur Bildgenerierung.
Abb|3: Der Additionsknoten von vvvv.
Abb|4: Linear Spread x und Linear Spread xy.
Abb|5: Verschiedene Arten von Spreads: Linear, Random, Gaussian, Bézier, Circular, Typo.
Abb|6: Die sechs Eckpunkte eines Würfels (links) und ein vergrößerter Bildausschnitt (rechts). Die Größe der Punkte ist identisch.
Abb|7: Das Gitternetzmodell eines Würfels (links) und ein vergrößerter Bildausschnitt (rechts). Die Liniendicke ist identisch.
Abb|8: Eine Fläche (links) und ein vergrößerter Bildausschnitt (rechts). Das Verhältnis von Fläche und Leeraum ist unverändert.
Abb|9: Ein Würfel (links) und ein vergrößerter Bildausschnitt (rechts). Das Verhältnis von Fläche und Leeraum ist unverändert.
Abb|10: Aufbau zum Speichern des Inhalts eines Renderers.
Abb|11: Mögliche Aufteilung eines Motives in gleich große Teile.
Abb|12: Manuelle Vergrößerung eines einzelnen Bildausschnittes mit vvvv.
Abb|13: GridSplit zur besseren Kontrolle des Bildausschnittes.
Abb|14: Hinzufügen einer Speicherfunktion.
Abb|15: Hinzufügen eines Zählwerks um den Export noch schneller zu machen.
Abb|16: Eingänge des konzipierten Exportmodules.
Abb|17: Ausgänge des konzipierten Exportmodules.
Abb|18: Das noch funktionslose Exportmodul in einem leeren Patch.
Abb|19: Das fertige Exportmodul.
Abb|20: Dialog zur Einstellung der Bildgröße in Photoshop.
Abb|21: Bildrastereinstellungen in Photoshop.
Abb|22: Die Oberfläche des „Stitcher“.
Abb|23: Vier Beispiele aus den „Screenshots of the Days“ der vvvv Homepage. Davon basieren drei auf fraktalen Algorithmen.

<< zurück ||

A| Anhänge

Zurück zur Diplom-Hauptseite