As much as I really like ES6 there are some things holding me back:

• the first iteration will accumulate a lot of code that can be pulled out into separate modules -- for example ray-sphere-intersection. The overhead of dealing with ES6 in small modules is a bit frustrating
• GitHub does not syntax highlight it correctly
• The transpiled source is usually pretty horrific; usually source maps hide this but sometimes you need to wade through it debugging/perf/etc

Maybe in time it will make more sense (taking advantage of SIMD, operator overloading and Value Types). Either way, the library should be usable without Babel or any fancy syntax transforms.

Right now this repo is just brainstorming ideas about creating a new WebGL framework.

This might be my new pet project, or maybe something more collaborative, or maybe nothing will happen and we'll just continue getting shit done with ThreeJS. 😄

what's wrong with ThreeJS?

It's awesome! But my main gripes:

• really bloated
• the size/breadth makes it difficult to contribute to, prone to bugs
• no official support for package managers
• no real versioning; difficult/impossible to build features on top of it that survive more than a single version
• no clearly defined scope; aims to do everything under the sun
• custom shaders are clunky to write, lots of magic under the hood
• targets a mostly non-WebGL audience, so a lot of low-level stuff is hidden form user (e.g. dynamic texture atlasing would be difficult/impossible in ThreeJS)
• gamma handling is currently broken [see here]

what about StackGL?

Also awesome, and not mutually exclusive to a new framework. Tons of modules will be useful, especially glslify. And many parts of the framework can be modularized and "given back" to stackgl ecosystem. However:

• immediate mode does not scale well for a high performant game engine
• there is a lot of redundancy in state switches and calls to gl.getParameter
• for the sake of modularity, there are some things an opinionated framework can do without, e.g. the caching in gl-shader [see here]
• right now there is some bloat/complexity due to Buffer, ndarray-ops etc which may not be needed
• in a multi pass G-buffer pipeline there ends up being a lot of coupling; hard to stay totally modular and you end up jumping through a lot of hoops instead of getting real work done
• it can be hard to know how to glue all the modules together
• in some ways it is more focused on research/etc than gamedev/VR
• the "Open" nature of stackgl means you end up with a lot of different styles & programming backgrounds, and not as clear a vision/direction for the project as a whole

so what about this imaginary new framework?

Let's call it glo for now (name pending) since light is going to be important. Nothing is clear but here are a few ideas:

• focused on G-Buffer / deferred render pipeline / physically-based rendering
• play nicely with WebVR
• gamma/linear should be handled correctly through entire pipeline
• uses glslify to keep shaders modular
• target audience should have a decent understanding of WebGL/GLSL
  • do not try to hide or dumb-down GL things
• optimize for perf & memory during rendering
  • e.g. don't hold onto unrolled vertices like in THREE.Geometry
  • but also don't fear concise and functional code, especially during initial development
• look into WebGL2 features
• explore modern practices like:
  • Compact Normals for G-Buffers
  • Aggregate G-Buffer Anti-Aliasing
  • Image Space Photon Mapping (GI)
  • Depth of Field

few notes on implementation / structure

• use feross/standard for style
• unit tests with smokestack 🎉
• follow SemVer; stay at 0.0.x for a while until things stabilize
• provides some abstraction for "Geometry", "Mesh", "Light" like in ThreeJS
• should not make sweeping assumptions about attribute types (i.e. should be more like THREE.BufferGeometry than THREE.Geometry)
• keep it slim; encourage growth in npm rather than the framework, e.g.
  • keep scope limited; I don't have time to manage 1000s of issues
  • instead of a built-in OBJ parser, user needs to use parse-wavefront-obj
  • same for triangulation, camera abstractions, torus-mesh, etc
  • debug/prototype stuff that never makes it into production should not be bundled into framework (like THREE.ArrowHelper)

big questions

Well.. there's a lot of things to figure out. But let's get the obvious questions out of the way:

• Vector types: should they be arrays or objects? [discussion]
• How wide is the scope of this framework?
• How high-level does the light abstraction go? Do we have hemisphere, area, directional, etc like in ThreeJS? Or do we just provide a thin interface and encourage growth in npm / userland?
• Same with materials: include Phong/Lambert/Glass/etc? Or should they be separate modules?
• What is the airspeed of an unladen swallow?
• What if the user doesn't want G-Buffer, just a simple pipeline?

Things like Vector, Color, Matrix4, etc.

It can be super frustrating dealing with code that looks like this:

tmp[0] = 5
tmp[1] = 0
tmp[2] = 0
obj.translate(tmp)

//or
vec3.add(obj.position, obj.position, somethingElse)

Instead of:

tmp.set(x, y, z)
obj.translate(tmp)

//or
obj.translate(somethingElse)

However.. array types have a lot of benefits including:

• code re-use; the end goal here is not to create yet another ThreeJS monolith and I don't want to support/maintain custom data types for matrices, quaternions, etc
• scope creep; there is no fear of scope creep since new features can be built independently of the framework and its data types (like mat4-interpolate)
• more functional, allows stuff like filter / slice / map
• n-dimensional algorithms using for loops (e.g. lerp-array)
• the dimensionality is intrinsic -- vec[0] is accessing the 0th component. this is quite elegant mathematically
• better composition with other modules; most npm modules use arrays for the above reasons

So I think array types for all these structures is still the best way to go.

But maybe since this is a fairly opinionated "frameworky" tool, there can be some middle ground that has a nicer UX.

shader

see dev branch for progress

• largely inspired by gl-shader, try to share code where possible e.g. gl-shader-extract
• only have a single program handle, no caching
• keep reloading in mind for live-reload
• provide the best possible UX for error logs, maybe using gl-shader-errors at some point
• glGetUniform calls should be more opaque so the dev doesn't accidentally query GL state
• KISS; avoid initial shader compile etc
• evaluate the gl-shader uniform wrapper approach and whether something else is more suitable