[doc] GPU-based GUI API design #68

AmesingFlank · 2021-07-07T03:36:38Z

This PR is intended to allow for discussions surrounding the APIs to be implemented in the new GUI system of taichi. Please do not merge it yet.

To view the markdown file included in this PR in a more friendly format, please visit this link

This is a very early draft. Any comments will be much appreciated.

netlify · 2021-07-07T03:36:40Z

✔️ Deploy Preview for docs-taichi-graphics ready!
Built without sensitive environment variables

🔨 Explore the source changes: da24e82

🔍 Inspect the deploy log: https://app.netlify.com/sites/docs-taichi-graphics/deploys/60ee8743d8f6880007eafa3f

😎 Browse the preview: https://deploy-preview-68--docs-taichi-graphics.netlify.app

AmesingFlank · 2021-07-14T07:27:05Z

website/docs/lang/articles/misc/new_gui.md

+
+```python
+gui = ti.ui.GUI('Window Title', (640, 360))
+```


I think you're looking at an older version of this file?

True, therefore some of the comments are folded. Some other parts marked "outdated" by github still applies but the position in the original document has changed or the object calling on has changed, but the idea is the same. Sorry about this, I made these comments a while ago and did not notice they are not published

bobcao3 · 2021-07-07T03:45:43Z

website/docs/lang/articles/misc/new_gui.md

+    for frame in range(10000):
+        render(img)
+        gui.set_image(img)
+        gui.show(f'{frame:06d}.png')


It would seems be cleaner to have frame capture in separate API. Then potentially depending on when the frame capture function is called, we may or may not have things like GUI or text captured.

bobcao3 · 2021-07-07T03:46:47Z

website/docs/lang/articles/misc/new_gui.md

+
+## Paint on a window
+
+`gui.set_image(pixels)` sets an image to display on the window.


A more precise name for this function would be present or blit, where present refers to displaying an image, and blit refers to painting a bitmap onto another surface (a display or another image)

bobcao3 · 2021-07-07T03:48:35Z

website/docs/lang/articles/misc/new_gui.md

