Lindsay Stanley Kay

SceneJS boundingBox Nodes

2010-03-02T02:53:00.000-08:00

SceneJS V0.7.0 now has boundingBox nodes, which specify the spatial boundaries of scene graph subtrees so that the subtrees are only traversed when their enclosing boundingBoxes intersect the current view frustum. When configured with a projected size threshold for each child, they can also function as level-of-detail (LOD) selectors.

Before I show you how to define them, take a look at this demo in which an array of objects are wrapped in LOD boundingBoxes so that they are each represented as cubes at the lowest level, then as spheres at the next level, then as teapots at the highest level:

To define a boundingBox that functions as both a frustum-culler and a LOD selector, configure it with both an axis-aligned boundary and a levels parameter like so:

This boundingBox will select exactly one of its child nodes to traverse for its current projected size, where the levels parameter specifies for each child the size threshold above which the child becomes selected. No child is selected (nothing is drawn) when the projected size is below the lowest level.

No automatic generation of boundingBoxes (or boundingBox hierarchies) is provided in V0.7.0. That's a tricky problem that will require some head-scratching. There's nothing stopping the scene-creation process (ie. exporter script or human) from creating hierarchies in the mean time, however.

Efficiency

Best case

SceneJS's view frustum is calculated from the combined View and Projection matrices using the technique by Grib and Hatmann, so the boundingBox's optimal case is when there are no modelling transform nodes (ie. rotate, scale, translate) above it, where its specified axis-aligned boundary can be tested directly against the frustum with no transformation.

Next-best case

If there is a model transform node, then the axis-aligned boundary is converted to an oriented bounding box (ie. of six 3D coordinates), which is transformed by the Model matrix, then converted back to an axis-aligned box for testing against the frustum.

If the model transform is statically configured (by a parameter object and not by a function), then the boundingBox can just memoize and then subsequently re-test the axis-aligned box against the frustum.

Worst case

When a higher model transform is dynamically configured, then the boundingBox must assume that the model matrix will change. In such case it will always recreate the oriented box coordinates, transform those, convert them to an axis-aligned box, then and test that against the frustum.

The moral of the story is: don't use boundingBoxes for large quantities of moving things. However, they are awesome for bounding static scene content and should be used liberally for the best case.

Custom SceneJS Shader Nodes

2010-02-23T15:31:00.000-08:00

Update March 16, 2010: This feature, the SceneJS.shading node, has been removed from SceneJS V0.7.0, which now automatically generates GLSL shaders internally, fitted to current scene state (number of lights, textures etc) as required by geometry elements. For efficiency, the shaders are cached for re-use among geometries that share scene state, each shader mapped against a hash code derived from the scene state. The benefit is that GLSL is now entirely encapsulated within SceneJS. Consequently, the SceneJS.shader node will be removed from the API.

Therefore, I snuck back here and deleted this article.

Thank you.

Extending SceneJS Nodes

2010-02-23T14:23:00.000-08:00

SceneJS V0.7.0 gives you more control over extending SceneJS nodes.

The scene definition API is functional, so what we really do when we "extend a node" is wrap an invocation to its function with a new function. So far we've been able to do simple extensions, such as how people have been extending the geometry node:

Note that V0.7.0 renames SceneJs to SceneJS - sorry about that, I know the grief that kind of thing causes - check the release notes for any more of that.

Note that we are ignoring any arguments passed to our new node, which is fine when your new node expects no parameters or child nodes.

If we wanted to pass arguments through to the wrapped node, we could do this:

That doesn't accomplish much however - what we normally want to do is insert a few special parameters into the wrapped node.

For that, V0.7.0 provides a new utility function, SceneJS._utils.extendNodeArgs, that can intercept the parameters argument and add new members as required. Here's how to extend the shader node to create your own shader:

Oh no, not again! V0.7.0 renames some of the scene nodes for a more declarative feel - in this case "shader" became "shading".

Here are the general cases for how we might invoke our new node:

myNewShading()
myNewShading(node, node..)
myNewShading({ vertexShaders: [ ... ] }, node, node..)
SceneJS.rotate(function(scope) { return { vertexShaders : [ ... ] }; }, node, node..)

In Cases (1) and (2), extendNodeArgs is going to insert the new parameters into the front of the argument array (which is empty in Case 1). Case (3) has a parameters object, which extendNodeArgs is going to augment with the "type" and "fragmentShaders" members, without replacing the existing "vertexShaders".

