diff options
Diffstat (limited to 'root/articles')
| -rw-r--r-- | root/articles/init.moon | 27 | ||||
| -rw-r--r-- | root/articles/mmmfs/gallery.moon | 49 | ||||
| -rw-r--r-- | root/articles/mmmfs/init.moon | 285 | ||||
| -rw-r--r-- | root/articles/realities.moon | 552 |
4 files changed, 913 insertions, 0 deletions
diff --git a/root/articles/init.moon b/root/articles/init.moon new file mode 100644 index 0000000..b706f7c --- /dev/null +++ b/root/articles/init.moon @@ -0,0 +1,27 @@ +import div, h3, ul, li, a from require 'lib.dom' +import define_fileders from require 'lib.mmmfs' +Fileder = define_fileders ... +require = relative ... + +Fileder { + 'name: alpha': 'articles', + 'title: text/plain': 'articles and papers', + 'moon -> mmm/dom': (path) => div { + h3 @gett 'title: text/plain', style: { 'margin-bottom': '-.5em' }, + ul for child in *@children + name = child\gett 'name: alpha' + desc = child\gett 'description: text/plain' + li { + a name, { + href: child.path, + onclick: (e) => + e\preventDefault! + BROWSER\navigate child.path + }, + ': ', desc + } + } + + require '.mmmfs' + require '.realities' +} diff --git a/root/articles/mmmfs/gallery.moon b/root/articles/mmmfs/gallery.moon new file mode 100644 index 0000000..081865a --- /dev/null +++ b/root/articles/mmmfs/gallery.moon @@ -0,0 +1,49 @@ +import define_fileders from require 'lib.mmmfs' +import div, h1, a, img, br from require 'lib.dom' + +Fileder = define_fileders ... + +with Fileder { + 'name: alpha': 'gallery', + 'title: text/plain': "A Gallery of 25 random pictures, come in!", + 'preview: moon -> mmm/dom': => div { + 'the first pic as a little taste:', + br!, + img src: @children[1]\get 'preview', 'URL -> image/png' + } + 'moon -> mmm/dom': => + link = (child) -> a { + href: '#', + onclick: -> BROWSER\navigate { 'gallery', (child\get 'name', 'alpha'), nil }, + img src: child\gett 'preview', 'URL -> image/png' + } + + content = [link child for child in *@children] + table.insert content, 1, h1 'gallery index' + div content + + 'slideshow: moon -> mmm/dom': => + import ReactiveVar, text, elements from require 'lib.component' + + index = ReactiveVar 1 + + prev = (i) -> math.max 1, i - 1 + next = (i) -> math.min #@children, i + 1 + + e = elements + e.div { + e.div { + e.a 'prev', href: '#', onclick: -> index\transform prev + index\map (i) -> text " image ##{i} " + e.a 'next', href: '#', onclick: -> index\transform next + }, + index\map (i) -> img src: @children[i]\gett nil, 'URL -> image/png' + } + } + for i=1,25 + id = 120 + i + .children[i] = Fileder { + 'name: alpha': "image#{id}" + 'URL -> image/png': "https://picsum.photos/600/600/?image=#{id}" + 'preview: URL -> image/png': "https://picsum.photos/200/200/?image=#{id}" + } diff --git a/root/articles/mmmfs/init.moon b/root/articles/mmmfs/init.moon new file mode 100644 index 0000000..8193356 --- /dev/null +++ b/root/articles/mmmfs/init.moon @@ -0,0 +1,285 @@ +import define_fileders from require 'lib.mmmfs' +Fileder = define_fileders ... +require = relative ... + +Fileder { + 'name: alpha': 'mmmfs', + 'description: text/plain': 'a file and operating system to live in', + + -- main content + -- doesn't have a name prefix (e.g. preview: moon -> mmm/dom) + -- uses the 'moon ->' conversion to execute the lua/pre moon function on get + -- resolves to a value of type mmm/dom + 'moon -> mmm/dom': () => + html = require 'lib.dom' + import article, h1, h2, h3, p, div, a, sup, ol, li, span, code, pre, br from html + + moon = if MODE == 'SERVER' + (str) -> code (str\match '^ *(..-) *$'), class: 'hljs' + else + (str) -> + result = window.hljs\highlight 'moonscript', (str\match '^ *(..-) *$'), true + with code class: 'hljs' + .innerHTML = result.value + + article with _this = {} + append = (a) -> table.insert _this, a + + footnote, getnotes = do + local * + notes = {} + + id = (i) -> "footnote-#{i}" + + footnote = (stuff) -> + i = #notes + 1 + notes[i] = stuff + sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i + + footnote, -> + args = for i, note in ipairs notes + li (span (tostring i), id: id i), ': ', note + notes = {} + table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' } + ol table.unpack args + + append h1 'mmmfs', style: { 'margin-bottom': 0 } + -- @TODO: s/filesystem/a way of organizing files/g + append p "a file and operating system to live in", style: { 'margin-top': 0, 'margin-bottom': '1em' } + + -- @TODO: motivation / outline problem + need + -- @TODO: quote http://pchiusano.github.io/2013-05-22/future-of-software.html on Applications + + append p do + fileder = footnote "fileder: file + folder. 'node', 'table' etc. are too general to be used all over." + + -- @TODO: mention: + -- can store anything - text, an image, a link to a website or video, + -- a program and anything else you can think of. + "in mmmfs, directories, files and applications are all kind of the same thing, or something like that. + Listen, I don't really know yet either. The idea is that there is only one type of 'thing' - + a fileder", fileder, ". A fileder can store multiple variants and metadata of its content, + such as a markdown text and a rendered HTML version of the same document. + It could also store a script that transforms the markdown version into HTML and is executed on demand, + automatically." + + append p "Fileders can also have other fileders as their children (just like directories do in a normal + filesystem). You can make a fileder view query these children and display them however you want. + A 'Pictures' fileder, for example, could contain a script within itself that renders all the picture files + you put into it as little previews and lets you click on them to view the full image." + + append p "This means the 'Pictures' fileder can also have an alternate slideshow mode, with fullscreen view and + everything (some of this is built, check out the gallery example below), or one that displays geotagged images + on a world map, if you really want that. Maybe you could build a music folder that contains links to youtube + videos, spotify tracks and just plain mp3 files, and the folder knows how to play them all.", br!, " + In this way fileders fulfil the purpose of 'Applications' too." + + -- @TODO: BUT doesn't have to be only for one type of file: + -- @TODO: rework + -- making a multi-media collage representing your thoughts and mental organization of a topic + append p "A fileder is also responsible for how it's children are sorted, filtered and interacted with. + For example you should be able to create a fileder that is essentially a 'word document' equivalent: it can + contain images, websites, links and of course text as children and let you reorder, layout and edit them + whenever you open the fileder." + + append p "Sounds cool, no? Here's some examples of things a fileder can be or embed:" + + -- render a preview block + preview = (child) -> + -- get 'title' as 'text/plain' (error if no value or conversion possible) + title = child\gett 'title', 'text/plain' + + -- get 'preview' as a DOM description (nil if no value or conversion possible) + content = child\get 'preview', 'mmm/dom' + + div { + h3 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path + content or span '(no renderable content)', style: { color: 'red' }, + style: { + display: 'inline-block', + width: '300px', + height: '200px', + padding: '4px', + margin: '8px', + border: '4px solid #eeeeee', + overflow: 'hidden', + }, + } + + + append div for child in *@children + preview child + + append h2 "details" + -- @TODO s/parts: dimensions, aspects? + -- @TODO: first mention both properties & children; then go into detail + -- @TODO: main content + append do + name = html.i 'name' + type = html.i 'type' + + p "Fileders are made up of two main parts. The first is the list of ", (html.i 'properties'), ", + which are values identified by a ", name, " and ", type, ". These values are queried using strings like ", + (code 'title: text/plain'), " or ", (code 'mmm/dom'), ", which describe both the ", name, + " of a property (", (moon '"title"'), " and ", (moon '""'), ", the unnamed/main property) and the ", type, + " of a property. Property types can be something resembling a MIME-type or a more complex structure + (see ", (html.i "type chains"), " below). A fileder can have multiple properties of different types + set that share a ", name, ". In this case the overlapping properties are considered equivalent and the one + with the most appropriate ", type, " is selected, depending on the query. + The unnamed property is considered a fileder's 'main content', i.e. what you are interested in when viewing it." + + append p "The second part of a fileder is the list of it's children, which are fileders itself. + The children are stored in an ordered list and currently identified by their ", (code 'name: alpha'), + " property for UI and navigation purposes only (not sure if this is a good idea tbh)." + +-- append do +-- github = footnote a 's-ol/mmm', href: 'https://github.com/s-ol/mmm/tree/master/app/mmmfs' +-- "Oh and also everything is on github and stuff", github, +-- " if you care about that." + + append do + mmmdom = code ('mmm/dom'), footnote span (code 'mmm/dom'), " is a polymorphic content type; + on the server it is just an HTML string (like ", (code 'text/html'), "), + but on the client it is a JS DOM Element instance." + + p "What you are viewing right now is the main property of the root fileder. + The property is queried as ", mmmdom, ", a website fragment (DOM node). This website fragment + is then added to the page in the main content area, where you are most likely reading it right now." + + p "Anyway, this node is set up as a very generic sort of index thing and just lists its children-fileders' + alongside this text part you are reading.", br!, "For each child it displays the ", (code 'title: text/plain'), + " and shows the ", (code 'preview: mmm/dom'), " property (if set)." + + append h3 "converts" + append p "So far I have always listed properties as they are being queried, but a main feature of mmmfs is + type conversion. This means that you generally ask for content in whichever format suits your application, + and rely on the type resolution mechanism to make that happen." + + append pre moon [[ +-- render a preview block +preview = (title, content) -> div { + h3 title, style: { ... }, + content or span '(no renderable content)', style: { ... }, + style: { ... } +} + +append div for child in *@children + -- get 'title' as 'text/plain' (error if no value or conversion possible) + title = child\gett 'title', 'text/plain' + + -- get 'preview' as a DOM description (nil if no value or conversion possible) + content = child\get 'preview', 'mmm/dom' + + preview title, content + ]] + + append p "Here the code that renders these previews. You can see it ", (html.i "asks"), " for the + properties ", (code 'title: text/plain'), ' and ', (code 'preview: mmm/dom'), "), but the values don't actually have to + be ", (html.i "defined"), " as these types. + For example, the markdown child below only provides ", (code 'preview'), " as ", (code 'text/markdown'), ":" + + append pre moon [[ +Fileder { + 'title: text/plain': "I'm not even five lines of markdown but i render myself!", + 'preview: text/markdown': "See I have like + +- a list of things +- (two things) + +and some bold **text** and `code tags` with me.", +} + ]] + + append p "Then, globally, there are some conversion paths specified; such as one that maps from ", + (code 'text/markdown'), " to ", (code 'mmm/dom'), ":" + + append pre moon [[ +{ + inp: 'text/markdown', + out: 'mmm/dom', + transform: (md) -> + -- polymorphic client/serverside implementation here, + -- uses lua-discount on the server, marked.js on the client +} + ]] + + append h3 "type chains" + append p "In addition, a property type can be encoded using multiple types in a ", (code 'type chain'), ". + For example the root node you are viewing currently is actually defined as ", (code 'moon -> mmm/dom'), ", + meaning it's value is a pre moon function returing a regular ", (code 'mmm/dom'), " value." + + append p "Both value chains and 'sideways' converts are resolved using the same mechanism, + so this page is being rendered just using ", (moon "append root\\get 'mmm/dom'"), " as well. + The convert that resolves the moon type is defined as follows:" + + append pre moon [[ +{ + inp: 'moon -> (.+)', + out: '%1', + transform: (val, fileder) -> val fileder +} + ]] + + append p "The example with the image is curious as well. In mmmfs, you might want to save a link to an image, + without ever saving the actual image on your hard drive (or wherever the data may ever be stored - it is + quite transient currently). The image Fileder below has it's main (unnamed) value tagged as ", + (code 'URL -> image/png'), " - a png image, encoded as an URL. When accessed as ", (code 'image/png'), " + the URL should be resolved, and the binary data provided in it's place (yeah right - I haven't build that yet)." + + append p "However, if a script is aware of URLs and knows a better way to handle them, then it can ask for and + use the URL directly instead. + This is what the image demo does in order to pass the URL to an ", (code 'img'), " tag's ", (code 'src'), " attribute:" + + append pre moon [[ +Fileder { + 'title: text/plain': "Hey I'm like a link to picture or smth", + 'URL -> image/png': 'https://picsum.photos/200?random', + 'preview: moon -> mmm/dom': => + import img from require 'lib.dom' + img src: @gett 'URL -> image/png' -- look for main content with 'URL to png' type +} + ]] + + append getnotes! + + 'text/markdown': "this is a markdown version or something. + +There's no content here so switch back to the real one! +(Assuming there is a switching UI by the time you are reading this, which I assume since you are reading this at all. +If you are reading this in the source, then c'mon, just scroll past and give me a break.) + +(the switching UI has now been built.)" + + Fileder { + 'name: alpha': 'empty', + 'title: text/plain': "Hey I'm an ad-hoc child with no content at all", + } + + Fileder { + 'name: alpha': 'image', + 'title: text/plain': "Hey I'm like a link to picture or smth", + + -- main content is image/png, to be interpreted by URL to access + 'URL -> image/png': 'https://picsum.photos/200?random', + + -- preview is a lua/pre moon function that neturns an mmm/dom value + 'preview: moon -> mmm/dom': => + import img from require 'lib.dom' + img src: @gett 'URL -> image/png' -- look for main content with 'URL to png' type + } + + Fileder { + 'name: alpha': 'markdown', + 'title: text/plain': "I'm not even five lines of markdown but i render myself!", + + -- preview can be rendered using global convert + 'preview: text/markdown': "See I have like + +- a list of things +- (two things) + +and some bold **text** and `code tags` with me.", + } + + require '.gallery', +} diff --git a/root/articles/realities.moon b/root/articles/realities.moon new file mode 100644 index 0000000..f913842 --- /dev/null +++ b/root/articles/realities.moon @@ -0,0 +1,552 @@ +import define_fileders from require 'lib.mmmfs' +Fileder = define_fileders ... + +Fileder { + 'name: alpha': 'realities' + 'description: text/plain': 'exploring the nesting relationships of virtual and other realities' + 'moon -> mmm/component': => + import elements from require 'lib.component' + import h1, h2, p, a, i, div, ol, li, br, hr, span, button, section, article from elements + + _content = div! + append = _content\append + + if MODE == 'SERVER' + -- import compile from require 'lib.duct_tape' + + -- append '<script src="https://cdnjs.cloudflare.com/ajax/libs/svg.js/2.6.6/svg.min.js"></script>' + + export ^ + class Diagram + style = { + display: 'inline-block', + width: '150px', + height: '80px', + 'line-height': '80px', + color: '#fff', + background: '#666', + } + + @id = 1 + new: (@func) => + @id = "diagram-#{@@id}" + @@id += 1 + + render: => + rplc = with div id: @id, :style + \append '(diagram goes here)' + -- \append "<script type=\"application/lua\"> + -- local rplc = js.global.document:getElementById('#{@id}'); + -- local fn = #{compile @func} + -- diag = Diagram(fn) + -- rplc.parentNode:replaceChild(diag.node, rplc) + -- </script>" + rplc\render! + + if MODE == 'CLIENT' + export ^ + export o + eval = js.global\eval + GRID_W = 50 + GRID_H = 40 + + SVG = + doc: eval "(function() { return SVG(document.createElement('svg')); })", + G: eval "(function() { return new SVG.G(); })", + setmetatable SVG, __call: => @doc! + + o = do + mkobj = eval "(function () { return {}; })" + (tbl) -> + with obj = mkobj! + for k,v in pairs(tbl) + obj[k] = v + + class Diagram + new: (f) => + @svg = SVG! + @arrows = SVG.G! + @width, @height = 0, 0 + @y = 0 + + f @ + + txtattr = o { + fill: 'white', + 'font-size': '14px', + 'text-anchor': 'middle', + } + block: (color, label, h=1) => + @svg\add with SVG.G! + with \rect GRID_W, h * GRID_H + \attr o fill: color + if label + with \plain label + \move GRID_W/2, 0 + \attr txtattr + + \move @width * GRID_W, (@y + h) * -GRID_H + @y += h + if @y > @height + @height = @y + + arrattr = o { + fill: 'white', + 'font-size': '18px', + 'text-anchor': 'middle', + } + arrow: (char, x, y) => + with @arrows\plain char + \attr arrattr + \move (x + 1) * GRID_W, (y - 0.5) * -GRID_H - 11 + + -- inout: (x=@width, y=@y) => @arrow '⇋', x, y -- U+21CB + -- inn: (x=@width, y=@y) => @arrow '↼', x, y+0.25 -- U+21BC + -- out: (x=@width, y=@y) => @arrow '⇁', x, y-0.25 -- U+21C1 + inout: (x=@width, y=@y) => @arrow '⇆', x, y -- U+21C6 + inn: (x=@width, y=@y) => @arrow '←', x, y+0.25 -- U+2190 + out: (x=@width, y=@y) => @arrow '→', x, y-0.25 -- U+2192 + + mind: (label='mind', ...) => @block '#fac710', label, ... + phys: (label='phys', ...) => @block '#8fd13f', label, ... + digi: (label='digi', ...) => @block '#9510ac', label, ... + + next: => + @y = 0 + @width += 1 + + finish: => + return if @node + @svg\add @arrows + + @width += 1 + w, h = @width * GRID_W, @height * GRID_H + + l = GRID_W / 6.5 + @svg\add with @svg\line 0, -GRID_H, w, -GRID_H + \stroke o width: 2, color: '#ffffff', dasharray: "#{l}, #{l}" + + @svg\size w, h + @svg\viewbox 0, -h, w, h + @node = @svg.node + + addlabel = (label, diagram) -> + with div style: { display: 'inline-block', margin: '20px', 'text-align': 'center' } + \append diagram + \append div label + + figures = do + style = + display: 'flex' + 'align-items': 'flex-end' + 'justify-content': 'space-evenly' + (...) -> div { :style, ... } + + sources = do + short = => "#{@id} #{@year}" + long = => @names, " (#{@year}): ", (i @title), ", #{@published}" + { + { + id: 'Milgram', + title: 'Augmented Reality: A class of displays on the reality-virtuality continuum', + published: 'in SPIE Vol. 2351', + names: 'P. Milgram, H. Takemura, A. Utsumi, F. Kishino', + year: 1994 + :long, :short, + }, + { + id: 'Marsh', + title: 'Nested Immersion: Describing and Classifying Augmented Virtual Reality', + published: 'IEEE Virtual Reality Conference 2015', + names: 'W. Marsh, F. Mérienne', + year: 2015 + :long, :short, + }, + { + id: 'Billinghurst', + title: 'The MagicBook: a transitional AR interface', + published: 'in Computer & Graphics 25', + names: 'M. Billinghurst, H. Kato, I. Poupyrev', + year: 2001, + :long, :short, + }, + { + id: 'Matrix', + title: 'The Matrix', + year: 1999, + names: 'L. Wachowski, A. Wachowski', + long: => @names, " (#{@year}): ", (i @title), " (movie)" + short: => tostring @year + }, + { + id: 'Naam', + title: 'Nexus', + published: 'Angry Robot (novel)', + names: 'R. Naam', + year: 2012, + :long, :short, + } + } + + ref = do + fmt = (id) -> + + local src + for _src in *sources + if _src.id == id + src = _src + break + + if src + a { src\short!, href: "##{src.id}" } + else + span id + + ref = (...) -> + refs = { ... } + with span "(", fmt refs[1] + for i=2, #refs + \append ", " + \append fmt refs[i] + \append ")" + + references = -> + with ol! + for src in *sources + \append li { id: src.id, src\long! } + + sect = (label) -> + with section style: 'page-break-inside': 'avoid' + \append h2 label + + append with article style: { margin: 'auto', 'max-width': '750px' } + \append div 'Sol Bekic', style: 'text-align': 'right' + + \append h1 { + style: { 'text-align': 'center', 'font-size': '2em' }, + "Reality Stacks", + div "a Taxonomy for Multi-Reality Experiences", style: 'font-size': '0.6em' + } + + \append with sect "Abstract" + \append p "With the development of mixed-reality experiences and the corresponding interface devices + multiple frameworks for classification of these experiences have been proposed. However these past + attempts have mostly been developed alongside and with the intent of capturing specific projects ", + (ref 'Marsh', 'Billinghurst'), " or are nevertheless very focused on existing methods and technologies ", + (ref 'Milgram'), ". The existing taxonomies also all assume physical reality as a fixpoint and constant and are + thereby not suited to describe many fictional mixed-reality environments and altered states of consciousness. + In this paper we describe a new model for describing such experiences and examplify it's use with currently + existing as well as idealized technologies from popular culture." + + \append with sect "Terminology" + \append p "We propose the following terms and definitions that will be used extensively for the remainder of the paper:" + for definition in *{ + { "layer of reality": "a closed system consisting of a world model and a set of rules or dynamics operating on and + constraining said model." }, + { "world model": "describes a world state containing objects, agents and/or concepts on an arbitrary abstraction level." }, + '------', + { "reality stack": "structure consisting of all layers of reality encoding an agent's interaction with his environment + in their world model at a given moment, as well as all layers supporting these respectively." }, + '------', + { "physical reality": "layer of reality defined by physical matter and the physical laws acting upon it. + While the emergent phenomena of micro- and macro physics as well as layers of social existence etc. may be seen + as separate layers, for the purpose of this paper we will group these together under the term of physical reality." }, + { "mental reality": "layer of reality perceived and processed by the brain of a human agent." }, + { "digital reality": "layer of reality created and simulated by a digital system, e.g. a virtual reality game." }, + { "phys, mind, digi": "abbreviations for physical, mental and digital reality respectively." }, + } + if 'string' == type definition + \append hr! + continue + \append with div style: { 'margin-left': '2rem' } + term = next definition + \append span term, style: { + display: 'inline-block', + 'margin-left': '-2rem', + 'font-weight': 'bold', + 'min-width': '140px' + } + \append span definition[term] + + \append with sect "Introduction" + \append p "We identify two different types of relationships between layers in multi-reality environments. + The first is layer nesting. Layer nesting describes how some layers are contained in other layers; i.e. they exist + within and can be represented fully by the parent layer's world model and the child layer's rules emerge natively from + the parent layer's dynamics. Layer nesting is visualized on the vertical axis in the following diagrams. + For each layer of reality on the bottom of the diagram the nested parent layers can be found by tracing a line upwards + to the top of the diagram. Following a materialistic point of view, physical reality therefore must completely encompass + the top of each diagram." + + \append p "The second type of relationship describes the information flow between a subject and the layers of reality + the subject is immersed in. In a multi-reality experience the subject has access to multiple layers of reality and + their corresponding world models simultaneously.", br!, + "Depending on the specific experience, different types of and directions for information exchange + can exist between these layers and the subject's internal representation of the experience. + For the sake of this paper we distinguish only between ", (i "input"), " and ", (i "output"), " data flow (from the + perspective of the subject); categorized loosely as information the subject receives from the environment + (", (i "input"), ", e.g. visual stimuli) and actions the subject can take to influence the state of the world model + (", (i "output"), ", e.g. motor actions) respectively." + + \append p "In the following diagrams, information flow is visualized horizontally, in the region below the dashed line + at the bottom of the diagram. The subject's internal mental model and layer of reality are placed on the bottom left + side of the diagram. + The layers of reality that the subject experiences directly and that mirror it's internal representations are placed + on the far right. There may be multiple layers of reality sharing this space, visualized as a vertical stack of + layers. Since the subject must necessarily have a complete internal model of the multi-reality experience around + him to feel immersed, the subject's mental layer of reality must span the full height of all the layers visible + on the right side of the diagram.", br!, + "Information flow itself is now visualized concretely using arrows that cross layer boundaries in the lower part of + the diagram as described above. Arrows pointing leftwards denote ", (i "input"), " flow, whilst arrows pointing + rightwards denote ", (i "output"), "-directed information flow. In some cases information doesn't flow directly + between the layers the subject is directly aware of and the subject's internal representation and instead + traverses ", (i "intermediate layers"), " first." + + \append p "Before we take a look at some reality stacks corresponding to current VR and AR technology, + we can take a look at waking life as a baseline stack. To illustrate the format of the diagram we will compare it + to the stack corresponding to a dreaming state:" + + \append with figures! + \append addlabel "Waking Life", Diagram => + @mind! + @inout! + @phys! + + @next! + @phys '', 2 + @finish! + + \append addlabel "Dreaming", Diagram => + @mind! + @phys! + @finish! + + \append p "In both cases, the top of the diagram is fully occupied by the physical layer of reality, colored in green. + This is due to the fact that, according to the materialistic theory of mind, human consciousness owes its existance + to the physical and chemical dynamics of neurons in our brains. Therefore our mental reality must be considered + fully embedded in the physical reality, and consequently it may only appear underneath it in the diagram." + + \append p "During waking life, we concern ourselves mostly with the physical reality surrounding us. + For this reason the physical reality is placed in the lower right corner of the diagram as the layer holding the + external world model relevant to the subject. Information flows in both directions between the physical world model + and the subject's mental model, as denoted by the two white arrows: Information about the state of the world model + enter the subjects mind via the senses (top arrow, pointing leftwards), and choices the subject makes inside of and + based on his mental model can feed back into the physical layer through movements (lower arrow, pointing rightwards)." + + \append p "In the dreaming state on the other hand, the subject is unaware of the physical layer of reality, though + the mind remains embedded inside it. When dreaming, subjects' mental models don't depend on external models, hence + the mental layer of reality must be the only layer along the bottom of the diagram." + + \append with sect "Current Technologies" + \append p "Since recent technological advancements have enabled the development of VR and AR consumer devices, + AR and VR have been established as the potential next frontier of digital entertainment.", br!, + "As the names imply, the notion of reality is at the core of both technologies. + In the following section we will take a look at the respective stacks of both experience types:" + + \append with figures! + \append addlabel "VR", Diagram => + @mind! + @phys! + @inout nil, 1 + + @next! + @phys '', 2 + @inout nil, 1 + + @next! + @digi! + @phys '' + @finish! + + + \append addlabel "AR", Diagram => + @mind! + @inout nil, 1.25 + @inn nil, 0.5 + @phys! + + @next! + @phys '', 2 + @inn nil, .5 + + @next! + @digi nil, .5 + @phys '', 1.5 + @finish! + + \append p "In both cases we find the physical layer of reality as an ", (i "intermediate layer"), " between the mental + and digital layers. Actions taken by the subject have to be acted out physically (corresponding to the + information traversing the barrier between mental and physical reality) before they can be again digitized using + the various tracking and input technologies (which in turn carry the information across the boundary of the physical + and digital spaces)." + + \append p "The difference between AR and VR lies in the fact that in AR the subject experiences a mixture of the + digital and physical world models. This can be seen in the diagram, where we find that right of the diagram origin + and the mental model, the diagram splits and terminates in both layers: while information reaches the subject both + from the digital reality through the physical one, as well as directly from the physical reality, the subject only + directly manipulates state in the physical reality." + + \append p "The data conversions necessary at layer boundaries incur at the least losses in quality and accuracy of + information for purely technical reasons. However ", (i "intermediate layers"), " come at a cost larger than just + an additional step of conversion: + For information to flow through a layer, it must be encodable within that layer’s world model. + This means that the 'weakest link' in a given reality stack determines the upper bound of information possible to + encode within said stack and thereby limits the overall expressivity of the stack.", br!, + "As a practical example we can consider creating an hypothetical VR application that allows users to traverse a + large virtual space by flying. While the human mind is perfectly capable of imagining to fly and control the motion + appropriately, it is extremely hard to devise and implement a satisfying setup and control scheme because the + physical body of the user needs to be taken into account and it, unlike the corresponding representations in the + mental and digital world models, cannot float around freely." + + \append with sect "Future Developments" + \append p "In the previous section we found that the presence of the physical layer in the information path of + VR and AR stacks limits the experience as a whole. It follows that the removal of that indirection should be + an obvious goal for future developments:" + + \append figures addlabel "holy grail of VR: 'The Matrix'", Diagram => + @mind! + @inout! + @phys! + + @next! + @digi! + @phys '' + @finish! + + \append p "In the action movie 'The Matrix' ", (ref 'Matrix'), ", users of the titular VR environment interface with it + by plugging cables into implanted sockets that connect the simulation directly to their central nervous system.", br!, + "While these cables and implanted devices are physical devices, they don't constitute the presence of the + physical layer of reality in the information path because while they do transmit information, the information + remains in either the encoding of the mental model (neural firing patterns) or the encoding of the digital model + (e.g. a numeric encoding of a player character's movement in digital space) and the conversion is made directly + between those two - the data never assumes the native encoding of the physical layer (e.g. as a physical motion)." + + \append p "While we are currently far from being able to read arbitrary high-level information from the brain + or to synthesize sensual input in human perception by bypassing the sensory organs, brain-computer interfaces (BCI) + are a very active area of research with high hopes for comparable achievements in the near future." + + \append p "Applying this same step of removing the physical layer of reality from AR, we end up with something similar + to the nano-particle drug in ", (i "Nexus"), " ", (ref 'Naam'), ". However this does not grant the user a similar + amount of control over his experience as the holy grail of VR does, since the user and the physical part of the + environment remain bound by the physical layer of reality's laws.", br!, + "Instead the holy grail of AR is reached with the creation of a god machine that can manipulate the state of the + physical world according to the user's wishes. In this way the digital and physical realities become unified and + fully 'augmented'." + + \append with figures! + \append addlabel "'Nexus'", Diagram => + @mind! + @inout nil, 0.75 + @inout nil, 1.25 + @phys! + + @next! + @digi nil, .5 + @phys '', 1.5 + @finish! + + \append addlabel "holy grail of AR: 'Deus Machina'", Diagram => + col = '#92807c' + + @mind! + @inout! + @block col, '' + + @next! + @block col, '', 2 + @svg\plain('phys + digi')\attr(o fill: 'white', 'font-size': '14px')\move 6, -2 * GRID_H + @finish! + + \append p "Despite the similarities of VR and AR, the two can be considered polar opposites, as becomes evident when + we compare their respective utopian implementations: they share the goal of allowing us to experience realities + different from the one we naturally inhabit, but while VR seeks to accomplish this by creating a new, nested reality + inside ours, thus giving us full control over it. + AR, on the other hand, is instead an attempt to retrofit our specific needs directly into the very reality we exist + in.", br!, + "This is in direct contrast with the popular notion of the 'reality-virtuality continuum' ", (ref 'Milgram'), ": + the reality-virtuality continuum places common reality and VR (virtuality) as the two extreme poles, while AR + is represented as an intermediate state between the two. Here however we propose to view instead AR and VR as the + respective poles and find instead reality at the centerpoint, where the two opposing influences 'cancel out'." + + \append with sect "Conclusion and Further Work" + \append p "In this paper we have proposed a taxonomy and visualization style for multi-reality experiences, as well + as demonstrated it's flexibility by applying them as examples. Through the application of the proposed theory, + we have also gained a new and contrasting view on preceding work such as the reality-virtuality-continuum. + We have also found that the taxonomy can be used outside the research field of media studies and its use may extend + as far as philosophy of consciousness (see Appendix below)." + + \append p "Further research could enhance the proposed theory with better and more concrete definitions. + In the future, the proposed taxonomy might be used to create a more extensive and complete classification + of reality stacks and to analyse the relationships between them." + + \append with sect 'References' + \append references! + + \append with sect "Appendix: Relation to Theories of Mind" + \append p "This paper starts from a deeply materialistic point of view that borders on microphysicalism. + However it should be noted that the diagram style introduced above lends itself also to display other + philosophical theories of mind. As an example, the following graphics show a typical VR stack as interpreted by + Materialism, Cartesian Dualism and Solipsism respectively:" + + \append with figures! + \append addlabel "VR in Materialism", Diagram => + @mind! + @inout nil, 1 + @phys! + + @next! + @phys '', 2 + @inout nil, 1 + + @next! + @digi! + @phys '' + + @finish! + + \append addlabel "VR in Solipsism", Diagram => + @mind nil, 2 + @inout nil, 1 + + @next! + @digi! + @mind '' + @finish! + + \append addlabel "VR in Cartesian Dualism", Diagram => + @mind nil, 2 + @inout nil, 1 + @next! + + @phys nil, 2 + @inout nil, 1 + @next! + + @digi! + @phys '' + @finish! + + \append p "However these philosophical theories of minds also constitute reality stacks by themselves and as such can + be compared directly:" + + \append with figures! + \append addlabel "Materialism", Diagram => + @mind! + @inout! + @phys! + + @next! + @phys '', 2 + @finish! + + \append addlabel "Solipsism", Diagram => + @mind! + @finish! + + \append addlabel "Cartesian Dualism", Diagram => + @mind! + @inout! + @next! + + @phys! + @finish! +} |