Mask meshes (4)

Mask meshes (3)

Mask meshes (2)

Mask meshes (1)

Stingers morph (2)

Stingers morph (1)

Stingers (2)

Stingers (1)

This plot was made for Plot Party on a A6 paper.
Experimenting again with some 3D polygon generator and camera projection.

Plot Party – Drops (2)

Plot Party – Drops

Plot Party – Grids (2)

Plot Party – Grids

Plot Party – Red, Black, White (2)

Plot Party – Red, Black, White

This plot was made for Plot Party on a A6 paper. 
Playing with gouache paint with brushes.

Plot Party – Paint

This plot was made for Plot Party on a A6 paper.

Plot Party – Polygons

This plot was used as a cover for my new vlog &quot;Un an en Chine&quot;.
<iframe width="100%" height="400" src="https://www.youtube.com/embed/r6R-fYQLYOg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Un an en Chine

Travel to China

This is a physical counterpart of a NFT from the Plottable Era: (II) Medieval collection released on fx(hash) on December 2023. This plot was released through the &quot;Redeemables&quot; feature of fx(hash).

Plottable Era: (II) Medieval #213

Plottable Era: (II) Medieval #209

100 followers on Warpcast

Lava lamp (2)

Made for <a href="https://genuary.art">Genuary 2024</a> 13 &quot;Wobbly function day&quot;.

Wobbly (2)

for <a href="https://genuary.art">Genuary 2024</a> 26, &quot;Grow a seed&quot;.
Made with circle packing and using perlin noise to decide on the colors.
Each flower is made of spirals and circles. The clover is made with 4 parametric heart curves.
Plotted with fountain pens on watercolor paper (A4).

Genuary24: flowers (2)

Genuary24: flowers (1)

for <a href="https://genuary.art">Genuary 2024</a> 28, skeuomorphism.
What is the skeuomorphism of a pen plotter? One interpretation is to use a fountain pen and recreate millimeter paper with a curves on it like if someone made it by hand.
Plotted with fountain pens on watercolor paper (A4).

Genuary24: skeuomorphism

for <a href="https://genuary.art">Genuary 2024</a> &quot;recreate from your gallery photo&quot;, 
 I&#39;ve reproduced this medieval art from Paris&#39; Cluny museum. Result is raw and very first prototype (typically would need to tweak the code), was fun to figure out some code and only using #penplotter strokes

Genuary24: medieval plate

for <a href="https://genuary.art">Genuary 2024</a> 24, Impossible objects, i&#39;ve made a Klein bottle representation.
Made with distance function paradigm and marching cubes algorithm.
Plotted with gel pens on black paper (A4).

Genuary24: Klein bottle

for <a href="https://genuary.art">Genuary 2024</a> &quot;8x8&quot;.
Plotted with fountain pens on watercolor paper (A5).

Genuary24: 8x8x8

for <a href="https://genuary.art">Genuary 2024</a> &quot;Point - line - plane&quot;.
Plotted with fountain pens on watercolor paper (A5).

Genuary24: Point-line-plane

for <a href="https://genuary.art">Genuary 2024</a> &quot;Use a library that you haven’t used before&quot;, I have interpreted the theme on my &quot;pen plotter&quot; prism as &quot;Use a technique you never used before&quot; and here goes Dry Pastel! I have never experimented this on a pen plotter and it was a lot of fun. It was done live on a Twitch stream.

Genuary24: panda pastel

Revisiting <a href="/plots/1358">plots/1358</a> with colors.

self-plottable code with colors

for <a href="https://genuary.art">Genuary 2024</a> &quot;Flocking&quot;, I used Perlin noise to generate a flock of vectors.

Genuary24: Flocking

for <a href="https://genuary.art">Genuary 2024</a> 18, &quot;Bauhaus&quot;, I have inspired from the <a href="https://en.wikipedia.org/wiki/Bauhaus">Bauhaus</a> movement and its use of primary colors and simple shapes.
3 inks of fountain pens on watercolor paper (A4).

Genuary24: Bauhaus

for <a href="https://genuary.art">Genuary 2024</a> 17, &quot;Inspired by Islamic art&quot;, I tried to reproduce caligraphic shapes with only fountain pen lines.

Genuary24: inspired by Islamic art

for <a href="https://genuary.art">Genuary 2024</a> 16, we visualize 10&#39;000 datapoints on a spiral curve.

10'000 datapoints

for <a href="https://genuary.art">Genuary 2024</a> 06, we have revisited the Windows pipe screensaver. 
Made with distance function paradigm and marching cubes algorithm.
Plotted with gel pens on black paper (A4).

Genuary24: screensaver

This is a rework of <a href="/plots/1353">plots/1353</a> 
<hr>
In <a href="/plots/1353">plots/1353</a> experiment, we have made JavaScript code that is &quot;self-plottable&quot;: the code produces a plottable SVG of itself.
When working with pen plotters, we do not have fonts so we need to recreate the strokes to make letters and this code do it in the most minimal way possible: each character are encoded as few strokes on a 0..9 grid. The glyphs are placed on a A4 paper to recreate the code that produces them! 
This initial experiment was entirely made on Twitch, and the replay is available on Youtube: <a href="https://www.youtube.com/watch?v=C1z_4jzMDYk">https://www.youtube.com/watch?v=C1z_4jzMDYk</a> (the glyph editor, drawing the glyphs and making the code itself).
<iframe width="100%" height="360" src="http://www.youtube.com/embed/C1z_4jzMDYk?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

<hr>
for <a href="https://genuary.art">Genuary 2024</a> 15 &quot;Less than 1kb of artwork&quot;. It has been quite challenging to optimize the code to fit in 1007 bytes, but it was a lot of fun! Like &quot;JS1K&quot; kind of JavaScript golfing, you have to hack into the language features to make the worse possible hacks to save bytes. But here, it pushes this to the extreme: I had to consider removing as many characters as possible, so we got rid of these characters (vs the past version): <code>!$&#39;*;?ABCI\bkuz{}</code> !!! You may think some part of the code are verbose but it&#39;s also all about removing these characters!
<ul>
<li>no more <code>!</code> not operation. we wimake checks to be truthy only.</li>
<li>no more <code>$</code> string interpolation. we use <code>+</code> instead.</li>
<li>no more <code>&#39;*</code> string multiplication. we use divisions instead!</li>
<li>no more <code>;</code> statement separator. We don&#39;t use semicolons and otherwise we use <code>,</code> instead.</li>
<li>no more <code>?</code> ternary operator. We use <code>&amp;&amp;</code> and <code>||</code> instead.</li>
<li>no more <code>ABCI</code> string literals. These are due to <code>Array</code>, <code>viewBox</code>,.. we managed without!</li>
<li>no more <code>\</code> escape character. We don&#39;t join on <code>\n</code> anymore, the stroke building is inlined into one path!</li>
<li>no more <code>kuz</code> object literals. this came from <code>black</code> and other keywords, I took some hard decision to not even have <code>fill=&quot;none&quot; stroke=&quot;black&quot;</code> part, so you don&#39;t get a very beautiful preview but it&#39;s still plottable.</li>
<li>no more <code>{}</code> object literals. This was one fun, we removed all blocks, no more <code>if</code> and <code>for</code>, and instead we use only <code>.map</code> and we embraced the <code>(instr1, instr2, ...)</code> synthax of JS <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_operator">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_operator</a></li>
</ul>

1007 bytes of self-plottable code

Wobbly (1)

Made for <a href="https://genuary.art">Genuary 2024</a> 12 &quot;Lava lamp&quot;, continuation of <a href="/plots/1355">plots/1355</a>.
There are only 3 fountain pen inks used here and it was amazing to be able to have so much color tones thanks to ink blending. There will definitely be more of this!
Coded live on <a href="https://twitch.tv/greweb">https://twitch.tv/greweb</a>

Lava lamp (1)

Made for <a href="https://genuary.art">Genuary 2024</a> 11 &quot;In the style of Anni Albers&quot;.
Streamed live on <a href="https://twitch.tv/greweb">https://twitch.tv/greweb</a>

Texture experiment

Made for <a href="https://genuary.art">Genuary 2024</a> 10 &quot;Hexagon&quot;.
This implements &quot;A local cellular model for snow crystal growth&quot; paper by Clifford A. Reiter (2004) in Rust language, and renders it as a physical pen plot.
This cellular automaton is so chaotic that the generator will run multiple simulations in parallel and select one to be chose.
I have refined the original cellular automaton with some local effects that will make the propagation varies (using a perlin noise) and will also spawn at random locations.
The rendering is using my &quot;worms filling&quot; technique that allows to fill the space with strokes, in a manner that also contributes to the frost visual effect.
I&#39;ve been having so much fun exploring this algorithm, which isn&#39;t so complex but yield very interesting patterns.

FROST (4)

for <a href="https://genuary.art">Genuary 2024</a> 09 &quot;ASCII&quot;, I&#39;m sharing a self-plottable code: A code that self reproduce the SVG of itself and is pen plottable. No font used, just few strokes encoded with a 0..9 grid. From the glyph editor to the pen plot, the dev was entirely streamed on twitch. Replay is available on Youtube: <a href="https://www.youtube.com/watch?v=C1z_4jzMDYk">https://www.youtube.com/watch?v=C1z_4jzMDYk</a>.

self-plottable code

This is a prototype from Analog Patterns generator.
Analog Patterns is the result of a creative collaboration between the photographers @project_pajon and the generative artist @greweb, known for his plottable creations. The collection focuses on the subtle patterns hidden in the complex natural and human-made environments that we find ourselves in.
The individual unique images are generated with procedural code when minted. 
Each piece of this art collection is created the moment you mint it!
To achieve this the generator uses 100 analog photos from Pajon. For each minted image the generator picks 1 or 2 random photos and composes them using randomly selected collage effects. The rendering is then projected into an only-strokes-version that can be physically plotted with fountain pens (21cm square) and using a random palette of ink.
This hybrid approach, blending photography with procedural code, results in intricate generative outcomes oscillating between realism and abstraction. This highlights the interplay between human and natural patterns and the element of randomness inherent in the artistic process.

Analog Patterns: Proto 13

Analog Patterns: Proto 12

Analog Patterns: Proto 11

Analog Patterns: Proto 10

Analog Patterns: Proto 9

Analog Patterns: Proto 8

Analog Patterns: Proto 7

Analog Patterns: Proto 6

Analog Patterns: Proto 5

Analog Patterns: Proto 4

Analog Patterns: Proto 3

Analog Patterns: Proto 2

Analog Patterns: Proto 1

&#39;Plottable Era: (II) Medieval&#39; is the second generator in the &quot;Era&quot; generators series, highlighting different periods and civilizations. Following &quot;Primitive&quot;, this new series shows epic battle in a medieval scenery with mountains, castles, and ships.
The project was released on fx(hash) as a generative collection: <a href="https://www.fxhash.xyz/generative/29725">https://www.fxhash.xyz/generative/29725</a>

Era Medieval: Proto 21

Era Medieval: Proto 20

Era Medieval: Proto 19

Era Medieval: Proto 18

Era Medieval: Proto 17

Era Medieval: Proto 16

Era Medieval: Proto 15

Era Medieval: Proto 14

Era Medieval: Proto 13

Era Medieval: Proto 12

Era Medieval: Proto 11

Era Medieval: Proto 10

Era Medieval: Proto 9

Era Medieval: Proto 8

Era Medieval: Proto 7

Era Medieval: Proto 6

Era Medieval: Proto 5

Era Medieval: Proto 4

Era Medieval: Proto 3

Era Medieval: Proto 2

Era Medieval: Proto 1

Era Medieval: Cover

variation of <a href="/plots/1311">plots/1311</a>.
for <a href="https://genuary.art">Genuary 2024</a> 06, we have revisited the Windows pipe screensaver. 
Made with distance function paradigm and marching cubes algorithm.
Plotted with white gel pens on black paper (A4).

Genuary24: screensaver (3)

variation of <a href="/plots/1311">plots/1311</a>.
for <a href="https://genuary.art">Genuary 2024</a> 06, we have revisited the Windows pipe screensaver. 
Made with distance function paradigm and marching cubes algorithm.
Plotted with fountain pens on white paper (A4).

Genuary24: screensaver (2)

variation of <a href="/plots/1307">plots/1307</a>.
for <a href="https://genuary.art">Genuary 2024</a> 02, the word &quot;palette&quot; is encoded as ASCII binary on a spiral. Plotted with a brush and going through a few inks drop randomly placed with a eye dropper.

Genuary24: No palette (3)

variation of <a href="/plots/1307">plots/1307</a>.
for <a href="https://genuary.art">Genuary 2024</a> 02, the word &quot;palette&quot; is encoded as ASCII binary on a spiral. Plotted with a brush and going through black inks drop randomly placed with a eye dropper.

Genuary24: No palette (2)

for <a href="https://genuary.art">Genuary 2024</a> 08, we have implemented Lorenz system, but instead of drawing the curve, we have used my &quot;worms filling&quot; algorithm to fill the density accumulated by the particles traveling on the Lorenz system. Plotted with Sakura gel pen on black paper.

Genuary24: Chaotic system

for <a href="https://genuary.art">Genuary 2024</a> 07, we created a new <a href="/plots/tags/plotloop">#plotloop</a> animation. Plotted with Diamine Bloody Brexit ink on white paper (A4).

Genuary24: loading animation

for <a href="https://genuary.art">Genuary 2024</a> 05, I have revisited a creation from Vera Molnár, pioneer of computer art. We randomly spawn polygons forming rows respectively to Vera&#39;s creation and fill them with my &quot;Worms filling&quot; algorithm to make it plottable. The result is plotted with a fountain pen on watercolor paper. This was streamed on my Twitch channel.

Genuary24: In Honor of Vera Molnár

for <a href="https://genuary.art">Genuary 2024</a> 04, my logo is transposed to pixels with different resolutions and random pixel glitch. Plotted with gel pen on black paper.

Genuary24: pixels

for <a href="https://genuary.art">Genuary 2024</a> 03, the word &quot;recursion&quot; is encoded as ASCII binary on a spiral of a spiral of a spiral. Plotted with gel pen on black paper (A3).

Genuary24: recursion

for <a href="https://genuary.art">Genuary 2024</a> 02, the word &quot;palette&quot; is encoded as ASCII binary on a spiral. Plotted with a brush and going through 9 inks drop randomly placed with a eye dropper.

Genuary24: No palette

for <a href="https://genuary.art">Genuary 2024</a> 01, the word &quot;particle&quot; is encoded as binary on a spiral emitting binary particles. Plotted with Sakura gel pen on black paper.

Genuary24: Particles

Following last year tradition with <a href="/plots/848">&quot;L&#39;homme et la machine&quot; (2022)</a> and <a href="https://greweb.me/gnsp">Generative Nano S+ collection (2021)</a>, this year I&#39;ve gone a step further by crafting 144 unique physical postcards offered to my colleagues at Ledger (distributed to Paris, Vierzon, London and Portland offices).
They all form this physical animation: <a href="https://objkt.com/asset/KT1AZYsEjt8HFEXWZUjGVfBxtzKPobNo3x1t/16">https://objkt.com/asset/KT1AZYsEjt8HFEXWZUjGVfBxtzKPobNo3x1t/16</a>
This project is an artistic interpretation of videos from the Ledger commercial featuring the Ledger Nano X. The artwork is physically realized by using pen plotting with white gel on black paper. I have created a video by compiling the 144 frames of the plot, using the stop-motion animation technique.
The medium used is fascinating as it represents an organic and analog process. In this process, everything is made with strokes, and I have taken creative liberty to map the video pixels into lines using my algorithm &quot;Worms filling&quot; (this algorithm mimics the movement of worms navigating through food, representing areas where color is needed). Additionally, this method produces an electric arc effect, which aptly inspired the project&#39;s name, &quot;Electric wallets.&quot;
At the bottom, each frame features a small binary pager, indicating its unique number.
<hr>
<img src="/images/plots/1305makingof.jpg" width="100%" />

To give an idea of the intense involvement of this artwork, here is an approximative time and cost of this project. Of course, I&#39;m leveraging on many of my past experience, experiments and on my pen plotters machine (which itself have important fixed costs).
<ul>
<li>Development: roughly 5 hours. (leveraging on lot of past experiments)</li>
<li>Pen plotting time: roughly 36 hours (in total). There are 18 sheets to produce and each takes approximatively 2 hours to plot. A sheet is a A3 grid of 8 postcards.</li>
<li>Pen costs: about 10 Sakura gel pens were used. (approx 3€ each)</li>
<li>Paper costs: 18 Fabriano A3 black paper were used. (approx 1.10€ each)</li>
<li>Digitalisation time: roughly 8 hours. I had to photograph each sheet, manually crop and align the 144 images to make back the video. Then I had to cut them all physically. This is taking a lot of time.</li>
</ul>
That means in total:
<ul>
<li>49 hours of work</li>
<li>50€ of material costs</li>
</ul>
The project was creating in November 2023.
<iframe width="100%" height="400px" src="https://www.youtube.com/embed/8qapeBf2RMo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Electric wallets (144 frames)

This work is based on <a href="/plots/934">the 5k twitter plot</a>.
I just reached 1000 followers on Instagram and this is a physical celebration of this milestone. All Instagram handles were drawn on paper, with a pen plotter robot.
If you follow me on Instagram, you are very likely in this, will you spot yourself? Let me know on twitter. Good luck =)

1000 followers on Instagram

I have revisted my plot party entry <a href="/plots/1141">#1141</a> that I made for plotparty initially.
This is also an entry for #plotparty &quot;Layers&quot;.

Minimalistic White Clouds

Plotting collaboration with @swizzlevixn who gave me a Crow shape that I then packed (in &quot;quinconce&quot; layout) and piped into a custom coloring technique I called &quot;Worms filling&quot;.

Crow (black on white)

Crow (white on black)

Medieval Frames (White on Black)

Le corbeau et le renard

Medieval Frames

Sea of inks

FIRE

<img width="50%" src="/images/2022/shattered/thumbnail.jpg" style="float: right">

"Shattered" is a new generative and plottable art that will be released the February 23rd, 2022 (6PM Paris time) on the emerging platform https://plottables.io/.

> Shattered [adj] – broken into many small pieces.
>
> This plottable NFT generator visualizes the explosion of polygons (e.g. squares) into pieces then rendered using different filling techniques and suggested inks. There are various rare cases to discovery, like the shape, filling method, alignments,...
>
> The plots are designed to be plotted with fountain pens and on A4 paper, but the plotter artist is free to do any interpretation they want, chose different colors, different paper techniques, the possibilities are endless! Depending on your configuration, the plot can take between 15 minutes to a few hours to execute.
>
> @greweb can ship plotted editions to NFT owners with a small extra cost via https://greweb.me/plots/nft



## Physically plottable?

<video loop autoplay controls src="/images/2022/shattered/video.mp4" width="100%"></video>

