Web Workers and WebGL

[Lindsay Kay]

Hi,

just wondering who amongst us has been using HTML5 worker threads with
WebGL?

A half baked idea, but I wonder if they could at all be used to
alleviate texture-creation overhead..?

That seems to be the bane of large scenes that pull in content on-
demand through a WebSocket - if there are lots of large textures in
there, the FPS is going to get awfully lumpy (ie. use thinks it's
crashed!) Anybody have thoughts on this?

cheers,
Lindsay

[Joshua Bell]

On Wed, Aug 4, 2010 at 12:11 PM, Lindsay Kay <linds...@xeolabs.com> wrote:

just wondering who amongst us has been using HTML5 worker threads with
WebGL?

The Sirikata folks (Daniel Horn, Ewen Cheslack-Postava) presented on this at WebGL camp, when talking about architectures for VW clients in the browser. Slides should be at: http://www.webglcamp.com/wiki/index.php?title=Schedule 

 

A half baked idea, but I wonder if they could at all be used to
alleviate texture-creation overhead..?

That seems to be the bane of large scenes that pull in content on-
demand through a WebSocket - if there are lots of large textures in
there, the FPS is going to get awfully lumpy (ie. use thinks it's
crashed!)  Anybody have thoughts on this?

Why would you choose pull down content over WebSocket rather than using WebSocket simply for signaling (e.g. "ball ID#1234 has appeared at x/y/z") and then pulling down the content (geometry, textures) using regular asynchronous HTTP (via XHR or Image or ...), which can take advantage of caching, CDNs, etc?

This is a serious question, as there is active discussion on the IETF HYBI group about including content-type metadata in WS frames. Knowing your reasoning would help in that discussion.

[Joshua Bell]

I didn't see any further responses on this thread - hopefully I didn't stifle it with my response! I'm still very curious.

Is anyone else thinking about doing content transferring over WebSockets? Lindsay, can you tell us more about your direction here?

[Lindsay Kay]

Hi, your comments on benefits of HTTP for pulling content were food
for thought - I'm not sure exactly how efficacious my idea is, perhaps
a little naive, not sure.

What I'm aiming at with scenejs is lots of modularity, with
decentralised control logic. Scenes can be composed of subgraphs that
are library assets, each of which can have their own WebSocket(s) to
connect back to their server-side processes.

For example, a city block asset gets updates on traffic light state
from its traffic-control server process, while the airplane asset
flying overhead gets updates on position from the airplane-control
server process, etc. Those updates could be data state, or subgraph
additions/removals.

With Scenejs, you can embed Socket nodes throughout your scene, which
can relay events in their subgraphs back to their servers, which can
respond with data and content, which the Sockets then push down into
their subgraphs. Actually, the amount of content that is actually
pulled in could be minimal when you predefine it on the client as
Symbols, and just pull Instance references to those through the
Sockets. Also, if you have two or more Sockets in a scene that point
to the same server, then they can share the same WS connection.

Here's an experiment I did with a WebSocket server on NodeJS for
SceneJS a while back: http://github.com/xeolabs/scenejs-node-ws-examples/tree/master

In one of the examples, the server can push data, create content (a
teapot) or destroy content - here's a snippet from the server, where
it generates a responses to "createTeapot", "rotateTeapot" and
"destroyTeapot" commands

switch (params.cmd) {
case "createTeapot" :
data = ' { ' +
' configs: {' +
' "#world-root": {' +
' "+node" : SceneJS.node({ sid:
"teapot" },' +
' SceneJS.translate(' +
' SceneJS.rotate({'
+
' sid:
"rotate",' +
' angle: 0,'
+
' y : 1.0' +
' },' +
'
SceneJS.objects.teapot())))' +
' }' +
' }' +
' }';
break;

case "rotateTeapot" :
data = ' { ' +
' configs: {' +
' "#teapot": {' +
' "#rotate" : {' +
' angle: 45' +
' }' +
' }' +
' }' +
' }';
break;

case "destroyTeapot" :
data = ' { ' +
' configs: {' +
' "#world-root": {'
+
' "-node" : "teapot"' + //
maps to "removeNode"
' }' +
' } ' +
' }';
break;

default:
error = 'I dont understand that cmd: ' + params.cmd;
}

The "configs" element is a map that is understood by the Socket node -
here's a breakdown of the first response:

configs: {

// A sub-node of the Socket with SID "world-root"

"#world-root": {

// "+node" maps to the sub-node's "addNode" method. The
value of this property is
// a chunck of scene graph to attach through that method.

"+node" : SceneJS.node({ sid: "teapot" },
SceneJS.translate(
SceneJS.rotate({
sid: "rotate",
angle: 0,
y : 1.0
},
SceneJS.objects.teapot())))
}
}

Couple of articles on key scene node types for this:

Socket - http://scenejs.wikispaces.com/SceneJS.Socket
WithConfigs, which pushes state/content into subgraphs the same way as
Socket can - http://scenejs.wikispaces.com/SceneJS.WithConfigs

Yes that's a whole lot of weird API, but hopefully you can grok what
I'm thinking from it!

On Aug 12, 11:19 am, Joshua Bell <j...@lindenlab.com> wrote:
> I didn't see any further responses on this thread - hopefully I didn't
> stifle it with my response! I'm still very curious.
>
> Is anyone else thinking about doing content transferring over WebSockets?
> Lindsay, can you tell us more about your direction here?
>
>
>

> On Wed, Aug 4, 2010 at 1:35 PM, Joshua Bell <j...@lindenlab.com> wrote: