2016-03-29 – Getting into a rhythm

Alex: The past month for me has been preoccupied with preparations for an upcoming (unfortunately not space-related) paper. So all of my last week’s work was spent on meetings and coordination.

Emil: The antialiased abuffer + framebuffer renderers with volumetric renderering support are now merged into develop. On some machines, there appears to be an issue with the antialiased abuffer, causing triangle borders to be rendered incorrectly. I have not been able to reproduce the problem on my own machine yet, but this problem is one of my top priorities for the coming weeks.

Erik & Kalle: We have had long discussions on pros and cons with different tesselation methods and map formats. It seems like a tile based mesh rendering is what is mostly used nowadays for large scale planetary rendering. We have also had a lot of discussion regarding floating point precision errors and how it partially can be solved with a scale graph approach. Together with the other team members we have decided to ignore the scale graph related problems for now and assume that the planets origin is in their respective center. Local elevation probably need to be done in camera space.

Michael & Sebastian: For the past week we have experimented with interpolating 3D model data and generating a 2D slice for a plane. With one of the models we can extract the correct metadata to place and orient the planes correctly.

2016-03-22 – Have you tried turning it off and on again?

Alex: After a long, long absence the DevBlog is finally being updated again. Even without posting anything here, the development has been progressed rapidly over the past 7 months. Tomas and Emil have defended their thesis on interactive volume rendering of large data and Emil has since transitions into working on OpenSpace as a developer. Speaking of new people, we have a couple of new developers in the mix as well. Eric and Jonathas will help out from New York with their expertise in development and architecture knowledge, Erik and Kalle are doing their thesis work at the American Museum of Natural History and will work on geospatial images, and last but not least, Michael and Sebastian are doing their thesis at Goddard and will be working on bringing current space weather information into the hands of the public. I’m looking forward to providing up-to-date information on all of these processes again!

Eric: Since I am new to the project I’m still getting up to speed. Since I work for AMNH I took care of paperwork so that I can get paid. I also read the past blog entries so I know more of the development history. I’m working on learning the build process, including CMake, so that I can build the executable(s?), first on my Mac, and then Windows.

Emil: I’m in the process of finishing up a new interface for volume ray casters, that will enable rendering of volumetric data together with antialiased geometry. The volumetric rendering is integrated with the abuffer renderer to properly support multiple intersecting half-transparent volumes with half-transparent geometry inside. For platforms not supporting the abuffer renderer (opengl < 4.2), volumes can still be rendered using the framebuffer renderer. In this case, geometry is first drawn to a separate fbo with a depth buffer attached to it. The depth buffer is fed into the proceeding volume rendering step, so that part of volumes can be occluded by geometry. A scene with only one volume and fully opaque geometry can be rendered correctly even with this approach. However, when falling back on this simpler rendering scheme, volumes are not blended correctly with each other, nor with semi-transparent geometry. Depending on future priorities, this method can also be extended to support correct alpha blending of non-intersecting objects (both volumes and geometries), by adding a CPU based depth sorting step. Intersecting half-transparent objects will probably never be supported for opengl < 4.2. While implementing the new volume rendering algorithms, the depth buffer of the framebuffer renderer has been replaced with a 32 bit float texture for the framebuffer renderer. Both the abuffer and framebuffer renderers now represent depth as the actual camera-to-fragment distance encoded into 32 floating point bits. This will hopefully give us appropriate resolution for doing depth sorting even for huge scenes, with high precision close to the camera, and lower resolution farther away.

Michael & Sebastian: The past two weeks we have been working on screenspace images and framebuffers working for both flatsceens and domes. It is coming along great, and it needs testing. This week we just started a new feature to render 2D data from space weather models in the right place.

Erik & Kalle: We arrived to the US at Monday night. Tuesday, we met up with Carter and Vivian at AMNH and we got introduced to the people in the science bulletin and to our new offices. First week was mostly spent on setting up OpenSpace and researching tesselation and all the map formats.

2015-07-10 – Ready to lift-off

Alex: In preparation for the New Horizons flyby at Pluto on July 14th, we wrapped up most of the coding and started extensive testing with the various sites that participate in the event. What programming there was was focused on various bug fixing, fixing memory leaks, and a slight redesign of the way the origin and the current coordinate system is chosen.

