Hi Fabien, I've been offline during the last few days (due to RL issues) - but I'm definitely interested.
(I sent my GSoC application on Sunday - based on the ideas I've already mentioned on the mailing list. Those might still be subject to change if needed.) I have only had a brief look at StelProjector so far, but I think it might be possible to move it to the video subsystem side, with each projector having a manual and shader based implementation. That might not be a good thing if the user code needs to create their own Projectors, though, as it'd require them to write multiple implementations. Perhaps it could be written in such a way that a manual implementation (universally usable by any backend) always exists, with an optional shader-based implementation. Still, as said before, my primary goal is to refactor the code (with separate GL1 and GL2 implementations). Initially, code such as StelProjector would still be outside of this, but i should be easy to move into the video subsystem. Same with using features such as VBO. Once I get the refactoring work done, I can concentrate on more GL2 features. What's important is that the refactored code leaves space for alternative implementations. (This also decreases the probability of unexpected bugs) About Qt5: I haven't had a chance to play with it yet, but AFAIK it shouldn't bring too many breaking changes. What's the timeline for Stellarium to start supporting Qt5? How drastic changes will be needed in Stellarium? Is this something I can expect to happen before/during GSoC, or would I have to set it up/ update it to work with with Qt5 myself? About Qt3D: We need a GL1 backend, which depends on Qt4. If a GL2 backend depends on Qt3D (part of Qt5), it would not be usable in the Qt4 build. So we'd end up with a Qt4/GL1 build and a Qt5/GL2 build. Is that acceptable? The only other way would be to have two GL2 backends (which probably could share some code). That said, from my look at Qt3D, most of it seems to be introduced in Qt 4.8. So it might be possible to only use a Qt 4.8-compatible subset. I've had a look at it and it seems like Qt3D would greatly simplify a GL2 backend (e.g. an easy-to-use VBO wrapper and QGLBuilder - I expect to create a similar class for geometry generation and it seems like QGLBuilder would be a good backend). It seems to have other useful features, such as 3D model loading, but I don't think that should be a part of the video subsystem. FM On 4/5/12, Fabien Chéreau <fabien.cher...@googlemail.com> wrote: > 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 <kiithsa...@gmail.com> wrote: > > ------------------------------------------------------------------------------ > 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 > Stellarium-pubdevel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
