We won the IEEE SciVis Contest 2016


Each year at the renowned international conference for visualization, the IEEE VIS, the so called SciVis Contest takes place. This year, we, the staff of the Computer Graphics and Visualisation Group of the TU Dresden, together with colleagues from the Visualization Research Centre of the University of Stuttgart, have won the contest.

With the SciVis Contest the visualization community can confront themselves with challenging visual analysis tasks on real data scenarios. This year’s contest asked questions about large ensemble data sets of chemical processes of salt dissolution, namely the appearance and influence of viscous fingers. The entry by TU Dresden was deemed being the most wholesome and versatile solution, and thus gained the winning edge over its competitors.

Posted in Science

XKCD Reblog Started

When I read this comic on xkcd i started thinking. I enjoy reading xkcd. Few comics are bad, most are nice, and some are brilliant. And those are the ones I will now start reblogging here, as distributed archive. 😉

“If you can read this, congratulations—the archive you’re using still knows about the mouseover text”!

“If you can read this, congratulations—the archive you’re using still knows about the mouseover text”!
Digital Data [xkcd_1683]

Posted in General Tagged with: ,

The Lua Nuget Package


I adopted yet another nuget package: Lua

The reason, of course, is MegaMol, more precisely an upcoming addition to MegaMol enabling scripting of all internal management functions. After some thought, we opted for Lua as scripting language in our project. Building Lua is no big deal. But I also wanted the build process of MegaMol as a whole to be a simple as possible. On Windows this calls for nuget.

Of course, the nuget package already existed, but it was old. Instead of just starting another one, I contacted the original authors of the coapp team. They were happy to grant me access to the package, so that I could update to the new binaries. I will try my best to keep it up to date and to support many Visual Studio versions and settings.

Posted in General Tagged with:

MegaMol™ with Inter-Plugin Dependencies


This article details the work with inter-plugin dependencies in MegaMol™. The primary scenario is to have one (or many) plugins use Call classes exported by another plugin (and not the MegaMol™ core).

Actually, nothing was changed in the MegaMol™ core. Inter-plugin dependencies already worked, to some extent. The limits, and especially the behavior in error cases are described below.

Test Project: interplugin_test

The following project shows two plugins:


Plugin A exports 2 modules and 1 call.

Plugin B exports one module using the call exported by modul A.

Exporting Call Header

Usually, modules and calls are only exported via their meta data description classes as part of the implementation in “plugin_instance”. This meta data is sufficient for the MegaMol™ core to instantiate the module at runtime. However, these classes are normally not exported by the plugins.

If you want to use a class, a Call, in other plugins at compile time, you have to export the type. You need to place the corresponding header file in the public export folder. For a typical case, have a look at the demo project: “./a/include/interplugin_test_a/IplgDemoCall.h” I also recommend to add the header files to the filter “Public Header Files” in the Visual Studio Solution Explorer.

Additionally, you need to export the class using the corresponding API macro: e.g. “INTERPLUGIN_TEST_A_API”, which is defined in the plugin’s primary header file, e.g. “interplugin_test_a/interplugin_test_a.h”

Of course, you still need to export the meta data description for the call itself in the “plugin_instance” definition (cf. “interplugin_test_a.cpp” line 51).

Using Call in another Plugin

Now, to use the Call in another Plugin, that one basically needs to link against the exporting Plugin. Following the demo project, the exporting plugin is called A and the using plugin in named B.

First A is a library and a normal development dependency for B. For Visual Studio, I recommend using the “configure.win.pl” and “ExtLibs.props.input” similar to any other 3rd-party library. In the demo project, the access to the subdirectory of A is hard coded in the “ExtLibs.props.input”. Then, you can use this user macro in the project settings:

  • C/C++ > General > Additional Include Directories
    • E.g. $(PluginAPath)include\
  • Linker > General > Additional Library Directories
    • E.g. $(PluginAPath)lib\$(PlatformName)\$(Configuration)\
  • Linker > Input > Additional Dependencies
    • E.g. interplugin_test_a.lib

As you see, the linker only uses the built input library of the plugin, not the compiled plugin A itself.

Now you can find the public header file of the call exported by the plugin, cf. “./b/src/IplgValueInvertB.cpp” line 3. Plugin B uses this class like any class exported from the core. Nothing special is required.

For Linux you could introduce similar settings in the “CMakeLists.txt” file. I did not.

Since I install everything of MegaMol™ into a local user directory (using the install prefix settings in the build scripts) all parts of MegaMol™ are available at the same location. This includes the core, which the “CMakeLists.txt” file already searches for and Plugin A, which is thus accidentally found too. So the public include files, which were copied when Plugin A was “installed” are already available. Linux does not require shared objects to link against their dependencies. The runtime loader is expected to resolve all issues. Thus, for building on Linux no additional settings are required.

If you want to be able to work with plugins not locally installed, you should write a corresponding find script for the base plugin A and use “find_package” in the “CMakeLists.txt” of plugin B. For now, I don’t care.

Configuring MegaMol™ with both Plugins

Just add both plugins, as usual, to the MegaMol™ configuration file. Either explicitly (recommended) or using file globing. You should keep the dependencies in mind. So you should load plugin A before you load plugin B. But technically, it does not matter.