Joakim: The last two weeks have been extremely busy (which is why i failed to produce a blog post last week) and great progress has been made with OpenSpace. During the past two weeks we have performed remote networking tests where we connected to Hayden Planetarium, New York, and ran OpenSpace in a remote session setup. Extensive amounts of stability testing has been performed, and as a result of the tests many bugs have been fixed and memory leaks carefully plugged 😉 I have also redesigned and reimplemented the network communication protocol and message handling in an effort to make it more stable. Right now everything seems to run smoothly and stable, even during pressure tests, and I am focusing on our big ‘New Horizon’ event next week. Super excited!

2015-07-03 – Getting closer to the Fly-by

Alex: This week, I fixed the issues that started to appear on newer nVidia drivers about two months ago which meant that the rendering would disappear. This was due to an error in the texture initialization that worked sofar, but nVidia has gotten more restrictive about what their drivers will accept. The rest of the week was put into maintenance of the Timeline and Launcher applications to deal with changes in OpenSpace.

Emil & Tomas: The last week was a four-day week due to the celebration of 4th of July! So we watched fireworks and drank beer. Tomas had a local IPA and Emil had fun. We solved some remaining issues with the integration of multires into abuffer, including the case when the camera is inside the volume. The camera can now be inside multiple volumes at the same time.

2015-06-26 – Saying goodbyes

Alex: More work on the Launcher in terms of cleaning up the CMakeLists file and dealing with threading priority on Windows. The rest of the last week was busy with preparing both a poster presentation about OpenSpace as as well as a paper revision to our biggest visualization conference IEEE Vis. Finger’s crossed!