Like in [my previous article](https://greweb.me/2021/11/plottable-storm), the generator produces "Plottable NFTs".

A Plottable NFT is, like regular art NFT, a token to a digital artwork that can be sold and resold on a second market – blockchain guarantees its unicity.

The **Plottable** NFT also gives a privilege to its owner: making or requesting a physical plot (with an artistic fee to cover costs, [see /plots/nft](https://greweb.me/plots/nft)). As a physical work can be executed multiple times, every physical piece remain unique: plotting is an analog process that will inevitably yield different results.

<img width="100%" src="/images/2021/11/plottablestorm/schema.png">

[https://greweb.me/plots/nft](https://greweb.me/plots/nft) sets my own "plotting services" terms but any other plotter artist is welcome to collaborate and contribute to offering to the community their own services under their terms and interpretation of the art – I would just ask to verify that the requester owns the NFT.

<img width="100%" src="/images/plots-promo/letters.jpeg">

> You can also be your own artist, buy a plotter, try it out! This is all designed to be open-source friendly and you can download the SVG yourself!

### Prototype, prototype, prototype

Many prototypes have been physically plotted in order to guarantee the viability of results: plottable often is a challenge when it comes to pen and paper. The density is very challenging to adjust: not enough lines and you miss the opportunity for great ink effects and saturation. Try with too much lines and your paper is melting.

<img width="100%" src="/images/2022/shattered/prototypes.jpg">

These prototypes helped to adjust the density and tweak the algorithms over the weeks of development.

<img width="100%" src="/images/2022/shattered/prototype1.jpg">
<img width="100%" src="/images/2022/shattered/prototype3.jpg">
<img width="50%" src="/images/2022/shattered/prototype2.jpg"><img width="50%" src="/images/2022/shattered/prototype5.jpg">
<img width="100%" src="/images/2022/shattered/prototype4.jpg">

## How does the generator work

The generator works in a few steps:

- Step 1 implements **the shattering** and outputs polygons.
- Step 2 implements **the filling**: the polygons are filled with various techniques and colors.
- Step 3 implements **post-processing effects**. Not only a SVG is generated, but it is also used in a WebGL shaders texture to simulate ink and paper effects.

## Step 1: the shattering

The "shattering" is implemented with a recursive function that, given a polygon, randomly cut it in half and apply the same recursion on each part. The cut happens in many different ways. For instance, there is a chance for the "cut" to be aligned with the polygon. The recursion can also randomly stop, which can sometimes keep great parts intact. There is even a very small chance (~0.3%) to not obtain a cut at all and have the original polygon preserved. Parts are usually split near their center and the 2 parts that result from the cut can diverge from each other – this simulates some kind of "pushback" resulting of the shattering.

### 'Shape' feature

The main polygon used before the shattering occurs can vary from a square to a circle, with rare cases of triangles, hexagons,...

Square remains the most common shape to have.

<img width="50%" src="/images/2022/shattered/examples/shape-square.jpg"><img width="50%" src="/images/2022/shattered/examples/shape-circle.jpg"><img width="50%" src="/images/2022/shattered/examples/shape-hexagon.jpg"><img width="50%" src="/images/2022/shattered/examples/shape-pentagon.jpg">

### 'Parts' feature

This feature categorizes the number of polygon parts that result from the shattering. It can vary from one to thousands.

<img width="100%" src="/images/2022/shattered/examples/variety3.jpg">

### 'Pushback' feature

This feature expresses how intense the Pushback is for a given piece – effect that shifts parts away from each other.

<img width="100%" src="/images/2022/shattered/examples/pushback-high.jpg">

It can sometimes not exist at all which make the polygon preserving its general shape and only showing subdivisions:

<img width="100%" src="/images/2022/shattered/examples/pushback-none.jpg">

### 'Alignment' feature

The alignment represents how perpendicular the parts are organized altogether.

This has no alignment:

<img width="50%" src="/images/2022/shattered/examples/alignment-none.jpg">

These have the max alignment:

<img width="50%" src="/images/2022/shattered/examples/alignment-max.jpg"><img width="50%" src="/images/2022/shattered/examples/alignment-max-2.jpg">

### 'Destructed' feature

'Destructed' is a rare feature that expresses that part of the polygons has been destructed. This sometimes happens when the shattered parts are pushbacked out of boundaries.

<img width="50%" src="/images/2022/shattered/examples/destructed-1.jpg"><img width="50%" src="/images/2022/shattered/examples/destructed-2.jpg"><img width="50%" src="/images/2022/shattered/examples/destructed-3.jpg"><img width="50%" src="/images/2022/shattered/examples/destructed-4.jpg">

### 'Distribution' feature

'Distribution' feature expresses the area balance between parts. Here are some examples:

**"One Major"** (2 examples side by side)

<img width="50%" src="/images/2022/shattered/examples/distribution-onemajor-2.jpg"><img width="50%" src="/images/2022/shattered/examples/distribution-onemajor.jpg">

**"Two Main"** (2 examples side by side)

<img width="50%" src="/images/2022/shattered/examples/distribution-twomainparts-2.jpg"><img width="50%" src="/images/2022/shattered/examples/distribution-twomainparts.jpg">

**"Small Parts"** (2 examples side by side)

<img width="50%" src="/images/2022/shattered/examples/distribution-small-parts-2.jpg"><img width="50%" src="/images/2022/shattered/examples/distribution-small-parts-3.jpg">

## Step 2: the filling

each polygon resulting from the shattering is individually filled with various techniques. That said, the shattering algorithm has already decided how each polygon is colored and filled. There is a higher chance that related parts have same fill and color, but it can still happen that one has many different filling techniques on the same piece:

<img width="50%" src="/images/2022/shattered/examples/variety.jpg"><img width="50%" src="/images/2022/shattered/examples/variety2.jpg">

These are statistically the TOP 10 filling technique combination to most likely occur:

```
Statistics of feature 'Fill':
 Web, Spiral: 6.0%
 Web: 5.7%
 Web, Ping Pong: 3.3%
 Spiral, Web: 3.3%
 Ping Pong: 3.1%
 Scratches: 2.8%
 Hatch: 2.5%
 Ping Pong, Scratches: 2.3%
 Stippling: 2.3%
 Web, Spiral, Empty: 2.2%
```

The 66% remaining is going to many different combinations of one of the 8 different filling technique that can occur: **Empty, Spiral, Web, Ping Pong, Scratches, Hatch, Stippling, Zigzag** which I'm going to detail now:

### Fill = Empty

There is a first, rare filling technique that consists of NOT filling! but simply stroking the polygon. It is mostly used on small polygons and used in combination with another filling technique.

<img width="100%" src="/images/2022/shattered/examples/fill-empty.jpg">

### Fill = Spiral

Spiral is the most complex algorithm of the generator and can take up to a few seconds to run in JavaScript. It works by connecting randomly sampled dots by rotating the lines, each iteration scans for a point making the smallest angle turn, this creates a spiral that statistically converge to the center.

<img width="50%" src="/images/2022/shattered/examples/fill-spiral.jpg"><img width="50%" src="/images/2022/shattered/examples/fill-spiral-3.jpg">

Due to the complexity of the algorithm, I have chosen to bail out some cases to fallback to "Web" filling technique which is why you most likely never get a "Spiral only" filling (it can still happen ~0.4%).

### Fill = Web

The web is, after spiral, the second most popular filling technique to happen but is the most likely technique to happen as "standalone" (without combination with another filling technique)

<img width="50%" src="/images/2022/shattered/examples/fill-web.jpg"><img width="50%" src="/images/2022/shattered/examples/fill-web-3.jpg">

One of the easter eggs of this Fill technique is that it will sometimes also have circles hole that the algorithm will try to avoid:

<img width="100%" src="/images/2022/shattered/examples/fill-web-2.jpg">

The algorithm samples a bunch of points along the polygon edge and connects dots randomly. The dots are connected with lines that maximize avoiding the circles and "traversing" the polygon rather than connecting lines that would be along an edge. Points are also samples randomly away from the polygon edge in order to avoid too much paper density problem – it creates an interesting border width effect.

### Fill = Ping Pong

Ping Pong filling is the idea to throw a ray that bounces on the polygon edge.

<img width="100%" src="/images/2022/shattered/examples/fill-pingpong.jpg">

The basic idea is to sample points along the polygon perimeter and then to do a permutation of indexes that can for instance looks like this: **0, 100, 200, 1, 101, 201, 2, 102, 202,...\***.

Many optimizations were done on this to make the plot viable. Each line is traced by counting how much lines traversed at a given position and will stop as soon as it's too "crowded".

We can notice the algorithm at work on the previous example as we see some "gaps" near the intersection of some lines, but in practice, a plot will be generally fine as the ink will "bleed" a bit and fill these gaps.

### Fill = Hatch

the hatching technique traces parallel lines with a varying distance to produces a fabric pattern. The lines are chosen in a way that they are aligned to the longest segment that can exists inside the polygon.

<img width="50%" src="/images/2022/shattered/examples/fill-hatch.jpg"><img width="50%" src="/images/2022/shattered/examples/fill-hatching-3.jpg">

### Fill = Stippling

the stippling technique is implemented with many samples points from which a small line stroke is done. The line stroke segment, which is one millimeter long, is oriented following a simple field determined with the center of the polygon: `atan2(cx - p[0], cy - p[1])`

<img width="50%" src="/images/2022/shattered/examples/fill-stippling.jpg"><img width="50%" src="/images/2022/shattered/examples/fill-stippling-2.jpg">

### Fill = Scratches

<img width="100%" src="/images/2022/shattered/examples/fill-scratches.jpg">

Scratches are sorting randomly samples points on two perpendicular axis that follow the general polygon direction.

### Fill = Zigzag

<img width="50%" src="/images/2022/shattered/examples/fill-zigzag.jpg"><img width="50%" src="/images/2022/shattered/examples/fill-zigzag-2.jpg">

Zigzag has a similar idea as in Scratches except it only traces line on one axis and will only sample points on the edge.

## Step 3: post-processed effects

To give more life to the digital shape, I have added some paper grain effects as well as a lighting effect that grows from the center.

It is important to note that I actually generate 2 SVGs:

- one dedicated for the WebGL shaders where I use #0FF, #F0F, #FF0 colors and addition mode to be able to tell what even ink there is at a position. It allows me to implement some sort of ink simulation (those which remains minimal, but using opacity to express the saturation of an ink and each color defines 2 colors on each it derives too – for instance the yellow of Diamine Amber is diverging to orange tones)
- a second SVG is the downloadable SVG that tries to approach as much as possible the ink color and have layers ready for the plotter. Note that you can directly drag&drop (or right-click) from the digital canvas itself (thanks to a hidden `<img>` in the DOM)

## Palette

The art pieces are picking colors among a palette of 9 curated inks from Diamine that looks like this:

<img width="100%" src="/images/2022/shattered/inks.jpg">

They are sorted from common to relatively rarer cases.

- Black
- Poppy Red
- Turquoise
- Amazing Amethyst
- Indigo
- Hope Pink
- Amber
- Pumpkin
- Aurora Borealis

The most common case is to obtain a plot that will only have one ink chosen, but the plot can go up to having 3 different colors. They are split into different layers.

<img width="50%" src="/images/2022/shattered/examples/colors-2.jpg"><img width="50%" src="/images/2022/shattered/examples/colors-3.jpg">

## Artistic challenges and choices

To wrap up, it took me quite a lot of iterations to reach decision on many aspects and tweak what would be my final pieces. In generative art and especially when you reach a high variety of results it is really hard to guarantee one given output is satisfying. This is especially true in my case that involve many level of recursion which makes it very hard to control the outcome. The wider your generation is, more likely you will get non interesting results or edge cases you do not prefer to happen. The boundaries of the generation have to be well controlled in order to avoid the "bad cases".

**Total rewrite of my tech stack**. Technically speaking, this generator was a total rework of my stack, which is in Rust, back into pure JavaScript. As the code is on-chain, it needs to be very well optimized in term of bytes and I used many techniques from back of my JS1K / JS13K days! I compressed my GLSL shader code as well as the JavaScript code, I use only tuples (arrays) to represent my data so they do not have the verbosity of JS objects, etc...

**curating away the bad cases**. The way I generally approached the curation in my generator is to curate away the cases I didn't want rather than explicitly curating the cases I want! Typically, one algorithm will control the quality of the output and will be retrying the result until it satisfies the criterias. One example is I have to exclude any "empty result" to happen. I also explicitely wanted to bail out a result containing only one cut (2 polygons).

**Brace for impact**. embracing collisions and allowing some shapes to intersect was part of the "glitch" I wanted to keep. It can be interesting to have a mix of inks that occur on these intersections. This is a rare effect.

**recursion depth**. It took me quite a lot of shattering iteration to decide on the maximum number of recursion I would do as well as it's rarity. At the end, I've chose to make the "low number of parts" rarer than having a very exploded shattered case, because it emphasis on what the piece is about. Pieces that are intacted or only cut in a few parts are still very interesting to have and should actually be quite scarced.

**shapes rarity & filling consistency**. The way the shape are filled are not always decided randomly and many logic bail out from cases I didn't want.

<img width="100%" src="/images/2022/shattered/thumbnail.jpg">

Shattered is a NFT plottable generator that visualizes the explosion of polygons (usually squares) into parts that are rendered with different filling techniques and suggested inks. There are various rarity elements, like the shape, filling method, inks...

Shattered, a plottable generator on plottables.io

This fourth article (in a series of 7 articles) reveals the technique used to render the Nano swivel.

<video muted loop autoplay controls src="/images/2022/gnsp/361.mp4" width="50%" style="float:left; margin-right: 40px; margin-bottom:20px"></video>

**Timeline:**

- [article 1: GNSP – the concept](/2021/12/gnsp)
- [article 2: the 3D distance to a Nano S+](/2021/12/gnsp-raymarching)
- [article 3: the nano screen](/2022/02/gnsp-nanoscreen)
- [**article 4: the swivel**](/2022/02/gnsp-swivel)
- article 5: the background
- article 6: the video generation
- article 7: the final drop
- (?March) public mint

**The collection is browsable on https://greweb.me/gnsp**

**OpenSea: https://opensea.io/collection/gnsp**

 

This is very similar to the "nano screen" in that we will use a Canvas 2D as a texture to the GLSL shader and it will be projected on the swivel surface.

## The Canvas 2D generative swivel code

A canvas 2D of 1200 x 400 pixels is used to draw the swivel engraved texture. We use it to possibly display a text and draw some "plotted lines".

```js
async function metal(word, swivelPlotted) {
 const w = 1200;
 const h = 400;
 const canvas = document.createElement("canvas");
 canvas.width = w;
 canvas.height = h;
 const ctx = canvas.getContext("2d");
 ctx.fillStyle = "#000";
 ctx.fillRect(0, 0, w, h);
 ctx.fillStyle = "#fff";
 let font = "Arial";
 // ...plot things...
 // ...draw text...
 return canvas;
}
```

Here is what the texture of #472 looks like:

<img src="/images/2022/gnsp/472-texture.png" width="100%" />

and here is the final result in the raymarched object:

<video muted loop autoplay controls src="/images/2022/gnsp/472.mp4" width="100%"></video>


### "plotted" lines

<video muted loop autoplay controls src="/images/2022/gnsp/461.mp4" width="100%"></video>

The swivel can sometimes be "laser plotted" which is a reference to the "plotting" work I've been doing last year. This "plotting" is a simple stacking of lines which create some mountains effect.

In the following code, `swivelPlotted` is defined when plotting is active and is an array of random values.

```js
if (swivelPlotted) {
 ctx.strokeStyle = "#fff";
 ctx.lineWidth = 3;
 const octaveCount = Math.floor(3 + 6 * swivelPlotted[4]);
 const perlin = generatePerlinNoise(w, h, {
 octaveCount,
 amplitude: swivelPlotted[3],
 persistence: 0.2,
 });
 let pad = [50, 20];
 let amp = 120 * mix(swivelPlotted[0], swivelPlotted[1], swivelPlotted[2]);
 let incr = Math.floor(3 + 50 * swivelPlotted[1]);
 if (incr < 15 || (octaveCount < 4 && amp > 40)) {
 ctx.fillStyle = "#000";
 font = "Arial Black";
 }
 let heights = Array(w).fill(h);
 for (let y = h - pad[1]; y > pad[1] + amp; y -= incr) {
 ctx.beginPath();
 let up = true;
 for (let x = pad[0]; x < w - pad[0]; x++) {
 let dy = amp * perlin[y * w + x];
 let yy = y - dy;
 let m = heights[x];
 if (yy > m) {
 up = true;
 continue;
 }
 heights[x] = yy;
 if (up) {
 ctx.moveTo(x, yy);
 up = false;
 } else {
 ctx.lineTo(x, yy);
 }
 }
 ctx.stroke();
 }
}
```


### text

As shown at the beginning, we can also simply have a text on the swivel. Sometimes it is combined with the plotting effect.

<video muted loop autoplay controls src="/images/2022/gnsp/322.mp4" width="100%"></video>

```js
if (word) {
 ctx.textAlign = "center";
 ctx.textBaseline = "middle";
 const lines = word.split("\n");
 const sz = Math.floor(
 20 + 1200 / (3 + Math.max(...lines.map((l) => l.length)))
 );
 ctx.font = sz + "px " + font;
 lines.forEach((line, i) => // multi line
 ctx.fillText(
 line,
 w / 2,
 Math.round(h / 2 + 1.2 * sz * (i + 0.5 - lines.length / 2))
 )
 );
}
```


### sticker text

We can also use emoji instead of text.

<video muted loop autoplay controls src="/images/2022/gnsp/365.mp4" width="100%"></video>

## Raymarching shader integration

The swivel metal texture is rendered using a brownian noise. (like explained in https://thebookofshaders.com/13/)

Contextually to the raymarching, we have the local coordinate of the swivel (including its rotation), which allows us to do a texture lookup on the swivel text texture. All of this information (noise and texture) is encoded in the material value (a float). It is possible to encode it on one value like this because it's a grayscale value.

```glsl
noiseMetal = fbm(vec2(40.0, 1000.) * p.xy);
vec2 coord = fract(vec2(1.0, -3.0) * p.xy + vec2(0.5));
vec4 mt = texture2D(metalText, coord);
float t = mix(0., grayscale(mt.rgb),mt.a * step(p.z, 0.) * step(p.x, -0.5) * step(abs(p.y), 0.16));
float swivelM = 2.2 + t;
s = opU(s, HIT(swivel, swivelM));
```

## sticker emoji

<video muted loop autoplay controls src="/images/2022/gnsp/321.mp4" width="100%"></video>

For the sticker that appear on the swivel, we add to the distance a disc and we use a side effect `vec3 sticker_color` variable that is later used in the `shade` function. The position of the sticker is randomly placed.

```glsl
${
 !opts.sticker
 ? ""
 : `
vec2 q = p.xy + vec2(${opts.stickerPosX.toFixed(2)}, ${opts.stickerPosY.toFixed(2)});
float sticker_size = 0.15;
float sticker_border = 0.01;
coord = fract(vec2(.5,-.5) * q / sticker_size - 0.5);
vec4 v = texture2D(stickerText, coord);
sticker_color = mix(vec3(1.), v.rgb, v.a);
float l = length(q.xy)-sticker_size;
s = opU(s, HIT(max(
 abs(p.z + 0.13)-0.005,
 l-sticker_border
), 4.2 - step(0.0, l)));
`
}
```

This fourth article reveals the technique used to render the Nano swivel.

GNSP – the swivel rendering

This third article (in a series of 7 articles) reveals the technique used to render the screen display itself.

<video muted loop autoplay controls src="/images/2021/12/gnsp/419.mp4" width="50%" style="float:left; margin-right: 40px; margin-bottom:20px"></video>

**Timeline:**

- [article 1: GNSP – the concept](/2021/12/gnsp)
- [article 2: the 3D distance to a Nano S+](/2021/12/gnsp-raymarching)
- [**article 3: the nano screen**](/2022/02/gnsp-nanoscreen)
- [article 4: the swivel](/2022/02/gnsp-swivel)
- article 5: the background
- article 6: the video generation
- article 7: the final drop
- (?March) public mint

**The collection is browsable on https://greweb.me/gnsp**

**OpenSea: https://opensea.io/collection/gnsp**

 

The screen, displays the unique BIP39 word and can sometimes have an effect or an animation. In the NFT metadata, they are expressed on the "Screen" feature, and here is the distribution:

```
 <not defined>: 1527 = 74.6%
 scrolling: 251 = 12.3%
 blinking: 136 = 6.6%
 negative: 81 = 4.0%
 complex: 25 = 1.2%
 negative and scrolling: 11 = 0.5%
 half-negative: 8 = 0.4%
 negative and blinking: 7 = 0.3%
 half-negative and blinking: 2 = 0.1%
```

This means 75% of the time you will only get the text displayed statically but in other case you have various effects implemented.

## Step 1: a Canvas2D texture is used for the word text

a 128 by 64 Canvas 2D texture is generated – this is the actual resolution in pixels on the actual device.

```js
function screen(word) {
 const w = 128; const h = 64;
 const canvas = document.createElement("canvas");
 canvas.width = w; canvas.height = h;
 const ctx = canvas.getContext("2d");
 ctx.fillStyle = "#fff";
 ctx.fillRect(0, 0, w, h);
 ctx.textAlign = "center";
 ctx.textBaseline = "middle";
 ctx.font =
 (navigator.userAgent.includes("Mac OS")
 ? "" : "bold ") + "22px Arial";
 ctx.fillStyle = "#000";
 ctx.fillText(word, w / 2, h / 2);
 return canvas;
}
```

> Ok, there is a funny trick here on an annoying fact: depending on your OS you will have a different font weight, as Mac devices tend to have bolder font, I only used non bold in other cases. 




Apart this trick, there are nothing fancy here: we are just writing the word in the Canvas. So there are actually no animation logic at all here: the animations (text motion / balls motion in negative) are all implemented in the GLSL shader.


## Step 2: the text texture is processed in GLSL

I'm using `regl` library helper and I need to inject the text canvas as a `uniform sampler2D text` parameter:

```js
uniforms: {
 text: regl.texture({ data: screenCanvas, flipY: true }),
```

After this, the main trick is to project the 2D Texture of the word onto the 3D raymarched object, and in my case, I simply project it along the Z-axis, globally. Indeed it would need to be applied "locally" if the Nano was actually moving or rotating but I didn't need that so we can simply stick to a global mapping.

So basically:

```glsl
vec2 coord = someOffset + someMultiplier * p.xy;
float m = step(texture2D(text, coord).x, 0.5);
```

makes `m` being a value of either 0.0 or 1.0 based on if the pixel is on or off.

Now, it also need to be pixelated, so we need to round the coordinate:

```glsl
vec2 coord = someOffset + someMultiplier * p.xy;
vec2 a = coord * vec2(128.,64.);
coord = floor(a) / vec2(128.,64.);
float m = step(texture2D(text, coord).x, 0.5);
```

Then we add a `edge` effect. This `edge` represents the distance to the edge of a pixel.

```glsl
vec2 coord = someOffset + someMultiplier * p.xy;
vec2 a = coord * vec2(128.,64.);
float edge = min(fract(a.x), fract(a.y));
coord = floor(a) / vec2(128.,64.);
float m = step(texture2D(text, coord).x, 0.5)
 * (1.0 - 0.5 * step(edge, 0.25)); // changes the pixel color
```

This will accentuate even more the pixel effect as we can see in this zoom:

<img src="/images/2022/gnsp/pixel.png" width="100%"/>

Ok, to precise exactly what `coord` is, here is the actual code:

```glsl
vec2 coord = fract(fract(vec2(-0.2, 0.5) + vec2(3.6) * p.xy / vec2(-2.25, 1.0)) + ${
 opts.scrollingScreen ? "vec2(0.5+floor(time*15.0)/15.0, 0.)" : "0.0"
});
```

You can note that:
- multiply by `vec2(-2.25, 1.0)` to stretch a bit the font.
- in case of `scrollingScreen` an offset by `time` is applied on x coordinate, and using some floor function so it does it by "increments" (pixel scroll)
- we apply a whole `fract` function (which is a `% 1.0`) to keep the coord in a 0.0 - 1.0 range and actually make it repeat.

Now, to create the negative effect, what we simply need to do is to either chose `m` or `1.0 - m` as a pixel value. 


This is implementing the simple idea to have half of the screen cut into two negative parts:

```glsl
${opts.halfnegativeScreen ? "m=mix(m,1.-m,step(coord.y, 0.5));" : ""}
```

And this implements the possibly blinking effect:

```glsl
${opts.blinkingScreen ? "m*=step(fract(2.*time),0.5);" : ""}
```

Now for the more complex animation, the effect varies at a given position on x,y, so we will give it to a function to determine if we need to swap the color. The animation we can see in the video above is a reference to one of my last year creation: [/shaderday/65](/shaderday/65).

```glsl
${
 !opts.screenAnimation
 ? ""
 : `
 float sz = ${(
 1 -
 opts.screenAnimation[3] * opts.screenAnimation[3]
 ).toFixed(2)};
 coord -= 0.5;
 coord *= vec2(2.,1.) * ${(
 1 -
 opts.screenAnimation[3] * opts.screenAnimation[3]
 ).toFixed(2)};
 coord += 0.5;
 ${
 opts.screenAnimation[1] < 0.2
 ? `coord.y${opts.screenAnimation[1] < 0.1 ? "+" : "-"}=time;`
 : ""
 }
 ${opts.screenAnimation[2] < 0.2 ? `coord.x-=time;` : ""}
 coord=fract(coord);
 m=mix(m,1.-m,step(shape(coord,2.*PI*time), 0.5));
 `
}
```


`screenAnimation` is a array of random values and with that, we can yield variation of the initial `shape` animation which is implemented relatively like in my [/shaderday/65](/shaderday/65):

```glsl
float shape (vec2 p, float t) {
 float smoothing = 0.15;
 p -= 0.5;
 vec2 q = p;
 pR(p, t + cos(${Math.round(5 * opts.screenAnimation[0] - 2)}. * t));
 vec2 dist = vec2(0.0);
 float crop = 99.0;
 float s = 99.0;;
 s = fOpUnionRound(q.y, s, smoothing);
dist = vec2(0.31, 0.0);
float radius = 0.11;
s = fOpUnionRound(s, length(p + dist) - radius, smoothing);
crop = fOpUnionRound(crop, length(p - dist) - radius, smoothing);
 s = fOpDifferenceRound(s, crop, smoothing);
 return smoothstep(0.0, 1.0 / min(resolution.x, resolution.y), s);
}
```

Finally, we map the "m" value to actual colors, and in our case it's basically black and white. Note the usage of `negativeScreen` flag:

```glsl
mix(
 vec3(0.01),
 vec3(1.0),
 ${opts.negativeScreen ? "1.-" : ""}m
)
```

> This GLSL code is templated in JavaScript as you may notice, it's a trick to make the GLSL compile even faster to avoid having runtime ifs.

**That's it folks! There are nothing more to say about the screen rendering of GNSP.**

This third article reveals the technique used to render the screen display itself.

GNSP – the Nano screen rendering

This second article (in a series of 7 articles) reveals the technique used to 3D render the Generative Nano S Plus collection: using a GLSL fragment shader, without any 3D model, raymarching a calculated distance to a Nano S Plus.

<video muted loop autoplay controls src="/images/2021/12/gnsp/509model.mp4" width="50%" style="float:left; margin-right: 40px; margin-bottom:20px"></video>

**Timeline:**

- [article 1: GNSP – the concept](/2021/12/gnsp)
- [**article 2: the 3D distance to a Nano S Plus**](/2021/12/gnsp-raymarching)
- [article 3: the nano screen](/2022/02/gnsp-nanoscreen)
- [article 4: the swivel](/2022/02/gnsp-swivel)
- article 5: the background
- article 6: the video generation
- article 7: the final drop
- (?March) public mint

**The collection is browsable on https://greweb.me/gnsp**

**OpenSea: https://opensea.io/collection/gnsp**

 

## The rendering is implemented in a GLSL Fragment Shader

The generative art is rendered entirely into one "fragment shader", which is essentially a GPU program that takes a bunch of inputs and efficiently calculates the pixel colors with your graphic card.

This is a paradigm I like to call "Functional Rendering paradigm": see article https://observablehq.com/@gre/introduction-to-functional-rendering-paradigm

On top of this paradigm, I have used a technique called Raymarching distance function, see article https://observablehq.com/@gre/introduction-to-raymarching-distance-functions

Here is the main algorithm that implement the raymarching: (where `map` is the distance function)

```glsl
HIT marcher (inout vec3 p, vec3 dir) {
 HIT hit = HIT(0.);
 float t = 0.;
 for (int i=0; i<120; i++) {
 HIT h = map(p + t * dir);
 t += h.x;
 if (abs(h.x) < .0001) {
 hit = h;
 break;
 }
 }
 p += t * dir; 
 return hit;
}
```

A fun proof of this is to play with the number of raymarching iteration (modulating iterations from 0 to 120):

<video muted loop autoplay controls src="/images/2021/12/gnsp/glitch.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/glitch2.mp4" width="50%"></video>

The main scene is described in this "map" distance function:

```glsl
HIT map (vec3 position) {
 HIT s = HIT(10. - length(position), 0.);
 float t = 3. * fract(time);
 float swivelAngle = PI * ( 1. +
 cubicInOut(min(1.0, t)) +
 cubicInOut(min(1.0, max(t - 1.8, 0.0))) );
 s = opU(s, sdLedgerNanoSPlus(position, swivelAngle));
 return s;
}
```

## The 3D distance to a Nano S Plus

Essentially, a Nano S Plus can be rendered with a bunch of union, difference and intersection math operations. Here are the basic utilities I used:

```glsl
// SHAPE PRIMITIVES:
float sdCylinder( vec3 p, vec3 c ) {
 return length(p.xz-c.xy)-c.z;
}
float sdCappedCylinder( vec3 p, float h, float r ) {
 vec2 d = abs(vec2(length(p.xz),p.y)) - vec2(h,r);
 return min(max(d.x,d.y),0.0) + length(max(d,0.0));
}
float sdBox( vec3 p, vec3 b ) {
 vec3 q = abs(p) - b;
 return length(max(q,0.0)) + min(max(q.x,max(q.y,q.z)),0.0);
}
float sdBox2(in vec2 p, in vec2 b) {
 vec2 d = abs(p) - b;
 return length(max(d, vec2(0))) + min(max(d.x, d.y), 0.0);
}
float sdBoxRoundZ(vec3 p, vec3 b, float r) {
 return max(sdBox2(p.xy, b.xy-r)-r, abs(p.z)-b.z);
}
// SHAPE OPERATIONS:
float fOpUnionRound(float a, float b, float r) {
 vec2 u = max(vec2(r - a,r - b), vec2(0));
 return max(r, min (a, b)) - length(u);
}
float fOpIntersectionRound(float a, float b, float r) {
 vec2 u = max(vec2(r + a,r + b), vec2(0));
 return min(-r, max (a, b)) + length(u);
}
float fOpDifferenceRound (float a, float b, float r) {
 return fOpIntersectionRound(a, -b, r);
}
float opSmoothSubtraction( float d1, float d2, float k ) {
 float h = clamp( 0.5 - 0.5*(d2+d1)/k, 0.0, 1.0 );
 return mix( d2, -d1, h ) + k*h*(1.0-h);
}
void pR(inout vec2 p, float a) {
 p = cos(a)*p + sin(a)*vec2(p.y, -p.x);
}
```

This code might seems complex, but it's relatively simple primitives, some are from this great article: https://iquilezles.org/www/articles/distfunctions/distfunctions.htm


With these utilities, I have developed that function called `sdLedgerNanoSPlus`, that implements the **distance to a Nano S Plus**:

`HIT sdLedgerNanoSPlus (vec3 p, float rot)`

Knowing the "space distance to an object" allows to use a raymarching algorithm to render it in 3D.

The function takes two parameters `p` and `rot`:
- `p` is the 3D point from which to evaluate the distance. If the Nano S Plus is at 1 meter away from the Nano S Plus, it must return a value of 1 meter. as simple as this.
- `rot` allows for me to control the rotation of the swivel, so it can be animated from the caller.

The function returns one `HIT` value. `HIT` is a simple alias to `vec2`, which actually allows me to return a tuple of two values: `(distance, material)`. On top of the distance, I need to track what is the "closest material". Basically answering the question: from the point `p` what is the part of the Nano S Plus that is the closest? For instance, the swivel, the plastic part, the screen,...

> I was able to take precise measurements from some wireframes of the actual device and tried to make it as close as possible, transposed into code.


This is probably a lot of code to digest, but here is its implementation:

```glsl
HIT sdLedgerNanoSPlus (vec3 p, float rot) {
 float btn = sdBoxRoundZ(
 vec3(abs(p.x - 0.18) - 0.22, p.z, p.y - 0.155),
 vec3(0.06, 0.03, 0.04), 0.03);
 float case2d = sdBox2(p.xy, vec2(0.624, 0.174)-0.08)-0.08;
 float swivel_hook = sdCylinder(p.xzy, vec3(-0.44, 0.0, 0.074));
 HIT s = HIT(max(
 min(
 opSmoothSubtraction(
		 min(
 max(case2d+0.015, abs(p.z+0.12)-0.015), // main casing carving
 btn-0.004 // btns carving
 ),
 max(case2d, abs(p.z)-0.101) - 0.01, // main casing
 0.008
 ),
 min(
 btn,
 max(swivel_hook-0.015, abs(p.z)-0.12) // plastic in the casing for the swivel
 )
 ),
 -swivel_hook // carve the swivel hook out
 ), 2.05);
 // screen
 float screen2 = sdBox2(p.xy - vec2(0.18, 0.), vec2(0.27, 0.12));
 s = opU(s, HIT(max(s.x, screen2), 2.1));
 // swivel
 p.x += 0.04;
 p.x += 0.4;
 pR(p.xy, rot);
 p.x -= 0.4;
 float w = 0.54;
 float x = p.x + 0.8;
 float z = abs(p.z) - 0.12;
 float swivel_radius = 0.192;
 float swivel_metal_width = 0.006;
 float rounding = 0.003;
 float swivel = opSmoothSubtraction(
 sdCylinder(p.xzy, vec3(-0.4, 0.0, 0.08)), // carved
 min(
 sdCappedCylinder(vec3(p.y, z, x - 0.4), swivel_radius, swivel_metal_width),
 sdBox(vec3(x - 0.41 + w, p.y, z), vec3(w, swivel_radius, swivel_metal_width))
 )-rounding,
 0.04
 );
 // metal to close the swivel end
 swivel = fOpUnionRound(swivel,
 sdBox(vec3(x + 0.135 + w, p.y, p.z), vec3(swivel_metal_width, swivel_radius, 0.123))
 ,0.01);
 noiseMetal = fbm(vec2(40.0, 1000.) * p.xy);
 vec2 coord = fract(vec2(1.0, -3.0) * p.xy + vec2(0.5));
 vec4 mt = texture2D(metalText, coord);
 float t = mix(0., grayscale(mt.rgb),mt.a * step(p.z, 0.) * step(p.x, -0.5) * step(abs(p.y), 0.16));
 float swivelM = 2.2 + t;
 s = opU(s, HIT(swivel, swivelM));
 return s;
}
```

To visualize it more, I've animated the code to make it show the different steps union and difference operations:

<video muted loop autoplay controls src="/images/2021/12/gnsp/model.mp4" width="100%"></video>

But let's try to dive into more details and tricks.

### The main casing

The first part of the function is making the plastic casing:

```glsl
float btn = sdBoxRoundZ(
 vec3(abs(p.x - 0.18) - 0.22, p.z, p.y - 0.155),
 vec3(0.06, 0.03, 0.04), 0.03);
float case2d = sdBox2(p.xy, vec2(0.624, 0.174)-0.08)-0.08;
float swivel_hook = sdCylinder(p.xzy, vec3(-0.44, 0.0, 0.074));
HIT s = HIT(max(
 min(
 opSmoothSubtraction(
 min(
 max(case2d+0.015, abs(p.z+0.12)-0.015), // main casing carving
 btn-0.004 // btns carving
 ),
 max(case2d, abs(p.z)-0.101) - 0.01, // main casing
 0.008
 ),
 min(
 btn, // buttons themself
 max(swivel_hook-0.015, abs(p.z)-0.12) // plastic in the casing for the swivel
 )
 ),
 -swivel_hook // carve the swivel hook out
), 2.05);
```

We can see that I use a lot of `min()` to combine the primitives. when you apply `min(A,B)` between the distance of objects A and B it is essentially the distance to the union of A and B, because min returns the closest distance. so `min` is an union.

We can also see the use of many `max()` like for instance `max(case2d, abs(p.z)-0.101) - 0.01` which renders a rounded box but with sharp edge on the Z axis:

![](/images/2021/12/gnsp/casing.png)

> `max(A, B)` is basically the intersection of A and B. Sadly, it's not an "exact" distance that limits the ability to bevel a tiny bit the edge. If someone have a trick to implement this shape with the exact distance, I would love to know.

`max(case2d, abs(p.z)-0.101) - 0.01` is therefore made of the intersection of:
- `case2d` is a 2D box in xy space. defined by `sdBox2(p.xy, vec2(0.624, 0.174)-0.08)-0.08`. The value 0.8 is removed from the box dimension but also then removed from the distance. That value is actually the border radius of the box.
- `abs(p.z)` is the distance to the Z plan. `abs(p.z)-0.101` is distance to a volume of the plan enlarged with a `0.101` padding.

### Carving out

![](/images/2021/12/gnsp/casingdig.png)

The first operation done on the casing is to carve the part of the buttons and the inside. This is essentially done with the operation `max(A, -B)` (remove B from A), except here we are using a smooth difference operation to not make too "sharp" cuts.

The same technique is used on the swivel hole:

![](/images/2021/12/gnsp/casingdig2.png)

And again done on the model swivel shape:

![](/images/2021/12/gnsp/swiveldig.png)

**but for the swivel, it is done with a "smoothing difference"**, which creates the nice rounded effect in the hole:

![](/images/2021/12/gnsp/swiveldigresult.png)

Here is the code that do this:

```glsl
opSmoothSubtraction(
 sdCylinder(p.xzy, vec3(-0.4, 0.0, 0.08)), // the carving shape is a cylinder
 min(
 sdCappedCylinder(vec3(p.y, z, x - 0.4), swivel_radius, swivel_metal_width), // circle of the swivel
 sdBox(vec3(x - 0.41 + w, p.y, z), vec3(w, swivel_radius, swivel_metal_width)) // long rectangle metal part
 )-rounding, // add a bit of rounding (bevel)
 0.04
)
```

and if we tweak that 0.04 value between 0.0 and 0.1, we obtain this interesting range of smoothing subtraction:

<video muted loop autoplay controls src="/images/2021/12/gnsp/smoothdiff.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/smoothdiff2.mp4" width="50%"></video>

There would be so much to improve in the modelization. For instance, I couldn't figure out a simple way to make the smooth corner of the swivel metal, so I end up with this simplification which isn't perfect:

![](/images/2021/12/gnsp/modelsimpl.png)

```glsl
// metal to close the swivel end
swivel = fOpUnionRound(swivel,
 sdBox(vec3(x + 0.135 + w, p.y, p.z), vec3(swivel_metal_width, swivel_radius, 0.123))
,0.01);
```

Distance function can always be optimized and details can always be added, possibilities are infinite it's only a matter of how much hours do you want to spend on. And on my case, it was basically a weekend.


## Lighting and material

There would be a lot to write about the accumulation of techniques used for the lightning. Basically there are 2-3 lights in the scene and some are casting some shadows using raymarching as well.

<video muted loop autoplay controls src="/images/2021/12/gnsp/material.mp4" width="100%"></video>

*That video looks surprisingly so professional, I love it!* The scene is just this code:

```glsl
HIT map (vec3 p) {
 HIT s = HIT(10. - length(p), 0.);
 s = opU(s, HIT(length(p)-0.5, 2.05)); // sphere distance is just length(p)-radius
 return s;
}
```

It shows the rendering of a sphere on the plastic material. Before I talk about the materials, let's focus on the lighting.

### The lighting

The general code that renders the scene is pretty straightforward:

```glsl
vec3 scene(vec2 uv) {
 vec3 c = vec3(0.); // color of the pixel to set
 vec3 p = cameraP;
 vec3 dir = normalize(vec3(uv - .5, 1.)); // perspective camera
 dir = lookAt(cameraP, focusP) * dir; // camera focus on a point
 HIT hit = marcher(p, dir); // this throw camera ray and tells what points it hits (material and distance)
 vec3 n = normal(p); // this calculates the NORMAL VECTOR on the surface of the hit object
 c += lighting(hit, p, n, dir); // <= THIS IS WHERE LIGHTING IS CALCULATED
 c = mix(c, sceneBgColor, pow(smoothstep(4., 10., length(p-cameraP)), .5)); // mist on far away objects
 return c;
}
```

Ok, so as you can see on the previous video, we have essentially 2 lights in the scene, one blueish and one redish. They spread differently in the material to simulate a bit their different size. We however can see the user of a THIRD light, which is more in the back and will be useful to simulate the fact the background is emitting its color. This was very useful for strong background colors like orange:

<video muted loop autoplay controls src="/images/2021/12/gnsp/100.mp4" width="100%"></video>

This is what lighting is implementing:

```glsl
vec3 lighting (HIT hit, vec3 p, vec3 n, vec3 dir) { // (code is a bit simplified from original)
 vec3 l, ldir;
 vec3 c = vec3(0.);
 l = vec3(lightPos, 1.5, -3.4);
 vec3 obj = shade(hit, p);
 ldir = normalize(l - p);
 c +=
 0.92 * vec3(0.9, 0.7, 0.6) * (
 // ambient
 0.1
 // diffuse
 + obj
 * (.5 + .5 * diffuse(p, n, l)) // half lambert
 * (0.5 + 0.5 * softshadow(p, ldir, 0.05, 5., 8.))
 + specular(n, p, hit.y, ldir, dir, 10.)
 );
 l = vec3(-lightPos, 5., -2.);
 ldir = normalize(l - p);
 c +=
 0.92 * vec3(0.3, 0.5, 0.6) * (
 // ambient
 0.1
 // diffuse
 + obj
 * (.5 + .5 * diffuse(p, n, l)) // half lambert
 + specular(n, p, hit.y, ldir, dir, 20.)
 );

 l = vec3(0., 2., 8.);
 ldir = normalize(l - p);
 c += bgLightColor * (
 obj
 * diffuse(p, n, l)
 + specular(n, p, hit.y, ldir, dir, 20.)
 );
 return c;
}
```

You can see the first thing done here is:

```
 vec3 obj = shade(hit, p);
```

It is a very important step that ask the hit object material "give me your color". I will cover it in the Material section.

Then for each light I want to apply, you can see the same pattern:

First of all, we will put the light at a specific position in the space. For instance:

```glsl
l = vec3(lightPos, 1.5, -3.4);
```

we calculate the actual light direction with `p` which is the point of interest to color.

```glsl
ldir = normalize(l - p);
```

And then we can finally add to the object its emitted color:

```glsl
 c +=
 0.92 * vec3(0.9, 0.7, 0.6) * (
 // ambient
 0.1
 // diffuse
 + obj
 * (.5 + .5 * diffuse(p, n, l)) // half lambert
 * (0.5 + 0.5 * softshadow(p, ldir, 0.05, 5., 8.))
 + specular(n, p, hit.y, ldir, dir, 10.)
 );
```

and there are a few components that is very inspired by the classical "ambient diffuse specular" paradigm: https://learnopengl.com/Lighting/Basic-Lighting which I recommend you to read if you want to dive more into this part.

In my case, I use half lambert technique which I find really interesting for a cartoon-ish effect https://developer.valvesoftware.com/wiki/Half_Lambert and because i don't use expensive ambient occlusion.

I also, in this light case, will use `softshadow` that cast a shadow toward the light direction.

**specular** function is an important utility that have this implementation:

```glsl
float specular (vec3 n, vec3 pos, float m, vec3 ldir, vec3 dir, float p) {
 return specularStrength(m, n, pos) * pow(max(dot(dir, reflect(ldir, n)), 0.0), p);
}
```

note that we can have different "specular strength" for each material or even depending on the position.

### The material `specularStrength()`

<video muted loop autoplay controls src="/images/2021/12/gnsp/material.mp4" width="100%"></video>

As we can see in this material, the plastic has been added some texturing.

This is implemented with a fbm noise and it is contained in the material value.

Then I had two possible ways to make it visible: either I change the color of the material OR I change the way it reflect lights in `specularStrength`. I've used the second option for the plastic case:

```glsl
float noiseMetal;
float specularStrength (float m, vec3 n, vec3 p) {
 if (m < 2.1) {
 	float v =
 	 n.z * fbm(600. * p.xy) +
 	 n.x * fbm(600. * p.yz) +
 	 n.y * fbm(600. * p.xz);
 	return 0.4 + 0.3 * v;
 }
 if (m < 2.2) {
 return 2.0;
 }
 if (m < 4.) {
 return 0.6 - 0.5 * noiseMetal + 1. * ceil(m-2.21);
 }
 return 0.4;
}
```

So pretty basic stuff, I use `m` material value, which is a one dimension value to express all materials in. in plastic case, we are in the `m < 2.1` case which have a strong noise frequency.

On the same principle, we can see it is also done for the swivel metal.

I used some trickery here because, as the swivel is moving, I had to use a global variable to set the noise value because I don't have the "local position", only the global position.

The `noiseMetal` is set directly from the `sdLedgerNanoSPlus` function with this:

```glsl
noiseMetal = fbm(vec2(40.0, 1000.) * p.xy);
```

where `p` is a local position of the swivel, contextual to the rotation applied to it.

The 40/1000 implements a stretched fbm noise which nicely recreates the effect:

![](/images/2021/12/gnsp/metaltexture.jpg)


### The material `shade()`

`shade(hit,p)` is essentially the material coloring function. It tells what color does the object reflect at a given hit position.

Here is its implementation for the whole scene (I have omitted some part that will be covered in other articles):

```glsl
vec3 shade (HIT hit, vec3 p) {
 if (hit.y < 2.0) return sceneBgColor;
 if (hit.y < 4.0) {
 if (hit.y < 2.1) {
 	return plasticColor;
 }
 if (hit.y < 2.2) {
 return ...SCREEN RENDERING HERE...;
 }
 // swivel metal
 return vec3(0.7 - 0.1 * noiseMetal - 0.2 * (hit.y - 2.2));
 }
 if (hit.y < 5.0) {
 return stickerColor;
 }
 return vec3(0.0);
}
```

So it's a simple, "give me the color of the material id number". The only trick for the noise metal was to make it a bit darker on some part to accentuate the metal effect.

**The next article is going to dive into what this `...SCREEN RENDERING HERE...` part is doing, and more generally how I managed to also make the screen display text from inside a shader!**

This second article (in a series of 7 articles) reveals the technique used to 3D render the Generative Nano S Plus collection: using a GLSL fragment shader, without any 3D model, but with raymarching distance function technique.

GNSP – the 3D distance to a Nano S Plus

This article is the first of a series of 7 articles that will explain the development and release of GNSP – a special NFT collection I've been secretly working on for a Christmas gift offered to my colleagues at Ledger. It has been a wonderful year between my crypto-developer work and my crypto-artist work and this collection is here to celebrate it.

**Timeline:**

- [**article 1: GNSP – the concept**](/2021/12/gnsp)
- [article 2: the 3D distance to a Nano S Plus](/2021/12/gnsp-raymarching)
- [article 3: the nano screen](/2022/02/gnsp-nanoscreen)
- [article 4: the swivel](/2022/02/gnsp-swivel)
- article 5: the background
- article 6: the video generation
- article 7: the final drop
- (?March) public mint

<video muted loop autoplay controls src="/images/2021/12/gnsp/1558.mp4" width="50%" style="float:left; margin-right: 20px; margin-bottom:20px"></video>

The NFT collection is called "GNSP" which stands for "Generative Nano S Plus". The Nano S Plus is the new incoming device that Ledger will release next year, it was [announced at Ledger Op3n a few weeks ago](https://www.youtube.com/watch?v=qUVkfPwSdyg&list=PL6VM0N695IhkMNEvBAOoLeKLU05qDNfd5).



The NFT collection is pushed on Polygon (Ethereum Layer-2) and will have in total **2048 items** – one is unique for each word in [the standard BIP39 wordlist](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt). A dedicated contract was developed that allowed to do an internal airdrop but will later allow to open for a public mint phase. Right now, there are 233 mints done and owned by many of us but later, there will be 2048 items fully available! There are many diversity in this **generative art work**. Nothing has been developed "statically" everything is random and generative.

 

**The collection is browsable on https://greweb.me/gnsp**

The collection is also browsable on https://opensea.io/collection/gnsp but again, is only partial as not all the items are yet minted in the [contract](https://polygonscan.com/address/0x3c11b1975c17fcf8cbb315d4430233ed1e87cf05). The current plan is to release the public mintability in a near future – please stay tuned in case this plan changes.

## Why this collection?

First of all, I would like to say that I've been working on this secretly on my own artistic time to drop this as a great surprise for all my colleagues. These are not "NFTs made by Ledger" but I had great feedback and help from some colleagues in the team. I did this because i'm passionate but also because there is something valuable and important:

As an engineer working at Ledger for the past 4 years, it's sad to see how undervalued and forgotten are the security aspects of crypto-currencies in the NFT world. I have seen so many tutorials "how to get into NFT" that don't even mention the use of hardware wallets, and sadly we already have seen many hacks due to the use of software wallets not backed by a hardware wallets. The collection is an interesting way to convey this message – making it an NFT collection actively make everyone at Ledger learning more about owning NFTs and how it works under the hood as this is still a very bleeding edge technology! Your Ethereum address is your identify, your NFT collection is your digital persona, you better want it secured.

## real-time, model-less 3D raymarching

The 3D rendering is rendered in real time, in a GLSL fragment shader, without any 3D model, using raymarching distance function technique. Even tho a high quality video is attached to each of the NFTs and stored on IPFS, the source code is fully public [here](https://github.com/gre/gre/tree/master/doodles/generative-nano-s-plus) and it only needs an index to entirely render with just code, it is self hosted on https://greweb.me/gnsp/0. The 2048 series is finalized, it's not a secret and there are no "reveal" because its code is immutable.

More explanation of the rendering technique used will be explained in further articles.

## rarity, randomless and likelyhood

It's important to understand I didn't design the outcome of the actual collection, I have only designed the likelyhood of things to happen. For instance, I have designed that there is a 2 out of 2048 of chance that one of the item have a "Snoop Dogg" on the Swivel metal engraved part but when the dice was thrown, only one item happened to have the trait: https://greweb.me/gnsp/547.

<img width="50%" src="/images/2021/12/gnsp/547.png" />

The designed likelyhood of probability of things to occured have driven the final outcome of the rarity of all the traits. They will be fully available when everything has been minted. Note that the contract distribute the items randomly on-chain on each mint action so even I can't control who gets what. In other words, the collection is deterministically finished and fully discoverable as of today but it is getting distributed pseudo-randomly.

There are a lot of traits to discover, here is a few highlights. There are reference to some of my past work. There are many different kind of animations of the camera, swivel and screen.

<video muted loop autoplay controls src="/images/2021/12/gnsp/419.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/100.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/710.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/1300.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/1353.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/494.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/1170.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/1047.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/1231.mp4" width="50%"></video><video muted loop autoplay controls src="/images/2021/12/gnsp/260.mp4" width="50%"></video>

Some articles will cover more of these.

## Development eXperience set up and code architecture

The first PoC of this artwork was developed in one day, directly inside Google Chrome using the integrated IDE that lives under the Dev Tools: Did you know you can edit and save code from there? I have just used this, I did not use any compiler / webpack / babel but instead, I have directly used web modules and the `.mjs` extension. Unfortunately, I still needed an http server (that just hosts a folder) because `file://` doesn't allow web modules.

![](/images/2021/12/gnsp/dx.jpg)

The code was decoupled in modules to allow to split the logic, rendering, and execution code:

- **the logic part**: [`features.mjs`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/features.mjs) have all the likelihood logic that generates all the parameters and "features" for the art.
 - also some utilities: [`rng.mjs`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/rng.mjs) and [`perlin.mjs`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/perlin.mjs) that implement all the noise utilities.
 - it allowed me to run some statistics script to tweak my likelihood.
- **the render part**: [`art.mjs`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/art.mjs) takes in input the features/parameters to render the actual art.
- **the execution part**:
 - [`index.html`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/index.html) file that put everything together for web. It's using module import, also also import the only dependency I have: [regl](https://github.com/regl-project/regl/).
 - [`node.mjs`](https://github.com/gre/gre/blob/master/doodles/generative-nano-s-plus/node.mjs) implements headless Node rendering of the art, using headless-gl and node-canvas. It worked smoothly but I will explain this part more in *article 6* especially on why this ended up not being a so good idea for performance and what other alternatives I used.

This article is the first of a series of 7 articles that will explain the development and release of GNSP – a special NFT collection I've been secretly working on for a Christmas gift offered to my colleagues at Ledger. It has been a wonderful year between my crypto-developer work and my crypto-artist work and this collection is here to celebrates it.

GNSP – the concept

[plotnft]: https://greweb.me/plots/nft
[fxhash]: https://www.fxhash.xyz/u/greweb

**=> https://www.fxhash.xyz/u/greweb <= is where you can find my plottable generators.**

I plan to release a plottable generator every Wednesday – this article covers today's release & share some thoughts on how to approach generative art variety.


**Last week highlight:**

<img width="40%" src="/images/2021/11/plottablestorm/digital.jpg" style="float: left">

[See article to explain this concept](/2021/11/plottable-storm) released last week with "Plottable Storm" from which I learned and grew some ideas for the next iterations!
Plottable Storm may still be available on https://www.fxhash.xyz/generative/1050 – it was released via a mint of 10tez, which was pretty expensive for the platform's current price average – but made sense as the first "plottable NFT" of the platform. Note that, getting a physical plot is only an option, on which I will ask (1) to own the NFT and (2) to pay extra fees for me to plot it on demand.

 

## 🎉 Release: Plottable Mountain Moons

Ok, this may be the best plot generator I have ever created so far. I have put so much effort. This is months of iterations and experiments concentrated into one generator. I had goosebumps exploring the results and plotting them. This is just an illegal amount of fun.

I have also improved the ink simulating shader and added animation to make it visually interesting on its digital rendered version. Here is a quick preview:

<video loop autoPlay muted src="/images/2021/12/plottable-mountain-moons/promo1.mp4" width="100%"></video>

**Find it on => https://www.fxhash.xyz/u/greweb <=**

## Tips: Prototype, prototype, prototype

I've developed my generator in the mind that it would be realistic to plot with fountain pens, e.g. without destroying the paper. This means I had to test a bunch of prototypes to check that:
- Paper can handle it (think of it like "load testing" but with ink)
- It's good looking (ink need to react well, some ink mix can be bad looking for instance)
- that the digital preview and the ink simulation is accurate (I've added many new inks and I had to tweak colors)

Here are a few prototypes I did this weekend... Actually 18 plots! Beware I use that as an iteration loop, so some helped to tweak things and do not necessarily represent a possible outcome anymore, but it's mostly the case.

<img width="100%" src="/images/2021/12/plottable-mountain-moons/all.jpg">

Each plot is done on a 21 by 21 centimeters watercolor paper.

Here are a few zooms:

<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom1.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom2.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom3.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom4.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom5.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom6.jpg">
<img width="100%" src="/images/2021/12/plottable-mountain-moons/zoom7.jpg">

And finally, the OG one that is the generator cover:

<img width="100%" src="/images/2021/12/plottable-mountain-moons/plot.jpg">


## Economy: Supply and Price

Determining the supply and price to put an NFT generator has never been easy. In fxhash, there is a great average of price of 0.5tez to 2tez which is very cheap if you think about what is happening in Ethereum. In a way, it needs to fit in this platform range, but I also need to think a lot about the supply: to me, the supply is proportional to the variety of your generator, how different results it can produce. Low Supply creates scarcity while High Supply gives more chance to collectors and reduce the FOMO effect. The price is also a way to limit the number someone can take, but is not very fair for low budget,...

For my case, and it may only justify for my own plans. I fallback-ed a bit on the idea (at least this time) to make is a Low Supply.

I decided this time to make it high in supply and a relatively accessible price for these reasons:

- This generator covers a great amount of my plotting work this year. A lot of primitives and shape combination has been converged into one big generator. And I find it fair and ethical that I can't anymore in the future release new generators that overlap too much with these. So in a way, this is a sacrifice to make. That means, I better need the supply to be high enough to make the generator fully express its variety.
- The idea of this NFT, first of all which are pretty cool as digital art, is also to use them as a power to have a physical action: claiming a physical plot to be performed. That physical plot request costs a fee. (currently set at 15tez but may evolve depending on demand and my capacity to respond to it) That means I want the price of the NFT itself to be relatively accessible which means low, which means supply need to have a better offer to those who will want to find the rare gems.
- I want my collectors to fully embrace collecting for the art and lower the "collecting for the speculation". Increasing the supply will decrease the scarcity effect that exist on second market. That said, it's not that high supply (smolskull was 2000!) and there will be room for second market to occur for those who are looking for "the perfect plot to perform".

## Tech: In pursuit of the perfect rarity equilibrium

My plot generator are develop with Rust. I have developed myself my own set of tools and I will basically have a watch loop that recompile and regenerate a .svg each time I change code. My Visual Studio Code set up will have a SVG display within the IDE while I can edit the generative code. This makes a nice ~5s live reloading development loop. Not bad.

The problem of this is that it's a generator, it yields a lot of different results. So I usually would just have a "seed" parameter exposed on the CLI and generate a folder with tons of images. Not very practical neither.

This time was still a bit of this for the initial development. But at some point I have to really think about the rarity of the results and trying to make everything interesting and unique. on my JavaScript side, I have a `generateVariables(random)` function that takes a RNG and yield a bunch of parameters to give to my generator as well as all the "features" to put in the NFT metadata.

### rarity analysis

This was really useful to split this in a dedicated file, because I could then develop a small node script that would do an analysis on 100 000 tries and give me stats about rarity. For instance:

```
Ink Sherwood Green
 undefined: 95.2%
 Mountain: 2.1%
 Stars: 2.1%
 Both: 0.6%
Inks Count
 2: 71.7%
 1: 28.3%
Mountains 2-Colors
 No: 80.6%
 Yes: 19.4%
Mountains Visibility
 Low: 46.7%
 High: 34.8%
 Full: 10.8%
 Empty: 7.7%
```

Which is super useful to try to classify and adjust how much you want a given case to occur. Indeed it forces you to really think about your classification first.

### as a query language

Ok, now what's super cool about this is I have a way to query my generator to give me a result of a given query!! So I made it work. Here are few examples:

```
node script.mjs 'p["Primitives"] > 4 && p["Inks Count"]==2'
ooa7qfERP3s73oycm7hvvtexuidFMvHtcr6dcLRHSpM9Uz33gVt
...
node script.mjs '(p["Ink Aurora Borealis"] && p["Ink Poppy Red"]) && p["Primitives"]>4 && o.a1 > 0.5 && o.f1 > 0.02 && p["Elements Count"]=="Normal" && p["Mountains Visibility"]=="Low"'
ooAzT5R8UgCy7eFYbvtryykBt8AVVBf25MQG7eknVfzHstahomV
```

the query is literally JavaScript code. And here is the simple script to run it:

```js
const predicate = new Function("p,o", "return (" + (argv2 || "true") + ")");
let r, hash;
do {
 const { fxhash, random } = newRandom();
 r = generateVariables(random);
 hash = fxhash;
} while(!predicate(r.props, r.opts));
console.log(hash);
```

### generating the .svg files in a folder

I didn't plan to explain in depth my tech stack because it would deserve a whole article, but to summarize: **generator is developed in Rust language, compiled in WASM which takes props and outputs SVG, which is rendered with WebGL shaders (sorry for your headaches)**

WASM can run in a web browser and is pretty efficient. (I'm not sure you can say the same of p5js for instance)

What's cool is WASM can also run in Node.js. So putting together that `generateVariables(random)` and even the query system, I ended up with a very powerful tool.

For instance, here I could generate a lot of results that have Blue Mountain and either Yellow or Pink moons:

```
node script.mjs '(p["Ink Amber"] || p["Ink Pink"]) && p["Ink Bloody Brexit"]=="Mountain"'
```

<img width="100%" src="/images/2021/12/plottable-mountain-moons/folder.jpg">

Pretty cool hey!

and the JavaScript is faily simple evolution of the previous code:

```js
const wasmBuffer = fs.readFileSync(path.join(__dirname, "./rust/pkg/main_bg.wasm"));
const wasmLoad = import("./rust/pkg/main.mjs");
wasmLoad.then(async (wasmModule) => {
 await wasmModule.default(wasmBuffer);
 const predicate = new Function("p,o", "return (" + (argv2 || "true") + ")");
 let r, hash;
 while (true) {
 const { fxhash, random } = newRandom();
 r = generateVariables(random);
 hash = fxhash;
 if (predicate(r.props, r.opts)) {
 const svg = wasmModule.render(r.opts);
 fs.writeFileSync("dist/" + hash + ".svg", svg, "utf-8");
 }
 }
})
```

I will definitely reuse this idea in the future. **With powerful tools comes great responsibilities!**

I plan to release a plottable generator every Wednesday – this article covers today's release & share some thoughts on how to approach generative art variety.

“Plottable Mountain Moons” and an approach to query generative art

[plotnft]: https://greweb.me/plots/nft
[fxhash]: https://www.fxhash.xyz/generative/1050


## The "Plottable NFT" paradigm

I've finalized what will be my paradigm for the next weeks and months:

- I will release a digital version of my work using NFTs and notably generative art NFT platforms.
- I will allow the NFT owners to request a physical plot on demand. ([https://greweb.me/plots/nft][plotnft])

### A collaborative and open ecosystem

The NFT, like any regular NFT, points to a digital artwork that can be sold and resold on second market – blockchain guarantees its unicity.

In the "Plottable NFT", such **NFT gives a privilege to its owner: requesting a physical plot** (with an artistic fee to cover costs, [see /plots/nft][plotnft]). This obviously can be executed multiple times, yet every physical piece is unique: plotting is an analog process that will inevitably yield different results.

[https://greweb.me/plots/nft][plotnft] sets my own "plotting services" terms but any other plotter artist is welcome to collaborate and contribute to offering to the community their own services under their own terms and interpretation of the art – I would just ask to verify that the requester owns the NFT.

<img width="100%" src="/images/2021/11/plottablestorm/schema.png">

The NFT vs physical art decoupling allows a business model that allows both the digital creator and the physical creator to be rewarded and makes the NFT truly interesting as a token that has a real-life action: to unlock physical pieces.

> You can be your own artist too, buy a plotter, try it out! This is all designed to be open-source friendly and you can download the SVG yourself!

## @greweb's generative art, plotting and NFTs

### RELEASING "Plottable Storm" on fxhash.xyz

[**=> Check my profile on fxhash.xyz <=**][fxhash]

**Here is one digital ink simulated version: (this is not a photo!)**

<img width="100%" src="/images/2021/11/plottablestorm/digital.jpg">

**Here is the physically plotted version: (photo of the 3 hours long plot on A4 paper)**

<img width="100%" src="/images/2021/11/plottablestorm/physical.jpg">


This work is based on one of my original exploration: [https://greweb.me/plots/312](https://greweb.me/plots/312).

> Plottable Storm is a flow field simulating fountain pen ink drawing on paper on its digital form. 10 inks, many rarity features varying noise, size and color positionning. Having only one color is rare.
> The digital NFTs can be used to perform a physical action: @greweb plotting on demand a fountain pen plot for those who also want physical originals.
>
> Digital and Physical art, hybrid and decoupled:
> - The art is made as a regular digital NFT on Tezos blockchain – its digital form rendered with WebGL shaders.
> - Token to the physical world: owning each NFT confer the power to request the related physical plot.
> 
> A collaborative and open ecosystem: an SVG file can be downloaded (Drag&Drop or right-click save) and plotted with fountain pens physically by plotter artists who can interpret it the way they want in their own conditions. @greweb offers his service on https://greweb.me/plots/nft
> 
> Designed for A4 size. Estimated time of 3 hours of plotting time (25% speed)


**Here are a few other physical plots made during the exploration**, especially important to tweak the generator to make a plot that would be feasible without damaging the paper too much!

<img width="100%" src="/images/2021/11/plottablestorm/2.jpg">
<img width="100%" src="/images/2021/11/plottablestorm/3.jpg">
<img width="100%" src="/images/2021/11/plottablestorm/4.jpg">

### Coming from past explorations

This latest work is a continuation of a lot of previous explorations. In the past months, I've been continuously exploring different ways to combine physical art with digital NFT and one of the recent way I've been trying this is ["Pattern 03" (article)](/2021/08/pattern-03).

I've been polishing my ink simulator lately and based on the same principle I will be able to generate more plots and have easy ways to iterate on. The tech stack is a bit ambitious, experimental and unique:

- The SVG generator is implemented in Rust language and then compiled and executed in WASM on the browser.
- It is rendered in real time and enhanced with WebGL shaders.

In context of [Ethereum absured fees](https://etherscan.io/gastracker), I've decided to focus my NFT effort on other blockchains like Tezos. I'm also focusing even more on my "plottable art" lately because, even if it's maybe not where I find the most sucess, it is definitely what I love the most experimenting with. There are so much challenge to tackle with the physical ink and paper constraints.

### Future plans

This year, I've been releasing a plot a day as shown on [https://greweb.me/plots](https://greweb.me/plots) and I intend to continue to do so, but in a more organized way:

**On the next weeks, and on a weekly basis,** I intend to release a new plottable NFT generator on fxhash. "Plottable Storm" is hopefully the series of many! I will adapt some of my best plotting explorations of this year but I also plan to dedicate time on exploring new ideas.

**Starting next year, on a monthly basis,** I intend to have a "subscribe to my plots" series where people would receive surprise plots in their mailbox from me and using a NFT membership system. The idea is still a work in progress – **Would you be interested in this idea? Don't hesitate to keep in touch with me if you like this concept.**

I will release a digital version of my work using NFTs and notably generative art NFT platforms. I will allow the NFT owners to request a physical plot on demand.

“Plottable Storm”, a generator of plottable SVGs

This weekend, a new platform called fxhash emerged on https://fxhash.xyz/, which opens to everyone the release of NFT art generators – similar to artblocks.io but on the Tezos blockchain.

This platform have a lot of hicetnunc's vibe when it was released back in March: it is very experimental yet a huge community is jumping into it – this was long awaited on Tezos. It is trustless and fully opened like hicetnunc was. Despite being in a beta state, there is already a decent UX and DX (developer experience): The developer onboarding might be one of the best among all the generative art platform I've been able to test. Without contacting anyone, I was able to publish my first generator. You get guided interactively and end to end from testing your generator, snapshotting the preview and signing transactions to publish it. It is completely trustless and autonomous.

**Beware the platform is still barely working due to heavy load from the community trying to jump into it.**

This weekend, I released a variant of one of my "shaderday" to make "Wave":

> Wave by @greweb – https://www.fxhash.xyz/generative/67
>
> <video src="/images/2021/11/duality/wave.mp4" width="60%" controls autoplay muted loop></video>

I will now release a new generator called 'Duality' – heavily inspired from https://greweb.me/shaderday/65 but with a lot of variety of results and loop possible.

## Duality

will appear soon on https://www.fxhash.xyz/u/greweb

> Duality is a minimalistic loop of circles and squares jumping between dark and light sides. wide variety of effects using repetitions, polar modulus, disc and squares. There are very rare cases implemented that may be revealed over mints! A generalization of my "Jumping Blob" creation – develop in 2021 under water by @greweb.

<video controls autoplay muted loop width="100%" src="/images/2021/11/duality/a.mp4"></video>
<video controls autoplay muted loop width="50%" src="/images/2021/11/duality/b.mp4"></video><video controls autoplay muted loop width="50%" src="/images/2021/11/duality/c.mp4"></video>
<video controls autoplay muted loop width="50%" src="/images/2021/11/duality/d.mp4"></video><video controls autoplay muted loop width="50%" src="/images/2021/11/duality/e.mp4"></video>
<video controls autoplay muted loop width="50%" src="/images/2021/11/duality/f.mp4"></video><video controls autoplay muted loop width="50%" src="/images/2021/11/duality/g.mp4"></video>
<video controls autoplay muted loop width="50%" src="/images/2021/11/duality/h.mp4"></video><video controls autoplay muted loop width="50%" src="/images/2021/11/duality/i.mp4"></video>

fxhash: duality

- [Pre-release article](/2021/08/pattern-03)
- [Post article: Part 1: covering the rarity aspects](/2021/08/the-day-after-pattern-03)
- [Post article: Part 2: covering the future plots](/2021/08/plotting-pattern-03)

> 🤗 **The ethblock.art BlockStyle ['Pattern 03'](https://ethblock.art/style/32) sold out yesterday in only 2 hours with 888 pieces.** I still can't believe it. There are no words to describe how thankful I am for all your support. THANK YOU!

You can browse through the mints on [https://ethblock.art/style/32](https://ethblock.art/style/32).

As a first disclaimer, I will have to say it's nearly impossible to cover in this article all of the 888 or even to classify them, there are amazing discoveries. I will highlight some of them.

## Rarity in ethblock.art

With ethblock.art there is always a search for the rare piece. This happens because everyone wants to find the pearl that no one will have, the one that will be unique among them all. Nevertheless, the rarity often appears where no one expected. There is also a bit of game theory at play here: if everyone mints the same rarity, it's not reeeaaally rare anymore in the final collection. What makes a great piece ultimately is the general composition and the (relative) beauty of the piece. I would always recommend not necessarily to search for the "rarity by design" (by the BlockStyle creator rules) but to find something that you like with all these components at play.

In the case of 'Pattern 03', some very cool patterns emerged. Symmetry plays an important role to reveal it, like in Nature.

The metadata of OpenSea are still loading as we speak but I'm going to highlight a small analysis of what happened with some of the picks to explain it.

## Designed rarity of Pattern 03

There were a few elements that were covered yesterday (check the [Pre-release article](/2021/08/pattern-03)) and that took an important part yesterday.

### Crosshatch shape

This shape has been used relatively popularly as it's quite rare.

Here are many examples:


[*#6824 BY BITSIKKA.ETH* ![](/images/2021/08/picks/6824.png)](https://ethblock.art/view/6824)
[*#6739 BY 0X8A53...63CF* ![](/images/2021/08/picks/6739.png)](https://ethblock.art/view/6739)
[*#6813 BY 0XE20A...866E* ![](/images/2021/08/picks/6813.png)](https://ethblock.art/view/6813)
[*#6807 BY J0RDAN.ETH* ![](/images/2021/08/picks/6807.png)](https://ethblock.art/view/6807)
[*#6931 BY SETANIMALS.ETH* ![](/images/2021/08/picks/6931.png)](https://ethblock.art/view/6931)
[*#6611 BY KLEINTONNO.ETH* ![](/images/2021/08/picks/6611.png)](https://ethblock.art/view/6611)

### The symmetry

Symmetry helped a lot on revealing some human / animals patterns and let me highlight some.

[*#6991 BY 0X5A17...4A17* ![](/images/2021/08/picks/6991.png)](https://ethblock.art/view/6991)
[*#6958 BY 0XB84D...04D3* ![](/images/2021/08/picks/6958.png)](https://ethblock.art/view/6958)
[*#6766 BY BITSIKKA.ETH* ![](/images/2021/08/picks/6766.png)](https://ethblock.art/view/6766)
[*#6776 BY 0XB8BA...F556* ![](/images/2021/08/picks/6776.png)](https://ethblock.art/view/6776)
[*#6778 BY 0X27F8...269B* ![](/images/2021/08/picks/6778.png)](https://ethblock.art/view/6778)
[*#6766 BY BITSIKKA.ETH* ![](/images/2021/08/picks/6766.png)](https://ethblock.art/view/6766)
[*#7154 BY 0X2D55...8034* ![](/images/2021/08/picks/7154.png)](https://ethblock.art/view/7154)
[*#6808 BY 0X3037...CF6E* ![](/images/2021/08/picks/6808.png)](https://ethblock.art/view/6808)
[*#6817 BY 0XE63E...1D85* ![](/images/2021/08/picks/6817.png)](https://ethblock.art/view/6817)

### inks used

As I expected, black was the most common ink used. It's pretty good to get nice contrasts, especially on important patterns.

Black is 25% of plots, then comes "Bloody Brexit" ink which is a dark blue (about 10%). then the great "Red Dragon" which is a strong red (about 8%). Then indigo and turquoise take about 5% each.

I don't have precise stats because OpenSea is still indexing.

### colors-duality

About 20% of the picks are using two colors so it was an undeniable search from minters.

I was very interested by the combination of colors that were chosen, some I had never considered in the past and it truely was a revelation to me on some ink coupling to try more in future.

[*#6824 BY BITSIKKA.ETH* ![](/images/2021/08/picks/6815.png)](https://ethblock.art/view/6815)

[*#7000 BY PLAYPAUSESTOP.ETH* ![](/images/2021/08/picks/7000.png)](https://ethblock.art/view/7000)

[*#7013 BY 0X81E5...5D63* ![](/images/2021/08/picks/7013.png)](https://ethblock.art/view/7013)

[*#6790 BY 0XB8BA...F556* ![](/images/2021/08/picks/6790.png)](https://ethblock.art/view/6790)

[*#6832 BY 0X42AD...B84E* ![](/images/2021/08/picks/6832.png)](https://ethblock.art/view/6832)

[*#7030 BY 0X6E82...918E* ![](/images/2021/08/picks/7030.png)](https://ethblock.art/view/7030)

[*#6637 BY 0XB8BA...F556* ![](/images/2021/08/picks/6637.png)](https://ethblock.art/view/6637)

## Undocumented rarity of Pattern 03

There were a few surprises that I didn't document but that some of you found out!

### "partial" lines

Another dimension of the "colors duality" is actually to have the second color not plotted at all, it makes it back to one color but with part of the pattern that is simply disabled.

It's about as rare as having a dual color. And it was used by a few pieces.

**it allowed to keep only one line here:**

[*#6777 BY 0X44DC...F3BD* ![](/images/2021/08/picks/6777.png)](https://ethblock.art/view/6777)
[*#6736 BY 0X04C4...A644* ![](/images/2021/08/picks/6736.png)](https://ethblock.art/view/6736)

there are many other examples of "partial" lines.

### The "strikethrough" lines.

I've made it possible that on top of borders, there would be some strikethrough lines. It was both a really rare feature and also very hard to use properly in a way that it's really estetic. It allows to "divide" the space of the canvas.

Here are technically all the possible strikethrough:

<img src="/images/2021/08/strikethrough.jpg" width="400"/>

Here is a prototype plot that shows how lines blends:

<img src="/images/2021/08/strikethrough-pic.jpg" width="400"/>

It's not easy to "simulate" in the digital version and be 1:1 with the physical result because all the parameters at stake with the fountain pen, ink and paper.

Technically, the SVG have a lot of lines that goes back and forth to achieve this:

<img src="/images/2021/08/strikethrough-spec.png" width="800"/>

One of the mint:

[*#6979 BY 0XBA29...0345* ![](/images/2021/08/picks/6979.png)](https://ethblock.art/view/6979)

### Ink saturation

One of the important feature I developed was to try to simulate the effect of important amount of ink. This is something you can see at stake in https://mountainofink.com/blog/diamine-pink which is one of the ink I use.

Here are 3 examples:

[*#6802 BY 0X04C4...A644* ![](/images/2021/08/picks/6802.png)](https://ethblock.art/view/6802)
[*#6804 BY 0XAE68...FBE3* ![](/images/2021/08/picks/6804.png)](https://ethblock.art/view/6804)
[*#6800 BY 0XE20A...866E* ![](/images/2021/08/picks/6800.png)](https://ethblock.art/view/6800)

that last one will be particularly interesting to plot because of the "red-ish" effect of that ink.

### Curly loops: a rarity that wasn't found! (correct me if i'm wrong)

There were a rare possibility that the displacement would have been so high that it would have make lines curly.

This was in the prototype:

<img src="/images/2021/08/picks/curly.png" width="400"/>

I have to admit this property is pushing the plotting to a certain extreme because small curls often will be too hard for the paper and the pen will start digging through it. So i'm relief 50% of the plots are not like this. 😅

## Organic rarity

There are rarity aspects that happened organically and that I didn't planned or anticipate at all. That is the beauty of generative art in general. It goes beyond its creator.

### low/stable `f` noise values

(refer to [first article](/2021/08/pattern-03) for explanation of `f`)

While there were indeed a possibility for the `f` value to go low or having a very similar value, I didn't anticipate it would be used as a feature and having other factors (e.g. `displacement`)

So these art appear to not have `f` noises at all:

(fun fact, this block was minted [3 times!](https://opensea.io/collection/blockart?search[stringTraits][0][name]=BlockNumber&search[stringTraits][0][values][0]=13115508))
[*#7025 BY 0X91D7...28B3* ![](/images/2021/08/picks/7025.png)](https://ethblock.art/view/7025)

as well as this one which nearly have no `f` but have an heavy cos displacement and a pattern I never expected:

[*#7182 BY 0X7DB2...E04B* ![](/images/2021/08/picks/7182.png)](https://ethblock.art/view/7182)

There are a few similar pieces having these wavy displacement

[*#7193 BY 0X9422...17DF* ![](/images/2021/08/picks/7193.png)](https://ethblock.art/view/7193)
[*#6938 BY ZEROLIGHTING.ETH* ![](/images/2021/08/picks/6938.png)](https://ethblock.art/view/6938)

### Great usage of the "radial gradient"

One uncommon feature of the generator was to create concentric circles. It can happen either by "removing" or by "adding" into the `f` factor. It was curated in various interesting ways.

[*#7049 BY PSYCHOKILLER.ETH* ![](/images/2021/08/picks/7049.png)](https://ethblock.art/view/7049)
[*#7042 BY GABRIELLEMIC.ETH* ![](/images/2021/08/picks/7042.png)](https://ethblock.art/view/7042)
[*#7178 BY PBOCK.ETH* ![](/images/2021/08/picks/7178.png)](https://ethblock.art/view/7178)
[*#6714 BY 0XE20A...866E* ![](/images/2021/08/picks/6714.png)](https://ethblock.art/view/6714)

### Pushing the plots to their extreme

I'm not astonished that some mints pushed the generator to its extreme boundaries but some of the picks still surprised me.

**very low line resolution (mod5) with white holes:**

[*#7056 BY 0XBA29...0345* ![](/images/2021/08/picks/7056.png)](https://ethblock.art/view/7056)

**extreme displacement and f going beyond 1.0 (so it overlaps the next line)**

[*#7040 BY 0XD21A...100C* ![](/images/2021/08/picks/7040.png)](https://ethblock.art/view/7040)

**one liner**

[*#7151 BY 0X5AB4...BAD5* ![](/images/2021/08/picks/7151.png)](https://ethblock.art/view/7151)

**invisible art** (which funnily I tried to prevent but you still found one!)

[*#6900 BY 0X81E5...5D63* ![](/images/2021/08/picks/6900.png)](https://ethblock.art/view/6900)

**extreme amount of lines**

[*#6640 BY 0X8A53...63CF* ![](/images/2021/08/picks/6640.png)](https://ethblock.art/view/6640)


**A LOT OF OTHER COOL THINGS! impossible to cover everything.**

[Next article on the future plots](/2021/08/plotting-pattern-03)

The ethblock.art BlockStyle 'Pattern 03' sold out yesterday in only 2 hours with 888 pieces. The day after Pattern 03, covering the rarity aspects.

The day after Pattern 03 (1/2)

- [Pre-release article](/2021/08/pattern-03)
- [Post article: Part 1: covering the rarity aspects](/2021/08/the-day-after-pattern-03)
- [Post article: Part 2: covering the future plots](/2021/08/plotting-pattern-03)


> 🤗 **The claiming phase has ended. Please now refer to https://greweb.me/plots/nft if you want a physical plot.**

## What about the physical art?

Quick recap of the philosophy announced before the BlockStyle was released:

**Decoupling physical art from its digital form:** Not all digital NFT collectors also are physical collectors. It is therefore important to allow both to co-exist without having a limitation on any side.

**Openness and scalability of physical plotting**. The digital NFT have a "SVG" button on hover which allow to download the SVG file (right click, download). The SVG format is a vectorial format that is used to define all the "paths" of drawing. It is the recipe to plots. That way, this is truly scalable and decentralized. Like blockchain is. I am not necessarily the only one that can plot the work physically. It could be you. It could be another artist. This model allows it.

**An economy around the digital NFTs?** In this decoupled model, 'Pattern 03' digital NFT are the main pivot NFTs at stake. an economy can be built around them. Physical artists can plot them, create & sell on side collection that allows the second market to grow. There are many ways this can be traded: for instance swapping the digital NFT as a currency is a possibility that would be recommended, but so is doing a more regular "selling print as a service"... Ultimately, the physical artist value their own skills, own "touch" – a bit like a baker can sell baguettes with a shared recipe designed by ancestors.

## *"@greweb 'Pattern 03' plots"* collection

A collection [*"@greweb 'Pattern 03' plots"*](https://opensea.io/collection/greweb-pattern-03-plots) has been created on OpenSea.
It will curate plots that I will start drawing in the coming days.

It's going to be a time-consuming process as a plot takes about 1 hour to perform (depending on settings and complexity of the lines). The physical art is designed to be plotted with fountain pens on A4 water-colour 300g paper and then cut into a 21 by 21 centimeters piece with a 5mm padding (so your art is a 20x20cm square). The planned inks to use are those described by the "Ink" trait (Diamine inks). The digital NFT has simulated a rendering that will be relatively well respected. There is going to be unpredictability when plotting it for real.

> Disclaimer: Beware I will likely not be able to plot them all. There are 888 items and it takes an average 1 hour to plot. However, I'll start plotting following a bit this curation decision process:
> - personal favorite picks
> - I will look at Opensea most starred NFTs
> - I will look at Opensea most sold NFTs
> - also if you really want the physical piece. e.g. if you ask me on Discord / Twitter. I can sure take request and add it in the wished list But I can't guarantee it as it would probably takes me 800 hours =)

## [EXPIRED] First phase: 🎉 claim a physical plot *before November 1st, 2021*

This first phase will ends on November 1st, 2021 for all physical NFTs. The presented offer will only be available during that time. The NFT physical I own after this time will still be owned by me and a second phase will be documented later.

**How did it work?**

You can claim a physical NFT (created on the collection shared above) **as long as you own the digital NFT**. 

To claim it, you make a small Offer on the NFT physical (pay what you want, e.g. 0.03 WETH – ideally >0.02 to cover the mint cost) so I can verify you are the NFT digital owner & proceed to the NFT transfer of that 'physical NFT'.

You will then get a code to obtain it physically.

**How shipping works?**
- The 'physical NFT', once acquires, will have unlockable content with instructions on how to contact me for proceeding to shipping.
- **IMPORTANT: Please use a PO Box or other postal service ( e.g. https://en.wikipedia.org/wiki/Poste_restante ). I do not want to know your home address, thanks.**
- On my side, I will use a simple (possibly tracked) letter to ship the 20x20cm art internationally.

## second phase

**The second phase is done via https://greweb.me/plots/nft**


<img width="50%" src="/images/2021/08/artist-1.jpg" /><img width="50%" src="/images/2021/08/artist-2.jpg" />

The ethblock.art BlockStyle 'Pattern 03' sold out yesterday in only 2 hours with 888 pieces. Let's cover what's next with future plots.

The day after Pattern 03 (2/2)

See follow-up articles:

- [Post article: Part 1: covering the rarity aspects](/2021/08/the-day-after-pattern-03)
- [Post article: Part 2: covering the future plots](/2021/08/plotting-pattern-03)

🤗 **The ethblock.art BlockStyle ['Pattern 03'](https://ethblock.art/style/32) was released on August 28th, 2021 and sold out in only 2 hours with 888 pieces.**

Pattern 03 is a tribute to fountain pen plotting, generating strokes lines to yield unique patterns. It recreates the condition of ink on paper in a digital art form. The second market will be exciting as these are also physically plottable. A SVG file can be downloaded from each NFT that is the recipe for a physical artist to perform the art physically (20cm square), with their own tools.

This article goes through many features of the generator and includes plotting tricks, technical notes, and useful information for collectors. You will see images attached, both digital and physical prototypes, at the end the rendering is very similar!

<img width="50%" src="/images/2021/08/pattern-03-post.jpg" /><img width="50%" src="/images/blockstyles/pattern-03/01.png" />

For many months, I've been exploring plotting art with fountain pens while exploring many different creative coding techniques. Every day, I've been releasing generators and plotting art that you can find on https://greweb.me/plots. This has been very interesting both technically and artistically. I expanded more and more my algorithm knowledge and creative coding techniques. These various experiences now contribute to this next level: I've made a "super generator" that generalizes many of them into one bundled *ethblock.art* BlockStyle generator.

Pattern 03 took a lot of patience and iterations to achieve its final result. I put my own expectation pretty high, I wanted great variety (and tweaking parameters is always hard). I also wanted a very realistic rendering technique that would almost look like the physical piece. The digital version had to be as good, if not better, than the possible physical piece that it could produce. I believe a lot in digital NFT by itself and the goal is to embrace digital-first.

In the past months, I've been thinking a lot about NFTs and the possibilities of physical VS digital art. I see many artists bridging the two worlds as well, there are many great experiments out there, I collected a bunch of physical art myself via NFTs. You already saw me already trying this ["plot loops"](/2021/05/plot-loops) concept.

**By minting on the generator, you are generating digital art.**

A lot of effort has been spent on the digital piece itself. It renders in a very realistic way on your browser, almost like if it was plotted, simulating many aspects of plotting. There is even a slight animation that I let you discover! The digital art is a unique 1:1 piece that will be an NFT that includes the SVG recipe:

 **By minting on the generator, you are curating one recipe for a possible plot.**

I've been plotting many prototypes to tweak parameters in a way that everything should technically be drawn with fountain pens! By minting, you are curating a plottable art that an artist from the plotting community could use. I've intentionally made it public and open for anyone to download the SVG related to a mint piece: ultimately anyone can plot it. This only unlocks the possibility and I will personally be one of this "physical artist" for the coming weeks. **(see *NFT and physical pieces?* section for more information)**

**By minting on the generator, you are a curator of the future plot collection.**

Giving the possibility for curators to select plotted art out of a generator with fine controls to tweak it is beyond anything I've seen done today in this field. In fine, minters have the responsibility to chose something really interesting that worth plotting, to express this responsibility, the fees to mint has been a bit higher than my previous BlockStyle.

 
 What I now want to achieve is to make the NFT as good "digitally" as it can be "physically". I've been plotting many prototypes to tweak parameters in a way that everything should technically be drawn with fountain pens! I want this art to be both physical and digital and in a loosely coupled way that gives full freedom of preferring one or the other or both.

 I intend later to offer a way for collectors to obtain the physical creation from me, but I believe this idea is beyond me and anyone in the plotting community could pick these to plot them. I believe a lot in free art, opensource and hacking mindset. I enjoy a lot free initiative like [plotterfiles.com](https://plotterfiles.com/) and this was a great inspiration here.

## What is EthBlock.art?

Before talking about 'Pattern 03', a quick recap of the platform I'm releasing on:

EthBlock.art aims to create a virtuous ecosystem of "deterministic art", code visualization of Ethereum blocks. Everything is data: from the ethereum block of transactions, to the code that visualizes it, and to the NFTs minted/traded using Ethereum transactions (that themselves are into Ethereum blocks).

This is a virtuous ecosystem, similar to [Supply Chain Transformation concepts](https://en.wikipedia.org/wiki/Value_chain): each actor in this ecosystem add value and get retributed for it, as I tried to explain in this schema:

![](/images/posts/cryptoaliens/ethblockart.png)

## The controls

As a minter, you get 6 "mods" controls.

- **MOD1:** allows you to pick your color. which recreates the conditions of some inks. Black is very powerful but also other inks are very vivid.

- **MOD2:** is controlling two factors, the border width (0.5 to 1.0) and the intensity of the noise (cycles twice).

- **MOD3:** is a general padding control and also tweaks border placement and sometimes lines distance.

- **MOD4:** control the alignment of waves and the amplitude of the "displacement" effect.

- **MOD5:** controls the resolution of each line. (beware high values slows down other mods)

- **MOD6:** adds a variable blur effect.

> MOD2 to MOD5 are controlling at least two properties of the art. This is something I like to call the "duality of controls". When you make one slider controlling two properties, you are giving a lot of variety while "constraining" the boundaries of the possible tweaks, forcing the minter to look for other blocks. This also is very important for the UX of the controls. There is always a tradeoff between being fully in control and having to search another block.

## Rarity features, block data and what drives the generation

In JavaScript is implemented the logic to extract out the "parameters" of the generator from the block data. While some of the work relies on the block hash and use an RNG (fun fact: there are 70 calls to `random()` to make it very diverse in results and rarity), some of the work also are big data analysis on the block data.

I'm going to document here how some of the main features work, You can do a general Ethereum blocks analysis to find the shape you prefer!

There are some other rarity features that I intentionally do not fully document. You do not need to "hunt" for the rarity that is "designed by the author", but instead search for the organic rarity & enjoy patterns and unexpected shapes.

> I crawled a lot of data from coingecko and etherscan to snapshot the prices of all ERC20 tokens in a way that I can value exactly how much a block have in $. I can then compare the Ethereum value and the ERC20 tokens value and do decisions based on it. (evaluated with Aug 2021 static prices)

### Main shapes

This most important feature split is the main shapes:

- If there is at least one transaction and mostly only Ethereum is transferred on that block (which is the case for very old blocks btw), you're going to get a **"rectangle spiral"**.
- If more $ is transferred in ETH than in ERC20 tokens, it's going to be **vertical lines**, **horizontal otherwise**.
- And finally, if there are actually exceptional amounts of ERC20 transfers (mostly only ERC20 transfers) it's going to Cross-Hatch.


### lines and "sub-lines"

**First: The plots are all composed of N main lines.**

The number of lines are driven by the number of transactions. More there are transactions in the minted art, more likely the number of lines will be high. This goes between 1 and 90 and these extremes are rare.

**Second: each line subdivide into M "sub-lines".**

It is most visible when there are not a lot of "lines" as it will diverge so much that sublines are no longer touching:

![](/images/2021/08/turquoise-crosshatch.jpg)

but it can also be subtle and not separate at all:

![](/images/2021/08/orange_lines.jpg)

### `f` main driver of curves

What I call `f` is a function that drives the sublines positioning and effectively makes them expanding or collapsing into one same line.

It is implemented using various noises and combined with different techniques. The following plot is covering most of them:

![](/images/2021/08/pink-osc.jpg)

- the general noise effect is the most common feature here and is available 99% of the time (not having this noise is rare). It is built with Simplex Noise and domain warping.
- the circling is an added feature that is not very common. It can have various properties.

There are also other cases like the fact lines would sometimes stop when the `f` values goes below 0.0.

### `displacement` second driver of curves

Displacement is a similar yet different technique. It allows displacing the whole lines independently of the `f` values. 

- The waving effect seen in the pink image above is produced with simple trigonometry.
- It can aggressively make lines moving a lot, even "looping" sometimes.

Displacement is overall a relatively rare feature. It is also one possible source of trouble for plotting (can dig the paper if you draw too much at the same place!) so it was pretty well contained.

Here is an example of displacement with aggressive settings:

![](/images/2021/08/aggressive-displacement.jpeg)

> It looks like a photo but this is actually the digital version!

### Inks and colors

The curator-artist chose one color among 11 inks. Each ink has various properties and some are very vivid. I would overall recommend black which produces very good contrast plots, but it's great to have the general possibility.

![](/images/2021/08/inks.jpg)

There are some plots that have color duality and that can also be plotted:

![](/images/2021/08/color-duality.jpg)

> This is a prototype and I was not careful as the corner and the final line scratch. Plotting is a challenge!

## Plot optimizations

A plotter is a machine that follows your drawing paths, here using SVG. When you do a SVG `<path>` every `move` (M) will be an actual move so you got to avoid useless moves. As it's easy to "move to the start" in algorithms, something that should not happen here.

Sometimes, the pen also was going up where I planned to "continue", this was the case of the initial algorithm of the "rectangle spiral", I avoided doing moves and preferred to connect lines.

To optimize the traveling of plotting lines, I've made it go back and forth: The first line is drawn from left to right, the second line gets drawn from right to left, and so on... This allows to avoid too much undesired ink accumulation or other pen/paper issues by alternating the direction.

Another problem I've optimized is the order of plotting lines and sublines. Instead of plotting all sublines in once, I preferred to plot the first subline of each line, then the second subline of each line, and so on... Despite the small extra move it requires, it's very important to balance the ink evenly as some inks tend to "dry" a bit over time which makes the drawing "fade away" as it flows. What's interesting is you can see the fading happening on each line:

![](/images/2021/08/strokes-zoom.jpg)

which is something I've simulated on the digital piece too! The effect varies from one ink to another.

> See also how the ink behaves on this photo? accumulation of this ink produces red-ish colors. Something that can be observed on the digital generator as well!

## Technical stack

Technically speaking, I believe this is the best achievement I did in a few years and profoundly refreshing. I managed to connect my creative coding pipeline: Rust generating SVG files, used through WASM and post-processed in WebGL to add extra effects and simulate the ink drawing. This was a blast to put these all together and I feel I've found something I'll keep doing in the next weeks and months.

The choice to use Rust was initially a personal exploration, using a language that is meant to be performant while being relatively high level and functional. It's something I did initially for plots and it helped on time-consuming algorithm. I've used it here for two reasons: first of all, most of my tooling for plotting is written in Rust, I'm very fluent it in now and I have many helpers I could reuse, secondly, there is a gain of performance. I have initially written my code in JavaScript and had some bad performance on the simple templating of the SVG code, I've estimated a gain of about x2 on the performance of using Rust. There are no super complex algorithms here, but it's still 2-3 loops with big iterations on them. The performance overall can still feel a bit slow, but you have to imagine each mod changes regenerate the SVG that can be up to 4 MB of XML.

I didn't try to enable asynchronicity or parallelism but it's something I will dig in the future when I'll do more complex work like shape packing (that can require parallelization).

This is a melting pot of technologies as I had to work on 3 aspects:
- In JavaScript is managed the logic that handles mods and block data and bakes the "parameters" of the generator.
- In Rust is implemented the generator itself, taking parameters in input and resulting SVG file.
- In WebGL/GLSL and gl-react library is implemented the simulation of ink on paper rendering.

## NFT and physical pieces?

The release of "Pattern 03" on EthBlock.art is primarily "digital" NFTs. Every BlockArt is going to be a digital NFT that includes the SVG recipe to make it physical.


**The physical collection is not meant to be 1 physical for 1 digital**. The idea is that the digital NFT remains unique but the physical art can be explored in different ways or ordered multiple times, it will not be guaranteed unique. Actually I can't prevent the plot to be done X times, like anyone can draw X times a La Joconde. However Nature have randomness and each physical plot will be unique.

**This is by design decoupled.**

- There are curators that prefer digital art, this is the BlockArt. There are curators that may be interest by the physical version.

- The "physical artist" do not necessarily need to be the same as the "digital artist". The idea here is the art goes beyond me, the digital pieces are recipes and a community of plotters could be using these digital pieces in different ways under different terms and with their own tools. This is the openness of blockchain and NFT and this is secured by the contracts and the ownership of NFTs.


**What I plan personally to do "as a physical artist"**. Now that this decoupling is explain, let me take the physical artist hat.
As physical plot have some cost, there are many ways to cover this. Indeed the simplest way is just to sell physical goods like a regular marchant.

As I said before *Nature have randomness and each physical plot will be unique.*. As a physical plot is still unique, I will emit an NFT each time I plot something.

In my case, there will be two ways of buying the physical piece:

- Either you will be able to SWAP your digital NFT against the physical NFT. And physical art will be shipped physically to where you want.
- Or you will be able to BUY it, but the price will be intentionally HIGHER than the digital NFT / will be following a bit the "floor price" of the digital NFTs of the collection.

I will also be the one to chose what I plot, I will not necessarily "plot them all" (but I can take requests) and I will not necessarily keep a 1:1 relationship as shared before. Actually, if you chose the SWAP option, I will have back the NFT digital, this is the way I get "paid" as I can then put it back on market.

I believe this ecosystem will be amazing and will allow a lot of options and freedom. I am so thrilled by the possibilities of NFT.

<img width="50%" src="/images/2021/08/artist-1.jpg" /><img width="50%" src="/images/2021/08/artist-2.jpg" />

Pattern 03 is a tribute to fountain pen plotting, generating strokes lines to yield unique patterns. It recreates the condition of ink on paper in a digital art form. The second market will be exciting as these are also physically plottable. A SVG file can be downloaded from each NFT that is the recipe for a physical artist to perform the art physically (20cm square), with their own tools.

Pattern 03, the first plottable generator on ethblock.art

<img width="400" src="/images/2021/05/relics.gif" />

# Releasing **Relics**, my first curated NFT collectible series, on Tezos blockchain and platform [_hicetnunc.xyz_](https://hic.link/greweb).

**Collection:** There are 28 curated visual loops that will be shared on the 7 days of this week. 4 NFT a day. I will use French day names as well as French seasons to name them all.

**Technical:** Relics collection are unique animation made with Perlin noise, cellular automaton and GLSL. The generator is fully open source and available on my website here: https://greweb.me/shaderday/63 as I strongly believe in open sourcing literally everything I do even as an artist. That said, I curated carefully the 28 unique NFTs myself and it's the only official collection of that generator.

> Contact me if you are the buyer to obtain the parameters of your NFT. Unfortunately it's not possible yet to "unlock" content as part of buying a NFT but I would be glad to give you the parameters of your NFT! I can also generate high resolution versions on demand (but also, the open sourced code allows it, once you have these parameters!).

_Lundi d'hiver, Lundi de printemps, Lundi d'été, Lundi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/61391"><img src="https://cloudflare-ipfs.com/ipfs/QmSbZ7iK1S2aDKtTM4HLkzjZrMCwgyDhNbqum8kQTfF44N" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61403"><img src="https://cloudflare-ipfs.com/ipfs/QmbGrg2mckEbz5u6ShuQi5SbRcUKkEiY9S8irExUiJLizS" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61410"><img src="https://cloudflare-ipfs.com/ipfs/QmZSQduPnXvmWvFo8JdC3WrxjzU9MbaKGD2JtywtWRq6C8" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61413"><img src="https://cloudflare-ipfs.com/ipfs/Qmb2qS5Vp7YPfW5KqqgEm4aFqeTaGv2RXb81j1mG9dcLqL" width="25%"/></a>

_Mardi d'hiver, Mardi de printemps, Mardi d'été, Mardi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/63131"><img src="https://cloudflare-ipfs.com/ipfs/QmQHcBZ18wYDMq2B2i7AfQFC1e5CJytgsYxYzuanJ8Zxuy" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/63126"><img src="https://cloudflare-ipfs.com/ipfs/QmZRfP9fNKWRizNzHEiB4yHFPTSAuij53XJzXdeqz2qqNu" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/62848"><img src="https://cloudflare-ipfs.com/ipfs/QmT4xPg39PyVDEYGSi1BRce62jJnt2w8SmCDxEYJaZ47cQ" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/62839"><img src="https://cloudflare-ipfs.com/ipfs/QmXrWE4csSkPXYRg3BqhFmKVCzbXGDtNLRkku6Gc2PCY2Y" width="25%"/></a>

_Mercredi d'hiver, Mercredi de printemps, Mercredi d'été, Mercredi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/64885"><img src="https://cloudflare-ipfs.com/ipfs/QmcwpMrbg3n3iNo1TgQUS5LarKwFwz6kK9wexkc38ybRgT" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64874"><img src="https://cloudflare-ipfs.com/ipfs/QmeDzVu5G1wLJxEsDXJXtdiJpMWAiRDfJnRgx16VmGH96X" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64863"><img src="https://cloudflare-ipfs.com/ipfs/QmZuJcvNG2T7sCn959CWEuHZxi1C2Nr5H5JzbV6Sp5Pz3p" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64852"><img src="https://cloudflare-ipfs.com/ipfs/Qmcomh1sD8L6wewENSWnqLT4akpRwrDpgABy8viu68b9Ua" width="25%"/></a>

_Jeudi d'hiver, Jeudi de printemps, Jeudi d'été, Jeudi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/66703"><img src="https://cloudflare-ipfs.com/ipfs/QmRe8RwPjLhatKbSMV5YGf3TDBKdB8W7xVnM8zQzNqe3dM" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66686"><img src="https://cloudflare-ipfs.com/ipfs/QmNpPhofb4eJJq7YCDpjba8t3fNFQkY8W9ryM2iSreWkwB" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66683"><img src="https://cloudflare-ipfs.com/ipfs/QmRN9L8PhKmfb4uM2LsFb2C2Gxa3YHZ7KQFZsSbSAUAMZ6" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66674"><img src="https://cloudflare-ipfs.com/ipfs/QmXh2RAdgP841oJWdyMtBSQ78XnYQwHzEkTF8qze6hnbCn" width="25%"/></a>

_Vendredi d'hiver, Vendredi de printemps, Vendredi d'été, Vendredi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/68578"><img src="https://cloudflare-ipfs.com/ipfs/QmTXdtycdrp4v6UWymCeDJCamxHqUdHdy99XfK7vmVqqtx" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68575"><img src="https://cloudflare-ipfs.com/ipfs/QmVyxcykCS8f1vpriReyedAfdP1M9wHq8pwyKtWtoUgXRb" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68572"><img src="https://cloudflare-ipfs.com/ipfs/QmY1HcgrX7S5wxaYxRoFuxUWEdG6W6gAApDpzc1oYHSUDt" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68522"><img src="https://cloudflare-ipfs.com/ipfs/QmSc8Q5ozk8nhLvzF6jry613WDhvFX6PjbqnKbyb97smhy" width="25%"/></a>

_Samedi d'hiver, Samedi de printemps, Samedi d'été, Samedi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/69282"><img src="https://cloudflare-ipfs.com/ipfs/QmasrfTskgzSj48gG62xFyWvXrJXWznyPakMB7GtYwgcY3" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69280"><img src="https://cloudflare-ipfs.com/ipfs/QmdvFEWzkbK2yPNSNURPNNJTkGf55MoDfboXboCvYwVUob" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69276"><img src="https://cloudflare-ipfs.com/ipfs/QmZhD4pwmRB43CN7hXKouGHMgCdwuFfnBweJfNBeSJeTBt" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69275"><img src="https://cloudflare-ipfs.com/ipfs/QmdgVW9CnMY1P6o41EEaiwsJMDQdgxhPzo4xmrV8YLLJ66" width="25%"/></a>

_Dimanche d'hiver, Dimanche de printemps, Dimanche d'été, Dimanche d'automne._

<a href="https://www.hicetnunc.xyz/objkt/70994"><img src="https://cloudflare-ipfs.com/ipfs/QmbTE4QGptyHGYsyemttEXSDoydapMuBiT94kooD3zLHc9" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70991"><img src="https://cloudflare-ipfs.com/ipfs/QmXMUCZmptV4MyXJ8zUMM9ZoAfmWMLCTr5toPH99YLo6LY" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70973"><img src="https://cloudflare-ipfs.com/ipfs/QmfVNN6bfzhsEK5fx45DwQTQ6hMrbASxgGzQnSgTwJEbJd" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70967"><img src="https://cloudflare-ipfs.com/ipfs/QmU1VEYV7zyyN3LhES4mgAm8qdgjgvDERDRqu7GJnKtVQL" width="25%"/></a>

_published on [hic.link/greweb](https://hic.link/greweb)_

Relics collection are unique animation made with Perlin noise, cellular automaton and GLSL.

Relics NFT collection

I am thrilled to release my first **"plot loop"** and plan to release one every week. Let me explain simply the idea:

- an animation is generated with code, (SVG plottable files)
- Each frame of this animation is plotted physically,
- photographed back into a digital picture,
- and post-processed back into a video that makes it an artistic creation by itself as well as each physical plot being one "edition" of that plot loop series.

> **You can see all my plot loops made so far at [https://greweb.me/plots/tags/plotloop](https://greweb.me/plots/tags/plotloop)**

**So there are two creations:**

- the animation is itself digital art => it is released as an NFT, with as many editions as there are frames.
- each individual frame is physical art => it can be shipped to first buyer.

### Plots and NFT ?!

**Plot loop animations will be released as [Non Fungible Token (NFT)](https://www.youtube.com/watch?v=Y-i9Jsm95ro)** on [hicetnunc](https://www.hicetnunc.xyz/). It allows anyone with Tezos crypto currency to acquire this video on Tezos blockchain. Digital collectors are collecting one edition of this NFT which adds to their collection: **The NFT video is an art in itself**. On top of this, physical collectors can also claim the shipping of the physical art of the frame corresponding to the collected NFT edition (there is as many editions as there are frames plotted).

**This is a hybrid concept between physical and digital art.** By buying a frame (by order of buy), the first buyer has the possibility to chose what happens to the physical art: either you allow me to keep it OR you can claim it (contact me on Twitter) and have me sending it anywhere in the world!

> I'm writing a bigger article about my recent NFT exploration and my art in general. I've been exploring so many ideas recently. I already sold some plots via NFTs, I am very honored to have found some buyers 😍. They can still be found at [hic.link/greweb](https://hic.link/greweb). I'm currently burning them one after the other to expire the possibility to buy them as I will focus on these new projects.

## First release, the triplanet loop

**hicetnunc NFT: [OBJKT#57902](https://www.hicetnunc.xyz/objkt/57902)**

<a href="/plots/121"><img width="50% " src="/images/plots/121.gif"/></a>

My first plot loop is called "Triplanet". It's a transition of two parametric functions with many perlin noise displacements. This is a continuation of ["Planet Holes"](/plots/100) series as well as recent ["Parametric stack"](/plots/111) explorations.
Every frame is generated with a Rust script I wrote.

**Triplanet was released in [plots#121](/plots/121).** 16 frames have been plotted with fountain pen on bristol paper (ink: Red Dragon by Diamine).

<img width="100%" src="/images/plots/121_walled.jpg"/>
<img width="50%" src="/images/plots/121_zoom.jpg"/><img width="50%" src="/images/plots/121_plot.jpg"/>

**Plotting with fountain pen is challenging** as it requires many search on the ink, paper and many fail and retry. Plotting all these frames took an afternoon.

## What's next?

I plan to release a _plot loop_ every week.

It's taking a lot of time to plot all frames so there are great challenges: first of all is to reduce the number of frames, secondly is to make them worth it, to make them really good: I want every frame to be unique, to include some specific elements, easter eggs, that make it recognizable out of the other frames.

---

# Please also check out other great artists

I believe a lot of this hybrid idea of mixing plot, animation, and NFTs. It was very funny for me to see all coïncidence and convergence of ideas on this topic. It's one of these moments when we have the same ideas at the same time. I'm not the only one exploring this and I want to do a big kudos to these great artists.

### Marion [@atelier_marion](https://twitter.com/atelier_marion/status/1388071908575490048)

who recently released a very similar idea! <del>She has 2 more frames yet to be taken!</del> Not anymore!

<a href="https://www.hicetnunc.xyz/objkt/42546"><img src="https://cloudflare-ipfs.com/ipfs/QmXcAWQTaGHQp4BGy1krER284PoaPCNhKYzDrxp86MaM7b" style="max-width: 300px"></a>

She is also creating impressive drawing work as seen on her website: https://www.marionguy.com/shop

### Maks Surguy [@msurguy](https://twitter.com/msurguy)

who is behind [plotterfiles.com](https://plotterfiles.com/) platform. He also does a lot of great plotting art and thought about similar concept recently! [Checkout this article about his work.](https://medium.com/poptwig/artist-in-focus-maks-surguy-26277c95b197)

### Thomas Lin Pedersen [@thomasp85](https://twitter.com/thomasp85)

who is doing a [stuning work](https://www.hicetnunc.xyz/tz/tz2Pkj2xWJovKKCsABjnr3NbyMVJTMBkpTvb) and very impressive landscapes. Also selling NFT for shipping physical print.

He recently did a very cool NFT in collaboration with **Lionel Radisson** [@MAKIO135](https://twitter.com/MAKIO135):

<a href="https://www.hicetnunc.xyz/objkt/53662"><video style="max-width: 300px" controls autoplay loop src="https://ipfs.io/ipfs/QmaGfhSgWX1UTq6jPX11mfHDxccK5eXGYqi6u71zNLaBhY"/></a>

### ...so many other artists!

Let's chat! You can join us on [hicetnunc's discord](https://discord.gg/jKNy6PynPK) on channel #phygital-objkts which explore very similar idea and where other artists will be active!

I'm also available for collaboration.

Releasing my first 'plot loop', generative animation plotted and published as an NFT.

'Plot loops' concept

[main]: /2021/04/cryptoaliens

> See also [CryptoAliens: Genesis][main] main article.

This article explains how [CryptoAliens: Genesis (ethblock.art)][main] works in technical depth.

<img src="/images/posts/cryptoaliens/032_px.png" width="50%" /><img src="/images/posts/cryptoaliens/036_px.png" width="50%" />

First of all, I would like to point out the [source code is available here on Github](https://github.com/gre/gre/tree/master/blockarts/CryptoAliens).

This whole idea was kicked off on [Twitch](https://twitch.tv/greweb). A recording is [available on Youtube](https://www.youtube.com/watch?v=WUzOlLq0IAo). Apart from the many glitches this 3 hours session had remained to be solved, the main part of this was implemented that night. Indeed I had to work countlessly on polishing the shaders, lighting and post-processing. I also spent a lot of time using the block data in a meaningful way because it's what [EthBlock.art](https://ethblock.art) really is about.

## EthBlock.art revolutionary idea

Before going further into the technical details of CryptoAliens, I would like to point out how revolutionary this EthBlock.art idea is.

The project aims to create a virtuous ecosystem of "deterministic art", code visualization of Ethereum blocks. Everything is data: from the ethereum block of transactions, to the code that visualize it, and to the NFTs minted/traded using Ethereum transactions (that themselves are into Ethereum blocks).

**This is a virtuous ecosystem, similar to [Supply Chain Transformation concepts](https://en.wikipedia.org/wiki/Value_chain): each actor in this ecosystem add value and get retributed for it, as I tried to explain in this schema:**

![](/images/posts/cryptoaliens/ethblockart.png)

`CryptoAliens: Genesis` is one possible BlockStyle that I've designed, as a creative coder. It tries to visualize what happened in the Ethereum Block and will take mods into account to try to be as good as possible to deliver interesting possibilities to BlockArt minters.

## Ok, so how is it implemented technically?

Indeed WebGL.

More precisely, it is implemented with [`gl-react`](https://github.com/gre/gl-react) which is convenient to write and compose [_GLSL Fragment Shaders_](https://www.khronos.org/opengl/wiki/Fragment_Shader).

**here is the big picture of the pipeline:**

<video src="/images/posts/cryptoaliens/graph.mp4" width="100%" controls autoplay muted loop></video>

There are 2 main shaders: Mandelglitch (for skin texturing) and Scene (the main raymarching shader). Each of them take a bunch of parameters. `mod1..4` are values from the creator. The rest are inferred from the Block information, they are split into multiple parameters for convenience.

The parameters `s1..9` are coming directly from `mersenne-twister` library, a [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) used to get a wide and deterministic variety of shapes, initialized with the block hash. That said, as pointed in the previous section, the main features of the shape are determined by Ethereum block information itself (number of transactions, timestamp, transfers, gas used,...).

On top of these, some other parameters are controling key elements they come from more block information (heavy, head, bonesK, arms info,...).

The technique implemented on the main Scene shader is [raymarching distance functions](https://www.iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm). The shapes at stake are mostly segments that are merged with a smooth union. There are many loops involved which made it challenging to optimize.
There may be issues on some mobile phone even tho it works on mine thanks to a "pixelated" version. (downscaling the pixels helped)

Because of an heavy usage of this technique, the main scene was really challenging to optimize, it actually runs something like 5 FPS. My choice was to not animate it directly (you can see on the rendering graph that actually the buffer don't need to refresh, except when a "mod" is changed). However, thanks to intermediary framebuffers we can do 60 FPS animation at the postprocessing level. This is what the final user will get as the mods are static.

### Canvas 2D to draw texts

A Canvas 2D element is used to draw the text that will appear on top of everything.

```js
/// canvas used to draw in postprocessing ///
function FrameText({ blockNumber, dateText, width, height, kg, bones }) {
 const onCanvasRef = (canvas) => {
 if (!canvas) return;
 const ctx = canvas.getContext("2d");
 const w = ctx.canvas.width;
 const h = ctx.canvas.height;
 const pad = Math.round(w * 0.01);
 const padX = Math.round(w * 0.02);
 const fontS = Math.floor(0.19 * w) / 10;
 const fontSize = `${fontS}px`;
 ctx.save();
 ctx.fillStyle = "#000";
 ctx.fillRect(0, 0, w, h);
 ctx.font = "bold " + fontSize + " monospace";
 ctx.textBaseline = "top";
 ctx.fillStyle = "#fff";
 ctx.fillText(`CryptoAliens specimen #${blockNumber}`, padX, pad);
 ctx.textBaseline = "bottom";
 ctx.textAlign = "right";
 ctx.font = fontSize + " monospace";
 ctx.fillText(
 `born ${dateText}, ${kg} kg, ${bones} bones`,
 w - padX,
 h - pad
 );
 ctx.restore();
 };
 return (
 <canvas
 ref={onCanvasRef}
 width={String(width * 2)}
 height={String(height * 2)}
 />
 );
}
const FrameTextCached = React.memo(FrameText);
```

### How is Mandelglitch used?

As said, [Mandelglitch BlockStyle](https://ethblock.art/create/17) is re-used in this CryptoAliens BlockStyle. This really is the power of gl-react: it makes such composability really easy to do, the same way you can compose React components.

You can see in the [Youtube recording](https://www.youtube.com/watch?v=WUzOlLq0IAo) the way I have implemented it initially: it is just a simple import of Mandelglitch.js (literally the BlockStyle as-is) that I can just send as a uniform sampler2D.

```
<Node
 shader={sceneShaders.scene}
 uniforms={{
 t: <Mandelglitch block={block} mod1={mod1} mod2={mod2} mod3={mod3} />,
 ...
```

after that, it was simpler to embed Mandelglitch in the BlockStyle.

The way Mandelglitch texturing is used however is that I will only use the "red" component and remap it to CryptoAliens' own palette, in order to have a better control of the coloring.

### Code organisation

React and Gl-React allows to organize the code relatively easily. First of all each pass in the rendering scene is a component, then shaders are organized in the `Shaders.create` usage. I've tried to collocate them (still in same one big file to simplify the upload to EthBlock.art).

I find it pretty convenient to externalize piece of the logic into "hooks" function. Example:

```js
const CustomStyle = (props) => {
 // prettier-ignore
 const { block, attributesRef, mod1, mod2, mod3, mod4, highQuality, width, height } = props;
 // prettier-ignore
 const { kg, bones, theme, background, s1, s2, s3, s4, s5, s6, s7, s8, heavy, head, bonesK, armsLen, armsSpread, armsCenter, armsEndW, dateText, blockNumber } =
 useBlockDerivedData(block, mod1, mod2, mod3, mod4);

 useAttributesSync(attributesRef, kg, bones, theme);

 return (
 <LiveTV
 text={
 <FrameTextCached ... />
 }
 ...
 >
 <NearestCopy width={w} height={h}>
 <Scene
 t={<MandelglitchCached ... />}
 ...
 />
 </NearestCopy>
 </LiveTV>
 );
};
```

`useBlockDerivedData` internally uses `useMemo` in order to cache the computation of block data interpretation.

In order to make **only** one part of the tree to actively re-render, i've used a local `useTime` that would re-render only that part (the LiveTV final shader). It's implementation is trivial:

```js
function useTime() {
 const [time, setTime] = useState(0);
 useEffect(() => {
 let startT;
 let h;
 function loop(t) {
 h = requestAnimationFrame(loop);
 if (!startT) startT = t;
 setTime((t - startT) / 1000);
 }
 h = requestAnimationFrame(loop);
 return () => cancelAnimationFrame(h);
 }, []);
 return time;
}
```

## Arms joints rotation, GLSL random and determinism

Ok, this is a hard topic. But it's extremely important that every BlockArt reliably produce the same result with the same block data, regardless of the computer used.

That last "regardless of computer used" part has challenged me at the last minute! JavaScript doesn't have this problem because it's stable between implementations (computers, engines). However, **this is not the case with OpenGL / GLSL**: every computer, every hardware (GPU) or possibly the "backend" implementation for WebGL ([ANGLE](https://github.com/google/angle) have different backends) can differ when it comes to float precision and primitive results.

In my shader, I was using the classical `random` function that is documented at https://thebookofshaders.com/10/

```cpp
float random (vec2 st) {
 return fract(sin(dot(st.xy, vec2(12.9898,78.233))) * 43758.5453123);
}
```

It works very well when you need a nice 2D distributed noise for basic effects **but it is very bad if you strongly rely on a stable & consistent noise to generate different shapes**.

Empirically, I can observe that `sin()` yields different results on different computers.

This was impacting me badly because I was able to see very various shapes:

<img src="/images/posts/cryptoaliens/rand1.png" width="33%"/><img src="/images/posts/cryptoaliens/rand2.png" width="33%"/><img src="/images/posts/cryptoaliens/rand3.png" width="33%"/>

What I need to varies a bit here is just the angle at each joint of the arms. This is very important for the uniqueness of the creature. The problem is that if each value changes a tiny bit, the whole thing diverge VERY QUICKLY, as the rotation angle will accumulate.

Worse than that, I had a bad pattern to accumulate randomness like this:

```cpp
float ss1 = s1;
for (int i = 0; i < armsLen; i++) {
 ss1 = random(ss1);
 ...
}
```

Actually I don't need that, first of all it's probably not good for performance, secondly I can just afford taking the fractional part of a simple polynomial:

```cpp
float arm (inout vec3 p, float index, float w, float h) {
 float s = sdSegment(p, h, w);
 float base1 = 305.53 * s1 + 77.21 * index;
 float base2 = 403.53 * s2 + 69.71 * index;
 for (int i = 0; i < armsLen; i++) {
 float fi = float(i);
 float ss1 = fract(base1 + 9.412 * fi);
 float ss2 = fract(base2 + 8.823 * fi);
 pR(p.xy, 8. * s4 * (ss2-.5));
 pR(p.xz, 6. * s5 * (ss1-.5));
 s = fOpUnionSoft(bonesK, s, sdSegment(p, h, w));
 h *= .9;
 w *= .9;
 p.y -= 1.2 * h;
 }
 s = fOpUnionSoft(bonesK + 0.2 * s5, s, length(p) - armsEndW);
 return s;
}
```

Note that here it's very arbitrary numbers, the point is to obtain variety and unpredictability in the results. `fract` is a very simple operation (take the fractional part of the number). Indeed i'm still prone to approximation, but the risk is limited by the fact i don't go too high in values here. Worse case scenario is it varies a bit the rotation but it should be so tiny that it won't be visible.

As said before and as seen in this code, the number will be used to do rotations (that `pR` is transforming `p` with some rotations). I use `s4` and `s5` values to give the magnitude of rotations.

**Let's look at a few cases:**

If both s4 and s5 are very near 0.0, it will be straight arms (it's a rare case therefore).

<img src="/images/posts/cryptoaliens/042_px.png" width="50%"/><img src="/images/posts/cryptoaliens/033_px.png" width="50%"/>

If one of the s4 or s5 are 0.0, it will be only happening on one "plan", or slightly diverging spirals, which I assume also to be rare cases:

<img src="/images/posts/cryptoaliens/017_px.png" width="50%"/><img src="/images/posts/cryptoaliens/020_px.png" width="50%"/>

Otherwise, most of the times, it will be relatively random:

<img src="/images/posts/cryptoaliens/029_px.png" width="50%"/><img src="/images/posts/cryptoaliens/032_px.png" width="50%"/>
<img src="/images/posts/cryptoaliens/028_px.png" width="50%"/><img src="/images/posts/cryptoaliens/026_px.png" width="50%"/>

## going 128px. Last minute decision, hard tradeoff

Due to concerns on the "deterministic rendering" from Ethblock.art folks, I had to make a choice regarding the fact it was too slow on mobile... I've decided to switch to 128x128 rendering for ALL platforms so it's consistent.

All the images on that article were done on 1024x1024 which is slow on computer and not even working on my mobile phone. (OnePlus)

It's hard to have efficient raymarching today when you have many items.

**Ultimately, I like how it finally looks, there were some minimalism / cell shaded styles,.. now it embraces Pixel Art even more!**

<img src="/images/posts/cryptoaliens/r02.png" width="50%" /><img src="/images/posts/cryptoaliens/r01.png" width="50%" />

It's also always possible to make higher quality version of these rendering and I'm excited to experiment more of these in future.

---

My name is Gaëtan Renaudeau, and I'm a noise explorer. **feel free to ping me on Twitter [@greweb](https://twitter.com/greweb)**

Technical aspects of CryptoAliens digital creatures generated with Ethereum blockchain blocks. They can be minted on ethblock.at by anyone, which establishes a limited set of CryptoAliens species.

CryptoAliens: Genesis, a technical look

[create]: https://ethblock.art/create/24
[opensea]: https://opensea.io
[tech]: /2021/04/cryptoaliens-tech

> See also [CryptoAliens: Genesis, a technical look][tech].

<img src="/images/posts/cryptoaliens/021_px.png" width="50%" /><img src="/images/posts/cryptoaliens/001_px.png" width="50%" />

> CryptoAliens: Genesis establishes the first embryonic species. Which CryptoAliens are you going to chose? Each creature gets born on an Ethereum block that nourishes its shape: transactions, ETH value transferred, gas,... their unique skin comes from Mandelglitch's BlockStyle with the same rarity scheme.

## What are CryptoAliens?

CryptoAliens are digital creatures generated from Ethereum blockchain blocks. They can be minted on [ethblock.art][create] by anyone, to establishes a limited set of CryptoAliens species in a decentralized matter. Each block produced on Ethereum have unique elements that can be visualized in creative ways.

<img src="/images/posts/cryptoaliens/014_px.png" width="50%" /><img src="/images/posts/cryptoaliens/017_px.png" width="50%" />

> **CryptoAliens are born and nourished from transactions, transactions are bones, ETH is flesh,... and many other aspects that this article will explain!**

<img src="/images/posts/cryptoaliens/032_px.png" width="50%" /><img src="/images/posts/cryptoaliens/013_px.png" width="50%" />

### So I decide which ones are the CryptoAliens?

**Yes! As a NFT minter, you are the creator and you contribute at establishing the first 'Genesis' series of CryptoAliens.** You decide which creature deserve to live. You are the curator and it is your responsible to do a lot of research and find the most adorable (or the creepiest?) creature!

<img src="/images/posts/cryptoaliens/036_px.png" width="50%" /><img src="/images/posts/cryptoaliens/004_px.png" width="50%" />

### How many CryptoAliens are there?

Every single CryptoAliens species is unique and there are currently 12 millions because that's as many blocks there are today (April 2021). Every 15 seconds, a new block is minted on Ethereum blockchain (with usually hundreds of transactions in it) making a new CryptoAliens possibility.
The block is the DNA, but the creature only starts existing when minted!

**TLDR. CryptoAliens only comes to life when someone mint it as an NFT on the [ethblock.art][create] contract.** They can then be sold and traded on [opensea.io][opensea]. There is **a limited amount of CryptoAliens possible to mint** so be wise at your choice. In this 'Genesis' series, the current supply is set to 100!

<img src="/images/posts/cryptoaliens/002_px.png" width="50%" /><img src="/images/posts/cryptoaliens/003_px.png" width="50%" />

### What is 'Genesis' series about?

The idea of 'Genesis' is that we are collectively going to create the initial species of this universe (with the NFT we chose to mint).

Minting a _CryptoAliens: Genesis_ specimen is giving birth to the creature, therefore the current NFT is visualized on [ethblock.art][create] as a video tape recording of that time of birth (with the block number, time, weight and number of bones). These data are included in the NFT itself and could be reused in future!

## What determines how a CryptoAliens specimen looks like?

There are many information contains in Ethereum blocks that will get used to determine the general shape and gives its rarity.

### Block's timestamp

<img src="/images/posts/cryptoaliens/040_px.png" width="50%" /><img src="/images/posts/cryptoaliens/041_px.png" width="50%" />

When the block happened during UTC night, the visual will be in dark mode.

### Block's transactions amount

<img src="/images/posts/cryptoaliens/007_px.png" width="50%" /><img src="/images/posts/cryptoaliens/008_px.png" width="50%" />

When a block contains a lot of transactions it will impact its general weight. It will be highlighted by this very heavy blobs shapes. That said, the weight can be more or less dense based on amount of bones and also unique for each CryptoAliens specimen.

### Block's heavy transfers in ETH

<img src="/images/posts/cryptoaliens/035_px.png" width="50%" /><img src="/images/posts/cryptoaliens/020_px.png" width="50%" />

As said in the introduction, "ETH is flesh". Even tho most of the time it will impact the general weight of the creature, when a block contains an expectionally high transfer of Ethereum value, it will be highlighted by a big "head" on the creature. ("head" in doublequote because none of our scientist really figured what is this)

### Block's exceptionally low amount of ETH transferred

<img src="/images/posts/cryptoaliens/005_px.png" width="50%" /><img src="/images/posts/cryptoaliens/006_px.png" width="50%" />

On the contrary, when a block contains almost no ETH transfers, the arms will be very thin. Clearly ETH traders didn't nourish enough this poor creature.

### Block's important ratio of gas used (vs ETH value transfer)

<img src="/images/posts/cryptoaliens/023_px.png" width="50%" /><img src="/images/posts/cryptoaliens/016_px.png" width="50%" />

It often appears in combination with the previous criteria, if the ratio `total gas / total eth transfers` is high, meaning that a lot of the ETH is into gas, there will be some blobs at the end of the arms.

### ...and more block rare features

There are a lot of special cases are rare conditions that can happen. I will not disclose and I will let you discover. Some are really rare and some will be discovered in the future (even the author of blockstyle won't be aware of all cases!).

### Block's hash

Finally, the block hash gives variety in the results. It's necessary in order to have truly unique 12 millions species. But it's only complementary to the various other criteria. There are many features that are getting impacted by it, including the skin texturing (see _Mandelglitch BlockStyle_ section).

<img src="/images/posts/cryptoaliens/043_px.png" width="50%" /><img src="/images/posts/cryptoaliens/042_px.png" width="50%" />
<img src="/images/posts/cryptoaliens/012_px.png" width="50%" /><img src="/images/posts/cryptoaliens/038_px.png" width="50%" />

### What controls does the creator have?

At creation time, the minter also have the ability to move a bit the specimen:

- `mod1` is a simple rotation around it.
- `mod2` is a simple climbing and zooming.
- `mod3` will flex a bit the shape to make it torn & twist a bit.
- `mod4` have an impact on the color palette scaling.

**On top of this, mods have the ability to transform the skin texturing** which is actually based on [Mandelglitch BlockStyle](https://ethblock.art/create/17)! That means the rarity elements of Mandelglitch are shared in this new BlockStyle.

### mmh, Mandelglitch BlockStyle?

<a href="https://ethblock.art/create/17"><img src="/images/posts/cryptoaliens/mandelglitch.png" width="10%" /></a> **[Mandelglitch](https://ethblock.art/create/17) is a BlockStyle on [ethblock.art](https://ethblock.art/create/17), derived from Mandelbrot fractal.**

The visibility of Mandelglitch on the skin has been intentionally contained, but sometimes it is more visible. Here are two examples:

<img src="/images/posts/cryptoaliens/031_px.png" width="50%" /><img src="/images/posts/cryptoaliens/022_px.png" width="50%" />

## ...and, What's next?

Who knows what's next! As everything is available on the blockchain, what you mint is saved immutably and forever. Me or other artists could fork the code ([available on Github](https://github.com/gre/gre/tree/master/blockarts/CryptoAliens)) to make animated version of the CryptoAliens that were chosen (as this code is open source). Also we can imagine doing crossover between species or doing "evolution" of these species over time. Everything is possible!

---

See also [CryptoAliens: Genesis, a technical look][tech].

My name is Gaëtan Renaudeau, and I'm a noise explorer. **feel free to ping me on Twitter [@greweb](https://twitter.com/greweb)**

CryptoAliens are digital creatures generated from Ethereum blockchain blocks. They can be minted on ethblock.at by anyone, which establishes a limited set of CryptoAliens species. Each block produced on Ethereum have unique elements that can be visualized in creative ways.

CryptoAliens: Genesis [ethblock.art]

[cookbook]: https://gl-react-cookbook.surge.sh
[github]: https://github.com/gre/gl-react
[jest]: https://github.com/facebook/jest
[headless-gl]: https://github.com/stackgl/headless-gl
[bus]: https://gl-react-cookbook.surge.sh/api#bus

# Happy to release **[https://gl-react-cookbook.surge.sh][cookbook]** containing 43 unique examples and API documentation!

<video src="/images/2016/12/gl-react-v3.mp4" width="100%" controls autoplay muted loop></video>

> If you don't want to be "spoiled" by this article, go through [the cookbook examples][cookbook]. This article will explore some of them.



## gl-react has been rewritten from scratch

**gl-react v3 is a complete rewrite of the v2 implementation for better performance and compatibility with React paradigm.**

This is not yet published on NPM as it's [still in development][github] (the Web version is pretty ready, React Native version is not implemented).

Most features provided by gl-react v2 are preserved (API haven't changed, [see how similar is the HelloGL example](https://gl-react-cookbook.surge.sh/hellogl)), but v3 fixes most Github issues accumulated for a year.

### The biggest mistake of the previous implementation

If there is one lesson learned from previous gl-react implementation: **"unfolding" / consuming the `children` prop by yourself is (probably) wrong, let React solve this job!** Using React, you can benefit [React reconciliation and diff algorithm](https://facebook.github.io/react/docs/reconciliation.html).
In other words, always prefer to keep users' VDOM tree rather than consuming it with `React.Children.*` functions.

I feel dumb not having discovered this before, but if you are not actually rendering DOM it's an easy path for a library to just map, traverse, consume the children tree and just render what you needs (like just a `<canvas/>`). But this is probably a mistake! First, this makes it impossible to use React Devtools and see the original tree, but more importantly, it breaks interoperability with other libraries (e.g. don't forbid someone to use [react-motion](https://github.com/chenglou/react-motion) or [React Router](https://github.com/ReactTraining/react-router) in the middle of your components!).

A better idea is to preserve the user `children`. Keep your logic in each Component and use the React lifecycle to create and destroy things, and **use [React context](https://facebook.github.io/react/docs/context.html) to connect children to parent**.

> You should better keep user `children`, even if it means rendering it in an empty ``, _current workaround of `gl-react`, looking forward to hearing from you, idea inspired from the great [react-music](https://github.com/FormidableLabs/react-music)_

### What it means for gl-react

The gl-react v3 implementation truly uses React lifecycle: **a React Component update triggers a GL redraw**. That way, `shouldComponentUpdate` allows to do partial GL re-rendering. Each Node holds a [framebuffer object](https://www.opengl.org/wiki/Framebuffer_Object) (created on mount, destroyed on unmount) that only get redrawn when component updates and schedules a Surface reflow.

`<Node>` receives the `gl: WebGLRenderingContext` from the ancestor `<Surface>` thanks to [React context](https://facebook.github.io/react/docs/context.html). There is also a `glParent` context (a Surface or another Node) that is used to make GL components discoverable each other so we can build a dependency graph. This dependency graph allows to implement the correct `draw` pipeline (and it's pretty trivial, see [_Section "under the hood of Surface and Node redraw"_](#under_the_hook_redraw)).

## `<Bus>`, a better way to share computation

[gl-react used to automatically factorize the duplicates elements of the GL tree](http://greweb.me/2016/06/glreactconf/) but **it has been decided to remove this feature**: _This was actually a complex mechanism (a bit too "magic"), hard to implement and a premature optimization that can have slower performance._

The new gl-react embraces the React paradigm: The new way to express a Graph (and share computation) is **using a [`<Bus>`][bus]**...

### The `` `()=>ref` `` pattern

The problem we want to solve is to **express a graph with React**, which, at first glance, only allow to represent trees, not graphs!

The way we can solve this is by using refs and a "ref getter function":

1. **a Bus with a ref:** `<Bus ref="myBus">{content to inject}</Bus>`.
2. **pass a function that resolves the ref** to pipe Bus into another Node. e.g: `()=>this.refs.myBus`.

[blurmapdyn example](https://gl-react-cookbook.surge.sh/blurmapdyn)

<video loop autoplay controls src="/images/2016/12/blurmapdyn.mp4" width="100%"></video>

a single ConicalGradient should be used for all blur pass:
![](/images/2016/12/blurmapdynschema.png)

There are a few other good examples of ref usages:

- [blurmapmouse](https://gl-react-cookbook.surge.sh/blurmapmouse)
- [blurimgtitle](https://gl-react-cookbook.surge.sh/blurimgtitle) (same example that was features in 2016 React conf!)
- [behindasteroids](https://gl-react-cookbook.surge.sh/behindasteroids), crazy port of a game I made for js13k.

> The `()=>ref` pattern works only if you call the function after component did update (refs are set at this time).

## The good ol' children function

There is another pattern for more specific needs: instead of composing by giving an element, you can also compose by giving a **Function that returns an element**. Why that? Because, it's a way to nicely give you the redraw function: `redraw => <Video onFrame={redraw} />`:

[Checkout video example ![](/images/2016/12/videoredraw.png)](https://gl-react-cookbook.surge.sh/video?menu=true)

> We really just want to redraw if there is a new video frame.

We have merged the 2 patterns into one: if you provide a function, it's just called with `redraw`, and the returned value is used as a texture. We have a few cases to detect what kind of texture it is (and also an [extensible mechanism](https://gl-react-cookbook.surge.sh/api#textureloaders) used by implementations to load platform specific objects).
[(checkout this if you want to see the code)](https://github.com/gre/gl-react/blob/a33e6aa685479d588646b20dd62e1e25a64a5a47/packages/gl-react/src/Node.js#L704-L783)

## Node backbuffering & Backbuffer symbol

A new feature allows to inject the previous Node state as a texture. This is called backbuffering. One simple usecase is to implement Motion Blur persistence (like the GIF on top of this article).

We can also accumulate a state, for instance, to implement Game of Life!

[Game of life glider example ![](/images/2016/12/gol.gif)](https://gl-react-cookbook.surge.sh/golglider)

And the whole idea of gl-react (and React) is about composition. For instance, doing a rotating effect of that Game of Life is basically just `<Rotate> <GameOfLife /> </Rotate>`.

An interesting part is that you can update the GameOfLife at a rate that is independent from the **Rotate** rendering: just by making GameOfLife a pure component that receives a tick, or implementing shouldComponentUpdate update (you have as many choices as React have to [shortcut the rendering](https://facebook.github.io/react/docs/react-api.html#react.purecomponent)).

[golrotscu example![](/images/2016/12/golrot.gif)](https://gl-react-cookbook.surge.sh/golrotscu)

> See the counters that indicate the number of redraw. (the capture preview in the Box only get snapshot each 100ms, but in the real canvas, it runs at 60 FPS)

Finally, please checkout [ibex example](https://gl-react-cookbook.surge.sh/ibex) (extracted from another JS13K game! xD).

> You can't leave this article before seeing [ibex example](https://gl-react-cookbook.surge.sh/ibex)! I'm serious, this is probably the most accomplished code I ever wrote! xD

## <a name="under_the_hook_redraw"></a> under the hood of Surface and Node redraw

In order to make redraw efficient, `gl-react` have 2 phases: the `redraw()` phase and the `flush()` phase (reflecting the respective methods available both on `Surface` and `Node`). This is a bit like a rendering engine:

- **`redraw()` phase** sets a dirty flag to a Node and all its "dependents" (other nodes, buses, surface). _redraws happen generally bottom-up to the Surface._
- **`flush()` phase** draws all nodes that have the redraw flag. _draws happens top-down from the Surface._

`redraw()` is directly hooked to React update lifecycle (re-rendering a Node will calls `redraw()` for you).
To make this system efficient, **the flush() is by default asynchronous**, i.e. `redraw()` means scheduling a new gl draw.
Surface have a main loop that runs at 60 fps and call `flush()`. This is very efficient because if Surface does not have the redraw flag, `flush()` does nothing.

> In gl-react inspector, clicking on the redraw count will call `redraw()` on the node / bus. We can illustrate that only "dependents" get redrawn using the advanced [blurimgtitle example](https://gl-react-cookbook.surge.sh/blurimgtitle):

[only "dependents" get redrawn](https://gl-react-cookbook.surge.sh/blurimgtitle)

<video loop autoplay controls src="/images/2016/12/blurimgtitle-redraw.mp4" width="100%"></video>

This redraw/flush phases allow to prevent and skip rendering multiple times a Node. In some cases, we still want to redraw synchronously: with `<Node/>` `sync` prop. For instance, in Game of Life, we don't want to skip an update (the initial update set the initial GoL state, if it was async it might get skipped).

## Bonus

### Flow types

Flow types has been used for more robust code and better user experience. BTW, [WebGLRenderingContext will soon be released in flow](https://github.com/facebook/flow/pull/2764).

### Atom highlighting

If you are using Atom Editor, you can have JS inlined GLSL syntax highlighted.

![](https://cloud.githubusercontent.com/assets/211411/20623048/0527cce2-b306-11e6-85ee-5020be994c10.png)

_To configure this:_

- add `language-babel` package.
- Configure `language-babel` to add `GLSL:source.glsl` in settings "_JavaScript Tagged Template Literal Grammar Extensions_".
- (Bonus) Add this CSS to your _Atom > Stylesheet_:

```css
/* language-babel blocks */
atom-text-editor::shadow .line .ttl-grammar {
 /* NB: designed for dark theme. can be customized */
 background-color: rgba(0, 0, 0, 0.3);
}
atom-text-editor::shadow .line .ttl-grammar:first-child:last-child {
 display: block; /* force background to take full width only if ttl-grammar is alone in the line. */
}
```

### Tests: almost 100% coverage!

The library is tested directly on the command line, thanks to [Jest][jest] and [headless-gl][headless-gl] _(Big up to [mikolalysenko](https://github.com/mikolalysenko) for [headless-gl][headless-gl]!)_.
**gl-react have 2000 line of tests, involving a lot of gl calls, and readPixels, and it runs... in a few seconds!** _(to Jest devs: you are wizards!)_

```

 PASS ./all.test.js
 ✓ renders a red shader (75ms)
 ✓ renders HelloGL (15ms)
 ✓ ndarray texture (27ms)
 ✓ renders a color uniform (18ms)
 ✓ composes color uniform with LinearCopy (21ms)
 ✓ no needs to flush if use of sync (24ms)
 ✓ Node can have a different size and be scaled up (18ms)
 ✓ Surface can be resized (32ms)
 ✓ bus uniform code style (17ms)
 ✓ bus example 1 (17ms)
 ✓ bus example 2 (18ms)
 ✓ bus example 3 (17ms)
 ✓ bus example 4 (22ms)
 ✓ bus example 5 (14ms)
 ✓ bus example 6 (24ms)
 ✓ bus: same texture used in multiple sampler2D is fine (14ms)
 ✓ a surface can be captured and resized (16ms)
 ✓ a node can be captured and resized (17ms)
 ✓ Uniform children redraw=>el function (22ms)
 ✓ Bus redraw=>el function (16ms)
 ✓ many Surface updates don't result of many redraws (18ms)
 ✓ many Surface flush() don't result of extra redraws (10ms)
 ✓ GL Components that implement shouldComponentUpdate shortcut Surface redraws (27ms)
 ✓ nested GL Component update will re-draw the Surface (24ms)
 ✓ Node `clear` and discard; (24ms)
 ✓ Node `backbuffering` (32ms)
 ✓ Node `backbuffering` in `sync` (36ms)
 ✓ texture can be null (12ms)
 ✓ array of textures (22ms)
 ✓ Node uniformsOptions texture interpolation (17ms)
 ✓ can be extended with addTextureLoaderClass (70ms)
 ✓ Surface `preload` prevent to draw anything (59ms)
 ✓ Surface `preload` that fails will trigger onLoadError (59ms)
 ✓ renders a shader inline in the Node (15ms)
 ✓ testing connectSize() feature (17ms)
 ✓ handle context lost nicely (43ms)
 ✓ Bus#uniform and Bus#index (25ms)
 ✓ VisitorLogger + bunch of funky extreme tests (140ms)

-------------------------------|----------|----------|----------|----------|----------------|
File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines |
-------------------------------|----------|----------|----------|----------|----------------|
All files | 97.85 | 88.8 | 95.96 | 99.35 | |
 src | 97.82 | 88.95 | 95.9 | 99.35 | |
 Backbuffer.js | 100 | 100 | 100 | 100 | |
 Bus.js | 96.15 | 74.29 | 100 | 100 | |
 GLSL.js | 100 | 50 | 100 | 100 | |
 LinearCopy.js | 100 | 100 | 100 | 100 | |
 NearestCopy.js | 100 | 100 | 100 | 100 | |
 Node.js | 97.65 | 92.71 | 97.01 | 99.01 | 214,216,358 |
 Shaders.js | 100 | 76.92 | 100 | 100 | |
 Texture2DLoader.js | 100 | 100 | 100 | 100 | |
 TextureLoader.js | 100 | 100 | 100 | 100 | |
 TextureLoaderNDArray.js | 100 | 100 | 100 | 100 | |
 TextureLoaders.js | 100 | 100 | 100 | 100 | |
 Visitor.js | 100 | 100 | 75 | 100 | |
 VisitorLogger.js | 100 | 92.59 | 100 | 100 | |
 Visitors.js | 100 | 100 | 100 | 100 | |
 connectSize.js | 100 | 85.71 | 100 | 100 | |
 copyShader.js | 100 | 100 | 100 | 100 | |
 createSurface.js | 97.09 | 83.61 | 94.55 | 99.32 | 361 |
 genId.js | 100 | 100 | 100 | 100 | |
 index.js | 100 | 100 | 100 | 100 | |
 src/helpers | 100 | 75 | 100 | 100 | |
 disposable.js | 100 | 50 | 100 | 100 | |
 invariantNoDependentsLoop.js | 100 | 100 | 100 | 100 | |
-------------------------------|----------|----------|----------|----------|----------------|
Test Suites: 1 passed, 1 total
Tests: 38 passed, 38 total
Snapshots: 4 passed, 4 total
Time: 2.655s
Ran all test suites.
```

One limitation is that all tests need to be in a single file. [I created an issue here](https://github.com/facebook/jest/issues/2029). I think it's either an issue in [Jest][jest] or in [headless-gl][headless-gl].

## Tradeoffs and remaining work

The library tradeoffs are written in [TRADEOFFS.md](https://github.com/gre/gl-react/blob/master/TRADEOFFS.md). We might cover some unexplored direction in a near future and solve some of them.

v3 is still in development, the main unfinished part is the React Native implementation which is now the main priority of the library.
It will probably rely on an awesome initiative: a React Native WebGL implementation started in Exponent by [@nikki](https://github.com/nikki93)!

For more information, see [v3 alpha: development in progress](https://github.com/gre/gl-react#v3-alpha-development-in-progress).

gl-react has been reimplemented from scratch, feedback from previous mistake and overview of new features.

gl-react v3

[Relay]: https://github.com/facebook/relay
[Relay-spec]: https://facebook.github.io/relay/docs/graphql-relay-specification.html#content


[Relay][Relay] doesn't solve for you how you should render your components. Relay is "universal" and doesn't even assume it will be running in a browser context. It focuses only on providing an abstraction to work with GraphQL – the same way React focuses only on rendering. Each library solves one single problem at a time *(and hell, both are complex enough problem to solve already)*.

Because these libraries are very generic, it's now up to the community to solve the "more specific" parts. Just search on NPM and you can find tons of React libraries already, some might help you to solve part of the problem you want to solve.

This article demonstrates one use-case: **implementing a component handling the scroll of a list to pull more data** of a GraphQL connection with Relay.



## Usage

In React you should think in term of components that subdivide individual task to solve. To solve scrolling a connection you should just need this:

```js
<InfiniteScrollable relay={relay}>
 ...
</InfiniteScrollable>
```

Here is a real use-case we have at [projectseptember](https://projectseptember.com).


```js
import React, {
 Component,
 PropTypes,
} from "react";
import Relay from "react-relay";
import List from "material-ui/List";
import Content from "./Content";

class ContentStream extends Component {
 static propTypes = {
 relay: PropTypes.object.isRequired,
 user: PropTypes.object,
 };
 render () {
 const { user, relay } = this.props;
 return (
 <InfiniteScrollable relay={relay}>
 <List>
 {user.stream.edges.map(e =>
 <Content content={e.node} key={e.cursor} />
 )}
 </List>
 </InfiniteScrollable>
 );
 }
}

export default Relay.createContainer(ContentStream, {
 initialVariables: {
 first: 50,
 },
 fragments: {
 user: () => Relay.QL`
fragment on User {
 stream (first:$first) {
 edges {
 cursor
 node {
 ${Content.getFragment("content")}
 }
 }
 }
}
 `
 }
});
```

We don't have to express how to "pull for more data" in that code. In fact, this is delegated to `InfiniteScrollable` and we never have to think again about it.


## InfiniteScrollable implementation

Relay enforces to implement [a subset of GraphQL spec](https://facebook.github.io/relay/docs/graphql-relay-specification.html#content), like the Connection API. It's a good thing because we can also rely on this fact, and what we only need is the `relay` object to implement a generic pull-on-scroll.


```js
import {
 Component,
 PropTypes,
} from "react";
import {findDOMNode} from "react-dom";

const regex = /(auto|scroll)/;

const style = (node, prop) =>
 getComputedStyle(node, null).getPropertyValue(prop);

const scroll = (node) =>
 regex.test(
 style(node, "overflow") +
 style(node, "overflow-y") +
 style(node, "overflow-x"));

const scrollparent = (node) =>
 !node || node===document.body
 ? document.body
 : scroll(node)
 ? node
 : scrollparent(node.parentNode);

const resizeEventOn = n => n===document.body ? window : n;

export default class InfiniteScrollable extends Component {
 static propTypes = {
 children: PropTypes.any.isRequired,
 relay: PropTypes.object,
 style: PropTypes.object,
 loadPixelsInAdvance: PropTypes.number,
 relayVariable: PropTypes.string,
 chunkSize: PropTypes.number,
 // loadMore could even be generalize, this component works if you provide loadMore instead of relay
 loadMore: PropTypes.func, // (can) returns a promise
 };
 static defaultProps = {
 loadPixelsInAdvance: 1000,
 relayVariable: "first",
 chunkSize: 50,
 };

 state = { loading: false };

 resizeBoundOnDom = null;

 componentDidMount () {
 this.syncScrollBodyListener(this.props);
 this.checkScroll();
 }

 componentWillUnmount () {
 this.unbindResizeEvent();
 }

 componentDidUpdate () {
 this.syncScrollBodyListener();
 }

 unbindResizeEvent () {
 if (this.resizeBoundOnDom) {
 this.resizeBoundOnDom.removeEventListener("scroll", this.checkScroll);
 this.resizeBoundOnDom = null;
 }
 }

 getScrollParent () {
 return scrollparent(findDOMNode(this));
 }

 syncScrollBodyListener = () => {
 const resizeBoundOnDom = resizeEventOn(this.getScrollParent());
 if (resizeBoundOnDom !== this.resizeBoundOnDom) {
 this.unbindResizeEvent();
 resizeBoundOnDom.addEventListener("scroll", this.checkScroll);
 }
 };

 loadMoreUsingRelay = () => {
 const { relay, relayVariable, chunkSize } = this.props;
 return new Promise((resolve, reject) =>
 relay.setVariables({
 [relayVariable]: relay.variables[relayVariable] + chunkSize
 }, readyState => {
 if (readyState.error) reject(readyState.error);
 if (readyState.done) resolve();
 }));
 };

 checkScroll = () => {
 if (this.state.loading) return;
 const container = this.getScrollParent();
 if (!container) return;
 const { height } = container.getBoundingClientRect();
 const { scrollHeight, scrollTop } = container;
 const bottom = scrollTop + height;
 const { loadPixelsInAdvance } = this.props;
 const advance = bottom - scrollHeight + loadPixelsInAdvance;
 if (advance > 0) {
 this.setState({ loading: true }, () =>
 Promise.resolve({ advance, bottom, scrollHeight, height, scrollTop, loadPixelsInAdvance })
 .then(this.props.loadMore || this.loadMoreUsingRelay)
 .then(
 () => this.setState({ loading: false }), // technically could recall checkScroll here. in second callback of setState. fork it, try it, adapt it !
 e => (console.warn(e), this.setState({ loading: false }))
 ));
 }
 };

 render () {
 // you might want to render a spinner?
 // children might be a function?
 // etc..
 // these are some variations we could have from this starting point
 return this.props.children;
 }
}
```


This is a **possible implementation** of this problem. You might want to add more things based on your needs. For instance you could automatically render a loading spinner... or a million other things! Please try it, fork it, give feedback :)

It is also possible to implement it as a High Order Component (HOC): [https://github.com/facebook/relay/issues/1377](https://github.com/facebook/relay/issues/1377).

implement a component handling the scroll of a list to pull more data of a Graphql Connection with Relay

Relay, scrolling connections

[twitter]: https://twitter.com/ProjSeptEng
[website]: https://projectseptember.com
[rn]: http://facebook.github.io/react-native/
[graphql]: http://graphql.org/
[scala]: http://scala-lang.org/
[glreactconf]: /2016/06/glreactconf
[glreact]: https://github.com/ProjectSeptemberInc/gl-react
[glreactdom]: https://github.com/ProjectSeptemberInc/gl-react-dom
[glreactnative]: https://github.com/ProjectSeptemberInc/gl-react-native
[rnanimation]: https://facebook.github.io/react-native/docs/animations.html

🎉 Hooray! [We][twitter] recently released an iOS app called [Project September][website].

This application is built with nice tech stack including [React Native][rn] and [GraphQL][graphql]. The backend is powered by [Scala][scala], a robust functional language, and we use many other [cool techs][twitter].

This fashion app needed some fancy features: one was demo-ed at last [React.js conference][glreactconf] with the ability to do localized blur on text over images.

We have developed **[`gl-react`][glreact]** to abstract GL in React paradigm – with two companion libraries [`gl-react-dom`][glreactdom] and [`gl-react-native`][glreactnative] that glues React Native with OpenGL.

Let's first see 2 demos of OpenGL usage in our app, and then we'll write a bit about how it's hard to get animations right.



## The Text Over Image blur

### The goal

<img width="50%" src="/images/2016/07/current-1.png" /><img width="50%" src="/images/2016/07/current-2.png" />

### How it works

<img src="/images/2016/07/initial.png" />

**+** **_(layer)_**

<img src="/images/2016/07/layer.png" />

**=**

<img src="/images/2016/07/result.png" />

### Under the hood

- The shadow intensity, size, position, is procedurally generated, we can adjust that. The shadow color is the blurry image color
- The text color is determined by the color picked in blurred image at the shadow middle position. **If the `monochrome` value of that color is lower than 60%**, text will be white, otherwise text will be black.

Here is more detail on how the shadow is generated:

<img src="/images/2016/07/under-1.png" />

**\* (multiply alpha)**

<img src="/images/2016/07/under-2.png" />

**=**

<img src="/images/2016/07/under-3.png" />

**+ (layer)**

<img src="/images/2016/07/under-4.png" />

**=**

<img src="/images/2016/07/layer.png" />

### Fragment shader

```glsl
precision highp float;
varying vec2 uv;

uniform sampler2D img;
uniform sampler2D imgBlurred;
uniform sampler2D txt;

const vec2 shadowCenter = vec2(0.5, 0.9);
const vec2 shadowSize = vec2(0.6, 0.2);
float shadow () {
 return 0.8 * smoothstep(1.0, 0.2, distance(uv / shadowSize, shadowCenter / shadowSize));
}
float monochrome (vec3 c) {
 return 0.2125 * c.r + 0.7154 * c.g + 0.0721 * c.b;
}
vec3 textColor (vec3 bg) {
 return vec3(step(monochrome(bg), 0.6));
}

void main () {
 vec4 bg = mix(texture2D(img, uv), texture2D(imgBlurred, uv), shadow());
 vec4 fg = vec4(textColor(texture2D(imgBlurred, shadowCenter).rgb), 1.0);
 float fgFactor = 1.0 - texture2D(txt, uv).r;
 gl_FragColor = mix(bg, fg, fgFactor);
}
```

### Integration

```html
<GL.Node shader="{shaders.textOverImage}">
 <GL.Uniform name="img"> {img} </GL.Uniform>
 <GL.Uniform name="imgBlurred">
 <Blur factor="{20}" passes="{6}" width="{width}" height="{height}">
 {img}
 </Blur>
 </GL.Uniform>
 <GL.Uniform name="txt">
 <Text style="{titleStyle}">{title}</Text>
 </GL.Uniform>
</GL.Node>
```

## Uploading Thumbnail

This is a video record of our app:

<video controls autoplay muted loop width="100%" src="/images/2016/07/upload.mp4"></video>

The uploading spinner effect is implemented with an OpenGL shader. This was not easy to avoid all the blinks we used to have. We have different components to render each step (uploading animation / uploaded final image) and the uploaded image needs to be downloaded again to not render as white. One solution could be to use a monolithic "thumbnail" component that do everything. We wanted to keep independent components.
Hopefully, everything now works seamlessly with some "double buffering"/swapping mechanism we will explained at the end of this article.

## Animate all the things

### Designing animations

> Fluid, meaningful animations are essential to the mobile user experience.
> **[— React Native Animations documentation][rnanimation]**

It's not easy to design how an application should animate, to define transitions between all the different possible single state and edge-cases of your app. Designing animations, as part of UX design, is a time consuming work but it tends to be underestimated while being essential for moving from a _good app_ to a _very good app_. That tends to be the last 20% remaining missing parts of your app that are the hardest but that makes the 80% of a great UX.

### Implementing animations

Not only it's hard to have figured out the animations (to find the optimal UX) but it can also be quite challenging to implement them in a maintainable and robust way. Turns out most of the times, your code is not ready for it and it implies big refactoring.

#### in React Native

React Native [Animations API][rnanimation] makes it easier: you just have to switch to one of the `Animated.*` component. In `gl-react` we even support Animated values to flow into the shaders uniforms so it's very convenient to animate a GL effect.

That said, React Native Animations is not the ultimate silver bullet. There are things Animations won't solve for you. React Native Animated is still a low level API, it's also imperative and not opinionated on how you should turn it into descriptive paradigm.

I guess what's generally hard with animations in React functional/descriptive paradigm ("always `render()`ing Virtual DOM again" idea) is to figure out **how to not "break" your animations**. For instance, ugly animation interruption could happen if you `render()` a different component: because it forces the component to unmount. If you have an animation happening, you might not want it to stop, or at least you might want to smoothly customize the transition to the new state.

That's something CSS transitions might help solving, but in React Native we don't have them, so it's not so trivial.

##### our current solution

We have built our own abstraction to solve this problem: a Component decorator manages to kill a lot of flashes and blinks cases (e.g. images not ready yet, animation getting interrupted).

> What the decoration solves: when moving from A to B, you want B to be ready (e.g. images are loaded), you also want A to have finish its (animated) work.

**A component can express it needs some time to mount _(e.g. an image to load!)_ OR that it needs some time to unmount _(e.g. an "animating out")_. This will basically hold the rendering to happen:**

The decoration can implement "double buffering" on a Component: `render()` function keeps rendering Component with the previous "stable props" but will also render in background another instance of Component with the next props. When that next props Component is ready and loaded, we can successful swap it to be the new "stable props".

You have the basic idea, the decorator is not so trivial to implement as it also needs to handle some edge-cases, for instance if the decorator receives new props during the transition. We also have a minimal way to express "styles transitions" similarly to how CSS Transitions works.

🎉 There are some OpenGL in the Project September fashion app!

Universal GL Effects for Web and Native

<img src="/images/2015/10/gl-react.png" alt="" class="thumbnail-left" /> Last Thursday, my talk at [React Paris Meetup](http://www.meetup.com/ReactJS-Paris/events/226103821/) was about using **the functional rendering** paradigm of **WebGL** in **React**. The library [`gl-react`](https://github.com/ProjectSeptemberInc/gl-react) wraps WebGL in React paradigm with a focus for developing 2D effects, that we need in my current startup, [Project September](https://twitter.com/ProjSeptEng), where I have the chance to develop it.

## [Slides](http://greweb.me/reactmeetup7)

<iframe src="http://greweb.me/reactmeetup7" width="600" height="400" frameborder="0"></iframe>



## Abstract

We can write effects without having to learn the complex and imperative low-level WebGL API but instead composing React components, as simple as functional composition, using VDOM descriptive paradigm.

[gl-react](https://github.com/ProjectSeptemberInc/gl-react) brings WebGL bindings for react to implement complex effects over content.

[gl-react-native](https://github.com/ProjectSeptemberInc/gl-react-native) is the React Native implementation,
therefore allows universal effects to be written both for web and native.

These libraries totally hides for you the complexity of using the OpenGL/WebGL API but takes the best part of it: GLSL, which is a "functional rendering" language that runs on GPU.

This presentation is an introduction to WebGL in React and functional programming concept and showcases made with gl-react and gl-react-native

Introducing gl-react

*^ Sorry guys, you may have notice the blog post date is wrong. I won't change the URL, but thanks to how time works, this will be fixed in one month anyway :-D*

[ReactEurope](https://twitter.com/chantastic/status/616608931037646850) conference
was to me incredibly [inspiring](https://twitter.com/chantastic/status/616670658911715328) and [promising](https://twitter.com/chantastic/status/616995607043903488).
Yersterday got tons of news and tweets from JavaScript community.

One tweet and blog post by the great [@aerotwist](https://twitter.com/aerotwist) got my attention.

<blockquote class="twitter-tweet" data-cards="hidden" lang="fr">I often hear claims that “the DOM is slow!” and “React is fast!”, so I decided to put that to the test:&#10;&#10;<a href="https://t.co/M1RZZiyVT2">https://t.co/M1RZZiyVT2</a>&#10;&#10;🐢vs🐇&mdash; Paul Lewis (@aerotwist) <a href="https://twitter.com/aerotwist/status/616934953679458304">3 Juillet 2015</a></blockquote>

I would like to express here my opinion and feedback on using React.

I've been using React for almost 2 years now, and always in performance intensive use-cases, from Games to WebGL.

<a href="http://diaporama.glsl.io/" target="_blank">
<img src="/images/2015/07/diaporama_3.jpg" alt="" class="thumbnail-left" />
</a>

I've created [glsl.io](http://glsl.io/) and I'm working on [Diaporama Maker](https://github.com/gre/diaporama-maker).
Both applications are built with React and combined use of HTML, SVG, WebGL.

Diaporama Maker is probably the most ambitious piece of software I've ever personally done.

 

> In short, [Diaporama Maker](https://github.com/gre/diaporama-maker) it is a WYSIWYG editor for web slideshow (mainly photo slideshows). It is a bit like iMovie with the web as first target. [The project is entirely open-sourced.](https://github.com/gre/diaporama-maker)

Currently, I am able to render the whole application at 60 FPS and this is still unexpected and surprising to me
(press Space to run the diaporama on [diaporama.glsl.io demo](http://diaporama.glsl.io/)).
Well, more exactly, this would not have been possible without some optimizations
that I'm going to detail a bit at the end of this article.



## The point is productivity

I don't think Virtual DOM claims to be faster than doing Vanilla DOM, and that's not really the point. **The point is productivity.**
You can write very well optimized code in Vanilla DOM but this might require **a lot of expertise**
and a lot of time even for an experienced team *(time that should be spent focusing on making your product)*.

When it comes to adding new features and refactoring old ones, this goes worse.
Without a well constrained framework or paradigm, things does not scale far, are time consuming and introduce bugs,...
Especially in a team where multiple developers have to work with each other.

> **See Also:** [Why does React scale?](https://www.youtube.com/watch?v=D-ioDiacTm8) by [@vjeux](https://twitter.com/Vjeux).

## What matters to me

There is a lot of advantages of using Virtual DOM approach before talking about React performances.

Of course, this always depends on what you are building, but I would claim that
**there is a long way to go using React before experiencing performance issues**,
and in the worse cases: **you can almost always find easy solutions to optimize these performance issues**.

### DX

React has an incredible Developer eXperience (that people seem to call DX nowadays!) that can [help you improving UX](https://twitter.com/greweb/status/617258379183005696) and the ability to [measure Performances](https://facebook.github.io/react/docs/perf.html) and [optimize them](https://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate) when you reach bottlenecks.

You can easily figure out which component is a bottleneck in the Component tree as shown in following screenshot.

> ![](/images/2015/07/diaporama-perfs.png)
With printWasted() you can see how much time React has wasted to `render()` something that didn't change and how much instances has been created. (there is also printInclusive and printExclusive)

This is a bit equivalent of the Web Console Profiler except it emphasis on your application components which is a very relevant approach.

### React data flow

> I can't imagine re-writing Diaporama Maker in Vanilla DOM.

In Diaporama Maker, I have a lot of cross dependencies between components,
for instance the current `time` is shared and used everywhere in the application.
As a matter of fact, dependencies grow when adding more and more features.

> ![](/images/2015/07/diaporama_configure_kenburns.gif)
usages of time in 3 independent components.

**The descriptive Virtual DOM approach very simply solves this problem**.
You just have to pass props in to share data between components:
there is one source of trust that climb down your component tree via "props".

![](/images/2015/07/diaporama-maker-time-props.jpg)

With Virtual DOM approach, the cost to add one new dependency to a shared data is small and **does not become more complex as the application grows**.

> ![](/images/2015/07/diaporama_slide_content.gif)
another more complex showcase of shared states.

Using an Event System like you would do in standard Backbone approach tends to lead to imperative style and spaghetti codes (and when using global events, components are not really reusable).

Moreover, I think that `Views<->Models` Event System approach, if not carefully used, tends to converge to an unmaintainable and laggy applications.

### React is a Component library

React truly offers **component as first-class citizen**.
This means it allows component reusability. I've tried alternative like virtual-dom and I don't think it emphasizes enough on this benefit.

There are [important good practices](https://twitter.com/chantastic/status/616997918155759616) when using React like minimizing states and props and I'm not going to expand more on this subject. Most of these best practices are not exclusive to React but come from common sense and software architecture in general.
One of the important point for performance is to **choose a good granularity of your component tree**.
It is generally a good idea to split up a component into pieces as small as possible
because it allows to separate concerns, minimize props and consequently optimize rendering diff.

#### Diaporama Maker architecture

You would be surprised to know that Diaporama Maker does not even use **Flux** (that might be reconsidered soon for collaborative features). I've just taken the old "callback as props" approach all the way down the component tree. That easily makes all components purely modular and re-usable (no dependencies on some Stores).
I've also taken the [inline style approach]() without actually using any framework (this is just about props-passing `style` objects).

As a consequence, I've been able to externalize a lot of tiny components that are part of my application
so I can share them across apps and also in order to people to re-use them.

What is important about externalizing components is also the ability to test and optimize them independently (the whole idea of modularity).

Here are all the standalone UI components used by Diaporama Maker:

- [bezier-easing-editor](https://github.com/gre/bezier-easing-editor)
- [bezier-easing-picker](https://github.com/gre/bezier-easing-picker)
- [diaporama-react](https://github.com/glslio/diaporama-react)
- [glsl-transition-vignette](https://github.com/glslio/glsl-transition-vignette)
- [glsl-transition-vignette-grid](https://github.com/glslio/glsl-transition-vignette-grid)
- [glsl-uniforms-editor](https://github.com/gre/glsl-uniforms-editor)
- [kenburns-editor](https://github.com/gre/kenburns-editor)

(each one have standalone demos)


## Optimizing performances

<blockquote class="twitter-tweet" lang="fr">I&#39;ve been working on crazy projects using React (like <a href="http://t.co/U2oETh5lhZ">http://t.co/U2oETh5lhZ</a> ). most performance issues i&#39;ve met was not because of React&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/status/617210444839809024">4 Juillet 2015</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

Here are 2 examples of optimizations I had to do in Diaporama Maker that are not because of React:

- It is easy to write not very optimized WebGL, so I work a lot to optimize the pipeline of [Diaporama engine](https://github.com/gre/diaporama)
- CSS transforms defined on Library images was for a time very intensive for the browser to render so I am now using server-resized "thumbnails" instead of the full-size images. Asking the browser to recompute the `transform: scale(...)` of 50 high resolution images can be super costy. (without this optimization, the resize of the application was running at like 2-3 FPS because the library thumbnails need to recompute their scale and crop).

But what if you still have performance issue due by React? Yes this can happens.

### Timeline Grid example

In Diaporama Maker, I have a Component that generates a lot of elements (like 1300 elements for a 2 minutes slideshow) and my first naive implementation was very slow. This component is [TimelineGrid](https://github.com/gre/diaporama-maker/blob/b0c6447b127785bea3c2487b0c77037418298b8c/client/ui/TimelineGrid/index.js) which renders the timescale in the timeline. It is implemented with SVG and a lot of `<text>` and `<line>`.

The performance issue was noticeable when drag and dropping items across the application. React was forced to render() and compare the whole timescale grid every time. But the timescale does not change! it just have 3 props:

```xml
<TimelineGrid timeScale={timeScale} width={gridWidth} height={gridHeight} />
```

**So it was very easy to optimize it just by using the `PureRenderMixin` to say to react that all my props are immutable.**
(I could have implemented `shouldComponentUpdate` too).

After this step, and for this precise example, I don't think a Vanilla DOM implementation can reach better performance:

- when one of the grid parameter change, **EVERYTHING** need to be recomputed because all scales are changing.
- React is doing even smarter thing that I would not manually do? Like reusing elements instead of destroying/creating them.

There might still be ways to go more far in optimizing this example. For instance I could chunk my grid into pieces
and only render the pieces that are visible, like in an infinite scroll system *(I could use something like [sliding-window](https://github.com/gre/sliding-window) for this)*.
That would probably be premature optimization for this example.

## Wrap Up

To my mind, generic benchmarks always tends to be biased and does not represent use-cases reality unless you are really covering your application itself.

The TimelineGrid component optimization explained in this article is a very specific and well chosen example,
but it is one counter-example for such a benchmark.

Each application has its own needs and constraints and we can't really generalize one way to go.
Also Performance should not be the main concern to choose a technology.


It is easy to make Virtual DOM library benchmarks,
comparing the performance of rendering and Array diffing,
but does that covers 80% of use-cases?
Is performance really the point?
What tradeoff do you accept to make between Performance and Productivity?

Tell me what you think.

In the meantime, I think we can all continue getting applications done
and [developing amazing DX](https://github.com/gaearon/react-hot-loader).

I would like to express here my opinion and feedback on using React and performance optimization you can do.

Making performant React applications

A talk I did at webglparis to present GLSL.io and GLSL Transitions initiative.

@greweb

I plot every day...

I also love shaders...