We’ve extracted the 3D java applet functionality using the JMonkeyEngine and Vaadin from the Whole Brain Catalog Web and made it its own project. Today, we’ve added drag and drop functionality. Check it out:
3D Drag and Drop in Browser -- click for movie
Andrew Noske, one of our talented group members, proposed an interesting idea at the inaugural Dangerous Ideas social that we hold weekly at 4pm PST on Thursdays. Check it out below:
We are always interested to find new sources of inspiration to help us figure out where technology is headed. This year, we have come across several excellent sources of technology news that is relevant to doing open source programming online, with technologies such as java, GWT, python, etc. Most people know of Slashdot.org as a core part of the tech community, but here are a few alternate sites for news and help that we found awesome in 2010:
Sites to check out in 2011:
We’re curious about some new sites that we were alerted to this year for keeping up with tech trends. We’re not sure if they’ll last, but we’d love to hear if you’ve enjoyed these:
Hope everyone had a great break and looking forward to an exciting year in tech!
We’re getting excited over here about the possibilities of deploying the Whole Brain Catalog in a completely different way. I’ve decided to start exploring these possibilities to see if the technologies we are looking at could bear fruit. This may be a dead end, but its always fun to play with new tools!
The first thing that has gotten us excited is the discovery of a technology called Vaadin. Vaadin lets you write user interface code in Java only and then it magically converts that user interface into a web application written in JavaScript. If you are familiar with the Google Web Toolkit (GWT), this will sound familiar. However, it appears that Vaadin has some significant advantages over GWT. The ones we are interested in are the running of the client code on the server. This would eliminate the need for WBC users to download a ~50 mb webstart package. Also, regular GWT doesn’t allow the usage of any arbitrary Java libraries, which Vaadin apparently does.
Vaadin only handles 2D interfaces though, so the puzzle is to try to get a workable 3D interface involved as well. After a lot of investigation into the next generation 3D-in-a-browser solutions that are being put forward, it seems clear that there is still a long way to go before there is a clearly better technology for WBC than jMonkeyEngine. The advantage of switching to Vaadin, however, would be to deploy the 3D view as a much smaller lighter-weight java applet. The 2D interface would load up immediately as the user arrived at the web page, and would make waiting for the applet to load much friendlier.
The rest of this post will be devoted to my exploration trying to get Vaadin to work with a jMonkeyEngine applet.
We have added over two hundred Allen Atlas brain regions to the latest version of the Whole Brain Catalog. These changes haven’t been incorporated into the main release yet, but they are ready to be evaluated. The addition of the Allen Atlas brain regions gives a more a detailed and elegant view of the mouse brain, but visualizing over 200 brain meshes at once has proven to be challenging. The following post intends to elaborate on this new feature and the challenges we have come across during the implementation phase.
A Whole Brain Catalog user has the option of visualizing all brain regions at once or each individually, but for the purpose of simplicity only five brain regions are visible by default at program startup. In order to display all the brain regions in the scene, we first have to download the corresponding data files from our server. Once we have downloaded the data files, we create objects (Tangibles) for all the brain regions using a geometry mesh called “TriMesh”, which is available to us through the game engine platform JMonkeyEngine. As of this version we are using “.obj” files to store the brain region’s data, but we also have access to these files in Collada format which we intend to use in future releases.
Once we have finished downloading the data files and creating the objects (Tangibles) we need to render them on the scene. In order to do this we use the objects we previously created and make spatials (TangibleViews) out of them. A spatial is created by attaching the object (Tangible) to a JmonkeyEngine graph scene node called a Node. When all spatials have been created, we attach them to the 3D scene and this is how we are able to visualize the entire Allen Atlas brain inside the Whole Brain Catalog. One of the challenges we have come across while implementing this feature is the high amount of video card resources it takes to render over 200 meshes at the same time. Each brain region is represented by a mesh and each mesh can be represented by hundreds of verticies which can make the 3D scene really crowded. The more crowded the scene, the less performance we get from the application. For future releases, we will explore different rendering techniques to increase the performance of the application when the entire Allen Atlas brain is visible.
Be sure to visit our developer documentation for more information or post to our google groups mailing list if you have questions.
Ever wondered how the technologies used in the production of a tool like the Whole Brain Catalog come together? Our new team member, Ruggero Carloz, has put together a bare-bones “Hello World” example that marries the basic Whole Brain Catalog open source technologies. This provides a great template for building other applications and demos in this style. The basic framework is already in place in our volume rendering example, our MCell COLLADA example, and our neuron cloud example.
The technologies used here include:
You can check out the Hello World developer example documentation to see how we pull these technologies together to make a simple, deployable Swing app that is version controlled and managed by Maven.
Today we’re making available access to the statistics of how well the Whole Brain Catalog plant is running, as provided by Larry Lui of our talented systems group. We have put a detailed page containing links to various stats such as server up-time and data consumption on our wiki. This is in service of our commitment to building an open community platform. Please have a look around and let us know your comments on our user forum or on our developer forum.
CAPREA: I’ve been making progress on the MCell rendering collaboration with Tom Bartol, but I am not in direct contact with him. The current status of the MCell visualization is that the molecule diffusion animation is beautiful and faster than the the Millennium Falcon on a Kessel Run, but there is a mesh model with some 2.4 Million faces which needs to be seen in context with the molecules. Visualizing this has proven to be a challenge. Simply loading it into Blender or MeshLab gives both of these professional products problems. I have made significant progress on this in efficiency and refactoring, using a LODMesh in JME, and now we can view both the molecule animation and the background landscape of the cell parts. However, it must be made more efficient in before we show Bartol. The loading time is horrendous, Stephen say’s he’ll fix that with a strategy to load meshes straight from binary.
I’ve been working closesly with Han on volume rendering. Maven has been a pain for setting up such complicated projects. The dependency tree becomes more of a grey hazy bush in fog (It can be circular at times). Progress has been really slow, but yesterday we met a goal. Progress has been steady and painful, nothing has been slowing us down, but we weren’t going very fast to begin with.
In other developments, we have a new hire to our team, Carloz. We set him up with our development environment which is a day’s worth of learning curve to even an experienced programmer. I’m glad I got it piece-wise rather than all-at-once. It’s a lot to take in at once. Eclipse is complicated enough, and Maven’s complexity rivals that of a time machine cyborg with Unicorn magic.
We spent a lot of effort in the Whole Brain Catalog to create the necessary components to render 1500 neurons in real time in order to visualize the Gage lab’s dentate gyrus network. We have collected this effort together into a stand-alone example that illustrates the Whole Brain Catalog architecture. In this post, I want to explain how this works.
The first thing to understand is that we have a set of multi-compartment models of neurons that we have downloaded from NeuroMorpho.org and converted into NeuroML. These models describe the tree structure of the neurons in 3D. The challenge to render a single tree is to arrange approximately 500 3d rectangular solids so that it creates the shape of the tree, one compartment (a.k.a “segment”) at a time.
Just arranging these rectangles, however, only gets you so far. In the 3D world, its important to limit the number of verticies in your shapes in order to get good performance. The vertex count of a single tree can be quite high at full detail. So to get more performance out of the system, we use a trick in the game engine we use (JMonkeyEngine) called “Geometry instancing”. This lets us take a single rectangular solid and copy it 500 times to make a tree, and save on both vertex count and memory consumption. Its a very nice feature of the game engine.
But we ran into the same problem again when we reached the requirement to render 1500 full neuron trees, because we had one rectangular solid per tree, and 1500 solids is still a large number of verticies. Our solution was to build a “neuron cloud”. Any neuron morphology that participates in the cloud will be rendered by a single rectangular solid. This trick requires us to do a significant amount of book keeping up front, but results in the ability to render the complete complement of trees.
You can check out the source code for this example by checking out our wiki page on the CloudRenderExample. Questions? Ask us on our developers forums.
One of the crucial technologies we have taken advantage of in the development of the Whole Brain Catalog has been Maven2. Since not everyone is familiar with it, I thought it would be good to get a quick overview to it here.
The first thing to know about Maven is it provides the “single command” ability to build an entire code base. With SVN and Maven installed you can issue the following commands to download and build the entire source of the Whole Brain Catalog:
svn co http://wholebrain.googlecode.com/svn/wbc/trunk wbc
cd wbc
mvn clean install
The one caveat to this is that you need to place a single configuration file called settings.xml in your maven directory. Your maven directory is located at ~/.m2 on linux/mac, C:\Users\[username]\.m2 on Vista, and C:\Documents and settings\[username]\.m2 in Windows XP. You can download our copy of the settings.xml file here. This will point your copy of Maven at our proxy maven repository, which contains many of the third party dependencies necessary for the Whole Brain Catalog.
This last process (mvn clean install) will take a long time because it does a lot of magic things for you. First of all it downloads all the jar files that the Whole Brain Catalog depends on to your local machine, under your maven home directory. This will take a while as the WBC depends on a lot of jars. It will also download Maven specific jar files that are used to build the code, run tests, create java docs, do deployment, and so on. Once all these jars are downloaded, it will go step-by-step through the wbc modules, compile them, run their test cases, and package them into jars.
We prefer Maven to other build systems, notably Ant, because it hides a lot of functionality away in its plugins, allowing the build configuration to be specified within a single XML structure known as the “pom”, short for Project Object Model. This file, pom.xml, contains all details about the dependencies needed to build a system, how to configure compilation, how to package up the code, what the current version of the code is, and much more. More about Maven2 can be found online at its website.
