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.

Read the rest of this entry »

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:

• Maven2
• Maven webstart and release plugins
• Java webstart
• Java/Swing
• SVN

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.

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.