Case (4) has one of those nifty parameterisation functions that allows you to dynamically parameterise a node during scene-traversal. These functions pull parameters from a data scope that is being passed down through the graph (see the official examples for how that works). For this case, extendNodeArgs is going to augment the result returned by the parameterisation function.

Confused? Well so was I for a bit when I wrote this and I don't expect you to be Joe 90, so I'll be updating the examples with some templates for you to follow.

SceneJS Logger Nodes

2010-02-09T14:52:00.000-08:00

SceneJS V0.7.0 now lets you plug logger nodes into your scene graphs to catch errors, warnings and debug information from nodes that have something to say (such as complaints from assets and textures when they time out). Take a look at this example:

SceneJS always sets up a default logger that pops up alerts for errors and warnings, which you can replace for the whole scene graph by defining your own logger node close to the root of the scene graph. The default alerts are a little pushy, but at least they get your attention!

In this example I'm just that logger it with the same functionality just to show how it's done.

But here I'm also inserting a couple more loggers to show to to override logging for selected portions of the scene graph. In this hypothetical case, we have a couple of nodes that are being a real pain to debug, so we're making life easier by focusing some logging around those, with specially-prefixed messages.

Logging to Webpage

SceneJS V0.7.0 provides a specialised logger that logs to a DIV in the page. Use it like this:

If you omit the elementId, it will look for an element identified as "_scenejs-default-logging". That's so that when you show off your examples in the Playroom they will be able to find the logging element there.

SceneJS Error Management and Logging

2010-02-09T14:21:00.000-08:00

Texture and asset nodes no longer fail silently!

For V0.7.0, scene processes are now managed with a timeout. Timed-out processes are reaped after each scene traversal; each process thats been running too long is destroyed, a message is logged, and its timeout callback is called.

This is super handy for asynchronously loading resources, such as assets and textures. Let's look at assets.

When an asset node is first visited during scene traversal, it fires off a request to a server for a fragment of scene graph (an "asset"). It uses JSONP, which as we know does not tell us much when things go wrong - JSONP inserts a script tag into the DOM that pulls in the remote script - if the asset cannot be found then nothing much happens.

The asset node starts an asynchronous process that will return the asset's scene fragment to it if and when it successfully arrives. Since the transaction is asynchronous and some other node of the scene graph is likely to be currently under traversal, the asset node will just saves a reference to the fragment at that point. Then, when it is next visited, it will connect the fragment as a child and directs traversal down into it. However if the asset hasn't loaded by the time it's next visited, it will just pass traversal on through to the next node.

If the asset never loads, the user may never realise since the asset node will never do anything.

This is where a timeout-managed process is handy. On starting an asset request, the asset node starts a new process,configured with a timeout of (maybe) 60 seconds and a callback to fire in the event of it timing out. Then the asset allows traversal to continue on to the next node. After each scene traversal, SceneJS reaps currently active processes that have timed out. For each of those it logs an error with the new logger backend and calls the timeout, which for our asset node cause it to flag itself as "errored" so that it won't keep trying to load the asset.

SceneJS Memory Management Ninjitsu

2010-02-09T13:33:00.000-08:00

My mission is to have SceneJS never run out of memory.

SceneJS currently manages three kinds of resource in video RAM: shaders, geometry and textures. Each of these have a node type, along with a backend module that does things like create, activate, deactivate and destroy them. These backends I'll call "cachers".

For V0.7.0 I created a "memory manager" backend, against which cacher backends register themselves.

Whenever any backend wants to allocate some resource in video RAM, it will get the memory manager to mediate the allocation, passing in a callback that will attempt the actual allocation. The memory manager will then try the callback and if no exception is thrown by it, all is good and that's that.

However, if the callback throws an out-of-memory exception, the memory manager will poll each registered cacher to evict something to free up some memory in order to satisfy the request. As soon as one of the cachers has successfully evicted something, the memory manager will have another go with the callback. It will repeat this process, polling a different cacher each time, until the callback succeeds. For fairness, the memory manager remembers the last cacher it polled, to continue with the next cacher when it needs to evict something again.

The sequence diagram below shows the general deal:

Each cacher backend is responsible for maintaining its own eviction policy. I'm starting with the Least-Recently-Used variety, where each texture, program of geometry buffer set gets a "last used" timestamp and the one with the oldest timestamp gets evicted. Hopefully, with this strategy SceneJS wont run out of memory, and will at worst just slow down as backends find themselves continually having to reload resources.

Hopefully an LRU policy will capatalise on spatial coherence of scene content, where as long as the viewer doesn't teleport wildly about the scene, there will be a smooth flow of resources in and out of a working set of spatially local elements.

We'll see!

SceneJS Parameterised Assets

2010-01-31T05:14:00.000-08:00

Back in V0.3.0 I introduced asset nodes, which I blogged about back then.

After adding textures to V0.6.0, I started fooling around with the spiral staircase asset and realised that assets can actually be fully parameterised - which could be a rather powerful feature enabling libraries of customisable assets.

In the scene graph definition, we can import a staircase asset, feeding it some custom parameters through a scope node, which sets those on a local data scope for access by the nodes within the actual asset definition:

The result is this marbled spiral of steps:

And here is the asset definition, which finds all those parameters on the data scope:

Note that all those scope reads could be greatly optimised - after all, a scope will hunt all the way up to the root scope for a variable that does not exist on it.

We could wrap the asset definition in a closure containing variables for the parameters, then just initialise the variables from the scope in one hit, say within the config function of that texture node, them refer to those variables in all the assets subnodes instead of repeatedly reading the scope.

SceneJS Selector Nodes

2010-01-27T16:17:00.000-08:00

My last couple of posts on SceneJS bounding volumes and textures got me thinking about levels-of-detail in SceneJS scene graphs. It would be cool, for example, to select which textures are to be applied to child nodes depending on what level of detail we want to show. Or perhaps select an appropriate geometric representation to display.

Level-of-detail (LOD) or "detail culling" is a classic technique whereby we attempt to avoid rendering more than is necessary to create a nice image. Typically, it's done by taking a bounding a volume around a portion of the scene and determining its projected size within the display area. We would configure size thresholds at which different scene representations, of different levels of detail, would be rendered. So when the volume is, say, larger than 300 pixels wide we render the full detail version, when smaller than 100 pixels render medium detail, smaller than 10 render minimal detail etc.

A LOD scene node would then select a child for traversal to descend into for each detail level.

Often, we would only want to select between parents for some child node. Check this idea out:

That's what this node type would do. Recall that a node has a configuration object, followed by a variable list of child nodes. The last node in the child list is the child we'll select parents for, and the preceding two child nodes in the list are the available parents to splice. The configuration selects the second parent.

SceneJS Bounding Nodes

2010-01-26T12:44:00.000-08:00

Pretty soon I'm going to add boundary nodes to scenejs. Here are my current plans for those, subject to me changing my mind and sneaking back here to edit this post to make it look like I knew what I was doing all along.

There will be two ways in which you can use a boundary: 1) with manually-configured extents, or 2) as a hint that you'd like one, automatically created at the desired location in the graph, expanded to enclose geometry in its subtree.

I'll implement support for the use case soon and put that in a release, then leave support for the next case for a day when I've had enough Red Bull.

Update March 16, 2010: manually configured SceneJS.boundingBox node in SceneJs V0.7

Manually-configured extents

The first case is easy - a manually-created boundary is configured with extents like so:

When a COLLADA file is converted to a SceneJS JavaScript asset, it's a cinch for the converter to slap a bounding box around it, so there's plenty of mileage there.

Boundary hints

The second case ain't so easy. A boundary hint looks like this:

It has no extents, which is an invitation for SceneJS to automatically compute them, if it can.

Lets imagine what will happen within the scene traversal for this example. On visiting the boundary, SceneJS begins creating a bounding volume, set to minimal size. It also creates a new child data scope for the subtree and attaches a listener to the scope to be notified whenever data is read from the scope. If the listener fires during traversal of the subtree then the boundary will know that the subtree is not a "closed universe" in terms of data dependencies on higher nodes and cannot be counted on to always have the same geometric extents. For example, a rotation node might be taking its angle from a data scope written by a node somewhere up the tree. As long as the listener is never called, however, each geometry node is instanced into the local modelling coordinate-space of the boundary and the boundary is expanded to encompass it. However, as soon as the listener fires, the boundary permanently short-circuits itself so that it does nothing at all when visited, other pass traversal on to its child nodes, as if it was never there.

