From sjbaker@hti.com  Fri Sep 24 11:53:12 1999
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	["3650" "Fri" "24" "September" "1999" "11:43:23" "-0500" "Stephen J Baker" "sjbaker@hti.com" "<Pine.SGI.3.96.990924112154.13575A-100000@sutcliffe.bgm.link.com>" "88" "Re: Photo-realistic terrain" "^From:" nil nil "9" nil nil nil nil nil]
	nil)
Received: from issun6.hti.com (sunmgr.hti.com [130.210.206.69])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id LAA76009
	for <curt@me.umn.edu>; Fri, 24 Sep 1999 11:53:11 -0500 (CDT)
	(envelope-from sjbaker@hti.com)
Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA6C17
          for <curt@me.umn.edu>; Fri, 24 Sep 1999 11:52:40 -0500
Received: from sutcliffe.bgm.link.com ([130.210.63.42]) by issun5.hti.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA7249
          for <curt@me.umn.edu>; Fri, 24 Sep 1999 11:52:39 -0500
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sjbaker@hti.com>
In-Reply-To: <14315.41678.337648.604806@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.990924112154.13575A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: "Stephen J Baker" <sjbaker@hti.com>
To: "Curtis L. Olson" <curt@me.umn.edu>
Subject: Re: Photo-realistic terrain
Date: Fri, 24 Sep 1999 11:43:23 -0500 (CDT)

On Fri, 24 Sep 1999, Curtis L. Olson wrote:

> Someone asked about doing satallite based terrain overlays for flight
> gear.  They are doing MSFS scenery right now so they have the imagery
> and were considering doing a dual MSFS/FGFS scenery release.
> 
> In theory we could do that with the current file formats, although the
> big issue if you flew very far would be texture management.
> 
> So, have you put any thought into how something like this could be
> reasonably managed in ssg or is this a higher level issue that flight
> gear should worry about.
 
It's *definitely* a Flightgear problem.

> I guess from the fgfs perspective I could create and delete "states"
> as needed ... does ssg free up memory when you delete a state?
 
Yes - but that's not the fast thing to do.

Presuming all your texture maps are the same size, it's MUCH, MUCH
faster to reload the texels in the map using glTexSubImage than it
is to create a new map.  Also, glTexSubImage lets you update a
small chunk of the map each frame, so you can manage the amount
of time it takes to page in a map versus the amount of rendering
bandwidth you consume actually doing the download.

Hence, you'd design your terrain tools to use (say) 25 texture
map id's (and hence 25 ssgState's) in a 5x5 grid. Hence, tile[n][m]
in your world would reference ssgState ground_state[n%5][m%5].

Paging texture into those 25 slots could then happen in parallel
with the terrain pager.

However, to do all this stuff well, you find that you never have
anywhere close to enough texture memory even for a fairly coarse
texture precision because you are using 1024x1024 texture maps
(or whatever) for terrain tiles that are only (say) 128 pixels
across on the screen.  That's a terrible waste of texture memory.

The fix (in OpenGL 1.2 *only*) is that you can now limit the
range of MIPmaps that a polygon will use. Hence you only need
to load the lower level MIPmaps for that terrain tile until/unless
it gets close to the eye.

That's all well and good - but if you are using the glTexSubImage
trick to speed up texture swaps, you'll still have to have
texture memory assigned to the highest level map.

Perhaps an alternative is to keep some ssgState's for low
res maps out at the horizon and others for high res ones
close to the eye. That gives you more texture downloading
to do because you download the low res maps to the hardware
more than once.

I think this is going to be *VERY* hard to do on a PC without
breaking frame rate almost continuously.

In terms of actual SSG changes, we could add some API to hide
the actual glTexSubImage call:

void ssgTexture::loadSubImage( <stuff> )
{
  glTexSubImage ( handle, <stuff> ) ;
}

- but that wouldn't actually buy us much in terms of structure
or convenience - you can already get the GL texture handle out
of SSG if you ask it politely.

> I know we've had the discussion on the issues and on the relative
> merits of photo-realistic/satallite based textures vs. generic tiled
> textures.  It might be nice to support doing both depending on
> people's preferences.

Yep.  You are looking at a LOT of work though.

IMHO, you need to do the work of splitting the terrain pager
off into another thread before you even *consider* texture
paging.  Adding the texture pager to the current (non-threaded)
pager will just make it that much harder to split the pager
into another task when you eventually get around to doing
that.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

