Re: [Plib-devel] ssg sky

[Steve B. <sjb...@ai...>]

Durk Talsma wrote:

> > > Curt wrote:
> > >
> > > >     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
> > > >
> > > >I'm designing this in such a way that you can use a separate module
> > > >that calculates the real positions of the sky objects so you can have
> > > >a live dynamic sky that will precisely match the real world.

> > I'd certainly offer it up for potential inclusion in plib/ssg, but the
> > decision would be up to Steve.

I think it's very appropriate.

I imagine we're going to need to think in terms of an auxiliary library:
XXX is to SSG as GLU is to GL...where 'XXX' is this new thing.

> > My interests are more simulation
> > oriented rather than game oriented.

There are less differences than you might expect.

> >  I've been considering putting
> > together my own package of things that would sit a level up from plib,
> > or be out of the scope of plib ... things like a drop in sky, terrain
> > rendering/paging tools, or even a collection of vehicle dynamics
> > codes.

100% what I had in mind.  I've been thinking about extracting the
'walking/jumping/falling/sliding/swimming' code out of my Tux game
and putting them into such a library.  Adding some *simple* flight
math (nothing like as complex as flight gear) and some simple car
driving dynamics would produce something that would let most wannabe
games developers throw something together in very short order.

> > I'm thinking it would be nice to have plib + my_package = getting your
> > simulation project off the ground quickly.

Yes.

> The code that calculates the right position of the sun, moon, and planets
> currently pretty much intertwined with the rest of FlightGear, and one of my
> intentions is to seperate this from the core of the simulator code.

Good.

> Because
> Astronomy and time code is pretty much intertwined, I'm currently thinking of
> reorganizing this into a single time/astromomy lib. Though I'm open to
> including this code in plib as well, I'm not sure if this is the right place
> for this lib to go.

I guess we have some layering here:

        date + local time + lat/long position
                       |
                       |
                       v
          universal time + lat/long position
                       |
                       |
                       v
            Position of sun/moon/stars
               and sky colours
                       |
                       |
                       v
             Correctly rendered sky

The issue here is where to slice the layer that we want to be in SSG-Utils,
and what part to leave behind into some other package - or in FGFS.

It's not a particularly easy choice.  I'd guess that most games would want
to describe the colours of the sky in some detail (eg one of the Tux levels
has a completely orange sky to give a feeling of opressive heat - there is
no time of day I could feed into the top of that stack to get an orange
sky).  I'd guess that they'd also want to specify the general local time
of day though - but they wouldn't even care where the stars ended up.

Disentangling those things sounds tricky since we need to cross layers.

For my Tux game, I'd want direct control over the sky colour
and some very simple interface (like local time of day) to set the
sun/moon/stars.  I'd like to set the horizon colour(s) and the sky
top colour directly - then say "8:00am" and have everything else
'do the right thing' at some default lat/long/date.

OTOH, I could imagine (say) a car racing game having a user-settable
time of day so you could race at night, at dawn and at midday - and
even have the time change dynamically like it does in FGFS.

So, having the sky colours be 'right' for that time of day would
be OK for some games - but definitely not for others.

Only something like a flight sim would be likely to care about such
subtle effects as lat/long and date on the look of the sky.

I'd be quite happy to include all the 'astronomy' code into PLIB since
it's probably not actually very many lines of code - but exposing the
appropriate interface to set sky colours and such like directly would
be important - and it might be easier to do that by simply slicing off
the 'astronomy/time' layers and exposing whatever is left sticking up
as the API to the sky renderer.

Some other random thoughts:

* It would be cool to generalise the sky code to allow multiple moons
  (games set on Mars perhaps) and multiple suns (games set on Tattoine).

* What about clouds and how that ties into FGFS's weather modules....ikky!

* Does Curt's current sky code set SSG's light sources to the sun and/or
  moon coordinates?

> Eventually, I'd like to develop some code that is also suitable for use in
> stuff like a Space Flight simulator, and this would impose an additional
> demand on the lib. My first choice in that case would be to include the
> Astronomy and Time code in something like Curt's SimGear lib. As said, I'm
> open to suggestion.

Yes - me too!

What I want to avoid at all costs is introducing more dependancies into
games that use PLIB.  If Curt's new sky code is to be in some SSG-Utils
library then it needs to depend only on SG/SSG and (possibly) other PLIB
components.  I don't want people to have to download SimGear in order
to get (say) Tux_AQFH to display stars/sun/moon.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)