Thursday, October 22, 2009

WebGLU, the Open Source WebGL Utility library hits v0.2

I've just wrapped up v0.2 of WebGLU. I'm working on updating the full documentation, I hope to be done with it later today, or some time tomorrow. v0.2 is already in the SVN repository on WebGLU's SourceForge project page, or you can just download it directly.

To see how useful WebGLU can be, check out my 50 line demo.

I need feedback. If you want to do something with WebGL and WebGLU can't help, or using it hurts performance, please let me know!

WebGLU v0.2 Features/Changelog

WebGLU Library

  • Added WGLUShader
  • Added WGLUShaderProgram
  • Added WGLUTimer
  • Added WGLUFPSTracker
  • Updated WGLU
  • Updated WGLUObject
  • Updated WGLUAnimation (still a kludge though)
on that note, anyone know a good (read: non perfomance degrading) namespacing alternative for javascript?

WGLU Class

  • Added camera property to store various rendering data (position, target, aspect ratio, etc.)
  • Added an internal timer and fps tracker
  • Added WGLU.draw() which covers the standard use case (Identity modelview matrix ;perspective and lookAt multiplied projection matrix, params for the perspective and lookAt matricies is taken from the camera propery. Then calls WGLU.drawObjects())
  • Added WGLU.update() which covers the standard use case (tick the timer, update the fps tracker, update all objects)
  • Added WGLU.newProgram(name) which initializes a new WGLUShaderProgram and stores it in WGLU.programs[name]
  • Added logging calls to code, using callbacks instead of ifs
  • Added logging callbacks for Firebug, example output below.
  • Removed makeQuad and makePyramid until I've updated them
  • Removed calculateNormals as I've never actually used it, I'll add it back when I do

WGLUShader Class

  • Automatically tracks and manages its compilation status and notifies any shader programs using it if it needs recompilation
  • Parses attribute and uniform names and type specific length from the shader source automatically
  • Assumes uniforms named 'ModelViewMatrix' and 'ProjectionMatrix' are just that and assigns per object actions to them accordingly. You can also set them yourself with WGLUShader.setModelViewUniform(name) and WGLUShader.setProjectionUniform(name)
  • WGLUShader.getGLShader() [re]compiles the shader if needed, then returns the WebGL shader object usable in WebGL calls. 

WGLUShaderProgram Class

  • Automatically tracks and manages its link status and the compile status of all attached shaders, [re]linking/compiling if needed.
  • Keeps track of its shader's attributes, including their name, location from getAttribLocation, length, and a buffer.
  • Keeps track of its shader's uniforms, including their name, and action to perform per object.
  • Calls to attach shaders by id (from a script tag), by source code, or as a WGLUShader

WGLUObject Class

  • Any created objects are automatically added to WGLU's object list, don't know if I'm going to keep it this way though
  • Keeps track of the shader program to use when rendering.
  • WGLUObject.setElements(elementArray) switches the object to using drawElements instead of drawArrays. Call WGLUObject.setElements(false) to switch back.

Well, that's the biggest stuff anyway, there's tons of little things though. As promised, here's some logging output.


6 comments:

  1. It’d be much more useful if you avoided using Mozilla-specific ECMAScript extensions. Then it’d be much more likely to work in WebKit too.

    ReplyDelete
  2. @bdash, I only realized that what I was using was Mozilla-specific today for two reasons.

    One, I'm new to javascript, in fact this is my first time really using it.

    Two, I based my decision on the table in the javascript Wikipedia article, which shows Chrome and Safari supporting javascript 1.7 including `let`. http://en.wikipedia.org/wiki/Javascript#Vesions

    So, I went though the code a few hours ago and converted some stuff, I think I got it all. However if you think I missed something I'd really appreciate it if you filed a bug report.

    ReplyDelete
  3. Stick to ECMAScript 262 3rd edition if you want to be at all portable. There are no formal specifications for any of the functionality that Mozilla brands as “JavaScript 1.7” so it’s much less likely to be portable between JavaScript engines.

    ReplyDelete
  4. @bdash, thanks, bookmarked a copy and will go over it later.

    ReplyDelete
  5. Maybe run your code through "JSLint" too?
    http://www.jslint.com/

    ReplyDelete
  6. Well, v0.1 went through JSLint, haven't put v0.2 through, thanks for the reminder.

    ReplyDelete