Reverted 5573, i.e. the OpenGL refactoring from GSOC 2012

.bzrignore

@@ -5,7 +5,6 @@ CMakeLists.txt.user
 Stellarium.bat
 stellarium.iss
 stellarium-patch.iss
-*.kdev4
 ./doc/qt.tag
 ./locale
 ./util/locations-editor/Makefile

CMakeLists.txt

@@ -220,7 +220,6 @@ SET(USE_PLUGIN_OBSERVABILITY 1 CACHE BOOL "Define whether the Observability plug
 SET(USE_PLUGIN_OCULARS 1 CACHE BOOL "Define whether the Oculars plugin should be created.")
 SET(USE_PLUGIN_PULSARS 1 CACHE BOOL "Define whether the Pulsars plugin should be created.")
 SET(USE_PLUGIN_QUASARS 1 CACHE BOOL "Define whether the Quasars plugin should be created.")
-SET(USE_PLUGIN_RENDERERSTATISTICS 0 CACHE BOOL "Define whether the RendererStatistics plugin should be created.")
 SET(USE_PLUGIN_SATELLITES 1 CACHE BOOL "Define whether the Satellites plugin should be created.")
 SET(USE_PLUGIN_SOLARSYSTEMEDITOR 1 CACHE BOOL "Define whether the Solar System Editor should be built.")
 SET(USE_PLUGIN_SUPERNOVAE 1 CACHE BOOL "Define whether the Historical Supernova plugin should be created.")
@@ -458,7 +457,6 @@ INCLUDE_DIRECTORIES(
 	${CMAKE_BINARY_DIR}
 	${CMAKE_SOURCE_DIR}/src
 	${CMAKE_SOURCE_DIR}/src/core
-	${CMAKE_SOURCE_DIR}/src/core/renderer
 	${CMAKE_SOURCE_DIR}/src/core/modules
 	${CMAKE_SOURCE_DIR}/src/core/planetsephems
 	${CMAKE_SOURCE_DIR}/src/core/external

Doxyfile.cmake

@@ -491,7 +491,7 @@ SORT_BRIEF_DOCS        = NO
 # This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
 # and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
 
-SORT_MEMBERS_CTORS_1ST = YES
+SORT_MEMBERS_CTORS_1ST = NO
 
 # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
 # hierarchy of group names into alphabetical order. If set to NO (the default)
@@ -561,13 +561,13 @@ MAX_INITIALIZER_LINES  = 30
 # at the bottom of the documentation of classes and structs. If set to YES the
 # list will mention the files that were used to generate the documentation.
 
-SHOW_USED_FILES        = YES
+SHOW_USED_FILES        = NO
 
 # If the sources in your project are distributed over multiple directories
 # then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
 # in the documentation. The default is NO.
 
-SHOW_DIRECTORIES       = YES
+SHOW_DIRECTORIES       = NO
 
 # Set the SHOW_FILES tag to NO to disable the generation of the Files page.
 # This will remove the Files entry from the Quick Index and from the
@@ -801,7 +801,7 @@ FILTER_SOURCE_PATTERNS =
 # Note: To get rid of all source code in the generated output, make sure also
 # VERBATIM_HEADERS is set to NO.
 
-SOURCE_BROWSER         = YES
+SOURCE_BROWSER         = NO
 
 # Setting the INLINE_SOURCES tag to YES will include the body
 # of functions and classes directly in the documentation.

data/shaders/xyYToRGB.glsl

@@ -16,47 +16,45 @@ uniform mediump float term_y, Ay, By, Cy, Dy, Ey;
 uniform mediump mat4 projectionMatrix;
 
 // Contains the 2d position of the point on the screen (before multiplication by the projection matrix)
-attribute mediump vec2 vertex;
+attribute mediump vec2 skyVertex;
 
 // Contains the r,g,b,Y (luminosity) components.
-attribute highp vec4 color;
+attribute highp vec4 skyColor;
 
 // The output variable passed to the fragment shader
 varying mediump vec4 resultSkyColor;
 
 void main()
 {
-	gl_Position = projectionMatrix*vec4(vertex, 0., 1.);
-
-	// Must be a separate variable due to Intel drivers
-	vec4 tempColor = color;
+	gl_Position = projectionMatrix*vec4(skyVertex, 0., 1.);
+	highp vec4 color = skyColor;
 
 	///////////////////////////////////////////////////////////////////////////
 	// First compute the xy color component
 	// color contains the unprojected vertex position in r,g,b
 	// + the Y (luminance) component of the color in the alpha channel
-	if (tempColor[3]>0.01)
+	if (color[3]>0.01)
 	{
-		highp float cosDistSunq = sunPos[0]*tempColor[0] + sunPos[1]*tempColor[1] + sunPos[2]*tempColor[2];
+		highp float cosDistSunq = sunPos[0]*color[0] + sunPos[1]*color[1] + sunPos[2]*color[2];
 		highp float distSun=acos(cosDistSunq);
-		highp float oneOverCosZenithAngle = (tempColor[2]==0.) ? 9999999999999. : 1. / tempColor[2];
+		highp float oneOverCosZenithAngle = (color[2]==0.) ? 9999999999999. : 1. / color[2];
 
 		cosDistSunq*=cosDistSunq;
-		tempColor[0] = term_x * (1. + Ax * exp(Bx*oneOverCosZenithAngle))* (1. + Cx * exp(Dx*distSun) + Ex * cosDistSunq);
-		tempColor[1] = term_y * (1. + Ay * exp(By*oneOverCosZenithAngle))* (1. + Cy * exp(Dy*distSun) + Ey * cosDistSunq);
-		if (tempColor[0] < 0. || tempColor[1] < 0.)
+		color[0] = term_x * (1. + Ax * exp(Bx*oneOverCosZenithAngle))* (1. + Cx * exp(Dx*distSun) + Ex * cosDistSunq);
+		color[1] = term_y * (1. + Ay * exp(By*oneOverCosZenithAngle))* (1. + Cy * exp(Dy*distSun) + Ey * cosDistSunq);
+		if (color[0] < 0. || color[1] < 0.)
 		{
-			tempColor[0] = 0.25;
-			tempColor[1] = 0.25;
+			color[0] = 0.25;
+			color[1] = 0.25;
 		}
 	}
 	else
 	{
-		tempColor[0] = 0.25;
-		tempColor[1] = 0.25;
+		color[0] = 0.25;
+		color[1] = 0.25;
 	}
-	tempColor[2]=tempColor[3];
-	tempColor[3]=1.;
+	color[2]=color[3];
+	color[3]=1.;
 
 
 	///////////////////////////////////////////////////////////////////////////
@@ -66,39 +64,39 @@ void main()
 	// if log10Y>0.6, photopic vision only (with the cones, colors are seen)
 	// else scotopic vision if log10Y<-2 (with the rods, no colors, everything blue),
 	// else mesopic vision (with rods and cones, transition state)
-	if (tempColor[2] <= 0.01)
+	if (color[2] <= 0.01)
 	{
 		// special case for s = 0 (x=0.25, y=0.25)
-		tempColor[2] *= 0.5121445;
-		tempColor[2] = pow(tempColor[2]*pi*0.0001, alphaWaOverAlphaDa*oneOverGamma)* term2TimesOneOverMaxdLpOneOverGamma;
-		tempColor[0] = 0.787077*tempColor[2];
-		tempColor[1] = 0.9898434*tempColor[2];
-		tempColor[2] *= 1.9256125;
-		resultSkyColor = tempColor*brightnessScale;
+		color[2] *= 0.5121445;
+		color[2] = pow(color[2]*pi*0.0001, alphaWaOverAlphaDa*oneOverGamma)* term2TimesOneOverMaxdLpOneOverGamma;
+		color[0] = 0.787077*color[2];
+		color[1] = 0.9898434*color[2];
+		color[2] *= 1.9256125;
+		resultSkyColor = color*brightnessScale;
 	}
 	else
 	{
-		if (tempColor[2]<3.9810717055349722)
+		if (color[2]<3.9810717055349722)
 		{
 			// Compute s, ratio between scotopic and photopic vision
-			float op = (log(tempColor[2])/ln10 + 2.)/2.6;
+			float op = (log(color[2])/ln10 + 2.)/2.6;
 			float s = op * op *(3. - 2. * op);
 			// Do the blue shift for scotopic vision simulation (night vision) [3]
 			// The "night blue" is x,y(0.25, 0.25)
-			tempColor[0] = (1. - s) * 0.25 + s * tempColor[0];	// Add scotopic + photopic components
-			tempColor[1] = (1. - s) * 0.25 + s * tempColor[1];	// Add scotopic + photopic components
+			color[0] = (1. - s) * 0.25 + s * color[0];	// Add scotopic + photopic components
+			color[1] = (1. - s) * 0.25 + s * color[1];	// Add scotopic + photopic components
 			// Take into account the scotopic luminance approximated by V [3] [4]
-			float V = tempColor[2] * (1.33 * (1. + tempColor[1] / tempColor[0] + tempColor[0] * (1. - tempColor[0] - tempColor[1])) - 1.68);
-			tempColor[2] = 0.4468 * (1. - s) * V + s * tempColor[2];
+			float V = color[2] * (1.33 * (1. + color[1] / color[0] + color[0] * (1. - color[0] - color[1])) - 1.68);
+			color[2] = 0.4468 * (1. - s) * V + s * color[2];
 		}
 
 		// 2. Adapt the luminance value and scale it to fit in the RGB range [2]
-		// tempColor[2] = std::pow(adaptLuminanceScaled(tempColor[2]), oneOverGamma);
-		tempColor[2] = pow(tempColor[2]*pi*0.0001, alphaWaOverAlphaDa*oneOverGamma)* term2TimesOneOverMaxdLpOneOverGamma;
+		// color[2] = std::pow(adaptLuminanceScaled(color[2]), oneOverGamma);
+		color[2] = pow(color[2]*pi*0.0001, alphaWaOverAlphaDa*oneOverGamma)* term2TimesOneOverMaxdLpOneOverGamma;
 
 		// Convert from xyY to XZY
 		// Use a XYZ to Adobe RGB (1998) matrix which uses a D65 reference white
-		mediump vec3 tmp = vec3(tempColor[0] * tempColor[2] / tempColor[1], tempColor[2], (1. - tempColor[0] - tempColor[1]) * tempColor[2] / tempColor[1]);
+		mediump vec3 tmp = vec3(color[0] * color[2] / color[1], color[2], (1. - color[0] - color[1]) * color[2] / color[1]);
 		resultSkyColor = vec4(2.04148*tmp.x-0.564977*tmp.y-0.344713*tmp.z, -0.969258*tmp.x+1.87599*tmp.y+0.0415557*tmp.z, 0.0134455*tmp.x-0.118373*tmp.y+1.01527*tmp.z, 1.);
 		resultSkyColor*=brightnessScale;
 	}

doc/codingConventions.doxygen

@@ -20,7 +20,9 @@
 /*!
 
 @page codingStyle Coding Style Conventions in Stellarium
+
 @tableofcontents
+
 The increasing number of contributors require that we clearly define coding rules and guidelines. Although for historical reasons the current code of Stellarium does not always comply to these rules, they should now be respected for any addition or modification of the code.
 
 @section stylistic_conventions_sec Stylistic Conventions

doc/mainpage.doxygen

@@ -28,39 +28,13 @@ is targetted at developers of scripts, plugins and the core program.
 
 @section architecture_sec Program Architecture
 
-The code of Stellarium is split into several main blocks: <ul>
-
-<li> the main loop and main widget classes StelMainWindow, StelMainGraphicsView and
-StelAppGraphicsWidget.  Those classes have a single instance created at startup by the ::main()
-function.  They perform tasks such as creating of the main window and renderer, creating the
-stellarium core, creating the GUI. After initialization, they manage user's input event
-propagation and event loop. They are heavily based on %Qt features.  </li>
-
-<li> the core which provides generic services and features to the other components.  The main
-class is the StelApp singleton which is used everywhere in the code to access other elements.
-The StelApp instance creates all the main core services and modules at initialization.  Example
-services are sky layer management (e.g. images which have a fixed position in the sky) with the
-StelSkyLayerMgr, drawing with StelRenderer etc. . Two especially important manager classes are
-the StelModuleMgr and StelCore: the former manages the collection of StelModule instances
-registered in the program (see next point for more info on what a StelModule is). The latter
-provides performance critical features for computing coordinate transformation and other
-mathematical services.  </li>
-
-<li> a collection of StelModule instances which display the main elements of the program such as
-planets and stars. Each StelModule should be registered to the StelModuleMgr. Because many
-Stellarium components derive from the StelModule class, the main loop is able to treat them
-generically by calling their standard methods such StelModule::update() and StelModule::draw()
-at each program iteration. This also allows other program components to access them by name.
-StelModule can also be loaded dynamically by Stellarium, which is the standard way of creating
-@ref plugins.  </li>
-
-<li> the Graphical User Interface (StelGui). It is based on styled %Qt widgets which are
-rendered directly in the graphics window. User actions trigger signals connected to core and
-StelModules slots.  </li>
-
-<li> the script engine (StelScriptMgr) allows scripts to calls slots from the core and
-StelModule slots.  </li>
-
+The code of Stellarium is split into several main blocks:
+<ul>
+<li>the main loop and main widget classes StelMainWindow, StelMainGraphicsView and StelAppGraphicsScene. Those classes have a single instance which is created at startup by the ::main() function. They perform various tasks such as the creation of the main program window and openGL context, the creation of the stellarium core, the creation of the GUI. After initialization, they manage user's input event propagation and event loop. There are heavily based on %Qt features.</li>
+<li>the core which provides a number of generic services and features to the other components. The main class is the StelApp singleton class which is used everywhere in the code to access other elements. It is the StelApp instance which creates all the main core services and modules at initialization. Example services are OpenGL textures management with the StelTextureMgr, font management with the StelFontMgr, sky images management (images which have a fixed position in the sky) with the StelSkyImageMgr etc.. Two especially important manager classes (the ones with the "Mgr" suffix) are the StelModuleMgr and StelCore classes: the first one manages the collection of StelModule instances which are registered in the program (see next point for more info on what a StelModule is). The second one provides performance critical features for rendering various elements using openGL, or for computing coordinate transformation and other mathematical services.</li>
+<li>a collection of StelModule instances which display the main elements of the program such as planets and stars. Each StelModule should be registered to the StelModuleMgr. Because many components of Stellarium derive from the StelModule class, it is possible for the main loop to treat them generically by calling their standard methods such StelModule::update() and StelModule::draw() at each program iteration. It also allows other program components to access them by name. StelModule can also be loaded dynamically by Stellarium, which is the standard way of creating @ref plugins.</li>
+<li>the Graphical User Interface (StelGui). It is based on styled %Qt widgets which are rendered directly in the openGL window. Users actions trigger signals which are connected to core and StelModules slots.</li>
+<li>the script engine (StelScriptMgr) allows scripts to calls slots from the core and StelModules slots.</li>
 </ul>
 @image html stellarium-architecture.png