So it's been a while since my last blog post and KStars Lite has grown since that time getting more and more features from its elder brother KStars. Below you will find a list of changes I've made during this period:
1.Planet moons
This small addition required me to change the structure of PlanetNode. Because moons sometimes have to be drawn in front of the planet there is now PlanetMoonsNode that holds pointer to PlanetNode and a bunch of PointSourceNodes that represent moons. Whenever z-order changes PlanetMoonsNode reorders all nodes in node tree to follow the order.
Jupiter and its moons
2. Horizon and Ground
At first sight drawing horizon and ground might seem trivial (I also thought that it is) but it turned out that there is no in-built support for concave polygons neither in OpenGL nor in Qt Quick Scene. And the only way to draw a filled polygon in OpenGL is to convert it to the set of triangles. So I spent some time on finding the best algorithm or library to triangulate the polygon used for drawing ground and decided to use this library (standalone version of tessellator from OpenGL Utility Library (GLU)). It produces perfect results and performs well on both my laptop and Android tablet
3. Lines
This is a major part of SkyMapLite. Equator, Ecliptic, Constellation Bounds and Lines, Horizontal Coordinate Grid and Equatorial Coordinate Grid were ported to SkyMapLite. Unfortunately, lines caused significant loss in performance on Android due to a lot of calls to routines that convert equatorial and horizontal coordinates of object to QPoint. There are few ways how we can optimize it (e.g. use SkyMesh to skip checking of lines that are not visible in current sky hemisphere, optimize Projector) it but I decided first to finish porting all components to SkyMapLite and then come back to optimization.
Another trivial problem that turned out to be not so trivial caused Equatorial and Horizontal Coordinate Grids. In KStars they are drawn with dotted lines but Qt Quick Scene Graph doesn't support it. First I tried to use custom shaders but guys from Qt interest mailing list gave me an idea to use QSGVertexColorMaterial to draw different line segments with different color.
4. Labels
Another major member of KStars which is now available in SkyMapLite. At first I thought that each SkyNode (e.g. PlanetNode and PointSourceNode) can have its own label as a child node but this way it would be impossible to control the drawing order of labels as other planets or stars can overlap labels. So I created LabelsItem class that holds and updates all labels, which can be instantiated on request to LabelsItem.
Qt Quick Scene Graph doesn't offer tools for drawing text so I decided to store labels as textures. To do that you need to call SkyMapLite::textFromTexture() which will return QSGTexture with the text. This approach has one problem - if we want labels to have different size on different zoom levels than on each zoom change we will need to create a new texture or just resize the texture but I'm already working on this problem.
There are 2 types of labels LabelNode and GuideLabelNode where the latter can be rotated with a given angle but in most cases LabelNode is used.
Also I changed the structure of SkyMapLite and its children. Previously each of SkyComponents was represented with QQuickItem derived class that was reparented to SkyMapLite like SolarSystemSingleComponent -> PlanetsItem. Now I moved everything inside SkyMapLite e.g. PlanetsItem is now derived from QSGOpacity. This way we have only one clipping node and texture cache. The reason I haven't done that before is that rendering of QQuickItem and all another stuff are done in two separate threads that shouldn't intersect. I thought that we might have problems if I will delegate all data work to QSGNodes, but it turns out that multiple clipping nodes cause loss of performance and transition to this scheme was inevitable. Also I haven't faced any problems with this approach yet (it works better and there is much less duplicate code now).
Also I changed the structure of SkyMapLite and its children. Previously each of SkyComponents was represented with QQuickItem derived class that was reparented to SkyMapLite like SolarSystemSingleComponent -> PlanetsItem. Now I moved everything inside SkyMapLite e.g. PlanetsItem is now derived from QSGOpacity. This way we have only one clipping node and texture cache. The reason I haven't done that before is that rendering of QQuickItem and all another stuff are done in two separate threads that shouldn't intersect. I thought that we might have problems if I will delegate all data work to QSGNodes, but it turns out that multiple clipping nodes cause loss of performance and transition to this scheme was inevitable. Also I haven't faced any problems with this approach yet (it works better and there is much less duplicate code now).
Current state of KStars Lite on desktop
And on my Nexus 7 tablet
What's next?
My next stop is stars and DSOs. If everything goes well I will finish SkyMapLite by GSoC midterm examinations and proceed to optimization of KStars Lite.
Awesome work!
ReplyDeleteand as default view is even just good having just the star view without nothing else, but in the future I would like looking into integrating it into kirigami for eventual chrome interface around (if it's going to have things like some configuration dialog for things like searching location, enabling/disabling layers etc.
Thank you!
DeleteSure, the star view is a main part and I would like to keep all UI as much unobtrusive as possible.
Kirigami will be used for UI. I will start working on it after optimizing KStars Lite for mobiles.