Medien Wiki - User contributions [en]

GMU:Media Art Strategies/Leon-Etienne Kühr/Project

2022-09-14T10:44:06Z

Lalalolo: /* Kurzbeschreibung */

GMU:Media Art Strategies/Leon-Etienne Kühr/Project

2022-09-14T10:43:30Z

Lalalolo: /* Kurzbeschreibung */

GMU:Media Art Strategies/Leon-Etienne Kühr/Project

2022-09-14T10:43:13Z

Lalalolo: /* Installation */

GMU:Media Art Strategies/Leon-Etienne Kühr/Project

2022-09-14T10:42:59Z

Lalalolo: /* Präsenz (Mensch + Prothese) */

GMU:Media Art Strategies/Leon-Etienne Kühr/Project

2022-09-14T10:42:11Z

Lalalolo: /* Einflüsse anderer KünstlerInnen */

[[https://www.uni-weimar.de/kunst-und-gestaltung/wiki/GMU:Media_Art_Strategies/Leon-Etienne_Kühr/Project_old old project about telepresence]]

=Präsenz (Mensch + Prothese)=
Entwurf für eine Installation von Leon-Etienne Kühr und Clemens Hornemann

{{#ev:youtube|reuBmgCcBew|735}}

----
==Kurzbeschreibung==
Die Installation "Präsenz (Mensch + Prothese)" befasst sich mit der Untrennbarkeit physischer und digitaler Präsenz in der heutigen Zeit.

Ein mittig im Raum installiertes Smartphone misst die Signale und Wellen, die wir und unsere digitalen Geräte ausstrahlen. In einem Becken voll schwarzer Farbe werden durch Interferenzmuster und Wellen die gemessenen Daten dargestellt und reagieren kurz und langfristig auf die Veränderungen im Raum — die Menschliche Präsenz als messbare Größe sichtbar gemacht.

[[File:PMP_Render_front.png]]
----

==Hintergrund==

<br>

Das Smartphone:

Moderne Smartphones bieten vielfältige sensorische Schnittstellen zur Wahrnehmung und Interaktion mit ihrer Umgebung. Zudem sind sie die am [https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide häufigsten genutzte] und wohl intuitivste Mensch-Maschinen-Schnittstelle.

Durch ihre sensorische Vielfalt ist nicht nur die Vernetzung zu anderen Endpunkten des Internets, sondern auch zu ihrer physischen Umwelt möglich. Dabei werden sowohl physikalische Größen wie Temperatur, Ton, Erdbeschleunigung oder Lichtintensität als auch verschiedene digitale Schnittstellen wie Bluetooth, WLAN oder das Funknetz gemessen. Ein Großteil dieser Sensoren wurde im Laufe der Jahre zur Standartausstattung der Geräte, um bestimmte anwendungsspezifische Funktionen zu erfüllen, so in etwa ein Distanzsensor, um zu erkennen, ob das Smartphone gerade an die Ohrmuschel gehalten wird. Die Nutzung ist aber nichtmehr nur auf diese Funktionen beschränkt. So werden Sensordaten vom Gerät gesammelt, und auch Applikationen von Drittanbietern können auf die Sensoren zugreifen.

Manche dieser Schnittstellen zur Außenwelt wie WLAN oder Bluetooth arbeiten kontinuierlich und selbstständig im Hintergrund, beispielsweise, um nach Netzwerken in der Umgebung der Geräte zu suchen. Zu sehen ist dies am Beispiel der Corona-Warn-App; hier wird der Bluetooth-Standard verwendet, um von den in der Umgebung vorhandenen Smartphones auf die Präsenz anderer Menschen zurückzuschließen. Im Rückschluss bedeutet dies, dass in der gesellschaftlichen Wahrnehmung das Smartphone mittlerweile ein essentieller Teil unserer menschlichen Präsenz geworden ist. Das Smartphone wird als individueller Gegenstand untrennbar mit unserer Persönlichkeit verknüpft.

Über die Entität des Menschen:

Der Mensch ist, wenn es unter anderem nach dem französischen Philosophen Bernard Stiegler (1952-2020) geht, ein blindes, unvollständiges - ein frühzeitig geborenes Wesen – in der griechischen Mythologie nach Platon dadurch dargestellt, dass Epimetheus bei der Erschaffung der Lebewesen keine Gaben, keine Eigenschaften mehr für den Menschen übrig hatte. Erst durch den Diebstahl des Feuers und der Weisheit durch Prometheus, wurde der Mensch zu einer Entität, einem sehenden Wesen.

»Um einer zu werden, musste er negieren, was er war, indem er seinem Körper eine Prothese hinzufügte.« — Roberto Calasso (geb. 1941).

In der Frage nach der menschlichen Identität spielen demnach Bewusstsein und Zeitobjekte eine unbestreitbare Rolle. Vom Faustkeil über die Schrift zur Fotografie, bis zum Telefon und Internet: Prothesen, die das generationenübergreifende, kollektive Gedächtnis und damit die menschliche Geschichte darstellen — Werkzeuge, Gegenstände, Dinge.

Während Platon bereits die Schrift als problematische Gedankenprothese kritisierte, hat das Verhältnis von Mensch und Prothese (und die Kritik daran) mit den fortlaufenden Jahrhunderten der Kulturgeschichte nur an Komplexität gewonnen. Heute sind unsere Werkzeuge, Gegenstände, Maschinen, Konsumgüter längst nicht mehr nur Gedankenstützen, Verlängerungen und Verbesserungen menschlicher Organe und Gliedmaßen, sondern alles zusammen und noch viel mehr — Teile komplexer gesellschaftlicher Systeme. Unsere Prothesen haben sich zu (für den Einzelnen) immer unüberschaubaren Konstrukten mit Eigendynamik entwickelt, welche dennoch untrennbar und unverzichtbar mit unserem Leben verknüpft sind.

Besonders sichtbar geworden, ist diese komplexe, wechselseitig-elastische Beziehung zwischen Mensch und Prothese noch einmal in den letzten zwei Jahrzehnten. Smartphones, unsere immer greifbaren Universalprothesen zwischen Analogem und Digitalem, haben unser alltägliches Leben, unsere Gesellschaft maßgebend verändert. Immer mehr sind die Prothesen also auch Teil von uns geworden.

In unserer Arbeit wollen wir diese Entität der Präsenz aus Mensch und Prothese betrachten und betrachten lassen, doch nicht aus anthropologischer Sicht, sondern möglichst neutral, aus der Sicht unserer Prothesen auf uns. Ein Becken voller Farbe wird Behälter unserer Identität/Präsenz, bestehend aus Wellen, welche eine andere als die sichtbare Ebene der Wirklichkeit darstellen.

----

==Installation==
[[File:PMP_Input_Output.jpg|351px]] [[File:PMP_Render_frosch.png|351px]]

[[File:PMP_Render_top.png|351px]] [[File:PMP_Render_top_farbe.png|351px]]

Eine ein mal ein Meter große Metallwanne steht in der Mitte des Raumes. Auf Augenhöhe, durch ein Kabel verbunden mit der Wanne, schwebt ein Smartphone. Die Wanne ist gefüllt mit schwarzer, etwas dickflüssiger Farbe. Im Ausgangszustand ist die Oberfläche der Farbe glatt und ruhig. Betreten Menschen den Raum, reagiert die Installation.

Die Betrachter sind für das installierte Smartphone durch alle möglichen sensorisch messbaren Wellen wahrnehmbar: Licht/Schatten, Geräusche, Luftbewegung, Wärme etc. Auch die technischen Geräte der Betrachter, ihre Smartphones senden ununterbrochen Signale wie Bluetooth, UMTS oder WLAN aus.

Alle diese Signale und Wellen werden durch die Sensoren des Smartphones der Installation gemessen, in einer eigens programmierten App erfasst, auf unterschiedliche Audiofrequenzen und Steuersignale gemappt und an einen Raspberry Pi weitergegeben. Von dort laufen die Audiosignale durch einen Verstärker und speisen 8 Subwoofer-Konstruktionen unter der Wanne. Die Steuersignale regulieren zudem 4 Turbinen in der Farbe.

Die auf die Installation eintreffenden Signale sorgen für eine Reaktion in der Wanne. Die Subwoofer-Konstruktionen erzeugen über eine Membran Interferenzen und Wellenmuster, die Turbinen noch stärkere Wellen und Bewegungen. Bei wenigen Besuchern und wenig Input-Signalen gibt es feine Reaktionen — Interferenzmuster durchlaufen das Becken. Bei vielen Leuten und vielen Signalen wie etwa hoher Lautstärke oder Blitzlicht steigern sich die Reaktionen, die Turbinen drehen sich bis zu dem Punkt, dass die Farbe aus ihrem Becken in den Raum spritzt. Die Präsenz der Menschen manifestiert sich im Raum.

[[File:PMP_GR1.jpg|350px]] [[File:PMP_GR2.jpg|351px]]

[[File:PMP_GR4.jpg|350px]] [[File:PMP_GR5.jpg|351px]]

----

==Programmierung==

Für die Installation werden die Daten der ein- wie auch multidimensionalen Sensoren und Schnittstellen wie WLAN und Bluetooth gesammelt und über acht Audiokanäle sonifiziert. Zusätzlich werden bei starken Veränderungen drei Propeller gesteuert, um die Farboberfläche stärker zu beeinflussen.

Um Grundrauschen und Fehler der Sensoren zu minimieren, wird pro Datenkanal zunächst ein Mittelwert aus einigen vorherigen Werten gebildet. Dadurch wird gewährleistet, dass sowohl kurzfristige wie auch langfristige Veränderungen abgebildet werden.

Dabei sind den Audiokanälen keine jeweils festen Datenkanäle zugewiesen, sodass pro Lautsprecherkonstruktion nicht nur ein Datenkanal dargestellt wird, sondern die generelle Wahrnehmung des Raumes gemischt, über alle Konstruktionen abgebildet wird.

Neben einfachem Mapping der Daten auf geeignete Frequenzspektren, wird ein PID-Regler (proportional-integral-derivative controller) verwendet.
Dieser Kontrollmechanismus nutzt das Feedback der Sensoren, um durch Gegenbewegung zu versuchen, ein Gleichgewicht wieder herzustellen. Anders als bei der industriellen Verwendung dieses Reglers wird dieser hier benutzt, um eine Balance zwischen kurzfristigen und langfristigen Inputs zu gewährleisten.

Die über eine Sensor-Programmierschnittstelle zur Verfügung gestellten Daten werden kontinuierlich gesammelt und verarbeitet, wodurch eine adäquate Abbildung der für das Smartphone messbaren Präsenz erreicht wird.

Tabelle der Verfügbaren Sensoren:

[[File:PMP_Sensoren.png|351px]]

----

==Prototypen==
Auf dem Weg zur fertigen Installation wurden mehrere unterschiedliche Prototypen und Studien zur Erzeugung von Wellen angefertigt; auch wurde mit verschiedenen Materialien experimentiert.

[[File:PMP_Skizze_new.jpg|351px]]
[[File:PMP_Function_b.jpg|351px]]

Unter anderem wurde ein Prototyp mit einem Exciter (Körperschallwandler) an einer Holzplatte als schwimmender "Interferenz-Insel" angefertigt.

[[File:PMP_O2.JPG|351px]]
[[File:PMP_O4b.jpg|351px]]

Beim aktuellen Prototyp wird die Schallwellenübertragung mit Hilfe von Latex-Membranen realisiert, wie sie auch in der finalen Installation zur Anwendung kommen sollen.

[[File:PMP_P1.jpg|285px]]
[[File:PMP_P2.JPG|285px]]
[[File:PMP_P4.jpg|127px]]

----

==Umsetzung==

Aufgrund der Corona-Lage hat es sich bis jetzt als schwierig erwiesen, einen geeigneten Rahmen für die Präsentation unserer Installation zu finden, besonders da die Arbeit von der Interaktion mit den Betrachtern lebt. Unser Ziel ist es dennoch, möglichst bis zum Sommer einen geeigneten Ausstellungsort sowie Fördergelder bzw. finanzielle Zuschüsse zu akquirieren, damit wir die Installation final umsetzen können.

Besonders beachten müssen wir bei der fertigen Installation bzw. dem Ausstellungsort die vorhandene Lichtsituation, da Spiegelungen und Reflektionen einen großen Einfluss darauf haben, wie die Wellen in der schwarzen Farbe wahrgenommen werden. Außerdem sollte der Boden möglichst weiß oder zumindest mit weißem Papier bedeckt sein, damit sich die Farbe außerhalb des Beckens manifestieren kann; hierbei ist auf den Schutz des Ausstellungsortes vor Schädigungen durch die Farbe zu achten. Auch die Transportlogistik, Lieferzeiten sowie der benötigte Arbeitsaufwand von mindestens zwei bis drei Tagen zum Bau der Installation sollten bedacht werden.

Die Materialkosten haben wir in der folgenden Tabelle festgehalten:

'''Kostenaufstellung''': [https://docs.google.com/spreadsheets/d/1448o1PZdCmi9e1ZzCmdhUpYzGk5ClCqz45YITzwZX_w/edit?usp=sharing|Tabelle Preiskalkulation]

GMU:Media Art Strategies/Leon-Etienne Kühr

2022-09-14T10:41:26Z

Lalalolo: /* /Project/ */

== Project ==
together with [https://www.uni-weimar.de/kunst-und-gestaltung/wiki/GMU:Media_Art_Strategies/Clemens_Hornemann Clemens Hornemann]

== Tasks ==
=== Task 1 ===
It is hard for me to pick one favourite artwork as they all pursue very different strategies.
Julian Oliver’s ''Men in Grey'' captures the ''Zeitgeist'' of the uncontrollable rise of WiFi within our lives, while exposing us to our technological life, defined by groups and organizations that are beyond our own reach, without fear mongering or shaming us for our digital life. While the ''Men in Grey'' exposed one concerning facet of our daily life, the ''Yes Men'' achieve to confront us with the grim reality of a capitalistic economy in various ways and their ability and relentlessness to repeat variations of their media activistic stunts just makes abundantly clear, that change takes time and the will and courage of a few individuals that are in power.

Besides the politically motivated works, I find great pleasure in simplistic works like David Bowen’s ''Tele-present water'', while simple in concept, it focuses on the relation between our perceived world and the world of a buoy station at an unknown location, highlighting that even when not perceived by us the ocean is, was and always will be moving relentlessly, whether we are there to perceive it or not.

Even though its technical implementation is marvelous, what intrigues me the most about Random international’s ''Rain Room'' is its ability to convey the viewer an alternate reality, where it is not the rain that is repelled by us, but we repel the rain and how this simple change might change our behaviour and perception of the space around us.

[[:File:media-art-strategies_telegarden_slide.pdf|Slide Telegarden (Ken Goldberg & Joseph Santarromana)]]

GMU:Colloquium

2022-01-10T06:04:44Z

Lalalolo:

Here are the thesis projects from Bachelor, Master, and PhD students in winter semester 21/22

*[[/Jenny Brockmann/]]
*[[/Isabella Lee Aturo/]]
*[[/Ksenia Tajsic/]]
*[[/Joel Schäfer/]]
*[[/Yasemin Yagci/]]
*[[Rico Graupner/]]
*[[/Jörg Brinkmann/]]
*[[/Daniel Wolter/]]
*[[/Gabriel Moses/]]
*[[/Christina Schinzel/]]
*[[/Sandra Anhalt/]]
*[[/Vaclav Harsa/]]
*[[/Mindaugas Gapsevicius/]]
*[[/Sarah Alvim/]]
*[[/Benazir Basauri/]]
*[[/Lennart Oberlies/]]
*[[/Beatrice Perlato/]]
*[[/Quan Zhou/]]
*[[/Leon-Etienne Kühr/]]
== Attendance Timetable ==

{| class="wikitable"
|-
| '''Week'''
| '''Date'''
| '''Presenter'''
|-
| 1
| 25. October 21
| N.N.
|-
| 2
|2. Novmber 21
| Beatrice Perlato
|-
| 3
| 08. Novmber 21
| Yasemin Yagci
|-
| 4
| 15. Novmber 21
| Christina Schinzel
|-
| 5
|22. November 21
| Isabella Lee Arturo
|-
|7
|29. November 21
| Ksenija T.
|-
|8
|6. December 21
| Yasemin Yagci, Sarah Alvim
|-
| 9
|13. December
| Joel
|-
|10
| 20. Dec
| Holiday
|-
|11
| 3. January 2022
| N.N.
|-
| 12
|10. January
| N.N.
|-
| 13
|17.January 2022
| Sarah Alvim
|-
|14
| 24. January 2022
| Quan Zhou
|-
|15
| 31. January 2022
| Joel (short), Ksenija (short)
|-
|16
| 07. February 2022
| Leon
|}

[[Category:WS21]]

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:44:29Z

Lalalolo: /* GOL-Midi Semesterprojekt */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

-----

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

-----

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

-----

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

-----

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

-----

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

-----

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

-----

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

-----

==Usage==
To use the build just plug it in using a micro-USB cable and enable it in the DAW as a Midi-Device (named Arduino Micro).
Since the build only has two buttons (left and right) for many functionalities, alls buttons have multiple uses and combinations:
* '''Click Left''' (Down, Up under 200ms): '''Next Chord'''
* '''Hold Right & Click Left''' (Hold first): '''Previous Chord'''

* '''Click Right''' (Down, Up under 200ms): '''Next Cellular Automata Rule''' (0-255 wraps around)
* '''Hold Left & Click Right''' (Hold first): '''Previous Cellular Automata Rule''' (0-255 wraps around)

* '''Hold Left''' (Longer than 500ms): '''Increase BPM'''
* '''Hold Right''' (Longer than 500ms): '''Decrease BPM'''

* '''Hold Left & Hold Right''' (Longer than 500ms): '''Start/Stop playing'''
* '''Hold Left & Hold Right''' (Longer than 2000ms): Reset everything'''

-----

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

-----

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:43:02Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Usage==
To use the build just plug it in using a micro-USB cable and enable it in the DAW as a Midi-Device (named Arduino Micro).
Since the build only has two buttons (left and right) for many functionalities, alls buttons have multiple uses and combinations:
* '''Click Left''' (Down, Up under 200ms): '''Next Chord'''
* '''Hold Right & Click Left''' (Hold first): '''Previous Chord'''

* '''Click Right''' (Down, Up under 200ms): '''Next Cellular Automata Rule''' (0-255 wraps around)
* '''Hold Left & Click Right''' (Hold first): '''Previous Cellular Automata Rule''' (0-255 wraps around)

* '''Hold Left''' (Longer than 500ms): '''Increase BPM'''
* '''Hold Right''' (Longer than 500ms): '''Decrease BPM'''

* '''Hold Left & Hold Right''' (Longer than 500ms): '''Start/Stop playing'''
* '''Hold Left & Hold Right''' (Longer than 2000ms): Reset everything'''

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:42:39Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
To use the build just plug it in using a micro-USB cable and enable it in the DAW as a Midi-Device (named Arduino Micro).
Since the build only has two buttons (left and right) for many functionalities, alls buttons have multiple uses and combinations:
* '''Click Left''' (Down, Up under 200ms): '''Next Chord'''
* '''Hold Right & Click Left''' (Hold first): '''Previous Chord'''

* '''Click Right''' (Down, Up under 200ms): '''Next Cellular Automata Rule''' (0-255 wraps around)
* '''Hold Left & Click Right''' (Hold first): '''Previous Cellular Automata Rule''' (0-255 wraps around)

* '''Hold Left''' (Longer than 500ms): '''Increase BPM'''
* '''Hold Right''' (Longer than 500ms): '''Decrease BPM'''

* '''Hold Left & Hold Right''' (Longer than 500ms): '''Start/Stop playing'''
* '''Hold Left & Hold Right''' (Longer than 2000ms): Reset everything'''
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:40:38Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
Since the build only has two buttons (left and right) for many functionalities, alls buttons have multiple uses and combinations:
* Click Left (Down, Up under 200ms): Next Chord
* Hold Right & Click Left (Hold first): Previous Chord

* Click Right (Down, Up under 200ms): Next Cellular Automata Rule (0-255 wraps around)
* Hold Left & Click Right (Hold first): Previous Cellular Automata Rule (0-255 wraps around)

* Hold Left (Longer than 500ms): Increase BPM
* Hold Right (Longer than 500ms): Decrease BPM

* Hold Left & Hold Right (Longer than 500ms): Start/Stop playing
* Hold Left & Hold Right (Longer than 2000ms): Reset everything
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:40:18Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
Since the build only has two buttons (left and right) for many functionalities, alls buttons have multiple uses and combinations:
* Click Left (Down, Up under 200ms): Next Chord
* Hold Right & Click Left (Hold first): Previous Chord
* Click Right (Down, Up under 200ms): Next Cellular Automata Rule (0-255 wraps around)
* Hold Left & Click Right (Hold first): Previous Cellular Automata Rule (0-255 wraps around)
* Hold Left (Longer than 500ms): Increase BPM
* Hold Right (Longer than 500ms): Decrease BPM
* Hold Left & Hold Right (Longer than 500ms): Start/Stop playing
* Hold Left & Hold Right (Longer than 2000ms): Reset everything
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:39:44Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
Since the build only has two buttons for many functionalities, alls buttons have multiple uses and combinations:
* Click Left Button (Down, Up under 200ms): Next Chord
* Hold Right Button & Click Left Button (Hold first): Previous Chord
* Click Right Button (Down, Up under 200ms): Next Cellular Automata Rule (0-255 wraps around)
* Hold Left Button & Click Right Button (Hold first): Previous Cellular Automata Rule (0-255 wraps around)
* Hold Left Button (Longer than 500ms): Increase BPM
* Hold Right Button (Longer than 500ms): Decrease BPM
* Hold Left Button & Hold Right Button (Longer than 500ms): Start/Stop playing
* Hold Left Button & Hold Right Button (Longer than 2000ms): Reset everything
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:33:14Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:33:01Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|176px]][[File:PCB Arts -L.E.K Build 2.jpg|559px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:32:04Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|232px]][[File:PCB Arts -L.E.K Build 2.jpg|503px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:31:04Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|220px]][[File:PCB Arts -L.E.K Build 2.jpg|510px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:30:57Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|220px]][[File:PCB Arts -L.E.K Build 2.jpg|520px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:30:49Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|240px]][[File:PCB Arts -L.E.K Build 2.jpg|520px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:30:42Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|240px]][[File:PCB Arts -L.E.K Build 2.jpg|520px]]
Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:30:31Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|240px]][[File:PCB Arts -L.E.K Build 2.jpg|520px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:27:49Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|253px]][[File:PCB Arts -L.E.K Build 2.jpg|508px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

File:PCB Arts -L.E.K Build 2.jpg

2021-05-20T17:26:40Z

Lalalolo: File uploaded with MsUpload

File uploaded with MsUpload

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:23:57Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|200px]]

Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:23:42Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|200px]]
Due to an error I did on the left potentionmeter (missing connection). I was not able to follow my planned design and had to improvise.
To the same functionality as planned, I replaced the one potentiometer left with another button, giving me two buttons to work with.
I sadly had to use cables for the LED Matrix and parts of the buttons, due to my GND and 5V+ beeing all connected to each other.
The combination of lines and cables however works as intended.
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:19:40Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|200px]]

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:19:31Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:PCB Arts -L.E.K Build.jpg|400px]]

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

File:PCB Arts -L.E.K Build.jpg

2021-05-20T17:19:18Z

Lalalolo: File uploaded with MsUpload

File uploaded with MsUpload

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:18:56Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==

[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:11:45Z

Lalalolo: /* Demonstration */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|7doCJ39owTw|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:06:22Z

Lalalolo: /* Build */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]
(GIFs, click to play)

==Demonstration==
{{#ev:youtube|hLPOWT7qm5U|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

GMU:PCB Arts/L.-E. Kühr/GOL-Midi

2021-05-20T17:04:19Z

Lalalolo: /* GOL-Midi Semesterprojekt */

=GOL-Midi Semesterprojekt=
==Concept==
In this project I wanted to revisit my first-semester project about generating sound using cellular automata. Instead of synthesizing the sound directly from the state of the cellular automata, I wanted to take advantage of using the MIDI-capabilities of the ATmega32U4 microcontroller and design a custom PCB for an Arduino Micro shield which controlls the simulation. The state of the simulation is then send as MIDI over the USB-C port of the Arduino, which can then be used as a MIDI-controller. For the design of the PCB I wanted to take a procedural approach aswell while keeping it simple but taking advantage of all the layers available. The custom PCB controlls the speed and rules used in the one-dimensional automata. To visualize the automate an 8x8 LED matrix is used.

[[File:all_rules.png|800px]]

==Schematic==
To keep the controls simple, the only inputs used are two potentiometers and a button. for the LED matrix a preassebled 8x8 matrix with a MAX7219 controller are mounted through the back to make it shine through the PCB. Thus five holes have to be added for the five pins of the MAX7219 have to be added.
[[File:Schematic.PNG|800px]]

==PCB==
For the general PCB shape I wanted to use the retro-look of old hand-held game-consoles in combination with a texture that was generated by cellular automata.
After a rough layout in PCBnew, I went to Inkscape, traced an old GameBoy and began to make outlines for the edge-cuts and silkscreen layer. After importing the general shape, I layouted all the mounting holes and pins and began to wire everything on the backside of the PCB. I left a window in the mask-layer, where the LED matrix is going to be mounted to and surrounded every component with a symbolic outline in the silkscreen-layer.
[[File:pcb_new.PNG|800px]]

===Generation===
To fill the general outline with texture, a 1-dimensional cellular automata was used with random inputs and the infamous rule 30. I upscaled the resulting texture and imported it into Inkscape. The texture was then masked to exclude the immediate surroundings of the components. It was then once used for the silkscreen (just around the screen) and once for the front copper for the rest of the PCB.
[[File:rule30.png|600px]]

==Final Design==
[[File:3d-back.png|800px]]
[[File:3d-front.png|800px]]

==Programming==
===Simulation===
To efficiently simulate the 8-Bit automata the state of the cell and it's neighbours are interpreted as 3-Bit numbers that are then looked up in two arrays. One for the rules whether a cell is created and one for whether the cell should die. Rules for the automata can be changed using the shield.

===MIDI===
To send the state of the simulation using MIDI the library MIDIUSB (https://github.com/arduino-libraries/MIDIUSB) was used. The state of the simulation is mapped to chrods of a selected scale that are hardcoded in memory and can be send all at once or as an arpeggio. To map to the scales the state of the automata is interpreted as an 8-Bit number that is then mapped to the tone. The speed or time of the interval is controlled by the shield.

==Parts==
Besides the PCB the following parts are necessary:
* 2 Potentiometer
* Button 6mm
* MAX7219 8x8 LED Matrix-Modul
* Arduino Micro

==Build==
[[File:ezgif-6-ba2d047897d0.gif|360px]]
[[File:ezgif-6-46dbab99ab2a.gif|360px]]

==Demonstration==
{{#ev:youtube|hLPOWT7qm5U|735}}

==Further Reading:==
===Elementary Cellular Automaton===
* http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
* http://atlas.wolfram.com/01/01/rulelist.html
* https://plato.stanford.edu/entries/cellular-automata/supplement.html

File:Ezgif-6-46dbab99ab2a.gif

2021-05-20T17:03:45Z

Lalalolo: File uploaded with MsUpload

File uploaded with MsUpload

File:Ezgif-6-ba2d047897d0.gif

2021-05-20T17:03:44Z

Lalalolo: File uploaded with MsUpload

File uploaded with MsUpload

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T05:39:39Z

Lalalolo: /* Video */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==
Digital images can be treated as pseudo-random distributions of color. If these are interpreted as three-dimensional point-clouds, it is possible to overcome the planar image by adding depth and creating new ways to interpret the image by exploring the color distribution in its purest form. After using different color metrics to calculate the three-dimensional position of every point, complex structures and patterns emerge, colors shift, strains form and clusters of colors move from position to position.
----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).
{{#ev:youtube|cA7D-l4XI84|735}}

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.
{{#ev:youtube|ZSVnI2nV1V4|735}}

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T05:24:16Z

Lalalolo: /* Concept */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==
Digital images can be treated as pseudo-random distributions of color. If these are interpreted as three-dimensional point-clouds, it is possible to overcome the planar image by adding depth and creating new ways to interpret the image by exploring the color distribution in its purest form. After using different color metrics to calculate the three-dimensional position of every point, complex structures and patterns emerge, colors shift, strains form and clusters of colors move from position to position.
----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).
{{#ev:youtube|cA7D-l4XI84|735}}

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.
{{#ev:youtube|ztNLUFrtVVQ|360}}
{{#ev:youtube|4QoyVeXbwGY|360}}
{{#ev:youtube|kzz4ly4o89M|360}}
{{#ev:youtube|9kwDKTb-t1w|360}}

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T04:23:19Z

Lalalolo: /* Video */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).
{{#ev:youtube|cA7D-l4XI84|735}}

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.
{{#ev:youtube|ztNLUFrtVVQ|360}}
{{#ev:youtube|4QoyVeXbwGY|360}}
{{#ev:youtube|kzz4ly4o89M|360}}
{{#ev:youtube|9kwDKTb-t1w|360}}

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T04:12:42Z

Lalalolo:

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).
{{#ev:youtube|cA7D-l4XI84|735}}

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.
{{#ev:youtube|ztNLUFrtVVQ|735}}
{{#ev:youtube|4QoyVeXbwGY|735}}
{{#ev:youtube|kzz4ly4o89M|735}}

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T04:12:10Z

Lalalolo: /* Video */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.
{{#ev:youtube|ztNLUFrtVVQ|735}}
{{#ev:youtube|4QoyVeXbwGY|735}}
{{#ev:youtube|kzz4ly4o89M|735}}

==Media==
{{#ev:youtube|cA7D-l4XI84|735}}
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-13T04:11:09Z

Lalalolo: /* Approach */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

===Video===
The uniforms of the compute-shader can be updated during runtime. With the use of the Unity-Video-Player the input image can be the current frame of a video. If the video is updated every frame the particles get a new target position every frame creating a moving cloud of particles that create ever-emerging patterns of movment.

==Media==
{{#ev:youtube|cA7D-l4XI84|735}}
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T18:14:24Z

Lalalolo: /* Manipulation */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]

Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Media==
{{#ev:youtube|cA7D-l4XI84|735}}
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T18:13:26Z

Lalalolo:

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Media==
{{#ev:youtube|cA7D-l4XI84|735}}
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T18:01:06Z

Lalalolo: /* Manipulation */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|Hand Manipulation|735px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==
{{#ev:youtube|cA7D-l4XI84|735}}
----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T18:00:20Z

Lalalolo: /* Manipulation */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|none|1000px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==
{{#ev:youtube|cA7D-l4XI84|735}}
----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T17:59:57Z

Lalalolo: /* Manipulation */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|none|735px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==
{{#ev:youtube|cA7D-l4XI84|735}}
----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T17:59:18Z

Lalalolo: /* Outlook */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|none|500px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==
{{#ev:youtube|cA7D-l4XI84|735}}
----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T17:56:59Z

Lalalolo: /* Outlook */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|none|500px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==
<youtube>cA7D-l4XI84</youtube>
----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]

File:ImageCloud-Simple2.gif

2021-05-12T17:54:02Z

Lalalolo: Lalalolo uploaded a new version of File:ImageCloud-Simple2.gif

File uploaded with MsUpload

File:ImageCloud-Simple2.gif

2021-05-12T17:50:10Z

Lalalolo: Lalalolo uploaded a new version of File:ImageCloud-Simple2.gif

File uploaded with MsUpload

GMU:Critical VR Lab II - Lab Work/L.-E. Kuehr

2021-05-12T17:15:52Z

Lalalolo: /* Approach */

[[File:ImageCompute-header.png|700px]]
=color%20=
==Context==
In this project I wanted to revisit the idea of treating digital images as spatial pseudo-random distributions of color-entities (pixels in 2d, voxels in 3d).
As digital color is mostly stored as a triplett of color-channels (red, green and blue), it can easily be mapped into a three-dimensional space. We can further take advantage of the possible perception of true three-dimensionality using a VR-Headset. Having the image represented as a cloud of voxels in digital environment, we can then use the VR-controllers to manipulate the image in this three-dimensional domain using our hands by pushing and pulling parts of the image-cloud and remapping the cloud to the two-dimensional canvas. This technique might provide a more intuitive approach of manipulating images and their colors.
----

==Concept==

----

==Approach==
For every pixel in the image a colored voxel is spawned. The position of the voxel is than determined by different mapping functions that map the pixel (x, y, r, g, b) to position in space (x, y, z). In the default mapping every voxel is on a plane (z = 0) and the position in the plane is directly determined by the position in the original two-dimensional image.
[[File:ImageCloud-Default-Mapping.png|Default mapping|360px]]
[[File:ImageCloud-Simple2.gif|RGB Space|360px]]

Since the virtual space is three-dimensional space, the third dimension or depth (z-axis in this case) can be used to convey additional information thus revealing a new perspective on the image. The red channel could for example be mapped to the z-coordinate of every voxel. But we aren't limited to only using the z-axis. Since every digital image represents a subset of the rgb-space (cube), we can also map every pixel to a position in the rgb-space (represented as a cube).
<gallery>
File:ImageCloud-Approach1.png|Original Image
File:ImageCloud-Approach2.png|Red Color Channel Depth
File:ImageCloud-Approach3.png|RGB Color Space
File:ImageCloud-Approach4.png|HSV Color Space
</gallery>

===Mapping===
Since there are more three-dimensional color-representations of digital color such as HSV (or HSL) and YCbCr that have their own three-dimensional interpretations (HSV a cylinder, YCbCr a cube) and every singel channel can be mapped to the z-axis the following mappings were implemented:
{| class="wikitable"
|-
! Name
! X-Axis
! Y-Axis
! Z-Axis
|-
| Red Color Channel Depth
| Original
| Original
| Red
|-
| Green Color Channel Depth
| Original
| Original
| Green
|-
| Blue Color Channel Depth
| Original
| Original
| Blue
|-
| RGB Space
| Red
| Green
| Blue
|-
| Hue Channel Depth
| Original
| Original
| Hue
|-
| Saturation Channel Depth
| Original
| Original
| Saturation
|-
| Value Channel Depth
| Original
| Original
| Value
|-
| HSV Space (Cylinder)
| Hue
| Saturation
| Value
|-
| Y Channel Depth
| Original
| Original
| Y (luma component)
|-
| Cb Channel Depth
| Original
| Original
| Cb
|-
| Cr Channel Depth
| Original
| Original
| Cr
|-
| YCbCr Space
| Y (luma component)
| Cb
| Cr
|}

===Implementation===
Depending on the resolution of the original image the amount of voxels that have to be rendered and updated can easily exceed the millions. Since the resolution of VR-headsets is still limited aroud 2k it is sufficient to rescale the input-image to about 1024*1024 = 1048576 pixels. This is still too much to render and update every voxel as an independent object in real-time. A solution to this is using instancing on the GPU and just passing the color and position of the instances as a buffer. When using direct instanced drawing in Unity the calculation of the bounds of the object is very important to support native-features like view-frustum-culling.
To calculate the position- and color-buffer in realtime a compute-shader is used that can easily compute millions of independent calculations in parallel per frame. Compute-Shader inputs can be changed at runtime enabling transitions between diffrent resolutions, mappings and positions.

===Transitions===
Because the compute-shader can run every frame transitions between different states can be calculated. In this case a simple particle-based system was used where every particle (voxel) has a position, velocity and acceleration.

[[File:ImageCloud-Transition1.mp4|Mapping Transition|245px]]
[[File:ImageCloud-Transition2.mp4|Image Transition|245px]]
[[File:ImageCloud-Transition3.mp4|Resolution Transition|245px]]

Exmaples of transitions between mappings (left), images (middle) and resolutions (right).

===Manipulation===
Since VR-headsets were rare this semester I tried to use the [https://www.ultraleap.com/product/leap-motion-controller/ Leap-controller] to capture the movement of the hands and try to manipulate the image with it.
While I was able to set up and calibrate the controller in Unity, the captured motion was very inconsistent and jittery and the movement of the hand was limited. Since the camera had to be static the added value of the three-dimensionality was limited, using a VR-headset in combination with the Leap-controller might solve this problem.
[[File:ImageCloud-Manipulation1.mp4|none|500px]]
Another problem with manipulating the voxels is that the particle representations of the voxels are not part of the physics-world and cannot collide with the other objects. Every collision of every particle with every object has to be calculated in the compute-shader. While I was able to implement simple interaction with the center of one hand, I failed to implement a working collision for simple geometric forms in the compute-shader that was efficient enough to run every frame. This is possible, but GPU-collision is a difficult task that takes a lot more work than expected.
----

==Outlook==

----

==Media==
[[File:Creating a Graph 11.05.2021 08_56_28.png|360px]]
[[File:Creating a Graph 11.05.2021 08_57_26.png|360px]]
[[File:Creating a Graph 11.05.2021 08_58_03.png|360px]]
[[File:Creating a Graph 11.05.2021 08_59_21.png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_23 (1).png|360px]]
[[File:Creating a Graph 11.05.2021 09_00_44.png|360px]]
[[File:Creating a Graph 11.05.2021 09_01_11.png|360px]]
[[File:Creating a Graph 12.05.2021 14_03_36.png|360px]]