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.
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.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..)
Statistics:Posted by Neo--- — 05 Apr 2011 21:54
]]>
Statistics:Posted by jbilcke — 04 Apr 2011 12:58
]]>
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.
Statistics:Posted by keheliya — 04 Apr 2011 02:25
]]>
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..)
Statistics:Posted by jbilcke — 03 Apr 2011 22:20
]]>
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
Statistics:Posted by mbastian — 28 Mar 2011 23:19
]]>
Cheers,
Urban
Statistics:Posted by Neo--- — 28 Mar 2011 18:40
]]>
joshua wrote:While trying to mess around with WebGL to get a feel for what it is I'm getting myself into it I found that Chrome doesn't have support enabled for WebGL enabled by default in Ubuntu.
Thanks joshua. It was working in Chrome 9 but stopped working after an update to Chrome 10. Seems some graphic card drivers with OpenGL are heavily buggy. So engineers at Google and Mozilla have decided to blacklist certain models of graphic cards (ATI, Intel etc).You can find a blog post here I wrote about getting WebGL to work in Chrome 10+ and Firefox 4. Hope it'll be beneficial to many, who are having the same problem.joshua wrote:That didn't work, but some more Googling discovered that it had been added to a blacklist and you could get around that blacklist with
Statistics:Posted by keheliya — 24 Mar 2011 03:46
]]>
May be Gephi & JIT can collaborate in GSOC 2011 to make this idea a reality
Yeah very good idea, I sent an email to the author. I'm happy they are doing GSoC as well, it's an excellent project !We have considered this (see this topic), these librairies offer great features and flexibility but they are not performant enough for large graphs. The limits would be around 5000 nodes, and the experience limited, as zooming and panning speed would be reduced.I would like to know whether this project's scope cover considering other alternatives like d3.js and processing.js too for visualizing large networks on the web
Statistics:Posted by mbastian — 21 Mar 2011 04:54
]]>
Buyer beware, I didn't actually use those instructions. Some Googling discovered you could enable WebGL in chrome with:
CODE:
google-chrome --enable-webglCODE:
google-chrome --enable-webgl --ignore-gpu-blacklistStatistics:Posted by joshua — 19 Mar 2011 23:28
]]>
First of all congratulations for get selected on GSoC 2011 as a mentoring organization. I'm interested in the project idea 'Web based network visualization using WebGL'. As I understood, the objective of the project is to come up with an abstraction layer on top of an efficent library (i.e. PhiloGL) to layout large networks loaded as GEXF/JSON. I'm reading about PhiloGL & WebGL these days.
It's great to see a similar idea 'Use of Hardware Accelerated Techniques' in Javascript Infovis Toolkit (Sencha Labs) GSoC project ideas list too. May be Gephi & JIT can collaborate in GSOC 2011 to make this idea a reality (Just a thought
).I would like to know whether this project's scope cover considering other alternatives like d3.js and processing.js too for visualizing large networks on the web. I would like to discuss more on this idea with you all in this forum & mailing list and come up with a good work plan for the summer.
Statistics:Posted by keheliya — 19 Mar 2011 02:30
]]>
]]>
The proposal was not going so far and mostly concentrate on the visualization issues. However questions remains on the best way to provide an efficient network visualization platform on the web. For us we believe the first step is to let users have the same level of interaction Gephi can have on the desktop, but without the analysys platform. It's a bit what was done with the GexfExplorer project, which provide mostly read-only features, based on what GEXF file contains. I would also cite this project, http://cytoscapeweb.cytoscape.org/. It shows great effort to bring to the web complex features and consistency between desktop and web applications. But unfortunately it stuble on efficienty, try to load a 100 nodes graphs!
Statistics:Posted by mbastian — 05 Apr 2010 18:08
]]>
I understand that this project has been scrapped from the GSoC ideas list, but if there is any splinter of a chance that Gephi's accepting a proposal on this, I think I'd still try... (but please let me know if there's no point to do so)
Have a question though: how is the user expected to use this library? I get the impression that the user will be able to associate say, a gexf file, then use the library to define graphics attributes of node/edge, layout properties and preferred metrics calculations of the graph? So in this case the library means to abstract interaction from the user i.e. the library will provide a web-based display, but with API for the user to work with network properties -- is this the right understanding?
Statistics:Posted by juliana — 05 Apr 2010 05:02
]]>
in this we have to start a new project, by developing an efficient network visualization library for the web using WebGL. am I right ?
Statistics:Posted by fat0ss — 30 Mar 2010 15:21
]]>
]]>