> As with everything, really, the key here is integration.  Make it work
> with FlightGear so we can test.  Saying "here is code, can we use it?"
> just isn't enough.  It needs to be "here is a patch, try it and tell
> me what breaks".  Until we get that far, there really isn't much to
> argue about.

I completely agree with you on the integration part. I think the engine
is technically adequate for its intended purposes (i.e. satellite-textured 
landscapes). If you have any questions concerning the technical side, feel
free to ask. In this light, its also important to see it as an alternative,
not a replacement, for the current scenery, because each engine will have its
own set of advantages and disadvantages. 

By using an abstract API, a terrain engine could be choosen at runtime.
But it will definitely take some work to abstract out the terrain engine.
The good thing is, such an abstract API would make the scenery subsystem 
more modular and easier to use than in its current, tightly coupled form. 

I have attached what I could imagine as a useable terrain API (modulo
conflicts with reality :-)).


 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * General Public License for more details.
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 * \short Abstract class to define the API for the terrain rendering subsystem.
 * written by Manuel Massing, (c) 2004 by Manuel Massing
#ifndef TERRAIN_H
#define TERRAIN_H

#include <FDM/flight.hxx>
#include <string>
using namespace std;

class GeocCoord;

 * \short Abstract class which defines an API for the terrain rendering subsystem.
 * Offers methods for:
 * - rendering & detail management
 * - Airport management
 * - collision & elevation queries
class Terrain {
	enum RenderEntity {
		trTerrain              = 1,        // The basic landscape
		trRunways              = 2,        // Runway structures
		trRunwayLighting       = 4,        // Runway lighting
		trStaticGroundObjects  = 8,        // Landmarks, buildings, trees which were placed at scenery generation time
		trDynamicGroundObjects = 16        // Procedurally generated ground objects, e.g. trees, buildings

	 * Prepare rendering for the given viewing paramaters and the 
	 * configured detail levels.
	virtual bool update(FGViewer *viewer) = 0;

	// Interface it with scene graph or via a render() method?
	// Returning a scene-graph node is probably the better solution,
	 * Render the terrain using the viewer position and the given rendering flags.
	 * \note that rendering entities which where disabled during the update() call (i.e. entities with a detail setting of zero) will not be rendered.
	virtual void render(RenderEntity renderFlags) = 0;

	 * Return a scene-graph node which
	//SGNode *getSceneNode(RenderEntity flags);
	 * Set the detail level for the indicated rendering entity.
	 * Valid range is 0 (disable rendering) to the value returned by getDetailLevels(enum Renderflags),
	 * which corresonds to maximum detail.
	 * \param RenderEntity
	 * \param detailLevel The desired detail level, in the range 0 to getDetailLevels(entitiy).
	virtual void setDetailLevel(RenderEntity entity, const unsigned int detailLevel) = 0;
	 * A clear text (human-readable) explanation of detail level modalities.
	 * e.g. getDetailLevelFeatures(trTerrain, 1) could return
	 *      "Render terrain within 32 pixels accuracy.\n"
	 *      "Disable texture mapping.\n"
	 *      "Disable shading.\n"
	 * This is needed to offer an abstracted but descriptive representation for the user interface.
	virtual string getDetailLevelFeatures(RenderEntity entity, int detail_level) const = 0;

	 * Indicates whether airport definitions can be dynamically added at runtime.
	 * Otherwise, the terrain implementation only supports pre-compiled airports 
	 * (i.e. airports included at terrain-build time).
	virtual bool supportsDynamicAirports() const = 0;
	 * Add specified airport.
	 * Fails if airport already exists or dynamic airports are not supported.
	 * \param ID Zero-terminated string of the airport identifier
	 * \param airport An instance holding all the relevant information about the structure of the airport to be added.
	 * \returns true on success, otherwise false.
	//virtual bool addAirport(char *ID, const Airport &airport) = 0;
	virtual bool removeAirport(char *ID) = 0;
	 * Indicates whether an airport with the given ID is represented in the
	 * scenery.
	virtual bool hasAirport(char *ID) = 0;

	// Collision & elevation queries
	struct GroundInfo {
		FGInterface::GroundType type;         //! Ground type: Solid, Forest, Water, Catapult, Wire 
		sgVec3                  velocity;     //! Velocity of the ground surface
		float                   elevation_ft; //! Elevation above sea-level in feet
	//! Return the ground elevation in feet above sea-level.
	float                   getGroundElevation(GeocCoord &pos);
	FGInterface::GroundType getGroundType(GeocCoord &pos);
	//! Return ground type and elevation in a GroundInfo structure.
	GroundInfo getGroundInformation(GeocCoord &pos);

Flightgear-devel mailing list

Reply via email to