Which programming language and libraries would you recommend me to recreate the 3D geometric and linear algebra visualizations displayed in this book http://immersivemath.com/ila/learnmore.html ? I speculate it's either JavaScript or Python, but I'm not sure.
The most used JS library for 3D visualizations is Three. It's not the simplest to learn but the docs are great, it's powerful, and its popularity makes it "community-validated".
Another choice would be Babylon, which also have great documentation and also relies on WebGL for rendering.
D3, the de-facto standard for custom JS visualizations in JS, also handles a bit of 3D, although it's not focused on that.
If library size is a factor you consider, then Light might be a better choice, and if zero-dependency is also a plus, then you might consider Seen.
Cannon is more a 3D physics engine than a 3D visualization library, but it might come handy sometimes.
Consider also CopperLicht, Phoria, and Scene.
I wouldn't recommend doing 3D visualizations on the browser in Python, since there are many libraries in JS that are quite powerful, and moving a computationally expensive task such as 3D rendering on the server might overload it, not to mention the lack of interactivity that server-side rendering might incur.
Related
As I understand it, Bokeh looks to provide for Python, similar capability that D3.js provides for JavaScript. Some advantages for Bokeh I can see include the use of HTML Canvas (so we can render more to the browser), Abstract Rendering and a lower barrier to entry for people familiar with Python over JavaScript but wanting to develop interactive browser based visualisations.
This is great but, where do you go (i.e. as a developer) to extend Bokeh to match the flexibility offered by D3 e.g. to add Chord diagrams, Network graphs or develop more novel visualisations such as those demonstrated at IEEE VIS or the VAST challenge?
Does the Bokeh project have aspirations to become as fully featured as D3 (appreciate D3 has been around for a while now)?
They do want to be fully featured as D3:
Its goal is to provide elegant, concise construction of novel graphics in the style of D3.js, and to extend this capability with high-performance interactivity over very large or streaming datasets. Bokeh can help anyone who would like to quickly and easily create interactive plots, dashboards, and data applications.
This is detailed in their technical vision page.
To help extend Bokeh, check the extending Bokeh page and the example of wrapping a JS library (visjs). There is also a developer guide and a enhancement proposal document.
It would be awesome to have something like D3's transitions!
So, I have thought about designing a WebGL Graphics Engine, which will facilitate designing 3D Interactive Graphics for web. Now, my question is :
WebGL is Javascript API, so in order to design an engine for WebGL graphics, do I need to have a JavaScript compiler or anything ? What I want is a system which will let users see what they are creating (for example, like blender workspace, if you draw up a scene you can see and make changes simultaneously)
You would have to create some kind of engine, or framework that you'll build your system onto.
Creating only framework/engine would take at least 2-3 months, and if you plan creating something really big and advanced, that supports various effects rather than simple rendering primitives, than that might come down to 5-6 months. After that you could start creating your web application. So 6-7 months time for that? That shouldn't be a problem.
I don't know how advanced you are, how many people are you working with, but that seems very plausible and doable. But is worth of it? In a year, many different things will change, maybe new openGL ES version for webGL, changing api, supported browsers (IE recently joined the game),... it's really questionable.
You wouldn't need any kind of JS compiler or anything like it, just knowledge of advanced JS and many different techniques used in 3d, and since you plan building system that is far beyond just-graphic-stuff, then it adds even more to overall complexity and time consumption.
So, to answer your question: yes, it's very doable in a year, but will it pay off?
Similar things already exist in some form:
http://errolschwartz.com/projects/threescene/
http://badassjs.com/post/12885773103/threenodes-js-a-visual-webgl-scene-editor
CopperLicht engine has its own real-time editor
there are more lab-playground-like editors
I intend to use one of D3 or Dojo GFX to create some big data visuals like TreeMap, Wave-forms etc. The great thing about D3 is that many of these visualizations are already available as example implementations for fast development. Also its enter-update-exit paradigm fits nicely with my dataset. But I am not averse to using Dojo GFX (and writing my own Treemap etc implementations) if it is said to be more stable and better suited for mobile.
Seeking suggestions and comparisons...
In short, the answer is simple: If you are using dojo, use the GFX module. If you are not using dojo, use D3.
What's more, GFX and D3 are effectively the same thing: low level drawing APIs (herein visualization toolkits), both of which can be used in tandem with a larger javascript framework. GFX, in fact, must be used within dojo.
Since graphing/charting/drawing/whatever is often only part of a web application, the underlying framework architecture should be the driving force behind choosing a visualization toolkit. So basically, if you go dojo or not is what will answer this question for you, and if you do, GFX is a great option since it is already baked in (though I should mention that D3 can be wrapped in an AMD as referenced here).
And now, a real answer
If you have decided that the visualization toolkit is the driving force behind choosing a javascript framework and not the other way around, here are some thoughts on GFX vs D3:
Community Support: More people are developing and asking questions on D3. Looking at github watches/stars/forks, D3 leads with 1.9k/22.7k/4.7k over GFX's 54/52/91 (dojox is GFX's parent module). Here on stackoverflow D3 has nearly 7k tags compared to GFX's 26.
Features: GFX can render using SVG, VML, canvas, and even silverlight. By this, GFX has superior cross platform, browser, and version support. Beyond this, both visualization toolkits enjoy the same access to every feature you get when writing visualizations declaratively.
Learning Curve: Both toolkits are very low level APIs that are complicated to learn. D3's enter-update-exit pattern may be especially confusing for those not familiar with extensive method chaining.
Frameworks: Both of these visualization toolkits are used in larger charting frameworks. GFX is used by Dojo Charting, D3 is used by many including NVD3, D3plus, and Vega to name a few.
Which are the famouse 3d javascript libraries? By famous I mean something that is as famous Jquery is to web developers. By famous I mean things are properly documented and many resources are available i.e tutorials/books etc for newbies. I am trying to learn three.js but having hard time figuring out how to use because there isn't much documentation available for this. On top of that it is javascript so not even intellisense benefit ;) What are the other options for this type of 3d stuff? I am mainly interested in WebGL and Canvas.
Due to the great work of Mr. Doob (i.e. rome), three.js is quite famous.
If by famous you just mean 'popular', why not let google decide for you? When searching for JavaScript 3D Library, google seems to think the following is most popular.
http://www.c3dl.org/
It seems to fit your criteria, WebGL and Canvas.
I am holding back on seriously pursuing ProcessingJS pieces mostly due to the bloat of the library. I have found that pieces like Ball Droppings do not use the library's Processing syntax parser, which is good, since I imagine it would slow down the page more, especially adding to the initial load and setup time. Still, I am wondering if it's worthwhile to use it basically as a big utility library like UnderscoreJS. For example, how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS? Has anyone gone through the implementation of the Processing API extensively enough? When I skim through the I see a lot of boilerplate I don't really need, as well as a couple instances of questionable coding practices. But the library still seems to perform decently, at least on the ProcessingJS homepage, although the examples are set to run at 15fps, and not the (in my opinion) minimally acceptable 24fps.
I think it strongly depends on the project you are working on and the background knowledge you have with the processing library.
Processing.js is a great choice if you already have learned the original processing api (java) and want to leverage your existing knowledge in the web environment. It might be the only choice if you want to port an existing project to the web - actually this is probably the best time to use it.
If you are a JavaScript programmer and don't know much about processing you probably will dislike to write Java syntax in the browser and everything becomes even more problematic if you have to mix it with js. The API doesn't feel like JavaScript and there is a lot of code that could be written more elegantly.
Regarding performance it is not a bad choice, actually most projects run smoothly and I can definitely recommend using processing.js on circumstances like those explained above.
Here is great list of various javascript engines out there:
Javascript Graphic/Game Engines
It is hard to recommend a single library, as the requirements are specific to each project.
For simple graphics/diagrams: RaphaelJs is really nice and performs decently
how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS
Processingjs doesn't use SVG as far as i know, it only uses canvas. Raphaeljs only SVG. There's an interesting read here and also at wikipedia about the difference. The main difference is SVG stores the vector data of objects so you can easily change position, colour, etc... of stuff but also provides mouseover events. Canvas - and processingjs - does no such thing, it draws to the canvas and forgets everything so you have to do more work. Don't know about performance difference between the two.
As far as the processingjs API is concerned, I don't have any clue as how it is implemented but since John Resig of jQuery is involved it can't be that bad to say the least.
I agree with user hlfcoding that writing java in browser feels weird. I am too looking for a cleaner solution for my future canvas experiments.
I fail to see how re-rendering for each frame in JavaScript can be seen as performant.
That's exactly how canvas works, you have to calculate and render every frame in js, it's not processingjs specific. I don't think that's such a performance hit, behind the scene a browser running SVG does the same anyway.