#61 paves the way for setting up CI to automatically test all PRs as they come in. The next step would be to set up a service like travis. To do this we would then need someone with admin access on luma.gl to do the following:

Create an account on travis
Turn on travis integrations for luma.gl
Set up the travis.yml config script
(Optional) Maybe add a CI badge too
After it is all set up, we'll get immediate feedback on any PR like this, which greatly simplifies code review

Can find examples of variable difficulty http://codeflow.org/entries/2013/feb/15/soft-shadow-mapping/. I would limit to the directional light example.

After running:

git clone [email protected]:uber/luma.gl.git
cd luma.gl
npm install
npm start

and going to an example page (like http://192.168.1.154:3000/dist/core/instancing/), there's just an error message:

'import' and 'export' may only appear at the top level (4:0) while parsing /Users/adam/Desktop/luma.gl/dist/bundle.js while parsing file: /Users/adam/Desktop/luma.gl/dist/bundle.js

The dist/core/mandelbrot/ page loads, but /dist/core/mandelbrot/bundle.js 404s and the javascript console on the page says Uncaught ReferenceError: LumaGL is not defined.

Also - I'm not sure if budo can delay opening a tab until the initial build is complete, but the browser tab that auto opens flickers for 15 seconds as it try to live reload every time a file is generated.

Our model knows how to combine programs (shaders), attributes and uniforms.

It is also the base class for our geometric primitives (planes, cylinders, spheres etc). But geometric primitives are typically only a set of attributes and some props like drawType.

A separate geometry or attributes class that can be installed on a Model might be a more flexible setup, that would allow the overly broad Model class to become more focused.

Also compare attributes.js in deck.gl performance branch, it could be a good base for a geometry/attributes class.

@mikolalysenko

Current plans for luma.gl v4.0

WebGL2 support

• Add new WebGL2 classes
• Add WebGL2 features to existing classes
• Add docs
• Add test cases

GL state management

• Scaffold new state manager
• Make state manager handling framebuffer bindings
• Build state management into render calls

Documentation Overhaul

• All classes documented in markdown
• Examples ported to ES6

Polish

• Coverage/Coveralls badge

@wwwtyro - The local server (nmp run start) shows a directory listing including a lot of non-example related files. It would be nice to have a more visually appealing and clear landing page.

I am also wondering if we can now show multiple lessons in one page - with your latest changes we now support multiple parallel gl contexts. It'd be neat to just be able to scroll through all the lessons on a single page rather than click back and forth.

Not entirely certain how possible this is given git's distributed nature. If it's not, we could always tie into jenkins or travis for PRs. Those might be better or a good addition, because then we could do things like publish to npm or build dist (to a branch separate from master, which would be nice) automatically.

@wwwtyro A couple of your PhiloGL PRs happened after we forked, we need to get your changes moved over asap

@ibgreen and I discussed that a globe responsive to clicks would be useful for learning purposes, and he's told me to open an issue. Lesson here.

This method creates immutable textures that have better performance.

according to https://www.khronos.org/registry/webgl/specs/latest/2.0/

void texStorage2D(GLenum target, GLsizei levels, GLenum internalformat, GLsizei width, GLsizei height) (OpenGL ES 3.0.4 §3.8.4, man page)
Specify all the levels of a two-dimensional or cube-map texture at the same time.

The image contents are set as if a buffer of sufficient size initialized to 0 would be passed to each texImage2D call in the pseudocode in The OpenGL ES 3.0 specification section 3.8.4 (OpenGL ES 3.0.4 §3.8.4).

texStorage2D should be considered a preferred alternative to texImage2D. It may have lower memory costs than texImage2D in some implementations.

From discussion in #136

Since picking is not generally implemented in luma.gl, do we still want to have this property here

It is used but in deprecated code.
https://github.com/uber/luma.gl/search?utf8=%E2%9C%93&q=isPickable&type=

Also there is a picking example that uses this (the one that shows the different planets)

We should review this functionality - either delete it, or undeprecate it and document it.

ShaderCache has a couple of issues.

• shaders need to be cached per gl context, we could leverage a new context storage association mechanism developed for GL state management to get per context caching.
• The luma.gl Shader class has a delete method but we do not do reference counting, meaning that shared contexts are vulnerable to deletion. Consider adding reference counting.

On master, Safari and FF first throw an error on this Float32Array initialization. Getting past that, this.state.model is null in ScatterplotLayer in deck.gl.

I'm not clear on how much effort we're putting into keeping master unbroken across repos, so feel free to file this away for later. However, it's blocking investigation into visgl/deck.gl#652.

@wwwtyro http://uber-common.github.io/luma.gl/examples/lessons/15/

I used a index to decode the vertices position in vert shader,but doesn't work.

when I render this model, it renders nothing, and I got this:

what does it mean 'gl.NONE'?

Scenegraph.js has limited support for nodes but is currently broken. Ideally we should have a Group element in our model hierarchy that can contain other models and groups. Groups should be able to have local coordinate systems (scale, position, rotation, etc - full 4x4) that should recursively be applied to any child Models as they are traversed.

There should be a traversal method that maintains a matrix stack and push and pops transformation matrices as we recursively walk the tree.

Can be based of this and this.

Ideally with shadow mapping, like this beautiful thing! https://vine.co/v/iiUzevHT1Xj

I also have some ideas for realtime particles with participating media (http://www.cs.dartmouth.edu/~wjarosz/publications/dissertation/chapter4.pdf) which could be cool or sucky, not sure. :P

https://github.com/uber/luma.gl/blob/021b244970db81e131bfe2d9b7c42cbe98d9ac66/src/webgl/texture.js#L400

Breaks due to:

https://github.com/uber/luma.gl/blob/021b244970db81e131bfe2d9b7c42cbe98d9ac66/src/webgl/texture.js#L124

@wwwtyro - we want to drive a render loop to generate bitmaps that we can either export one by one or (eventually) feed into a video generation tool. We could modify any existing example. For now we could use window.saveAs or a polyfill to save the bitmaps one by one.

@mikolalysenko is working on headless-gl support so eventually we will make this all work on the server but for now we can start with this in the browser.

@philogb

It's currently rather difficult to debug shader errors because of a lack of context. Use https://www.npmjs.com/package/gl-format-compiler-error to make this more manageable.

• App should be able to switch back and forth between debug context and real context (right now once you turn on debug, that's it, you have taken the perf hit for the entire session).
• Also we need to get the new Khronos webgl2 debug support integrated. I am trying to see if I can get a life sign from current maintainer of the npm fork: vorg/webgl-debug#1
• We should improve the isWebGLContext detection code - current support for debug contexts is hacky. We could save the original context as a member of the debug context, and then do the instanceof check on that member instead when present.

Also see review comments in #136

Evaluate whether it makes sense to move the shader building structure to use glsl-parser and gl-shader to build the shaders in philogl. If it does make sense, then change it.

For example, the raytraced lighting (advanced) example here: http://glslb.in/

This is intended to be a <20min task. Just add a few test cases that construct our basic classes in the src/webgl directory and call a method or two. context funcs, Program, Buffer, Texture classes.

This will validate the electron integration #61

I am thinking we should have a structure with a -spec.js file matching each source file.

• test/webgl/buffer-spec.js
• test/webgl/program-spec.js
• test/webgl/buffer-spec.js
• test/webgl/index.js

alubox:luma.gl-master stevenbeeckman$ npm install
npm WARN prefer global [email protected] should be installed with -g

> [email protected] install /Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/gl
> prebuild --download

prebuild WARN install Prebuilt binaries for node version 0.10.40,0.12.7,1.0.4,1.8.4,2.4.0,3.3.1,4.1.1 are not available
prebuild ERR! configure error
prebuild ERR! stack Error: Invalid version number: 0.10.40,0.12.7,1.0.4,1.8.4,2.4.0,3.3.1,4.1.1
prebuild ERR! stack     at getNodeDir (/Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:69:25)
prebuild ERR! stack     at /Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:41:7
prebuild ERR! stack     at /Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:393:9
prebuild ERR! stack     at ChildProcess.exithandler (child_process.js:193:7)
prebuild ERR! stack     at emitTwo (events.js:106:13)
prebuild ERR! stack     at ChildProcess.emit (events.js:191:7)
prebuild ERR! stack     at maybeClose (internal/child_process.js:850:16)
prebuild ERR! stack     at Socket.<anonymous> (internal/child_process.js:323:11)
prebuild ERR! stack     at emitOne (events.js:96:13)
prebuild ERR! stack     at Socket.emit (events.js:188:7)
prebuild ERR! not ok
prebuild ERR! build Error: Invalid version number: 0.10.40,0.12.7,1.0.4,1.8.4,2.4.0,3.3.1,4.1.1
prebuild ERR! build     at getNodeDir (/Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:69:25)
prebuild ERR! build     at /Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:41:7
prebuild ERR! build     at /Users/stevenbeeckman/Downloads/luma.gl-master/node_modules/node-gyp/lib/configure.js:393:9
prebuild ERR! build     at ChildProcess.exithandler (child_process.js:193:7)
prebuild ERR! build     at emitTwo (events.js:106:13)
prebuild ERR! build     at ChildProcess.emit (events.js:191:7)
npm ERR! Darwin 14.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.2.0
npm ERR! npm  v3.8.9
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: `prebuild --download`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the [email protected] install script 'prebuild --download'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gl package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     prebuild --download
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs gl
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls gl
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/stevenbeeckman/Downloads/luma.gl-master/npm-debug.log

Adapting package.json so "gl": "^3.0.5" makes npm install work.

We need to add test cases in luma.gl to cover the failed size deduction in visgl/deck.gl#683.

Landing visgl/deck.gl#684 will help debugging in deck.gl

On dev branch, io/ isn't transpiled since it's out of the src/ folder. This causes issues with loading the library since it still requires transpilation when consuming the library.

Ref:
0a8aabe#commitcomment-17568765

• withState / withParameters
  Right now, scissorTests and framebuffer state are handled in withParameters, not in withState. We should eventually make withState handle every GL state.

• setParameters / setValues
  When to use setParameters and setValues are a bit confusing. We may consider clarify these two functions in docs or combine them.

• State manager also need to correctly handle those enable/disable states, as right now GL state cannot be disabled through our state manager.

@wwwtyro
256(index):1 [GroupMarkerNotSet(crbug.com/242999)!:D0AC894CA37F0000]PERFORMANCE WARNING: Attribute 0 is disabled. This has signficant performance penalty
(index):1 WebGL: too many errors, no more errors will be reported to the console for this context.

@wwwtyro

Working on linux (Ubuntu 14.04) - I see strange results.

Chrome - linux - 52.0.2743.116

Firefox - 48.0

I have tried enabling gpu renderings and webgl 2.0 in the flags:
http://askubuntu.com/questions/299345/how-to-enable-webgl-in-chrome-on-ubuntu

I have tried a similar thing with about:config.

Any ideas what flags or versions I should be running to get this to work on linux?

@wwwtyro We need to do quick pass on the markdown files in the docs folder

Broken: http://uber-common.github.io/luma.gl/

Code: https://github.com/uber/luma.gl/blame/master/README.md#L9

After #136 , FramebufferObject class from the deprecated/fbo.js that deck.gl is dependent on is no longer exported. This breaks deck.gl.

The replacement Framebuffer class is imcompatible with the previous FramebufferObject. This needs to be solved before we release a new luma.gl version

@wwwtyro - The code should not crash by trying to access global browser state like window etc that is not available in Node.js.

Even when WebGl is not available:

• createGLContext should through a descriptive Error exception ('WebGL not available') or similar.
• hasWebGL and extension queries should report false

This issue is the root cause of deck.gl issue 248. When clicking on a luma.gl view which is partially scrolled off screen by the pages scroll bar, relative mode click positions are incorrect. This issue does not occur if the luma.gl view is scrolled off screen by a containing elements scroll bars.

I think I've identified what's causing this issue. In the calculation of relative event positions, pos is subtracted from x/y (which is epos). Since epos is page relative, but pos is client relative, positions are incorrect if the client has scrolled the page. EventsProxy options used are relative true and centerOrigin false.

Is my reasoning correct? If so, I'll can submit a PR which addresses the issue.