Curtis L. Olson writes:
> 
> Paul Surgeon writes:
> > I'm sure this subject has been brought up plenty of times but I
> > think it would be great to compile a list of all the features that
> > we need the FG terrain rendering system to support.
> 
> Norman Vine writes:
> > > - Ability to cut in polygon models of airports.
> > 
> > Any cut in polygons respect tile boundaries 
> > i.e a polygon can only be in one tile 
> 
> It's easy to chop up polygons on tile boundaries, but you are probably
> referring to airport areas. :-)

I am referring to any polygon whether or not they are part of an airport
area is immaterial :-)

This has been discussed before and I do appreciate the 'pain' factor
on the construction side of things but having to special case airports
to cross tile boundaries is a killer when it comes to subdivision and
or indexing schemes.  

> 
> > > - Ability to page terrain / textures so continuous flights around the
> > >   world are still possible.
> > 
> > :-)
> 
> I only say this because I've seen a lot of ROAM type demos that look
> cool for a small area, but I get the sense that it's a bit trickier to
> build an entire seamless earth.  It's probably been done in commercial
> games (?) but I haven't seen this done in the open souce world.

Hence my smiley, also I am not convinced that FGFS should adbandon 
using pretesselated scenery in favor of a ROAM approach.  This doesn't 
necessarily mean that we can't have scenery LOD though

> Modeling the entire world is a good way to keep yourself
> honest. :-)

You are preaching to the choir here :-)
 
> > I think we could make the current scheme work as the only thing changing
> > will be the local 'Z' and height calculations would be *much*  simpler
> 
> We have to be careful though of objects floating up and down
> "noticable" as the underlying terrain LOD changes.

Yes and the Local Z simplification really only applies to ROAM like
tesselations not TINs
 
> > We still need polygons to shape the terrain for roads, rivers etc. during 
> > scenery creation and then there are the airports.
> 
> My understanding is that roads, rivers, lakes, cities, etc. (all that
> stuff we handle with 2d polygons right now) could be embedded in the
> aerial photos / textures that we are draping over the terrain, so
> there would be no need to cut them in as polygons.

I am not necessarily suggesting a ROAM approach as the data 
requirements are humongous both for the textures and the elevations.

What I think would be most beneficial is to write an abstract interface
for terrain first so that the actual mechanism used is not exposed to the
rest of the SIM.  What we have is a good start on this.

Cheers

Norman

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to