A Forking Commit Thread.

[Janus]

Hello folks, whom ever you are.
After littering all over other threads, I figured it was time to make a fresh one.

So here is where I will be putting up archives of my tweaks, functions, toys.
I will also be posting code so those who are simply curious, or wish to compile their own, can explore or experiment to their heart's content.

When I have a newer, better, or more complete version of something, I will be pulling the previous archives.
This is to conserve disc space on the hosting service.
I will also be making a forking directory in my downloads.
Full ready to compile snapshots will be uploaded to my downloads on occasion.

I start with Commit 5441, modded with RaDecDist.
RaDecDist displays the realtime, based on the simulation clock, position of any selected object except earth.

RaDecDist consists of two parts.
The first is in /src/celengine/univcoord.h:142 just after distancefromkm.

Code: Select all

   // 190404 Janus : get Distance in micro light years.
   double distanceFromUly(const UniversalCoord& uc)
      {
      return offsetFromUly(uc).norm();
      }


This adds a function to get absolute distance something is from earth in micro light years{Uly}, to the univcoord object{Class}

The second replaces some messy code in /src/celestia/celestiacore.cpp:3694 in celestiacore::renderoverlay, before the text handler.
If you reach the line that reads "// Text input", you have gone to far.
The code I replaced filters based on the observer being beside earth, mine does not.

Code: Select all

      // 190331 Janus : Display Ra Dec & now Dist at the bottom of everything not earth.
      // To be added is a filter for view details.

      Selection Sol_Object = u->find("Sol");
      Selection EarthObject = u->find("Earth", &Sol_Object, 1);
      Body* earth = EarthObject.body();
      if (sel.body() != EarthObject.body())
         {
         UniversalCoord SelPos = sel.getPosition(sim->getTime());
         Vector3d v = sel.getPosition(sim->getTime()).offsetFromUly(Selection(earth).getPosition(sim->getTime()));
         v = XRotation(astro::J2000Obliquity) * v;
         displayRADec(*overlay, v);
         double dist = SelPos.offsetFromUly(EarthObject.getPosition(sim->getTime())).norm();
         *overlay << "Dist:: " << DistanceLyToStr(dist / 1000000) << "\n";
         }


This displays the simulation clock based position RaDecDist coordinates of any selected object.

Some may wonder why I added a Uly based function when there is already a KM based one.
I did so because I like to use natural units when I work.
Only translating them to something more familiar when displayed.
Light seconds, AU, Uly, LY, Light minutes, make far more sense to me when looking around in space.

I will be posting other tweaks, mods, toys as I get time.
Always like this one, so people can try them out to what they like.
Combination will also be posted, mostly on request.


Janus.

EDIT: Superseded by post#6 with updated archive.

[Lafuente_Astronomy]

Hello Janus! Thank your for your developments as always. As it is always said, an object will always get improved no matter how good it was. Celestia is a ball that needs fixing even if it's not broken, because of certain problems that lie in its code or other codes that could use an improvement.

As such, your efforts to make Celestia better even with something like simple code changes will really benefit Celestia in the long run. I'll be willing to find out any problem that may still persists, so that you can track it down and make newer, better and more improved forks in the future. So, please allow me to help

[vpontin]

I still have issues with sun while rotating using this build

[Janus]

@vpontin

Is there an addon for planet 9?
I have no such entry so I am unable to replicate what you are seeing.
My testing is done with the base data.

You will also need to specify the display details you are using.
Star Style, Star Color, Ambient Light, Texture resolution, Anti aliasing.
Body,/Orbit/Label for planets & minor planets.

A download link to the addon would also help.


Janus.

[Lafuente_Astronomy]

A download link to the addon would also help.

I think he downloaded Planet Nine as part of Celestia Origin's addons

[Janus]

I will locate it from within Celestia Origin to look at.
Though to me it will be Planet X, or planet 10, I see Pluto as a planet, and I always will.

In the meantime I have another tweaked archive for people to amuse themselves with.
This one is commit 5445 based.
RaDecDist is included. {See earlier post for file mods.}


As is 20Gly star limit. {100Gly causes texture issues, probably from somewhere in octree.}
/src/celengine/stardb.cpp:48

Code: Select all

// Janus 190324 Adjust max star distance
constexpr const float STAR_OCTREE_ROOT_SIZE   = 20000000000.0f;


Hubble View is included as well, meaning you can zoom to pluto from earth, which can be amusing if you turn off follow.
/src/celestia/celestiacore.cpp:76

Code: Select all

// Janus 190306 fun mod for hubble view.
//static const float MinimumFOV = degToRad(0.001f);
static const float MinimumFOV = degToRad(0.00001388f);


I have also included Sync, which forces frame capture during recording to realtime.
Celestia normally advances simulation time by frame time during recording.
Doing this however, forces scripts out of sync since their clock and the simulation clock are unrelated.
This tweak is more complicated as it requires altering several files.

