Learning WebGL

3D Programming for the Web

12 Responses to “WebGL around the net, 5 April 2012”

1. Bruce Sherwood says:

   April 7, 2012 at 3:38 pm

   Here are details of how to do transparency in WebGL using depth peeling:

   http://www.khronos.org/message_boards/viewtopic.php?f=44&t=4905

   And mouse picking is treated in detail in a response to this post:

   http://www.khronos.org/message_boards/viewtopic.php?f=44&t=4899
2. Bruce Sherwood says:

   April 8, 2012 at 5:20 am

   I should clarify something, not necessarily for your blog but for your own information. You comment that in comparison with GlowScript (glowscript.org), “unglass.io is a more fully-featured 3D design tool that also allows you to share your workspace with other people as you build your content.” This is comparing apples and oranges, but I sympathize with your impression, because even technically strong friends sometimes have a hard time wrapping their heads around what GlowScipt is about. Your blog is aimed at people who are developing WebGL applications, and who necessarily have very high programming skills. Who GlowScript is for is the novice or occasional or nonexpert programmer who needs to create an algorithmically/program based 3D animation, as distinct from using some kind of 3D design tool — people who have the skills to write mathematical algorithms but most definitely do not have the background, time, or inclination to fight their way through something as highly complex as WebGL or OpenGL. The potential users of GlowScript (JavaScript + WebGL) are the same people who use VPython (Python + OpenGL; vpython.org). They include scientists and engineers, and students in computational science courses. GlowScript is really not much like any other WebGL application known to me, as it is an environment within which programmers can use WebGL productively without needing to know anything about WebGL. What may be of interest to implementers of WebGL applications are some of the techniques being deployed in GlowScript, including depth peeling to support transparency, and the details of mouse picking, which is why I’ve just posted descriptions of these schemes.
3. Florian says:

   April 8, 2012 at 11:56 am

   @Bruce

   Note that glowscript uses the GC to allocate things which is the reason why it has a studdering frame every 2 or so seconds. The GC cycle in browsers usually consumes something between 180-250ms of time which is unfortunately very user noticable.

   Another thing I noticed is that glowscript is generally slow (a simple scene runs at only 25fps on my machine which has a gtx-460 in it).
4. Bruce Sherwood says:

   April 8, 2012 at 4:11 pm

   I’m ignorant: what’s a GC? Perhaps from not knowing what to look for I haven’t seen the pauses you describe. For moderately complex scenes with a GT 240 I see 60 fps, such as this 10×10x10 grid of rotating boxes:

   http://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/RotatingCubes

   What is the example where you see low frame rate?
5. Benoit Jacob says:

   April 8, 2012 at 4:46 pm

   Bruce, GC = garbage collection. Browser vendors are working towards avoiding long GC pauses, but that work is still ongoing.
6. Bruce Sherwood says:

   April 8, 2012 at 9:13 pm

   Thanks. I should have figured that out for myself. I’m unaware of what alternative there is to the automatic garbage collection. GlowScript runs in a strict mode that requires “var”, so there aren’t globals to be garbage collected. There is use of “new”, not always paired with an explicit delete. Is it considered good practice to be scrupulous in the use of delete? Or to avoid new? Is the “stutter” that I haven’t noticed a feature/bug of GlowScript or a general problem that’s being worked on?
7. Florian says:

   April 8, 2012 at 10:34 pm

   Delete does not delete anything, it merely removes the name from the closure or object it refers to.

   “new” comes in many forms, those are: [], {}, new and function(){}

   The key to avoiding GC stuttering is to avoid allocating things during a running loop (i.e. in the draw callback, physics callbacks, etc.).
   Any allocation, any lists, objects, explicit objects with new and function bodies will all pile up on the GC. Integers and strings are mostly ok, it would seem that they get shortlisted by GC because they are immutable and cannot refer other objects.

   The alternative to allocating things is pre-allocating them, so you don’t have to during the runtime. Among other things it means you will have to use a stilted way to deal with vectors in order to avoid copying semantics on vector-ops. You will also have to avoid building dynamic structures of anything that you can’t stick in fixedly allocated lists, objects or typed arrays.
8. Bruce Sherwood says:

   April 9, 2012 at 4:25 am

   Thanks much, Florian, for the concrete advice. Two specific questions: 1) Are you saying that upon exit from a subroutine local variables and functions are not deleted? For example, should most functions and variables be moved outside of the main render function? 2) What specifically did you have in mind when you said, “Note that glowscript uses the GC to allocate things”? (I had assumed that all JavaScript programs used the GC to allocate things.)
9. Bruce Sherwood says:

   April 9, 2012 at 5:07 am

   I just realized something, Florian, about seeing a low frame rate. While it is of course easy to write a GlowScript program that is sluggish, it’s possible that you viewed a demo which has a deliberately chosen low frame rate. A GlowScript option lets you specify no more than N iterations of an animation loop per second, so that an animation will run at the same speed on all computers (that is, all computers fast enough to do N iterations per second). It’s a clamp.
10. Florian says:

    April 9, 2012 at 8:31 am

    @Bruce

    1) At exit from a subroutine is a slightly wrong term for JS. In JS each function is a closure, that’s embedded in a stack of closures. From within that closure all upscope closures can be accessed. A function body in JS is more like a special kind of object because it can have references to other things which survive the lexical scope of the closure. A typical case for this is:

    f = (function(){ var a=1; return function(){console.log(a++)} })();
    f() –> 1
    f() –> 2

    Likewise JS does not really have variables, closures keep named references to objects (numbers, strings, lists, objects and other closures). If an object is no longer referenced it is going to be deleted at some point (at the next GC collection cycle).

    2) Using the GC to allocate things means that you’re using either of these inside of your drawing loop: obect: “{}”, list: “[]“, explicit object: “new Anything” and function: “function(){}”.

    A typical piece of code doing this would be:

    var draw = function(delta){
    physics.step({
    delta: delta,
    onCollide: function(){ … }
    }}
    }

    This allocates one object (via object literal) and one closure object via function definition per frame.

    You will have to rewrite this to

    var onCollide = function(){ … }

    var draw = function(delta){
    physics.step(delta, onCollide);
    }
11. Jochen_0x90h says:

    April 10, 2012 at 10:43 am

    New WebGL demo “Radiotherapy” by Alcatraz & Scoopex released at revision demoparty:
    http://pouet.net/prod.php?which=59133
    (created with Inka3D)
12. giles says:

    April 11, 2012 at 2:01 pm

    @Bruce — many thanks for the clarification! FYI I’m not getting a GC judder on my Windows Vista machine using Chrome, so there’s presumably browser or OS dependence in how much of an issue this is. You might find this article from last week’s roundup useful, though: Brandon Jones on Javascript memory optimization and texture loading

    @Jochen_0×90h — thanks! I’ll put that in this week’s roundup.