• I am a Filmmaker/Researcher/Software Developer with interests in all things to do with Film, Animation, and Screenwriting. I studied for a PhD in Computer Graphics and Animation at the University of Sheffield, did a post-doc focusing on performance capture (face mocap) at the University of Surrey, and recently completed an MA in Filmmaking at the London Film School.


    Javascript Software 3D Renderer

    A few years back I wrote a software renderer in Java, a fun little project which worked quite well. However, Java is now dead, at least in webpages, so I thought I’d have a go at converting it to Javascript and see how it would do.

    You can have a look with the links below, but be warned that this is a bit of a processor hog. The best browser from my testing is Chrome, and Firefox is also ok, whatever you do do not use Internet Explorer the Javascript engine is horrifically bad. It’s also not going to run super fast on a tablet, although I have had it running on an ipad mini retina.

    I took all the maths from OpenGL, but I haven’t copied the function calls so it isn’t a GL implementation. There is no texture mapping at the moment, but it wouldn’t be at all difficult to add – although the speed issues mean that it will probably grind a bit. It does have per-pixel fragment shading, and the shaders I’ve used in the links below use Phong shading.

    Obviously this is a toy project and it has no real practical purpose, especially when hardware rendering is becoming available within browsers. However, it did teach me a lot about the differences in programming Javascript and other languages when it comes to optimisation. JS is quite different in terms of what can slow it down, and requires a modified strategy. In particular indirections in JS are evil, you can make your code much faster just by storing references in local variables.

    The code could probably still go a bit faster. I’m using a barycentric coordinates to interpolate values in the frame buffer. A scanline alternative may give an improvement, although tests did not show a speed up. I think the major blockage is that the renderer is quite complex, it even has its own shader implementation, which makes the render loop expensive. One nice thing about doing this in software is that I can make the background transparent and render on top of whatever background is in the webpage – which could be used to make some nice effects in a browser.

    Ultimately JS implementations are not quite fast enough yet, but Chrome in particular is getting there – so maybe in a couple of years this might be a bit more practical.

    Utah Teapot (3644 vertices, 6320 triangles)

    Happy Buddha (3701 vertices, 7390 triangles)

    Stanford Bunny (35947 vertices, 69451 triangles)

     

    No Comments