Joakim: Past two weeks I’ve spent fine tuning the remote-communication protocol and functionality, implementing new messages and message-types as well as improving overall stability.
I’ve also created a simple module for Spout (http://spout.zeal.co/) integration with the intention of making it easier to install and run OpenSpacein new locations.

Anton: Wrap up time! A Rosetta movie I just made with screen captures from OpenSpace can be found here: https://vimeo.com/131993576 . Thank you all very much for this time. Now it’s time for me to focus on writing the report!

Tomas & Emil: This week we got the Abuffer to work with our multi-resolution volumes! This means that we can render multiple intersecting multi-res volumes and geometries in the same scene. Next step is to merge this with the new data loader from Alex, so we can test our work further with real scenes. Hopefully we will soon receive 3D simulations of the space weather at the time when New Horizons flies by Pluto. If so, we may be able to insert the volume rendering into the NH scene created by the AMNH people. Many things will have to go really smooth in order for us to have it ready by the flyby of July 14, but let’s hope for the best!

2015-06-19 – Taking care of chores

Alex: I was doing many more works on the Launcher application this week. All downloads are now multithreaded so that they don’t block the main window thread anymore. Furthermore, the layout of the application has changed such that it will be easier for future-me to write a style sheet to make the application look pretty and that it is able to respect the path tokens that are set in the openspace.cfg file. A second big work package was helping with support for planetariums that we want to run in on July 14th. This meant writing more a verbose logging to find a particular error.

Anton: This has been kind of a scattered week from my part with three main tasks; adapting my recent work to the new modularized structure of OpenSpace. Preparing for and doing a demo of my work on 67P for a few guys at Evans & Sutherland via Skype and Screenleap. Last but not least also helping to reshoot some content for the NOVA PBS documentary.

Emil & Tomas: We have worked with changing the interface of the ABuffer to allow for custom volume rendering modules. This rewrite will make it possible to plug in our new multires-module, and have this working with both the basic volume rendering and geometries as well.

2015-06-12 One more month…

Alex: With the big Pluto encounter looming over all work, most of my week has been spend on core changes that no one will notice, but will make the future programming life much easier. Furthermore, I got a working prototype of the Launcher application working, full with individual file downloads, torrent support, as well as the capability to indirectly request files using the OpenSpace server. This distribution system allows us to roll out changes to the binary data files efficiently after the software has been distributed. Big files are distributes using the torrent protocol to ease our network a bit (and provide some more redundancy).

Joakim: The past week most of my time was spent working on other projects, there however some progress being made with the networking part and I also spent some time researching datasets for visualization.

Anton: This week my work station had recording duties at the Johns Hopkins Applied Physics Laboratories between Tuesday and Thursday, where part of the NOVA documentary was shot. I did some work on the model projection and started to prepare my local branch for probably my last big merge on board next week!

Tomas and Emil: This week, we managed to refactor the multi resolution volume rendering to become a separate module in OpenSpace. However, since the volume rendering and the order-independent transparency (ABuffer) are algorithmically tightly coupled, it is not obvious which parts of the code that should live in this new module, and which parts that should live in the open space base, where the ABuffer is currently implemented. Making it possible to dynamically plug in logic into the ABuffer-resolve step from the volume and multiresvolume modules (and potential future volume rendering engines) could be an approach to structure the code. We will probably dive into this area during the next or following weeks.

2015-06-05 Remote Operations

Alex: I was spending this week on a short vacation, so the length of my laundry list for the release unfortunately went in the wrong direction. However, I managed to implement a feature that makes use the autodetected OpenGL version to pick the correct rendering method. Furthermore, I started work on a Launcher application that will handle automatic file downloads and synchronization.

Joakim: This week I’ve spent my time figuring out how to communicate and interpate camera movement across different clusters for our upcoming ‘parallel’ event.
Last week me and Alex went to template hell and back. While ther we picked up some nice interpolation functionality!

Anton: This week we had a run through of OpenSpace for the NOVA producers to discuss what shots to include in a upcoming documentary and a demo for the education department at AMNH. I gathered some images from the ESA Rosetta blog, matching them with time stamps I got a couple weeks back to try projection to my 67P model. I also spent some time planning what my priorities should be during the last few weeks of my internship.

Emil and Tomas: This week, we have attended some of the lectures at the Space Weather bootcamp hosted by the CCMC. We gained a lot of insights about the basic physics of space weather, and also how the forecasters work. We started merging in the modularization into our experimental-flareGL branch, and plan to finish that early next week. The CCMC staff held a presentation for representatives from NASA and NSF (National Science Foundation) and we showed demos from the OpenSpace project with very positive response.

2015-05-29 – Housekeeping + Progress

Alex: One more week was focussed on the backend of OpenSpace with more work being put into the modularization of functionality and the resulting necessary CMake cleanup. It seems to work reliably now with the current limitation of being restricted to static linking. Moreover, I embedded Visual Leak Detector and used it to fix about 1500 instances of memory leaks. Lastly, I started implementations on a better data distribution scheme for big data files that are necessary for modules. Including the curl library to handle http downloads works well, now it is up to investigating if we want to use the torrent protocol as well.

Anton: This Tuesday we did an interesting demonstration for a reporter of the NY Times in the LeFrak theatre at AMNH. Development wise I’ve been continuing the work of projection to .obj models and now believe I am fairly close to a general solution with some promising progress just last night, there is however still some unwanted behavior to be addressed.

Tomas and Emil: We managed to solve the problem with the near plane intersecting the volume bounding box, by constructing the intersection in the fragment shader. In the future we will be able to create an opacity falloff when getting closer to the camera instead of having a steep change in opacity. The rest of the week, we had many and long discussions about a new brick selection algorithm, which will be adaptive to the transfer function.

2015-05-22 – Settling back into a normal working mode

Alex: The first half of my week was almost entirely focused on code hygiene. Fixing many instances where OpenSpace would crash if certain files are missing; cleaning up the code that was responsible for recompiling shaders once they get changed on disk. In the second half, I jumped at CMake and started modularization of the OpenSpace code base. There will be independent modules that are compiled and linked independently to reduce the friction between different parts of the code base.

Joakim: This week I’ve started work on remote control and synchronization between different clusters. I’ve also spent some time looking into how o render a fake, but realistic looking, galaxy.

Anton: After a recuperating weekend I have now started experimenting with how to project images to modules that are not considered very well approximated by triaxial ellipsoids. The problems to solutions encountered ratio on this has so far been high but my hopes are still high that I will get it working over the next few weeks.

Emil and Tomas: We have now replaced the GPU based TSP traversal entirely with a brick selector living on the CPU. Each frame, we send a buffer to the GPU with instructions where to sample values in the atlas. This seems to have resulted in a 10 times speedup for some specific visualization setups. Next, we will try to solve the case where the near plane intersects the bounding cube of the volume, preventing the volume from being rendered.

1 2 3 4 5 6 7