Hi Ferdinand, I've been reading your emails with interest, and also had a look at your branch. I think there are many things to do with OpenGL indeed. In the task list are:
1- Increase the isolation of the drawing code from the rest of the code. This is an effort which I started some years ago which led mostly to the StelPainter class. As you correctly mention, this work is not complete and could be improved quite easily. However, if we want to keep compatibility with GL1 (which I think is desirable), there will always be a part of the code which will need to to do things like "if GL1" xxx else yyy. This is because the logic contained in a complex shader like the one used for rendering atmosphere simply cannot be abstracted so that the code is similar for GL1 and GL2. I personally think it is quite OK to live with both versions if it's clear enough which part belong to which. This is not always the case currently, and I can imagine that using inheritance model to override GL2 part of the code could make things cleaner. 2- Investigate using the Qt3d framework (going to be release as part of Qt5: http://doc-snapshot.qt-project.org/5.0/qt3d-reference.html). This is a huge work that Qt people did here and could be used as a base framework for abstracting our GL rendering code. 3- Try to make the best use of GL2 features for our rendering code. In our code you have noticed that we don't make use of VBO. The main reason for that is that we currently need to pre-process most of the vertex in the CPU before sending them to the GPU. This is because in Stellarium we use non-linear projections (see StelProjector and StelProjectorClasses class) which cannot be described with a matrix and therefore don't fit the GL1 pipeline. What we currently do is basically projecting all vertex by hand on the CPU and just sending 2D vertices to the graphic card for display (see for example StelPainter::projectArray() ). Sometimes it's a bit more complicated because we also need to tesselate polygons when the distortion is too high or get rid of discontinuities (see StelPainter::drawStelVertexArray() ). If we decide to drop GL1 completely in a branch this would allow to move more part of the computing to the GPU which could handle some of these operations. However this task may have a very high complexity cost if it's not done very cleanly: maintaining dozen of shader which also may need to be recombined dynamically is not a trivial task, and I quite often doubt that the performance improvement will justify the increase in complexity. Again the solution may come here from the Qt3d code which could provides a nicer way of dealing with GL objects and a clean management of shaders. If you are interested by those challenges, let me know :) Fab On Fri, Mar 30, 2012 at 03:45, No Idea <[email protected]> wrote: >> If you can do this, please already take into account what's announced for >> Qt5: Drop of support for OpenGL1. > > I wasn't aware of this. I too think there should still be support for > older hardware. > I wouldn't worry about (new) netbooks (or other cheap hardware) not > supporting GL2, though. > > The main reason to support GL1 I can see at the moment are some open source > Linux drivers (especially older Radeons not supported by AMD anymore), > and some older Intel GPUs. On Windows Nvidia/AMD front, GL2 support > goes way back. > > The open source drivers are improving very fast lately, though. > > > I'm planning to reimplement existing functionality, and that includes GL1. > My idea is to have the main code in separate classes for each GL version > ("Renderer" - or whatever you name it - implementations: GL1Renderer, > GL2Renderer, etc.), while the code that can be shared would > be in classes commonly used by the implementations. > The QGL setup code could be separated into another class > ("GLProvider" - implemented by - Qt4GLProvider, Qt5GLProvider?), > which would be used by GL implementations of "Renderer". > > The result should be easy to adapt for Qt4/Qt5 builds with > a little conditional compilation (right now, #ifdefs are all over the place). > > (I don't know much about where does Qt 5 bring breaking changes - > all I know it's not supposed to be very drastic) > > > As for maintainability - I think I can write better documented code than > what I see in some places in Stellarium at the moment :) . > (There is a _lot_ of undocumented classes/methods all over the place). > > As for developer guidelines - what exactly do you mean? > API docs with examples for users? > (which I plan to do - you can look at my previous projects - linked to before) > > Or guidelines for future developers? > I can document the ideas behind the implementation, if that's what you mean. > > On 3/28/12, No Idea <[email protected]> wrote: >> As discussed on IRC yesterday, I propose a major OpenGL refactor >> as a project instead. >> >> The goal of this project would be to separate all OpenGL code >> into a separate subsystem consisting of multiple classes. >> Maybe even a separate namespace? (Stellarium doesn't seem >> to use namespaces - should I just put the code into >> a separate directory? - I'd like all "video" code to be in one place) >> >> This would have an implementation-independent API, >> as is common in various game engines, >> so that there could be separate implementations for >> e.g. GL1, GL2, but, in future, it'd be also easy to add >> GL3/4 or GLES. (even a SW renderer or D3D I guess). >> >> Note that I don't propose any new functionality, just a rewrite >> of what's already there. However, it should be easier to >> build on the refactored code, add support for e.g VBOs, >> and also to look for bugs and optimization opportunities. >> >> This weekend, I'll branch the Stellarium repo and experiment >> a little, and send a GSoC application. >> >> (Don't have time right now due to the university.) >> > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Stellarium-pubdevel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