+- `ti.Vector.field(3, shape=(x, y))` `(r, g, b)` channels on each
+  component (see [vector](../../api/vector.md#vector-fields) for details)
+
+- `ti.Vector.field(2, shape=(x, y))` `(r, g)` channels on each component


Maybe allow RGBA images as well. In most modern graphics APIs 3 channel buffers are emulated with 4 channel one anyways (due to alignment issues)

bobcao3 · 2021-07-07T03:50:35Z

website/docs/lang/articles/misc/new_gui.md

+
+    mouse_x, mouse_y = gui.get_cursor_pos()
+
+`gui.fps_limit` sets the FPS limit for a window. For example, to cap FPS at 24, simply use `gui.fps_limit = 24`. This helps reduce the overload on your hardware especially when you're using OpenGL on your integrated GPU which could make desktop slow to response.


Consider adding VSYNC in addition to FPS limit to have the image be presented smoothly. (Non-display framerate limits can be hard to enforce / inconsistent)

website/docs/lang/articles/misc/new_gui.md

+
+## GUI Widgets
+
+Sometimes it's more intuitive to use widgets like slider or button to control the program variables instead of using chaotic keyboard bindings. Taichi GUI provides a set of widgets for that reason:


bobcao3 · 2021-07-07T03:52:44Z

website/docs/lang/articles/misc/new_gui.md

+
+`ti.imwrite(img, filename)` can export a `np.ndarray` or Taichi field (`ti.Matrix.field`,  `ti.Vector.field`, or `ti.field`) to a specified location `filename`.
+
+Same as `ti.GUI.show(filename)`, the format of the exported image is determined by **the suffix of** `filename` as well. Now `ti.imwrite` supports exporting images to `png`, `img` and `jpg` and we recommend using `png`.


Wishlist: having support for *.HDR, *.exr, *.DDS, etc. These data types are more suited for rendering applications where high dynamic range image or floating point image is required.

Also seems redundant with the frame capture feature. Maybe add an API to export the frame data back into a taichi field, and use this image IO feature to save it do disk

AmesingFlank · 2021-07-14T08:04:01Z

website/docs/lang/articles/misc/new_gui.md

+
+## Clearing and showing a window
+```python
+window.clear(color)


I agree. That was kinda silly. But please look at the newest files..

bobcao3 · 2021-07-07T17:11:10Z

website/docs/lang/articles/misc/new_gui.md

+```python
+window.clear(color)
+...
+window.show()


Maybe have windows constantly show? And make show / hide toggle the window visibility state instead of having to call "show" every frame.

bobcao3 · 2021-07-08T08:38:09Z

website/docs/lang/articles/misc/new_gui.md

+
+
+## 3D Scene
+


A scene graph system may be the best, making it extensible, relatively easy to use, while being performance & GPU friendly.

Suggested change

# Renderer can render a scene / object

renderer = ti.ui.Renderer()

# Scenes are made up from objects / nodes, each node has a transform matrix and a list of children. The root node is called scene.

scene = ti.ui.Scene()

# Camera

camera = scene.addCamera()

camera.transform = ti.ui.ComposeTransform(...) # Many ways to set transform (e.g. translation / rotation / scale)

camera.fov = math.rad(70) # The FOV of camera

camera.near = ...

camera.far = ... # These should have a reasonable default value

# Primitives

trimesh0 = scene.addTriangleMesh(vertices, numVertices, firstVerex=0) # vertices should (ideally) be a 1D ti.dense

trimesh0.setColor() # This can be a color value, or another ti.dense for per-vertex color

trimesh0.setTexture("textureFile", uv) # UV should be a ti.dense for per-vertex UV. We should also consider supporting using ti.dense images as texture.

trimesh0.transform = ti.ui.ComposeTransform(...) # mesh is a scene node

pointcloud0 = scene.addPointCloud()

trimesh1 = trimesh0.addTriangleMesh(...) # Trimesh 0 contains a child mesh, creating a hierarchical transform

# Lights

pointlight0 = scene.addPointLight()

distantLight0 = scene.addDistantLight()

domeLight0 = scene.addDomeLight() # This can be uniform color or a skybox

# Rendering

# Renders the scene from camera to a target (e.g. window)

renderer.render(target, scene, camera) # target can be the window, another texture, or potentially ti.dense

This is extendable, and should be able to run efficiently on GPU. The potential is also there to tightly integrate real-time rendering into Taichi applications with dense field interactions. The UI backend should talk with the taichi backend to transfer the images / fields implicitly. In the beginning iterations we can force the user use the same renderer / taichi runtime or a few supported combinations. (e.g. gl-gl, vulkan-vulkan, cuda-gl, cpu-vulkan)

It would be ideal to create a seperate module just to manage API crossing. It is always possible to have shared host-device memory (cpu & gpu visible or even coherent). It is also possible to do supported interops such as Vulkan / GL image sharing or GL / cuda

Having a scene graph would be really nice. However, I think this somewhat defeats the goal of having a simple and easy-to-use API.

It would be ideal to create a seperate module just to manage API crossing.

Yes. This will be necessary if GGUI is to replace the legacy ti.GUI completely. Currently we are aiming to support Vulkan(GUI) <-> cuda(Taichi) only. (@k-ye When/if should I worry about other backends?)

bobcao3 · 2021-07-14T07:15:04Z

website/docs/lang/articles/misc/new_gui.md

+  canvas.clear(...)
+  canvas.triangles(...)
+
+  scene.clear()


Constantly rebuilding the scene will be costly

Not necessarily. The implementation is free to do all kinds of caching.

We wish to keep function calls such as canvas.triangles(a,b,c) inside the render loop in order to make it obvious to the users that the newest values of the taichi fields a, b, and c, which might have just been modified this frame, will be used for rendering. This keeps the semantics of the API simple.

Does the clear() function here means the clearing of the color & depth buffer of the canvas or does it mean clearing of the primitives defined from last frame (essentially a NewFrame() call)?

canvas.clear(): clearing the color & depth buffer of the canvas.
scene.clear(): clearing the geometries in the scene.

bobcao3 · 2021-07-14T07:17:23Z

website/docs/lang/articles/misc/new_gui.md

+```python
+canvas = window.get_canvas()
+```
+this retrieves a `Canvas` object that covers the entire window.


If you squint at canvas a bit, it is basically a 2d renderer that draws on a 2d texture / image. So maybe canvas should be created from ti.gui? As for the resolution, it seems canvas is always rendering vector objects, it might be fine to assume the canvas coordinate space is (0..1, 0..1)

So maybe canvas should be created from ti.gui?

I had a discussion with @k-ye about this. The reasoning is that we do not want the users to have to write canvas.render(...) and then write something like window.render(canvas).

As for the resolution, it seems canvas is always rendering vector objects, it might be fine to assume the canvas coordinate space is (0..1, 0..1)

Yes that is the current design. When users call canvas.triangles(...) etc. the ti vertex coordinates and other stuff should be in the [0,1]*[0,1] space.

You would still need to call window.render(canvas) anyways right? Otherwise how do the user decide whether the canvas is drawn on top of everything else or behind things like UI?

The plan is to have a simple model: UI widgets are always on top of the canvas.

AmesingFlank · 2021-07-14T08:11:45Z

@bobcao3 Thank you very much for your comments! But I think we might be aiming at slightly different things here. I believe the current task is to implement a GUI that (a) is simple to use even for not-so-experienced programmers and (b) does not suffer from the severe performance issues of the old ti.GUI. Integrating taichi with a powerful GUI system together with other awesome real-time rendering technologies is a fascinating task but I don't think that's top priority right now.

bobcao3 · 2021-07-14T08:16:50Z

@bobcao3 Thank you very much for your comments! But I think we might be aiming at slightly different things here. I believe the current task is to implement a GUI that (a) is simple to use even for not-so-experienced programmers and (b) does not suffer from the severe performance issues of the old ti.GUI. Integrating taichi with a powerful GUI system together with other awesome real-time rendering technologies is a fascinating task but I don't think that's top priority right now.

I believe that no matter what this API needs to be extendable and possible to be performant. Once you offer a API to the user you can't limit what they can come up with, and it is very hard to create a performant immediate mode GUI / data visualization system. I think scene graph can be easy enough to use (if you don't create a hierarchy it is as simple as the existing API, just that it's not immediate)

k-ye · 2021-07-14T12:05:21Z

Thanks @bobcao3! Let's just stick with the current API design, which is mostly consistent with how ti.GUI works currently. Note that the goal of this GUI system is to ship a basic solution in Taichi for users to visualize 3D results. It's not meant to become a full-blown real-time renderer.

bobcao3 · 2021-07-15T01:58:48Z

If I did not call scene.clear upon next frame, will the geometries from last frame persist? Which means we will need to keep a copy every frame

…

On Wed, Jul 14, 2021, 6:41 PM Dunfan Lu ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In website/docs/lang/articles/misc/new_gui.md <#68 (comment)> : > +import taichi as ti + +window = ti.ui.Window("Amazing Window",res) +canvas = window.get_canvas() +scene = ti.ui.Scene() + + +while window.running: + events = window.get_event() + if ev.action == ti.ui.ACTION_PRESSED and ev.key == ti.ui.KEY_SHIFT: + ... + + canvas.clear(...) + canvas.triangles(...) + + scene.clear() canvas.clear(): clearing the color & depth buffer of the canvas. scene.clear(): clear the geometries in the scene. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7Q5EYOOIUG3PHKMT2BELTXY4ENANCNFSM475Y7LOQ> .

AmesingFlank · 2021-07-15T02:41:03Z

If I did not call scene.clear upon next frame, will the geometries from last frame persist? Which means we will need to keep a copy every frame
…
On Wed, Jul 14, 2021, 6:41 PM Dunfan Lu @.***> wrote: @AmesingFlank commented on this pull request. ------------------------------ In website/docs/lang/articles/misc/new_gui.md <#68 (comment)> : > +import taichi as ti + +window = ti.ui.Window("Amazing Window",res) +canvas = window.get_canvas() +scene = ti.ui.Scene() + + +while window.running: + events = window.get_event() + if ev.action == ti.ui.ACTION_PRESSED and ev.key == ti.ui.KEY_SHIFT: + ... + + canvas.clear(...) + canvas.triangles(...) + + scene.clear() canvas.clear(): clearing the color & depth buffer of the canvas. scene.clear(): clear the geometries in the scene. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7Q5EYOOIUG3PHKMT2BELTXY4ENANCNFSM475Y7LOQ .

Yes. The geometries persist if clear() is not called.

I'm not actually sure if this is the most intuitive semantics. We do really want to make the API for drawing 3d geometries immediate, so that users can simply write scece.mesh(vertices,indices,...) in the render loop. Having a scene.clear() kind of goes against the immediate mode flavor.

However, if we were to go full immediate mode, the api would become something like

while 1:
     canvas = window.begin_canvas()
     scene = canvas.begin_scene()
     scene.mesh(...)

which does avoid scene.clear() but is even more cumbersome.

Suggestions?

FantasyVR · 2021-07-15T03:18:28Z

website/docs/lang/articles/misc/new_gui.md

+```python
+canvas.clear(color)
+canvas.triangles(a,b,c,color)
+canvas.triangles_indexed(positions,indices,color)


Great work @AmesingFlank ! I wonder could we also use triangles as the function name. You could determine whether drawing triangles with indices by evaluating the function parameters.

Yes. That could work.

bobcao3 · 2021-07-15T03:43:31Z

Begin & End has been the choice for immediate mode API for all sorts of systems. A full immediate mode API will have some performance issues, you can reference legacy GL performance

…

On Wed, Jul 14, 2021, 7:41 PM Dunfan Lu ***@***.***> wrote: If I did not call scene.clear upon next frame, will the geometries from last frame persist? Which means we will need to keep a copy every frame … <#m_-3178495068830036824_> On Wed, Jul 14, 2021, 6:41 PM Dunfan Lu *@*.***> wrote: ***@***.*** <https://github.com/AmesingFlank>* commented on this pull request. ------------------------------ In website/docs/lang/articles/misc/new_gui.md <#68 (comment) <#68 (comment)>> : > +import taichi as ti + +window = ti.ui.Window("Amazing Window",res) +canvas = window.get_canvas() +scene = ti.ui.Scene() + + +while window.running: + events = window.get_event() + if ev.action == ti.ui.ACTION_PRESSED and ev.key == ti.ui.KEY_SHIFT: + ... + + canvas.clear(...) + canvas.triangles(...) + + scene.clear() canvas.clear(): clearing the color & depth buffer of the canvas. scene.clear(): clear the geometries in the scene. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment) <#68 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7Q5EYOOIUG3PHKMT2BELTXY4ENANCNFSM475Y7LOQ . Yes. The geometries persist if clear() is not called. I'm not actually sure if this is the most intuitive semantics. We do really want to make the API for drawing 3d geometries immediate, so that users can simply write ''scece.mesh(vertices,indices,...)" in the render loop. Having a scene.clear() kind of goes against the immediate mode flavor. However, if we were to go full immediate mode, the api would become something like while 1: canvas = window.begin_canvas() scene = canvas.begin_scene() scene.mesh(...) which does avoid scene.clear() but is even more cumbersome. Suggestions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7Q5HVBE3RYJ6CTU65M5LTXZDETANCNFSM475Y7LOQ> .

bobcao3 · 2021-07-15T04:00:19Z

I would suggest instead of using a,b,c separately use a single buffer / 3xN image

…

On Wed, Jul 14, 2021, 8:28 PM Dunfan Lu ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In website/docs/lang/articles/misc/new_gui.md <#68 (comment)> : > + +## 2D Canvas + +### Creating a canvas + +```python +canvas = window.get_canvas() +``` +this retrieves a `Canvas` object that covers the entire window. + +### Drawing on the canvas + +```python +canvas.clear(color) +canvas.triangles(a,b,c,color) +canvas.triangles_indexed(positions,indices,color) Yes. That could work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7Q5BNKIGYDJ6R7UQKGSTTXZIWXANCNFSM475Y7LOQ> .

archibate · 2021-07-15T04:19:32Z

For robust APIs, does taichi-dev/taichi_three helps? I used pre-allocated vbo because taichi doesn't support dynamic field allocation to prevent copy overhead, in other words only copy when necessary, keep data around on gpu. For the `need deep copy` every frame problem, you could use the 'id' method, like `scene.update_riangle(0, a, b, c)` only updates the vbo of primtive No. 0. And if not called the triangle will be resistant in gpu memory and thus more efficient. 无法顺畅的大口呼吸，是活着的最好证明

…

---Original--- From: "Dunfan ***@***.***> Date: Thu, Jul 15, 2021 11:28 AM To: ***@***.***>; Cc: ***@***.***>; Subject: Re: [taichi-dev/docs.taichi.graphics] [doc] GPU-based GUI API design (#68) @AmesingFlank commented on this pull request. In website/docs/lang/articles/misc/new_gui.md: > + +## 2D Canvas + +### Creating a canvas + +```python +canvas = window.get_canvas() +``` +this retrieves a `Canvas` object that covers the entire window. + +### Drawing on the canvas + +```python +canvas.clear(color) +canvas.triangles(a,b,c,color) +canvas.triangles_indexed(positions,indices,color) Yes. That could work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

bobcao3 · 2021-07-15T04:25:27Z

In an immediate mode API we wouldn't really have a concept of VBO

…

On Wed, Jul 14, 2021, 9:19 PM 彭于斌 ***@***.***> wrote: For robust APIs, does taichi-dev/taichi_three helps? I used pre-allocated vbo because taichi doesn't support dynamic field allocation to prevent copy overhead, in other words only copy when necessary, keep data around on gpu. For the `need deep copy` every frame problem, you could use the 'id' method, like `scene.update_riangle(0, a, b, c)` only updates the vbo of primtive No. 0. And if not called the triangle will be resistant in gpu memory and thus more efficient. 无法顺畅的大口呼吸，是活着的最好证明 ---Original--- From: "Dunfan ***@***.***> Date: Thu, Jul 15, 2021 11:28 AM To: ***@***.***>; Cc: ***@***.***>; Subject: Re: [taichi-dev/docs.taichi.graphics] [doc] GPU-based GUI API design (#68) @AmesingFlank commented on this pull request. In website/docs/lang/articles/misc/new_gui.md: > + +## 2D Canvas + +### Creating a canvas + +```python +canvas = window.get_canvas() +``` +this retrieves a `Canvas` object that covers the entire window. + +### Drawing on the canvas + +```python +canvas.clear(color) +canvas.triangles(a,b,c,color) +canvas.triangles_indexed(positions,indices,color) Yes. That could work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7Q5CXXJ3SDVA46BSUI63TXZOV7ANCNFSM475Y7LOQ> .

AmesingFlank added 2 commits July 6, 2021 05:16

begin new gui doc

1d63690

wip

544dcac

isdanni changed the title ~~GPU-based GUI API design~~ [doc] GPU-based GUI API design Jul 7, 2021

AmesingFlank added 2 commits July 7, 2021 00:02

change camera api

188862c

drawing scene on canvas

1390bd8

AmesingFlank marked this pull request as draft July 14, 2021 01:52

AmesingFlank added 2 commits July 13, 2021 22:10

small api changes

1e2931b

wip

da24e82

bobcao3 reviewed Jul 14, 2021

View reviewed changes

FantasyVR reviewed Jul 15, 2021

View reviewed changes

k-ye mentioned this pull request Aug 9, 2021

GPU based GUI system taichi-dev/taichi#2646

Closed


		## Paint on a window

		`gui.set_image(pixels)` sets an image to display on the window.


		mouse_x, mouse_y = gui.get_cursor_pos()

		`gui.fps_limit` sets the FPS limit for a window. For example, to cap FPS at 24, simply use `gui.fps_limit = 24`. This helps reduce the overload on your hardware especially when you're using OpenGL on your integrated GPU which could make desktop slow to response.


		## GUI Widgets

		Sometimes it's more intuitive to use widgets like slider or button to control the program variables instead of using chaotic keyboard bindings. Taichi GUI provides a set of widgets for that reason:


		`ti.imwrite(img, filename)` can export a `np.ndarray` or Taichi field (`ti.Matrix.field`, `ti.Vector.field`, or `ti.field`) to a specified location `filename`.

		Same as `ti.GUI.show(filename)`, the format of the exported image is determined by the suffix of `filename` as well. Now `ti.imwrite` supports exporting images to `png`, `img` and `jpg` and we recommend using `png`.

+# Renderer can render a scene / object
+renderer = ti.ui.Renderer()
+# Scenes are made up from objects / nodes, each node has a transform matrix and a list of children. The root node is called scene.
+scene = ti.ui.Scene()
+# Camera
+camera = scene.addCamera()
+camera.transform = ti.ui.ComposeTransform(...) # Many ways to set transform (e.g. translation / rotation / scale)
+camera.fov = math.rad(70) # The FOV of camera
+camera.near = ...
+camera.far = ... # These should have a reasonable default value
+# Primitives
+trimesh0 = scene.addTriangleMesh(vertices, numVertices, firstVerex=0) # vertices should (ideally) be a 1D ti.dense
+trimesh0.setColor() # This can be a color value, or another ti.dense for per-vertex color
+trimesh0.setTexture("textureFile", uv) # UV should be a ti.dense for per-vertex UV. We should also consider supporting using ti.dense images as texture.
+trimesh0.transform = ti.ui.ComposeTransform(...) # mesh is a scene node
+pointcloud0 = scene.addPointCloud()
+trimesh1 = trimesh0.addTriangleMesh(...) # Trimesh 0 contains a child mesh, creating a hierarchical transform
+# Lights
+pointlight0 = scene.addPointLight()
+distantLight0 = scene.addDistantLight()
+domeLight0 = scene.addDomeLight() # This can be uniform color or a skybox
+# Rendering
+# Renders the scene from camera to a target (e.g. window)
+renderer.render(target, scene, camera) # target can be the window, another texture, or potentially ti.dense

[doc] GPU-based GUI API design #68

Are you sure you want to change the base?

[doc] GPU-based GUI API design #68

Conversation

AmesingFlank commented Jul 7, 2021 • edited Loading

netlify bot commented Jul 7, 2021 • edited Loading

This comment was marked as outdated.

AmesingFlank Jul 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as outdated.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as outdated.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AmesingFlank Jul 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AmesingFlank Jul 15, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AmesingFlank commented Jul 14, 2021

bobcao3 commented Jul 14, 2021

k-ye commented Jul 14, 2021

bobcao3 commented Jul 15, 2021 via email

AmesingFlank commented Jul 15, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bobcao3 commented Jul 15, 2021 via email

bobcao3 commented Jul 15, 2021 via email

archibate commented Jul 15, 2021 via email

bobcao3 commented Jul 15, 2021 via email

AmesingFlank commented Jul 7, 2021 •

edited

Loading

netlify bot commented Jul 7, 2021 •

edited

Loading

AmesingFlank Jul 14, 2021 •

edited

Loading

AmesingFlank Jul 14, 2021 •

edited

Loading

AmesingFlank Jul 15, 2021 •

edited

Loading

AmesingFlank commented Jul 15, 2021 •

edited

Loading