January 25th 2015, Android Track Rendering
← January 21th 2015 UI Simplification | ● | March 3rd 2015 Track Rendering Engine →
The actual status quo is that the app is able to record the gps location and store it in a sqlite database in packets of 15min track coverage. The packets are ancrypted, compressed and transmitted to the server, from which they are sent back home.
On the visualization side, the tracks can be visualized in 3D by exporting the transmitted packets from the database and dropping them into the QTViewer. This was the first major milestone:
The above visualization is aimed for being at home on a desktop pc. While on the go, there is currently no visualization of the tracks on the Android side. To fill that gap, the topic Android Track Rendering will be our major work load in the next weeks. It is going to be our second major milestone.
We do not intend to use OpenGL for the track rendering, we will only use simple line graphics to get a graphical overview of our current track. Still, it will be full 3D. I guess it will look a little bit like “Mercernary” from the good old times of the C64 and Atari XL:
To be able to render an arbitrarly large track efficiently, we use a 1D variant of the 2D C-LOD algorithm “Real-Time Generation of Continuous Levels of Detail for Height Fields” in V. Skala, editor, Proc. WSCG ‘98, pages 315–322, 1998.
The algorithm decimates the track based on a view-dependent scheme, meaning that it takes curvature and distance to the point of view into account. The farther a track point from the point of view, the lower the chance that it is going to be rendered.
As a result, a track that was recorded during an extended period of time like a month or so will reduce from many ten-thousands of points to only a few thousand points to be rendered interactively in 3D.
← January 21th 2015 UI Simplification | ● | March 3rd 2015 Track Rendering Engine →