https://github.com/hexagontruth/webgx

WebGPU program runner
https://github.com/hexagontruth/webgx

canvas shaders webgpu

Last synced: 8 days ago
JSON representation

WebGPU program runner

• Host: GitHub
• URL: https://github.com/hexagontruth/webgx
• Owner: hexagontruth
• License: other
• Created: 2023-05-14T14:24:18.000Z (over 1 year ago)
• Default Branch: master
• Last Pushed: 2024-12-25T22:28:03.000Z (21 days ago)
• Last Synced: 2024-12-25T23:19:36.857Z (21 days ago)
• Topics: canvas, shaders, webgpu
• Language: JavaScript
• Homepage:
• Size: 500 KB
• Stars: 0
• Watchers: 2
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
Webgx

=========

By Graham

A WebGPU player.

## Quick start

1. Clone the repo

2. Install dependencies with e.g. `npm install` or equivs

3. Run `npm start`

The server will run on port 8080 by default. Override with `PORT` environment variable.

## Overview

I adapted this from my (fairly bare-bones) WebGL shader art stack to a) familiarize myself with WebGPU, and b) continue my practice of doing shader art and related in a more modular way than e.g. just cloning and modifying single-page demos. It is obscure and idiosyncratic and I do not recommend anyone using it for any reason. Plz consult the WebGPU docs and write your own thing.

In a nutshell, we load a "program" file specified either by the URL path (the new way) or the `program` or `p` query parameter (the old way), referencing a JavaScript file in the `/lib` or `/user` directories that defines a set of WebGPU pipelines, buffers, and associated logic to perform a sequence of steps and — presumably — output the result of the same as a series of frames to the on-page canvas. The shaders are defined in separate files using a fairly rudimentary `#include` system, according to a directory schema that made sense when I first started using it a few years ago. Unlike in my WebGL thing, which just used JSON, the program files here are full JavaScript files  with access to a program object passed in from the player. Consult the `Program` class file for a full list of program configuration fields and their default values, as well as methods that can be invoked on the program instance. A rudimentary understanding of the possibilities of the same can be gleaned from the example shaders in the `/lib` directory.

To run e.g. the raymarching example, simply load the following URL (assuming default port settings &c.):

```http://localhost:8080/examples/raymarcher```

As noted, there are separate directories for built-in programs and shaders (`/lib`) and user-defined ones (`/user`). The server process is required to retrieve resources from both of these potential paths as well as to perform recording operations via ffmpeg and frame saving. Both directories however resolve from the `/data` web path internally, so one can conversely store program files in e.g. a `/public/data` directory, forego recording tools, and simply run the compiled assets directly via a static server from `/public`.

There is very little error handling being performed and the player is not in any way robust. It simply plays properly-formatted program and shader files for output or — within reason — interactive display. Probably.

At the moment there is no compute shader functionality. Adding this is my next order of business. This will probably also involve refactoring the whole buffer system into something a bit more modular and general-purpose.

Consult the `App` class for information on keyboard and button commands, and the (client) `Config` class for information on e.g. URL parameters and persistent settings.