Both plugins, all plugins, are basically Dlls. So if you load plugin B first, the Dll is loaded with all its dependencies. These include the Dll plugin A. So plugin A is in memory the, but the meta data is not known to the core yet. If then the command for loading plugin A is executed, the OS runtime is asked to load the Dll plugin A. Since that Dll is already in memory, the load succeeds and the plugins meta data is received and added to the core factory constructs.

Beware of Cyclic Dependencies

Cyclic Dependencies should be avoided, as always. In theory, they could work, like Plugin A uses a class from Plugin B and the other way round at the same time. However, if you are going towards such a scenario, I strongly recommend to create a third Plugin holding the shared classes, e.g. Calls.

Runtime Behavior if Dependent Plugin is not found

The OS runtime errors when a Dll (Plugin) cannot be loaded are rather useless. (I am working on something better here, but it is not as easy as one would think.) Usually, it only tells you that the Dll could not be loaded. So keep in mind, if you developing your plugins that other plugins you depend on, not only need to be available at compile time, but also need to be installed in the same bin directory for runtime access.

Version Number Tests

All plugins check their version numbers of Core and Vislib with the loading core. This is to avoid inconstancies at runtime. Imagine you build the Core, then work on your Plugin. In this work you stumble upon a bug in the Vislib and fix that. Then your core and your plugin use different Vislibs and only this very version check tells you that this is a bad idea.

Now, use that scenario and replace Vislib with plugin A. Welcome to hell. There currently is not version check implemented for cross-plugin dependencies. (Most likely, there will be no such check before the infamous coming “Call Interface Redesign”.) You need to be careful!

Posted in My Tools Tagged with:

NuGet Package: GLFW


I present you another NuGet package: GLFW. Ok. Originally redxdev created the package. And I only took the official prebuilt binaries from www.glfw.org and repacked them. All that fun for the support of Visual Studio 2015.

Posted in General Tagged with:

Open Source is great …


All I did was hitting the “Update” button in my WordPress installation.

Server closed session midway during update. Installer is unable to repair or fix or continue or whatever. And I spent my precious afternoon reinstalling my website and all the content from the backup. Thank you.

And don’t come to me claiming open source is not at fault here.

Posted in General Tagged with:



Simple computer graphics demos are often developed as console applications. Having the console window is simply convenient for debug output. However, if we then show these demos on our stereo powerwall, the console window flashing on program start is massively disturbing. That is why I take some time and wrote a little tool. It starts the console application, hides the console window, but captures the output. This way, we can still check what happened if something does not work.

I present the HiddenConsole:

HiddenConsole.zipHiddenConsole.zip Application starter hiding the console window
[55.3 KB; MD5: 848cbd8aa901fe38be8179d65b6d2162; More Info]

And, because I can, the source is freely available:


Posted in My Tools Tagged with: ,

Tutorial at IEEE VIS 2015 in Chicago


I have written about this before, but here is the official news reblogged from the SFB 716 website.

GPU-based interactive Visualization of Large Particle Data

20151112_vis2015_tutorialAt the end of October, the largest conference on scientific visualization – the IEEE VIS 2015 – took place in Chicago. This is an anual venue for experts from all over the world to present current research and discuss future challenges. With more than 1100 participants, the conference is considered the largest and most important international forum in this domain.

This year, Michael Krone and Guido Reina from the group of Prof. Ertl, together with Sebastian Grottel (TU Dresden) and Martin Falk (Linköping University, Sweden) organized a tutorial on interactive GPU-based Visualization of large particle data. They explained the technical aspects for ensuring high quality and interactivity of particle visualizaton, which are nowadays accepted as state of the art. Part of these techniques have been developed in the SFB716. Additionally, the presentation included details on abstractions required by continuosly growing data sets. Such abstractions were disucssed in the context of biomolecules and material surfaces as well as in the context of whole cell visualization.

The tutorial was very well received with over 50 participants. The course materials distributed there, including slides, source code and example data sets can be downloaded here.

Posted in Science Tagged with: ,

Cleaning Up


There were no post on the last two Sundays. And that was on purpose. The whole idea to write one post every Sunday was kind of good, but did not work. Far too many posts were fillers without any content. That is not good. Those posts only bloated my blog. Which helped no one. And bloating things up is something I do not like at all. Thus, it is time for a change. It is time to clean up!

I deleted all old filler posts. No one needs them.

Exoworlds is history. I had the idea for this game since school. And now it is time to let go. I will never find enough time to create the game in the form I imagined. The little time I have for something like this is better invested in my other projects, I have to say.

To be precise: MegaMol and SpringerJagd are my two remaining projects I will be working on. In the vicinity of those, more small utilities will emerge.

In future I try to post regularly. But I will not promise anything.

Posted in General

Afterword to IEEE VIS 2015



The IEEE VIS 2015 reached its end. And she was great once again. Good papers, good ideas, and good people to meet. It really was worth it.

My own tutorial was a big success, too. We had a much bigger audience than anticipated, and we received a whole lot of very positive feedback. I am very pleased.

And tired. Such a conference is always exhausting. And I do not have the time to relax yet. The next projects are already waiting.

Posted in Science