Re: [Plib-devel] ssg sky

[Curtis L. O. <cu...@in...>]

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.

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

Steve Baker writes:
> 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.

That's good news, I'm glad you are interested in doing something like
this.  I see two levels of things that might be useful ... a library
of routines to build primitive objects ... spheres, cones, boxes,
etc.  Something analogous to GLU.

Then there could be higher level items such as a complete drop skies,
or drop in terrain renderers, or ... what else is there ... everyone
here is only interested in flight sims, right? :-)

> > > My interests are more simulation
> > > oriented rather than game oriented.
>
> There are less differences than you might expect.

Yup, lots of stuff that applies to both sides ...

> > >  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 will be starting my new position in early april.  I haven't made any
official announcement yet to the cyber community (not that it would be
of interest to that many people ...)

Vehicle dynamics will be one big issue on my plate.  It would be great
to have something decent I could just use, but if not, I will make my
best effort to contribute whatever I have to write myself.

> 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.

To understand my sky implimentation, imagine some contraptions where
you have complete control over the positions of everything, and it
starts out with everything dangling in a big heap.

For a game that doesn't care about accurate positioning of these
things, you can just pick any position that looks good for you (by
trial and error for instance.)

For they sky, you need to feed in a top sky color and a horizon color.

This could be calculated by time, or sun angle with the horizon, or
you could just feed in random colors such as orange at the top and
purple at the horizon.

> 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.

True, that is why I set up the sky so these things are completely
driven externally ... and I would expect that as soon as someone tries
to use this outside of flightgear, they'll send me a nice long list of
additional parameters they'd like to have control of.

> 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.

I know the resistance to introducing additional packages and
dependencies, but somehow things that get into modeling of the real
world seem to me to be beyond the scope of plib.

> 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).

This would be easy ... although would involve some changes to the api.
Hmmm, multiple suns and moons ... that might make for some interesting
moon phase effects. :-)

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

I would like to build cloud support directly into the sky model and
provide some api to specify multiple cloud layers, altitude,
thickness, density, random variation, sunrise/set effects, wind
effects, and probably a few other things, but I probably won't have
time to deal with this in the near future.

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

My code right now just builds the ssg structures and provides a
mechanism for orienting/placing them properly.  I set the light source
else where.

> 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.

There may be some current simgear dependencies, but perhaps with a bit
of thought, most if not all of these could be removed.  The big one
that comes to mind is I use flight gear's mac/pc/unix path
generalization class ... but this could be eliminated and I could just
require the caller to provide the appropriate complete path to the
files needed (two textures and a star database.)

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org