This strategy will require that the modelling matrix stack be sort of forked at the boundary node. It also requires the framework user to use ONLY the SceneJS data flow mechanism to configure scene nodes (ie. not using their own global vars).

A boundary node could cause all transform nodes in its subtree to memoise their local matrices for availability to gemoetries to transform themselves by for the purpose of expanding the volume.

Also, it adds a bit of extra (pre)processing to the scene graph, but I think it could be quite transparent. Making it a "hint" lets me off the hook somewhat. Implementation could approach that incrementally - a first cut will follow the hint only if the subtree is totally static, with no config functions and no generators.

SceneJS GL State Nodes

2010-01-21T15:50:00.000-08:00

I just added "renderer" nodes to SceneJS. Basically, a renderer node sets WebGL state for the nodes in its subtree.

Check this early example out:

See how you can nest them. The inner one temporarily overrides everything in the outer one for its sub-nodes. Their "clear" properties indicate that we want them to clear their drawing areas (in this case bounded by scissor boxes) when visited during traversal.

The canvas and viewport nodes are gone - they are now merged into the renderer node.

See the "cullFace" property on the inner environment. To process that, SceneJS calls the WebGL's cullFace function on the active context, mapping the "frontAndBack" argument to the WebGL FRONT_AND_BACK (GL_FRONT_AND_BACK) constant. I want to expose the functionality of WebGL, but not directly expose the actual WebGL API.

Of course, this feature invites the scene designer to create some horribly sub-optimal scene graphs, that will cause the GPU to thrash around between states. For example: continuously enabling and disabling textures might not be so cool for optimal GPU pipelining, I'm not sure. I guess that's where a user manual might be handy. Or perhaps the scene graph could log warnings?

Anyway, this will be going into Release V0.5.0, hopefully this weekend, depending how much skateboarding I want to so as well!

Asset Imports with Backends

2010-01-19T20:36:00.000-08:00

I just had an idea on how to extend the SceneJS asset mechanism to also provide backend plugins to support new node types within the asset.

Assets are SceneJS nodes that load fragments of scene graph, defined in JavaScript, from remote locations. The fragments just evaluate straight into the scene graph with a minimal hit on frame rate. And of course, they come from trusted locations that will provide nice JavaScript that won't mess with your browser.

So,to refresh your memory, an asset node looks like this:

When visited during scene travesal, they make a request of an asset server, which responds with something like this:

That's a JSONP response with a callback that will glue the asset into the scene graph. The asset is then immediately executed.

What if the asset contained nodes that are not supported by the version of the SceneJS library that is running in the client, where the library doesn't have the backend plugins to support them?

One solution could be for the asset node to indicate the version of the library on the client. The server knows that the client does't have the support for the asset it is about to provide, so offers the backend plugins as part of the response:

The client then checks to see it has support for "foo" and "bar" node types (ie. does it have such backends and node functions). When it doesnt, it then loads and evaluates JavaScript from the offered URI to install the support. Then it evaluates the asset.

Exciting! The client only needs a core library!

Asset Nodes - Boundaries and Proxies

2010-01-13T12:18:00.000-08:00

One cool thing we could do with asset nodes would be to wrap them in a boundary node that would only allow traversal of its children when it intersects the current view volume:

On intersection, the asset is visited and begins its asynchronous load of its remote asset.

Speaking of which, I realised how much overhead there would be in parsing other file formats like COLLADA in the browser. Pulling in a big chunk of COLLADA and parsing all those features in the XML is going to cause a fair bit of latency in a running scene graph.

I also realised that the currently-supported JavaScript format for scene assets (like the example above) actually has a high power-to-weight ratio in terms of expressiveness, and evaluates into the scene way faster than any XML conversion would.

I still plan to support COLLADA assets, with XML parsing in the client. However higher priority for me now is a server-side proxy that converts COLLADA assets into SceneJS JavaScript assets.

Check out this asset node:

It asks the proxy for a COLLADA asset, the proxy then finds that COLLADA, converts it to a JavaScript scene chunk and returns that. It could also cache the JavaScript for when the same request is made in future.

Asset Import for SceneJS

2010-01-06T18:52:00.000-08:00

I just added the ability to load remotely-stored "assets", cross-
domain, into a scene graph at render time. Version 0.3.0 now has this new feature.

You use an asset node like this:

The uri is the location of the asset, in this case a JSON scene fragment, and a JSONP proxy to mediate the cross-domain request for it. This example is a real existing asset, at the time of the blog post.

At scenejs.com there's now an example in the Playroom that shows this in action, and the same example in the download.

Also, you'll find a new experimental asset catalogue over there, which I'll be hacking on over the next few weeks.

Assets can potentially be stored in any format, such as COLLADA, JSON, XML etc., and you can extend SceneJS with plugins to parse various formats.

When the scene is first rendered, an 'asset' node will make a JSONP request of a repository, which will respond with the asset data. The asset node will then convert the data into a subtree of scene graph content.

The asset node's request will always be asynchronous. This means that when SceneJS renders the asset node, it's not going to wait for the asset to load before continuing to render the rest of the scene.

SceneJS will just trigger the asset's request and move on. So if you're rendering one frame, you wont see the asset in the image. But if you keep rendering the scene for a few frames like in this example, as you would when animating, the asset will magically appear once loaded.

The ultimate plan with assets is to somehow use them to pre-load bits of scene just before they fall into view, then rely on SceneJS to flush them when they haven't been rendered recently.

SceneJS currently caches assets with a max-time-inactive eviction policy.

Next, I'll start on a backend plugin to help the asset node import COLLADA assets.

Whew!

SceneJS Coolness #1

2010-01-06T12:57:00.000-08:00

SceneJS is a JavaScript framework I just kicked off that allows you to program scene graphs on WebGL, which will soon enable our favourite browsers to hook into an underlying OpenGL library and render hardware-accelerated graphics.

I'm making SceneJS in my spare time, which means that I'll spend at least a day on it per week, but it's going great there's some fun demos and downloads now over at scenejs.com.

On this blog I'll do a regular braindump on how SceneJS is going and whatever ideas I have for it.

Compact Scene Definitions

One of SceneJS sweet spots is its functional design, which gives it a tendency towards compact, declarative scene definitions that are quick to define and easy to read. One of my aims is to make them as short as possible, so you can just stick them into your web pages and remember what they do when you come back to look at them months later.

Memoisation for Speed

Another benefit of SceneJS's functional design is that there are many opportunities to memoise state within closures to avoid the overheads of recomputation and memory management. A scene node is actually a higher order function that returns the actual function that will be called during scene traversal. The node computes various things from it's parameters, such as transformation matrices, which are then available via closure to its product function.

To use SceneJS efficiently, it's worth knowing something about what happens internally with node memoisation.

Nodes only memoise when they know for certain that their state will never change. In the examples you'll see how a node may be either configured statically with an object, or dynamically with a function that will return an object each time the node is visited. In the latter case, a node knows that it had better not memoise anything at all because it can't assume that the output of that config function will be constant.

Some nodes need to be a bit more clever about memoisation because either their effect on the underlying OpenGL state machine is potentially cumulative on the effects of higher nodes, or their internal state might be derived from the effects of higher nodes.

This is a fascinating area of ongoing research in SceneJS and a wellspring of optimisation opportunites.

Modelling transform nodes

Lets take a look at how modelling transform nodes (such as rotate, scale and translate) decide whether or not they will memoise. SceneJS maintains a modelling matrix as it traverses a scene; on entry, each of these nodes post-multiplies a transformation onto the matrix, later restoring it again on exit, effectively maintaining a matrix stack on the function call stack. The matrix has a "fixed" flag which is false whenever it is currently the product of at least one dynamically-configured modelling transform node. When a modelling transform node sees that flag is true, it knows that all higher modelling transform nodes are statically-configured and that, as far as it's concerned, the modelling matrix will always have the same value. So the first time the node is visited, it memoises the matrix after post-multiplication to avoid recalculating it each time. All it has to do from then on is copy into the active shader on the way in, then replace it with the previous matrix the way out - a big win!

However - you guessed it - the most inefficient modelling transform hierarchy is one in which the root transform is dynamically configured. This is, by the way, the rationale for SceneJS having seperate modelling and viewing matrices - to isolate modelling transform nodes from viewing transform nodes, which are likely to be dynamic. It's a small hit on the GPU to allow a big gain on the JavaScript side through memoisation.

Geometry Nodes

