Last week I mentioned some feedback I’d received from our HCI & Visualization team regarding the possibility of animating the heatmaps in the Types By Level UI. (Prior to this the Types By Level feature has really just been a legend for quick access to per-level heatmaps: I stopped short of attempting to animate the individual heatmaps while the timeline is playing.)
For some background, the Types By Level feature is a stack of “cards” that each displays data from a particular sensor type for a specific floor using a 2D heatmap. These cards are rendered as individual textures – using a single heatmap object to reduce the WebGLContexts that get created, as these are a scarce resource in browsers – which are then assembled into a stack of planes that gets rendered once again to display the UI. So there’s quite a lot going on, rendering-wise, and in all honesty I had very little expectation that any kind of animation would be meaningful.
But I gave it a try, because you never know. At first the performance was atrocious, but with a bit of work – and the good thing about this process is that I had an incentive to streamline the rendering as much as possible – I managed to get the performance to be tolerably poor. Here’s an animation of a full stack of sensor types being rendered for the NEST building:
So not great, by any means. I did find that by working with a subset of floors – allowing just a few floors to be selected for display – the performance improved quite a bit.
Here’s with two floors:
And here’s with a single floor (admittedly the one with the most interesting sensor data) displayed:
At this stage the performance is verging on usable. Here’s the UI being animated alongside a 3D view and some separate 2D panels (which get loaded when you double-click the Types By Level cards):
The panel is only rendered when visible, so closing it still improves the display performance significantly (should you want to get a more nuanced view of the sensor data). I suspect there may be some tweaks that might be made to eek out a little more performance from the feature, but for now this is good enough.
I’ve promoted the Types By Level UI to be a separate feature than can be loaded independently from the Surface Shading extension: it now has its own button in the Dasher toolbar. It works well with Surface Shading – and is a great way to dive into specific per-level data, of course – so things should work seamlessly enough.
I haven’t yet pushed this version live to dasher360.com, but will do so before too long. Right now the subset of floors is controlled by project settings – rather than by the user – so I have to decide which subset makes most sense in general for this project (and whether it makes sense for this to be overridden by the current floor when the user navigates to one).
