WebGL around the net, 30 May 2011

Have you done something in WebGL you’d like to share? Leave a comment below!

You can leave a response, or trackback from your own site.

9 Responses to “WebGL around the net, 30 May 2011”

  1. Thanks for the mention. :) Just wanted to throw out there that I published the second live demo last night at http://sinisterchipmunk.github.com/meadow.html. Runs great on my Mac, but I was a bit dismayed to find that due to outstanding issues with ANGLE (the subsystem that interprets WebGL calls for Windows), it’s not yet functional on Windows.

    The problem comes down to vertex texture lookups, which are currently unsupported in ANGLE even though about 80% of hardware drivers do support it (http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB).

    ANGLE says VTL support is high on their list, and indeed, I saw some commits earlier (http://code.google.com/p/angleproject/source/detail?r=643, http://code.google.com/p/angleproject/source/detail?r=635) indicating that they’ve already implemented it in trunk. So we should see VTL support in Chrome and FF on Windows before too much longer.

    As for other Jax demos, I’m cooking up 2 more at the moment. One is ~ half finished, the other I’m debating whether to push up there tonight.

  2. Benoit Jacob says:

    @Colin: vertex texture lookups are implemented in ANGLE since r644,

    Firefox/Aurora (to become Firefox 6) is using r653 so it has it already.

  3. jd says:

    I’m having a hard time figuring out an issue with this demo, it works on all my ATI and NVidia cards. However, others are having problems on ATI. An update appears to have gone out for ATI on Windows 7 just recently, please try this link and then let me know if it works along your graphics card model and OS.


  4. @Benoit: Great news! Can’t wait until it’s moved to production!

    @jd: No love on my MacBook Pro, NVIDIA GeForce 320M. I see a golden thingy for what looks like exactly 1 frame, then blackness.

  5. @jd: A little update, the flicker of gold that I saw at first turns out to be a static image :( so it’s all black from the get-go. Also, no JavaScript errors were reported, so that’s kind of unhelpful. I get exactly the same results in Chrome as I do in FF. For what it’s worth, I’ve been doing some tests with the same noise library you’re using (Ashima), so that’s not causing the problem.

    I’ve just made the Jax noise functions automatically query whether VTL is supported, and silently fall back to Ashima noise (per @jd’s example) if it’s not. It runs more slowly with Ashima (about half the FPS on my mac) but it does run, so I call that a win. When VTL support is working in Windows, Jax noise should just magically run faster on supported devices, and still be robust enough to not crash on devices that don’t support it. I’ve now tested the ‘meadow’ demo (see my first comment, above) on Chrome + Win7 without issue.

  6. @jd: Very strange. I don’t really understand what your code is trying to do, so I can’t go further on my end without some background, but here’s what I’ve found:

    I don’t think it’s a driver issue, at least on my machine, because the shaders compile and link properly; the render loop starts; all is happy and dandy. I’ve put debug lines at each of your ‘catch{}’ blocks and alerted the results of each step of the load process; everything goes smoothly.

    The variable +interval+ within the #in_out function seems to be the culprit. Its current value is 65536. By lowering it, I was able to get some visuals. I currently have it set to 37302.821. I’ve been slowly incrementing it, searching for the breaking point. I’ve come to the point now that if I increase it by just 0.001, the screen goes blank. As the number grows, the camera seems to be positioned closer to the edge of the world. So with a value of 65536, we’re well beyond the edge of the world with no hope of seeing it or finding it. I think that’s the core of the problem… but I don’t know enough about your program to take it further. I also don’t understand why this error would be prevalent on some machines but not others, unless it comes down to floating point precision or something along that line.

  7. Christian says:

    @jd: Just a black canvas here too, using an HD 4870 on Windows 7. Catalyst 11.2 and 11.5 (the latest version) gave the same result. All the JavaScript seems to run fine, and I see no errors in either Firefox or Chrome. Looks like it might be something in the shaders themselves?

    @giles: Finally something to contribute! I’ve set up a blog with, so far, an interactive fractal demo

    and an introductory tutorial to XML3D

    XML3D is a new declarative framework we’ve been working on that handles the WebGL back end while letting you define meshes, shaders and other objects through XHTML elements, similar to X3DOM. You can check it out at

  8. giles says:

    @Colin — looks like the demo is working nicely with your workaround, even on my least-reliable machine! The others on the Jax page look OK too.

    @jd — here’s something that might help (but will probably just make things more confusing — the other day I tried out your demo, didn’t see anything, and then put my laptop to sleep without closing the page. When I re-opened it, the demo appeared to be working. Very weird! I think it was Chrome — either way, it was Windows 7, ATI graphics.

    @Christian — thanks for the links — I heard about XML3D a year or so back, when it was separate to WebGL but the plan was to switch to a WebGL back-end. It’s good to see that’s worked out!

  9. jd says:

    Thanks for the help guys. I’ll try modifying the in_out to a lower range.

    Basically all I have is a flat sheet of vertices, I render and display it twice using ashima noise. The first pass does the ceiling, and 2nd the floor. Then to prevent a rolling artifact on the vertices I do a modulo step to lock their positions in space.

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter