plib-devel

[Plib-devel] ssg sky

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

For those of you not familiar with flight gear, here is a quick screen
shot of the sky elements I am working on building with ssg.  These
things should just depend on plib (and have no flightgear
dependencies.)

     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.

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

RE: [Plib-devel] ssg sky

[Dave M. <dp...@ef...>]

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.

cool! glad to see your hard work paid off.
is this intended for possible inclusion in ssg or a ssg example
or will it be only in flightgear.

--mcdave

RE: [Plib-devel] ssg sky

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

Dave McClurg writes:
> 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.
> 
> cool! glad to see your hard work paid off.
> is this intended for possible inclusion in ssg or a ssg example
> or will it be only in flightgear.

Dave,

I'd certainly offer it up for potential inclusion in plib/ssg, but the
decision would be up to Steve.  My interests are more simulation
oriented rather than game oriented.  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.

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

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

Re: [Plib-devel] ssg sky

[Durk T. <d.t...@di...>]

Curtis L. Olson wrote:

> Dave McClurg writes:
> > 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.
> >
> > cool! glad to see your hard work paid off.
> > is this intended for possible inclusion in ssg or a ssg example
> > or will it be only in flightgear.
>
> Dave,
>
> I'd certainly offer it up for potential inclusion in plib/ssg, but the
> decision would be up to Steve.  My interests are more simulation
> oriented rather than game oriented.  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.
>
> I'm thinking it would be nice to have plib + my_package = getting your
> simulation project off the ground quickly.
>

Well since this is my first post to the plib list, a quick introduction (for
people who are not subscribed to any flightgear list). The original (non
plib/ssg)  version of the astronomy code was written by me, approx. between
1997 and 1998. And in addition to this, I also worked on some other parts of
the FlightGear projects, mainly involving time code, some gui work, as well
adding a preliminary form of clouds. Because I haven't had much chance to
contribute lately, I haven't worked with plib that much.

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

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.

Regards,
Durk

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)

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

RE: [Plib-devel] ssg sky

[Norman V. <nh...@ca...>]

Curt wrote:
>
>I will be starting my new position in early april. 

Congrats !

Norman

Re: [Plib-devel] ssg sky

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

"Curtis L. Olson" wrote:

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

Yep.

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

I wasn't thinking of the full sophistication needed in a serious
simulation - just something quick and dirty to let potential game
developers get started quickly.

Something like the code that the SGI Performer library provides for
that kind of thing.
 
> For they sky, you need to feed in a top sky color and a horizon color.

Is the horizon directional?  When the sun sets (for example), the sunset
colour is most intense near to the point where the sun goes down.

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

MmmMmmmm - green and magenta skies.

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

Yes - I think so.  It's not so much that it's beyond the scope as
that PLIB is meant for games where the restrictions implied by
modelling the real world are frequently unacceptable.
 
> 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.)

PLIB really needs a path generalization thingy - perhaps we should
just suck that into the package too.

However, for the textures you could just look in the ssg path or let
the application tell you where they are.

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

Re: [Plib-devel] ssg sky

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

Steve Baker writes:
> > 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.
>
> I wasn't thinking of the full sophistication needed in a serious
> simulation - just something quick and dirty to let potential game
> developers get started quickly.
>
> Something like the code that the SGI Performer library provides for
> that kind of thing.

Sure ... we could save the sophisticated vehicle dynamics for another
library. :-)

> > For they sky, you need to feed in a top sky color and a horizon color.
>
> Is the horizon directional?  When the sun sets (for example), the sunset
> colour is most intense near to the point where the sun goes down.

Yes, you can specify an angle to rotate the sky so it can align with
the sun.  Again, the value of this rotation would be calculated
externally (and flight gear already contains the math to do this.)

> > 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.
>
> MmmMmmmm - green and magenta skies.

I'd hate to not be able to accurately model your world Steve. :-)

> PLIB really needs a path generalization thingy - perhaps we should
> just suck that into the package too.
>
> However, for the textures you could just look in the ssg path or let
> the application tell you where they are.

Yup, that would work fine.  If you like, I'd be happy to move
FlightGear's path generalization code to plib ... or I could
contribute it as a starting point so you could "SteveBaker-ify" it.
As long as we could still accomplish the same basic things with it,
I'd be happy to use plib functionality for platform path independence.

I think this would definitely something that would fit well within the
scope of plib.

If you are interested I could send you some code.

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

Re: [Plib-devel] ssg sky

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

"Curtis L. Olson" wrote:

> If you like, I'd be happy to move
> FlightGear's path generalization code to plib ... or I could
> contribute it as a starting point so you could "SteveBaker-ify" it.
> As long as we could still accomplish the same basic things with it,
> I'd be happy to use plib functionality for platform path independence.
> 
> I think this would definitely something that would fit well within the
> scope of plib.
> 
> If you are interested I could send you some code.

Yes please.

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

Re: [Plib-devel] ssg sky

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

Steve Baker writes:
> > If you are interested I could send you some code.
>
> Yes please.

Ok, here's what I've got.  Feel free to hack it up however you like.
As long as I can reasonably accomplish the same sorts of things with
it, I'll commit to using it within flightgear.

Note, the only "FlightGear" dependency is that this uses the STL
"string" class so I pull in the fgfs "compiler.h" file which is our
attempt to hide a variety of platform differences.  If you made this
"char *" based, then you could eliminate that dependency.

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

[Plib-devel] gtl: the Generalized Time Lib

[Durk T. <d.t...@ch...>]

[I'm cross posting this to both plib-devel and fgfs-devel, since I believe it
might be relevant for both

Steve Baker wrote:

> Durk Talsma wrote:

[SNIP]

>

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

Ok, I've just finished the first stab at writing a generally usable time lib,
which I gave the working title of gtl (see subject). Today, I've implemented the
first class, named Time, which handles all non-local time., ie. greenwich mean
time, UTC, julian, and Greenwich Sidereal time. It turns out pretty similar to
what Steve proposed, and consists mainly of recycled FlightGear code:

>
> 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 exception being that I don't use local time yet. I will add this later on, in
a separate class. The idea behind this is that you can only have one intstance of
a localtime class, but multlple instances of localtime in a single program. For
instance, in a hypothetical multiplayer sessionFlightGear, player one in Amsterdam
uses a different localtime then player b). in Sydney.

The  layout I have in mind looks something like the following:

Time:  all non-local time functions: hides all the nasty details of working
             with low-level time functions in a cross-platform environment.
             Only one instance allowed per program.(1)

LocalTime: A generic class for calculating local time, from longitude and UTC.
       |-------> EarthTime:   A more sophisticated mechanism, which makes
                                                      use of the timezone
mechanism
                                                      currently in FlightGear.


Timezone:   A database containing a description of all past and current timezone
                        rules. Currently already available in a somewhat crude
form.

While shuffling stuff around today, I made an interesting discovery: In
flightgear, we currently use two functions to obtain sidereal time. A precise
method and a fast method. I already noticed before that the precise method
appeared much shorter than the cheap method, so I decided, that while I was
tearing stuff apart, It would be interesting to benchmark both functions and see
how they performed. Much to my surprise, the precise method is about 3 times
faster than the cheap one. (About 30 million iterations in 30 seconds for the
precise method vs. about 10 million interations in 30 seconds for the cheap method
both tested on an Athlon 5000 MHz, running a 2.2.14 linux kernel). Inspection of
the profiling report, however revealedthat although the cheap method was indeed
somewhat faster in itself, it calls mkgm, which turned out to be relatively slow
and  take all  of the advantage away.

Based on this, I intend to scrap the cheap sidereal time estimation altogether,
because it will also yield a much cleaner code base.

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

Well, euhh... I already introduced a dependancy on SimGear, since I use simgear's
contants.h file.  This is only a working solution, however. Haven't really made my
mind up about this. The same goed for the Astronomy lib. Getting that one right
and making it usable across a wide range of purposes is extremely complicated. For
example, having planets in the correct position is overkill in an arcade game and
considered extreme by some people when it comes to FlightSims (sorry Steve :-)
:-)), but needed for stuff like planetarium programs and essential for something
like a space simulator. when it comes to the latter, differences in requirements
are huge as well. Whereas a 0.5 arc minute accurarcy could be tolarable for a
simple planetarium, you'd need an accuracy of at least a few kilometers when it
comes to writings space sims. In the last category, You'd also need code to render
planets, calculate graviational interactions, etc, etc,

Regards,
Durk

(1). Footnote: While thinking of it this morning, I realized that in some extreme
situation, one could write an intergalactic space flight simulation, using
spaceships that approach the speed of light. in that case clocks would go out of
sync, and one would need multiple instances of Time. However, waking up too early
this morning, and having a slight hangover, my mind refused to go in that
direction. So until it will, there's only one instance of class Time allowed.