Geometry nodes are usually static - you can generate configurations for those with functions, but that's rather inefficient since they they may have to recompute so things such as normal vectors each time they are visited. When they are statically configured, they can buffer their geometry as VBOs, which is cool because then you can have a set of reusable geometry primitives in fast video RAM, forming a kind of symbol table, then instance those with modeling transforms. Early benchmark tests instancing hundreds of buffered OpenGL teapots at high frame rates, which then revealed JavaScript to be the major bottleneck. I'm confident that can be offset significantly with clever and adaptive memoisation.

Shader Nodes

When first visited during traversal, a shader node loads a GLSL shader program into video RAM, memoises a pointer to it, then makes it active. Then, when departed from, it deactivates it again, leaving the program loaded. Then whenever the shader is visited again, all it has to do is reactivate the program.

Maybe SceneJS is a little memory-hungry - I may have to have some kind of eviction policy for VBOs and shaders, and maybe some kind of preloading trick to kick in when the load on the renderer is low. Those might not be a bad idea when I end up adding bounding volume generation later on.

Well that's enough for now, in the mean time I'll try think of a few more cool things, and maybe some things that ought to be cool.

Lindsay

Compact Scene Definition

One of SceneJS sweet spots is its functional design, which gives it a tendency towards compact, declarative scene definitions that are quick to define and easy to read.

Memoisation for Speed

Another benefit of SceneJS's functional design is that there are many opportunities to <a href="http://en.wikipedia.org/wiki/Memoization">memoise</a> state within closures to avoid the overheads of recomputation and memory management. A scene node is actually a <a href="http://en.wikipedia.org/wiki/Higher-order_function">higher order function</a> that returns the actual function that will be called during scene traversal. The node computes various things from it's parameters, such as transformation matrices, which are then available via closure to its product function.

To use SceneJS effiently, it's worth knowing something about what happens internally with node memoisation.

Nodes only memoise when they know for certain that their state will never change. In the examples you'll see how a node may be either configured statically with an object, or dynamically with a function that will return an object each time the node is visited. In the latter case, a node knows that it had better not memoise anything at all because it can't assume that the output of that config function will be constant.

Some nodes need to be a bit more clever about memoisation because either their effect on the underlying OpenGL state machine is potentially cumulative on the effects of higher nodes, or their internal state might be derived from the effects of higher nodes.

This is a fascinating area of ongoing research in SceneJS and a wellspring of optimisation opportunites.

Modelling transform nodes

SceneJS Roadmap #1

2010-01-06T12:56:00.000-08:00

Roadmap #1

By Lindsay Kay

The roadmap – what’s coming up.

1. Replace the Sylvester matrix library with a custom module optimised for SceneJS, using such tricks as efficient transform post-concatenation [CYCHOSZ].

2. Automatic hierarchical bounding-volume generation. There’s enough information already in the scene graph to determine which bits of it are static enough to warrant an efficiency boost from bounding volumes.

Internally, the nodes can tell whether their configurations are fixed or were generated by a function parameter. They can therefore determine whether they can safely memoise internal state. Transformation nodes, for example, will memoise their matrices internally if they know that their configs and those of higher transforms are static; they can then memoise their matrices, knowing that wont have to recompute them.

Geometry nodes are usually static – you can generate configs for those with functions, but that’s rather ineffient since they then have to recompute normals, reload VBOs etc. each time they are visited. It’s nice to have a set of reusable geometry primitives buffered as VBOs, forming a kind of symbol table, then instance those with modelling transforms. Early benchmark tests instancing hundreds of buffered OpenGL teapots at high frame rates, and actually revealed JavaScript-side operations, such as the matrix math module, as the major bottleneck.

3. Textures nodes, of course! But one thing I’d like to do is explore ways for them to work optimally with pipelined GPU architectures [VO]

4. Vector interpolation – a vectorInterpolator node using spherical linear interpolation.

[CYCHOSZ] Cychosz, J. M. 1990. Efficient post-concatenation of transformation matrices. In Graphics Gems, A. S. Glassner, Ed. Academic Press Professional, San Diego, CA, 476-481.

[VO] Vo, G. and Reiners, D. 2006. Towards a flexible back-end for scenegraph-based rendering systems. In Proceedings of the 4th international Conference on Computer Graphics and interactive Techniques in Australasia and Southeast Asia (Kuala Lumpur, Malaysia, November 29 – December 02, 2006). GRAPHITE ‘06. ACM, New York, NY, 303-309. DOI= http://doi.acm.org/10.1145/1174429.1174481