Athanasios Mantes writes:
Martin Spott wrote:
Martin Dressler wrote:Does this mean that all datasets are divided in tiles of the same
So I am asking for a way, or technique so as when rendering an objectFlightGear doesn't face similar problems. Sorry
after another, to avoid rendering the part of the object that is
vertically (same x,z coords) "covered" by the previous object, so as to
avoid mixing them. Here
(http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note
about the clipping I want to achieve. It is a side view of a rendering
of a terrain model, consisting of three datasets. How does FlightGear
face similar problems?
.... but there is a resembling situation. As I understand FlightGear _is_ capable of dealing with datasets of different resolutions. The situation is solved by having all data chunks comply with a distinct naming scheme based on the geographical location of each chunk. The a search path for scenery data is set up and when the tile manager requests a new tile he fetches the first one that appears in the search path. Appropriate ordering is achieved by placing the highest resolution chunks into the directory that appears first in the path,
dimension? If that is true, then the resolution of the datasets
displayed is a multiple of a pre-agreed quantum. (Forgive me if all
that is trivial to flightgear developers, but I'm new to the subject...)
There is only one data set for the terrain at run time in FGFS
Any merging is done off line ahead of time in a preprocessing operation that takes 'days' for the whole world
The resultant tiles may be of different size depending exactly where you are but any required edge matching is all done offline ahead of time in the preprocessing step.
Run time merging of different datasets is a difficult problem and is
currently beyond the scope of the FGFS Terrain engine
I'll also chime in that the original poster appeared to be approaching this issue with the assumption that a regular grid of data will be used ... probably assuming some sort of CLOD or ROAM type algorithm.
FlightGear as Norman points out preprocesses all the terrain data and chooses the highest resolution data set available for any given tile. It then runs a data reduction algorithm to generate a smaller subset of points that approximate the original set within some error tolerance. The resulting set of points is *not* a regular grid. Instead, the points are concentrated in rougher areas and spread thinner in smoother areas. We triangulate the resulting set of points to produce the surface we render. At the moment we produce and draw only a single level of detail for the entire world. This was a design choice that made a lot of sense at the time we made it, and still makes sense for many reasons today. Don't get me wrong, this approach has it's downsides too, so there is room for debate and differences of opinion on the subject. However, we have done a pretty good job of making this approach work pretty well for our needs.
If anyone is disturbed by our approach, they are very welcome to produce an alternate scheme that runs in parallel to the current default scheme. It is no small task though which is why I suspect no one has attempted to do this. And many of the other approaches we could try have their own sets of disadvantages, and often don't scale well to covering the entire world.
Regards,
Curt.
-- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
