Gephi forums

Since this idea was scrapped last year I would like to double check how the Gephi team views this idea as a GSOC project this year? I would hate to write a proposal for it only to later find it scrapped due to other priorities in the team

Good question. This proposal is a priority and will not be scrapped. We were hesitant last year, and I think we were right not to do it. WebGL is more mature now, as it reached a 1.0 specification and libraries like PhiloGL starts to appear.

So go for it, looking forward your proposal

Today I've tried X3DOM. This is a way of doing WebGL while keeping HTML concepts onboard. I think Neo--- is already familiar with it, and I invite others to have a look on it.

You use it by defining a scene graph using the DOM tree-like structure. Similar in concept to SVG, unless that it is low level and in 3D : you have to handle yourself how shapes are drawn (eg. if you want curved edges, you may have to code them. Maybe).

But was is important is that this approach make usage of current HTML APIs (DIVs, layers, HTML events, CSS theming and positioning..) straightforward, at the price of less freedom (t looks like support of shaders is quite limited for the moment). You work with shapes and paths, rather than on the pixel level.

I think such connection with HTML concepts is important in the design of a web interface. Otherwise you'd probably still have to write an equivalent high level interface for UI events on top of your 3D engine (eg. code a 3D graph traversing code for handling mouse clicks. In 3XDOM, you simply have to attach an onClick event to a DOM node, like a standard HTML button. it's really a time saver, and it rely on a well established API).

If you want fancy things, you can still merge CSS3 shadows, effects, gradients etc.. on top (or under) your 3D layer, control opacity, and transparents backgrounds - Examples of x3dom might not be very "color sexy", but I think this is more a matter of graphical and example page design that an engineering problem.

I've tested it on the latest stables versions of Chrome and Firefox 4. No glitches; this seems - finally - mature.
I've tried to embed it in a Dijit widget, to simulate some real world integration issues / DOM manipulation / CSS conflicts. It seems to work (I wanted to do this test, because I had issues with Processing.JS+WebGL, by example. the canvas failed to render when put in some HTML UI containers).

Also, I was surprised to find it is quite fast (30-55fps on my 1.8Ghz laptop - other WebGL libraries tend to pump my battery), see the examples.

Static 3D rendering is one thing, but the performance question for a real graph is still open, though. I know PhiloGL, SceneJS seems to play well on complex scenes.
But I don't know any benchmark for comparing WebGL libraries in term of FPS or features - only tests for browsers implementations. I think this largely depends on others factors like the layout algorithm and graph/ressource loading performance (data format and compression, server charge, bandwidth..)

Hi jbilcke,
Unfortunately I had problems in getting X3DOM to work in an Intel graphics card of mine, unlike PhiloGL etc. Will it be a concern since we need it to be cross-platform?
BTW, I would like to bring forward for your attention, WebGL-2D - An HTML5 canvas 2D API in WebGL. Its relatively new, but will suit the purpose if benchmarks perform better.

Hmm I was not aware of such compatibility issues - this is indeed problematic.
In this case, maybe it is preferable to use well supported libraries.

Yup, I played with X3DOM in the past and you posted a pretty accurate description of it and its capabilities. Since we will have to implement interactive components this high level approach of attaching event handlers to objects which are represented as DOM nodes offers great flexibility and substantially speeds up the development.

While I haven't noticed any problems when I played with it I can't really confirm or disconfirm problems with Intel graphic cards at the moment because I don't have access to any at the time.

Personally I share different suspicions with you regarding X3DOM - while the promise of having nodes represented as DOM objects is nice in theory, having thousands of DOM nodes can be a killer, especially with event handlers attached to them. I can't confirm this at the moment but this is an issue that will have to be checked before selecting X3DOM. Either during bonding period or at the very start of GSOC I plan to conduct a bit of benchmarking with all libraries that we will be considering. We have to remember that while 500 nodes is completely OK for all browsers, we are targeting more in the range of 10k-50k nodes. On the other hand, Javascript engines have been given a huge performance boost thanks to increased competition between Chrome and Firefox and based primarily on this I don't want to make a final decision without some concrete numbers behind my statements.

But I don't know any benchmark for comparing WebGL libraries in term of FPS or features - only tests for browsers implementations. I think this largely depends on others factors like the layout algorithm and graph/ressource loading performance (data format and compression, server charge, bandwidth..)

Nope, neither do I and at the time I can't imagine how can anything else but browser implementation be tested (well, we could probably compare features after we identify exactly what we want). The only solution that I see for this is that we try to find a few common cases that we can test (10k nodes, 10k nodes randomly moving, 10k nodes moving and changing colors, 10k nodes interconnected, 10k nodes interconnected and moving, etc.) and try to implement them (or at least a couple of subsets of it), hopefully without wasting too much time on them. With a bit of luck we will get some reasonable numbers without too large deviations.