jessevdk/webgl-play

WebGL Playground

  WebGL Playground

Visit http://jessevdk.github.io/webgl-play to start right now!

The WebGL Playground is a web-based, live editing environment primarily created to allow easy experimenting with WebGL. The main editor consists of a vertex shader editor, fragment shader editor, JavaScript editor and a live view of the current rendering. Rendering updates automatically as you type, while reporting any errors inline in the editors. A simple UI system allows you to create interactive demos.

The playground provides a number of convenient objects and methods to handle the menial parts of the GL API. Your focus should be mainly on experimenting with interesting rendering shaders and not surrounding WebGL boilerplate. At the same time however, the conveniences should not introduce too much "magic", so it's kept reasonably straight-forward and linear.

Getting Started

If you want to get started right away, please visit http://jessevdk.github.io/webgl-play for the official instance of the playground. Here you can look at examples from the gallery, create new experiments and share them as you like.

You can also run the playground very easily locally, or on your own server. Please see INSTALL.md for more information on installing the playground.

Building

For specific build instructions please see BUILD.md

Structure of this repository

The general structure of this repository is as follows:

• css/: all the website style sheets. The playground uses SASS and the main entry point is css/site.scss. Normal .css files are vendored from external sources.
• docs/: WebGL specific documentation.
• githooks/: useful githooks used during development.
• html/: the website html files.
• icons/: icons of various sizes, as well as the .blend file from which the icons are rendered.
• js/: all the website JavaScript files. Files are distributed over various (mostly self-contained) subdirectories. The playground uses browserify to merge all JavaScript together, and the main entry point is js/site.js. Externally vendored JavaScript files reside in js/vendor/.
• models/: high poly sample models available directly in the playground, including the Stanford Bunny, Buddha, Dragon, Utah Teapot and Blender Suzanne.
• scripts/: various scripts used for building the final website.
• server/: a server for the playground maintaining shared documents and the gallery. See server/README.md for more information.
• site/: pre-generated site. You can point your browser to this locally after a checkout.

webgl-play's Issues

Better warnings related to unavailable required extensions

Currently, when a document requires an extension which is not available, an error is generated and shown inline in the JavaScript editor at the requireExtension API call. This isn't very discoverable, in particular with larger JavaScript documents. It would be nice to show an overlay error message about the missing extensions such that it is immediately clear what the issue is.

Switching editors is broken.

I believe the issue is you are trying to access editors like this:
var editor = this[names[i] + '_editor'];

but it should be this:
var editor = this[names[i] + 'Editor'];

Entering e-mail address in token field for publishing is counter-intuitive

It is not very intuitive to enter the e-mail address in the token field when requesting a new token. This UI should be redesigned a bit to separate the two actions of requesting a token and publishing the document.

General and playground API documentation

There is currently little to no documentation available on:

1. The main playground application, how it works, where you can find certain actions, how to create new documents etc.
2. The JavaScript API made available in the playground. This mainly concerns some of the convenience methods and objects available in the playground, such as models and ui, but also the general structure of the JavaScript user methods.

Improve uncaught shader compilation errors

Currently, when either compiling or linking a shader (program) fails, the relevant tab in the program sidebar is highlighted and its title is set to the occurred error. This works, but it could be nice to also inform the user explicitly in the form of an error overlay message (at least the first time it happens).

Implement autocompletion for glsl

It would be nice to have autocompletion, and calltip information in glsl code, similar as those for JavaScript code. We already have all the annotated type information necessary to do this autocompletion so it shouldn't be too difficult to add something useful.

Allow submitting new github issues on the occurrence of uncaught errors

Such uncaught errors could be simply bugs in the playground, or driver/GPU specific shader compiler/linker errors that are not being caught by the parser/type checker. It would be nice if there is the possibility to create a new issue while attaching the relevant error information (traceback) to the new issue.

Improper extension errors in shader window

When (for example?) enabling EXT_frag_depth in host code and adding:

#extension GL_EXT_frag_depth : enable
//...
void main() {
    //...
    gl_FragDepthEXT = gl_FragCoord.z;
}

The fragment code window is in error display mode ("undefined variable gl_FragDepthEXT") despite correctly compiling, executing and rendering.

Improved support for mobile devices

Currently, mobile devices are simply not supported at all. The basic editor idea doesn't really work on any of these platforms, but it would still be interesting to be able to just view the examples working. For this we need a separate view of the playground which only shows the 3d view, but hides all the editing features. You should still be able to browse the gallery of course and open documents from there.

Additionally, some of the technologies used by the playground might not have wide availability across mobile devices, but I'm really not an export. For example, maybe localStorage, indexedDB or history can't be assumed to be generally supported and we'd need to implement some fallbacks for those cases/

Allow easy embedding of playground documents in existing websites

It would be great if we could allow to easily embed a playground document in an existing website. It shouldn't be too hard since most of the rendering vs application code is already separated. We'd simply need to generate a separate js which external websites could reference, load a document and render it on the website.

Improve JavaScript autocompletion

The autocompletion in JavaScript is currently very primitive, mostly due to simply looking up top-level symbols in a global context, without consideration of locally scoped variables. It would be relatively easy to improve on this a bit by using the AST we already obtain from esprima to resolve some straightforward things like variable assignments, as well as correctly resolving for the context function argument (c).

Allow reverting of locally stored shared documents

Currently when you open a remote document (either from the gallery or using a shared URI), a local copy of that document including its share key are stored in the users indexedDB. The next time the same document is requested, this stored document is opened instead. The reason for this is that this allows you to make local modifications to such document which are automatically stored, while not loosing those same modifications the next time you open the same remote document (or creating a duplicate).

I think this behaviour works well in most cases, but it needs some improvements:

1. It should show whether or not the locally stored document has been modified relative to the remote document (note that remote documents are uniquely identified and can't change, i.e. are immutable under their identifier).
2. Users should be allowed to revert to the original document, or maybe view a diff or something similar.

Importing multiple documents only really imports last one

Importing multiple documents at the same time doesn't seem to work. Even thought the overlay message indicates that all documents have been successfully imported, only the last document seems to be present in the database.

Allow simple commenting on gallery published documents

It is currently not possible to give feedback, or ask questions to the author of published documents. It might be nice to add a very simple, anonymous, commenting system for published documents.

Test support for IE

There is currently at least one issue with running the playground in IE (11), which is that we request a "webgl" context, whereas IE currently only supports the "experimental-webgl" context. There are likely other issues, but it is currently difficult for me to test things in IE, thus the lack of support.

Switching to gallery should exit fullscreen mode

When in fullscreen mode (press 'f' on the 3d view), switching to the gallery should exit fullscreen mode.