/src/celestia/avicapture.h:27 & 54

Code: Select all

// Janus 190320 added double for timing control
//  bool captureFrame( );
    bool captureFrame(double );


Followed by this at the end under private.

Code: Select all

// Janus 190320 frame sync signals
double frameTime { 1/frameRate};
double frameNext { 0 };


/src/celestia/avicapture.cpp:139, 144, 179

Code: Select all

// Janus 190320 Added Double for timing control.
// bool AVICapture::captureFrame()
bool AVICapture::captureFrame(double rightnow)

    if (!capturing) return false;

// Janus 193020 If not time for next frame, return
if (rightnow < frameNext) return false;


Followed at the of captureframe by

Code: Select all

// Janus 190320 Next Frame to record sync signal
frameNext = rightnow + frameTime;


/src/celestia/moviecapture.h:26

Code: Select all

// Janus 1903   Added double f time for frame sync.
// virtual bool captureFrame(double) = 0;
    virtual bool captureFrame(double) = 0;


/src/celestia/selestiacore.cpp:2135, 2394

Code: Select all

// Janus 190319 disable old frame time sync logic.
// tick skip for frame sync to be enabled instead.

//    if (movieCapture != nullptr && recording)
//    {
//        dt = 1.0 / movieCapture->getFrameRate();
//    }
//    else
//    {
        dt = sysTime - lastTime;
//    }


And finally

Code: Select all

// Janus 1903  Add systime for frame sync
    if (movieCapture != nullptr && recording)
        movieCapture->captureFrame(sysTime);


Right now this forces all recordings to be realtime only, which is both good and bad.
The Sync tweak will be improved or replaced once I have locked the script clock to the simulation clock.
Until then, this hatchet job, as horrific as it is, will just have to do.

I hope these amuse or are found useful.
Tested with vanilla data only, I do not currently have either Celestia Origin or Educational tools in any of my copies.


Janus.

EDIT: Superseded by new archive @ post#13

[Lafuente_Astronomy]

As is 20Gly star limit. {100Gly causes texture issues, probably from somewhere in octree.}

Well, perhaps there's a way to find out whatever problem lies within octree. Because in My Celestia, there are no problems associated with the 100 GLY distance. It's more or less a model problem in which the stars blink from time to time.

Also, I think another adjustment of the Search names must be checked on because apparently, any word that starts with the first few letters that comprise a letter in the Greek Alphabet turns into the Greek Symbol. I clicked Muphrid in Bootes, and this is what came out:

Since the first 2 letters of the word "Muphrid" forms the spelling of the Greek letter "Mu", it automatically transforms into the Greek Letter. So perhaps there's some additional fixing that can be done, aside from the texture issues.

[Janus]

@Lafuente_Astronomy

When the greek letter replacement code was written, spaces for separation were not included.
I lack the patience/interest to try to fix it myself.
If it were me however, I wouldn't try to do the replacement until a space was input, then include a space after it.
The way it written now, it substitutes substrings within words, which is extremely annoying.

Let me know how the rest of the stuff works when you get time.


Janus.

[Lafuente_Astronomy]

Alright then

[vpontin]

The exact SSC i'm using:

Code: Select all

"Planet Nine" "Sol"
{
   Class   "planet"
   Texture   "exo-class4.*"
   NightTexture   "exo-class4night.*"
   Radius   20000
   Oblateness   0.017
    Atmosphere
    {
        Height 130
        Lower [ 0.6 0.65 1.0 ]
        Upper [ 0.5 0.55 0.9 ]
        Sky [ 0.5 0.7 0.9 ]
    }
   EllipticalOrbit
   {
      Epoch   2457745.5  # 2016 Dec 23
      Period   11180.34
      SemiMajorAxis   500.0
      Eccentricity   0.25
      Inclination   20.0
      AscendingNode   90.0
      ArgOfPericenter   140.0
      MeanAnomaly   104.0
   }
   UniformRotation
   {
      Period   16
      Inclination   28
   }
   LunarLambert   0.5
   Albedo   0.4
   InfoURL   "https://en.wikipedia.org/wiki/Planet_Nine"
}



The textures are the standard ones for extrasolar neptunes shipped with Celestia

[Kochav Israel]

So I made using Python random.uniform function a bunch of coordinates within a span of few hundred light years.

The star on which it is centered is called Israel, and it is 370370370 light years away in the 1 GY build. I made 1000 red subgiants and 6000 yellow subgiants (radius 10'000'000 km).

And apparently Celestia arranges stars in some planes along the ecliptic meridian from 0 to 180, and even some meridian lines.

Is this because stars are still based on the parallax measures?

