Thursday, July 12, 2007

Quick reminder

Here's my first update which i did in '/marble/projects/flatproj', that was before I decided to move to a blog, and my decision to move to a blog was mainly done because of the 'blogish' style it had:

Hello everyone, this is a quick update in the development of the 2D projection of Marble.
The first week of the project wasn't very productive. It wasn't until the second week that this project took off, the next two weeks were very productive indeed. We've been working since then in the mapping of the texture for the flat projection. Finally we arrived at a point in which I think that part is almost ready, so for now we can paint the background of the map, other layers will be ready in a very near future.
In the current approach I totally reused the painting method that was already built in Marble named pixelValue, in which basically, I just calculate: the point in the screen what I want to paint and the longitude and latitude it must be representing so that i just send it to the pixelValue method and it automatically loads the needed tile and paints it accordingly.
Currently the zooming and moving of the map is already done so I can show you, this wouldn't be a good update without a screenshot, so please visit to see how's already done. What we see there is the texture being loaded but nothing else.
This used to only work on my PC because it was not a method by itself but most like a patch, now it's fully integrated with Marble's SVN, anyone who compiles marble can chose whether it paints the earth as a globe or as a flat map. So what was just done? well we changed the classes so that we could split them in different methods. The old class was TextureMapper which (as all other classes) assumed that we are painting a sphere, so we changed that behavior to ask how are we painting instead.
For that end, Andrew Manson introduced a new class named AbstractLayer so that any layer (and hence any painting method) can be inherited from that class. So I introduced another class which inherits from AbstractLayer: AbstractScanlineTextureMapper which will provide the methods or 'tools' and the basic values (such as the center point, the height and the width of the painted area...) needed to paint a map using an Scan-line approach (basically this means that we go scanning every pixel in every line of the painting area and calculate what longitude and latitude it must represent).
Once I did that, we inherited 2 classes from it: FlatScanLineTextureMapper and GlobeScanLineTextureMapper, booth have a self-explanatory name, but in case you don't get it we made our two methods for our two projections: Flat and Globe.
This is done and I only have to solve some medium (such as mouse detection, which still thinks that the globe is being painted) and minor problems.
So what will happen next? (hopefully a lot :D) well the first half of the GSoC project will be finished by fixing the mouse behavior and allowing place-marks to be painted as well as the vector map (rivers, countries, and so on...), and hence giving a full useful flat projection for marble.
In the next half of the project we will be working in another approach for the mapping method which will hopefully improve performance, my guess is that we will have a minor or medium, at most, performance gain because what will be changed is basically that we will no longer use the method pixelValue to look for the tiles needed and hopefully reduce HD seeking.

I post the image so that you don't have to follow the link, nor waste kde bandwith ;), so here is it:

After 'publishing' the post I was corrected by my mentor, Torsten, that the HD seeking is not the problem that we want to avoid but the fact that we recalculate and repaint everything again when we move the map. This is not needed in a flat projection, as the viewpoint doesn't change. So this will be solved in the next half of the project.

I'm not very versed in this topics, but according to my mentor what we will do is upload the map to the X server and then just repaint the areas which are missing when we move the map (or at least that i understood). That way we will vastly improve performance as we will not waste cycles in parts of the map that we already know.

And remember,this post it's outdated, and is merely an introduction, I will post another one in a couple of days in which I'll show you that the placemarks and the grid are coded.

Tuesday, July 10, 2007

First post

Hello, this is the first post of my blog. I've never really liked the blogs mostly because I had nothing interesting to say, however this has changed recently as I became a member on the GSoC project working on Marble an application for the KDE desktop. So I now have something to report to everyone: my development on Marble and any other project I might get my hands on. Currently I plan to continue in the marble development even after the end of the GSoC because it has been an excellent experience.
As the project it's halfway done I will post some post quickly basically describing what has been done and what still needs to be done. So here I'm, any comments are welcomed and will improve what we hope will be an excellent program: Marble.