# **halb**3
*Integrated Workflow for the Design of 2.5D Visualizations by Non-Experts in 2.5D.*

[Let's make it to the IEEE VIS '22](http://ieeevis.org/year/2021/blog/vis-22-in-oklahoma) and have minor or other major contributions prepared for [EuroVis '22](https://conferences.eg.org/eurovis2022/), [Web3D '22](https://web3d.siggraph.org/), [VMV '22](https://gcpr-vmv-2022.uni-konstanz.de/), '[VINCI '22](https://vinci-conf.org/), , VISIGRAPP etc.

The user is confronted with a visualization pipeline represented in 2.5D itself.
In order to create or design a visualization, the following phases have to be specified within the 2.5D environment:
* (1) Data **Import**,
* (2) Data **Filtering**,
* (3) **Mapping** to Color Scales and 2.5D-aware Glyphs, and
* (4) **Exploration** of the resulting, interactive Visuaization.
* (5) **Export** by means of *Visualization Config (json/yml)*, *Progressive-Rendering* (online, support for large scale), *glTF-File*, *blend-File*, *High-Quality Rendering* (offline, using cycles renderer)..., *Tempalte* for others to use...

Every phase is represented as a working area within the 2.5D space.
Here, the following ideas should be mocked:

**Bottom-Up** Workflow
: Each phase is represented as horizontal xz-Layer, starting with the *Data Import* layer at the bottom. All outgoing links (e.g., CSV import) are connecting to the input of the next, upper layer, i.e., *Data Filtering*. Each layer can be navigated to easily, and the previous (lower) and next (upper) layers are always indicated. The resulting visualization is show on the last, top layer.

* Mockup: ToDo
* Pros & Cons:
* ToDo

**Top-Down** Workflow
: Similar to the *Bottom-Up* workflow but starting with the *Data Import* as top-most layer, having the visualization at the bottom.

* Mockup: ToDo
* Pros & Cons:
* ToDo
* DL: expects this to be not favorable over the other ideas

**x-Flow** Workflow
: Using the 2.5D horizontal ground plane, starting with the first phase *Data Import* "left" (most negative x-positioning in respect to the other phases). Then the user navigates horizontally to the other phases (horizontal scrolling, horizontal panning, or fast travel using special interaction). The visualization itself is positioned most-positive x location.

* Mockup: ToDo
* Pros & Cons:
* ToDo

**z-Flow** Workflow
: Similar to x-Flow but layed out from front to back.

* Mockup: ToDo
* Pros & Cons:
* ToDo
* DL: While configuring stuff in a phase, one could always see the resulting visualization at the same time.

## (1) Data **Import**

Implementation
Data import uses parallelized CSV import (based on LW implementation) that provides typed arrays per column (local column store).

Representation

Every file loaded, is

## Design Language

- How to communicate, e.g., errors and warnings at certain nodes (inputs, outputs) or links.
- How to communicate asynchronous processes, e.g., waiting for results of server-side jobs, or local worker.
- How to communicate empty mapping, visualization template.
- ToDo / More to come

## Community Aspects

1. The intend is to allow for sketchfab or shadertoy like sharing of visualization designs. This includes *likes*, *comments*?, *previews?*, *tags* (or can these be generated by the specialized mapping?), etc. Furthermore.
2. There should be a way, to extend the catalogue of avaiable glyphs (data representations to map data to, e.g., cuboid, chess figures, trees, points, lines, etc.). At first, its probably good enough to extend the GitHub project... Blender assets etc?

## Techincal Components

### 3rd Party Components
This section highlights relevant implementations that are expected to be implemented and/or provided as separate projects but developed and maintained by us.

CSV Import
: Fast and awesome CSV reader that provides data as typed arrays. --**LW** (done?)

OpenLL
: We need sophisticated labeling that can be used for local, interactive client-side label placement as well as for scripted cycles renderings offline. So labeling is probable best provided as a service first, and available locally for interactive client-side rendering second. --**WS** (consolidate existing stuff, new impl)

Point Renderer
: WebGL-based point renderer facilitating high-quality and super fast rendering of massive amounts of points. Provided as *gpu-points* npm package and used with webgl-operate --**DL** (new impl)

Line Renderer
: WebGL-based line renderer facilitating high-quality and super fast rendering of massive amounts of lines, splines, curves including arrow heads and more. Provided as *gpu-lines* npm package and used with webgl-operate --**DL** (new impl)

Grid Renderer
: WebGL-based line renderer facilitating high-quality and super fast rendering of massive amounts of lines, splines, curves including arrow heads and more. Provided as *gpu-lines* npm package and used with webgl-operate --**DL** (new impl)

Navigation
: WebGL-based camera modifier implementing virtual camera based navigation metaphors. Provided as *gpu-navigation* npm package and used with webgl-operate --**DL** (extract+fixes)

Color Scales
: WebGL-based color scale implementation appropriate for data visualization. Provided as *gpu-colorscales* npm package and used with webgl-operate --**DL** (extract)

Text Renderer
: WebGL-based text renderer facilitating high-quality and super fast rendering of massive amounts of text-glpyhs in 2D and 3D alike, including basic typesetting. Provided as *gpu-text* npm package and used with webgl-operate --**DL** (extract)

Node-link-based Data Processing (extract)
: Typescript toolkit for rapid, CPU-based processing of data buffers. The processing can be described as node-link based config itself and results in a optimal, cached processing sequence for the required output buffers. Input would most likely be typed arrays (column-store of the CSV reader) --**WS** (extract+minor redesign?)

glTF-Renderer (extract & fix later)
: WebGL-based glTF renderer ... --**??** (extract+fixes)

Collaborative Interaction Framework
: ToDo --**??** (todo)