If yes, can I use the position [ x y z] thing to determine the position of the star instead of RA and dec? Position seems to show only for custom orbits of planets, but nobody says anything about it being for a star.

[onetwothree]

The problem is that Celestia uses 32bit float number type to work with coordinates so it has a very limited precision.

Yes, you can use xyz, see https://en.wikibooks.org/wiki/Celestia/Binary_Star_File, but it's still 32bit float.

[onetwothree]

Janus' changes for FPS during a video capture may not work in environments which force vsync.

[Gurren Lagann]

If you know Minecraft's Far Lands, Celestia is basically doing the same thing here.

[Janus]

It should not make a difference since the call is based on system clock timing.
What it does is select the closest frame display to the correct time slice.
As long as you maintain >2x capture rate calls, the actual display should make no difference.
I could also be wrong, but according the specs I have seen, I should not be.

Do not forget, it is an ugly kludge, done by brute force over sampling.
It also uses the current OS level video buffer to be displayed, which can never be more than one frame off.
Forced vsync is a display tweak intended to prevent tearing, and is a hardware/software combination that signals the displayware to change now.
If there is not a next frame ready, it does not change frames, instead redisplaying the previous one instead.


Janus.

[Janus]

@Kochav Israel

The problem here is the resolution of the processes used to import the data.
In this case, the floating point format used is called single precision.
The easiest way to explain is to give some basic information on them, and what information means.

SP: Single precision: 32-bit floating point:Sign[1];Exponent[ 8];Fraction[23]
DP: Double precision: 64-bit floating point:Sign[1];Exponent[11];Fraction[52]
XP: extended precision:80-bit floating point:Sign[1];Exponent[15];Fraction[64]
QP: quad precision: 128-bit floating point:Sign[1];Exponent[15];Fraction[112]

The way floating point works is the sign whether the complete number is + or -, regardless of its subcomponents.
The exponent is how many places the first bit of the answer is shifted from the zero bit{1}, this portion works backwards of what you would expect since negative values shift to the right, while positive shifts to the left.
The fraction is the collection of bits that follow the exponents implicit bit.

Next you go back to chemistry and physics to review digits of significance.
That rule states that the result of a calculation can be no more accurate than the inputs.

To compute maximum digits of input accuracy, the rule of thumb is 3.3 bits per base 10 digit.
When checking, be sure to include the implicit first "ON" bit from the exponent, which I will get to in a moment.
SP:(23+1)/3.3 = ~7; This mean SP has no more than 7 digits accuracy you can depend on.
DP:(52+1)/3.3 = ~16; This mean SP has no more than 16 digits accuracy you can depend on.
XP:(64+1)/3.3 = ~19; This mean SP has no more than 19 digits accuracy you can depend on.
QP:(112+1)/3.3 = ~34; This mean SP has no more than 34 digits accuracy you can depend on.

Since Celestia uses SP in the conversion routines, this limits the accuracy of addon stars.
The natural unit in Celestia is the Uly, or microlightyear.
While this allows great precision in our solar system, accuracy becomes 1Ly at 10MLy, which is where the limit normally is.

In your case, the maximum resolution you can achieve at that distance is ~37LY.
Changes to the import code to use DP will need to be made to do that however.
Once done, accuracy at 100Gly would be in the light month range.
In the light week range at the edge of the observable universe.

I had not anticipated anticipated your usage or I would have warned in advance.
What I thought was happening was someone was making an addon for all the 1Bly+ galaxies Hubble has been collecting.

Further research and reference material avaialble @wikipedia if you wish.


Janus.

[Janus]

@Kochav Israel

A question for you.
I have over time tinkered with converting position data within Celestia to double.
One of my many side projects has been doing this with recent code.
If I can do even a brute force version, would you mind testing it with your auto generated data to see how it looks?
What I would do is use the SP database, but make the in memory stored data, and derived data from text files, into doubles {DP} instead.
This would take the positional accuracy from 7 digits, to 16, or about a billion times more accurate.
I am curious what effect this would have.

Doing this though, will be a lot of work.
Float is the default not only in memory, but for the opengl as well.
gl_float would have to exchanged for gl_double, in addition to other changes in the main program.


Janus.

[onetwothree]

Float is the default not only in memory, but for the opengl as well.
gl_float would have to exchanged for gl_double, in addition to other changes in the main program.

Don't do that. Current video cards are very slow with double precision floats, the other day I read that Nvidia 1060 is 31(!!!) times slower with doubles comparing to floats.

[pirogronian]

Currently I try introduce double precision to stars position. I'll let You know when finally get successful compilation...

[onetwothree]

Not worth efforts. I'd think about adding additional coordinate for stars - its galaxy and change star coordinates from absolute to relative. For our Galaxy star coordinates will stay the same but for other they will be calculated as galaxy_center_coordinates + relative_star_coordinates.