This update summarizes the progress during the last two weeks. Most of the work involved moving code to use the new renderer subsystem, but there was still some API work (in particular, a shader API).
Some Stellarium code requires direct usage of shaders, and I expect the amount of this code will only increase. However, shaders are an implementation detail of a Renderer backend and might differ significantly between backends (e.g. GLSL for OpenGL2/ES, HLSL for DirectX, nothing for GL1 or some custom DSL for a software renderer).
Instead of attempting to wrap all of these behind a completely generic “Shader” interface, StelRenderer can report whether it supports GLSL or not and if it does, it can create a GLSL shader - StelGLSLShader interface, which might be implemented differently between different GL based backends (in our case, StelQGLGLSLShader). This is because a generic Shader would require user code to supply shader code for any supported shader format. The user can check if GLSL is supported, if not (GL1), use shader-less code (which will work with any backend, regardless of shader support, as e.g. a GL2 backend will handle it using shaders internally), and have optional shader-based code used when GLSL is supported. If ever needed, a check for HLSL support and a HLSL shader API can be added in future.
Before drawing with a shader, the shader must be bound, which, in case of the GL2 backend, overrides default internal shaders. It also must be released after drawing to reenable default shaders.
API-wise, it is a simplified version of Qt’s QGLShader allowing to set uniforms with Stellarium data types such as Vec3f, even automatically handling transposition for matrices. Attributes are part of the vertex buffer and are set internally by the backend. Only vertex and fragment shaders are supported, but geometry shaders can be added once needed (although they should only be optional).
I’ve added a StelCircleArcRenderer class which handles circle arc drawing logic (previously in StelPainter) on top of *StelRenderer. The logic is basically unchanged, with slight documentation improvements. It would be good to revisit it later to add caching or further simplifications.
StelRenderer now has text drawing functionality (drawText(), setFont()). As text drawing has many optional parameters, which previously caused unreadable argument lists, a builder struct was used to emulate optional/named arguments, e.g:
renderer->drawText(TextParams(16, 16 "Hello World!").angleDegrees(30.0f).shift(8.0f, 4.0f));
I’ve’ split StelRenderer::drawRect() into drawRect() and drawTexturedRect() for more self-documenting code and to decrease number of parameters. These replace all variations of StelPainter::drawRect2d() and StelPainter::drawSprite2d(), even supporting rotation (around the center of the rectangle, which is what drawSprite2d() handled previously). Previously, drawRect2d() had many versions which made it difficult to read at call site, and drawSprite2d() had very similar functionality, except that it supported rotation and only worked with texturing.
Most of the work was moving code to the new Renderer subsystem, in particular, the code in src/core/modules . Most of these classes are based on the StelModule interface. To avoid (de-facto) singletonification of StelRenderer (which would make any future refactorings more difficult), a StelRenderer pointer is now passed through the StelModule::draw() function.
The following classes were ported:
There are still more classes that need to be ported here, as well as in plugins.
I noticed that the GeodesicGridDrawer class is never used and doesn’t conform to the StelModule API - it only compiles because StelModule member functions have default empty implementations. I.e; it seems unmaintained.
Meteor drawing didn’t work before the move, but I’m not sure if this is still the case in trunk.
Many of these classes are rather poorly documented/messy, and could use more refactoring. (Again, Meteor, for example the train data member can’t be set from outside and seems like a premature optimization.)