Loading ...
Sorry, an error occurred while loading the content.

CanvasTastic - 3d lib for canvas developers

Expand Messages
  • Andrew
    http://matt.west.co.tt/talks/canvastastic/ http://matt.west.co.tt/javascript/canvastastic-beta-1/ Just ran across this and knew it d be of interest here.
    Message 1 of 3 , Sep 15, 2006
    • 0 Attachment
      http://matt.west.co.tt/talks/canvastastic/
      http://matt.west.co.tt/javascript/canvastastic-beta-1/

      Just ran across this and knew it'd be of interest here. Anyone else
      tried this out?
    • Philip Taylor
      ... That looks quite interesting, particularly with the gradient lighting - though it does seem to suffer from the usual 3D-in-2D-canvas problem of poor
      Message 2 of 3 , Sep 15, 2006
      • 0 Attachment
        On 15/09/06, Andrew <andrew@...> wrote:
        > http://matt.west.co.tt/talks/canvastastic/
        > http://matt.west.co.tt/javascript/canvastastic-beta-1/
        >
        > Just ran across this and knew it'd be of interest here. Anyone else
        > tried this out?

        That looks quite interesting, particularly with the gradient lighting
        - though it does seem to suffer from the usual 3D-in-2D-canvas problem
        of poor performance, which probably limits its usefulness somewhat.
        (And we can't simply wait a few months for computers to get fast
        enough - they're just adding more cores, which doesn't help
        single-threaded JS...)

        One issue it raises is that I'm not entirely convinced by the idea of
        putting everything into a scene graph and leaving it there for a long
        time, thinking mainly in the context of 3D games [which is possibly
        too limited a view...] - I can imagine too many cases where it'd make
        things more difficult than necessary, particularly when
        adding/removing/changing things in the world. Even in cases where a
        tree structure would initially make sense, like a man in a boat
        holding a rock, it'd require complex tree manipulation if you want
        that man to throw the rock; I'd probably be tempted to just make
        everything a direct child of the root node, which would defeat the
        point of having a graph. Otherwise I'd be tempted to empty and rebuild
        the scene every frame (immediate mode vs retained mode as mentioned in
        [1], or like canvas vs SVG) when trying to render a dynamic world, to
        avoid the need to keep the renderer's scene graph in sync with the
        world.

        A useful advanced rendering system would also have to be able to
        represent complex constraints and orderings - e.g. rendering onto a
        shadow map from one camera with texturing disabled, then moving to a
        different camera and drawing shadowed terrain then water then solid
        objects then transparent objects, etc. For non-trivial situations,
        that seems more convenient to specify as application-specific code
        than as a data structure. I'd be happier if the API provided a
        procedural way of drawing individual models, and then people could
        build on top of that to support their own unique rendering needs.

        So I guess I'd like Canvastastic (or other libraries with similar
        intent) to expose the individual functions for drawing arrays of lit
        polygons, setting the current transformation matrix, moving the camera
        even in the middle of a frame, etc, and have the current scene system
        be a completely separate layer that's replaceable by people who want
        more flexibility. It's possible that I'm thinking of situations that
        are more complex than the canvas would ever be sensibly used for, but
        there's no fun in always doing things the sensible way ;-)


        Anyway, I tried using Canvastastic in
        http://canvex.lazyilluminati.com/3dmodel/example0.html (requires
        Firefox 2.0+, with JS1.7 and E4X (used for loading COLLADA models)) -
        it works surprisingly fast at about 1fps for ~1500 triangles, though I
        suppose that's not very good for practical use and it has nasty
        depth-sorting artifacts. That example also has an option which uses
        the gles11 context [shouldn't that really be moz-gles11?] from the
        relevant Firefox extension, which seems to get clamped at about 45fps
        and still gives about 15fps when drawing the same model ten times per
        frame. That's a much faster way of doing 3D, but it's currently
        lacking in browser compatibility - so anything that works with the 2D
        canvas still seems useful, and it'll be interesting to see what people
        continue to make with it!


        [1] http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D

        --
        Philip Taylor
        excors@...
      • Matt Westcott
        ... That sounds reasonable enough - I wouldn t be against doing something like that in a future version. Extra layers of abstraction tend to be a good thing,
        Message 3 of 3 , Sep 18, 2006
        • 0 Attachment
          --- In canvas-developers@yahoogroups.com, "Philip Taylor"
          <excors+yahoo@...> wrote:
          >
          > So I guess I'd like Canvastastic (or other libraries with similar
          > intent) to expose the individual functions for drawing arrays of lit
          > polygons, setting the current transformation matrix, moving the camera
          > even in the middle of a frame, etc, and have the current scene system
          > be a completely separate layer that's replaceable by people who want
          > more flexibility.

          That sounds reasonable enough - I wouldn't be against doing something
          like that in a future version. Extra layers of abstraction tend to be
          a good thing, and I doubt it would make much difference to performance
          - from this and other experiments with graphics in Javascript, I've
          consistently found that the actual rendering is the bottleneck, and
          you can get away with a whole lot of calculation and data processing
          under the hood without it making an awful lot of difference to the end
          result.

          There's no deep reason why it's implemented the way it is - I don't
          have a huge amount of experience with real-world 3D APIs, so I just
          went ahead with what seemed logical to me. Also, it was first
          implemented as a standalone 3D demo
          <http://matt.west.co.tt/demoscene/gallions-reach/> and then the
          library part extracted out, rather than being developed as a library
          up-front, which might partly explain any lack of generality.

          As you mentioned in your blog comment, the 'layered' approach also has
          the benefit of potentially allowing the low-level part to be swapped
          out with a wrapper for one of the forthcoming OpenGL-like canvas
          backends. Of course, the problem there is that once someone starts
          seriously pushing that combination, it suddenly makes the original 2D
          backend rather inadequate...

          > It's possible that I'm thinking of situations that
          > are more complex than the canvas would ever be sensibly used for, but
          > there's no fun in always doing things the sensible way ;-)

          Well, quite - I think doing 3D in Javascript is past most people's
          threshold of madness anyhow, so who's counting? :-)
        Your message has been successfully submitted and would be delivered to recipients shortly.