New 64 bit 1.7 version suggestions and bugs

[John Van Vliet]

Saturnspice.ssc is indicated on the splash screen.

if you have not built 170 with the cspice and have not installed the spice kernels and not fallowed anything in the readme's
then turning on that ssc file and that extra folder on WILL KILL the program

please READ the instructions
( well mainly notes on things )

[Chuft-Captain]

Would someone please advise me of current location and status of 64bit build source files, and any specific build instructions/caveats.
The file provided by Janus above looks like it might be a 64bit executable, but I was unable to extract it, so I might have to have a go at building it instead.

Cheers
CC

[Janus]

@Chuft-Captain

If you want to try a 64 bit you can grab the directory below.

http://celestia.simulatorlabbs.com/Downloads/Celestia_VS2013/

It is a stand alone that requires only the VS2013 redists.
This contains 32 & 64 bit builds both of the following.

celestia-x86.exe; celestia-x64.exe : VS2013
celestia-x64-1Gy.exe; celestia-x86-1Gy.exe : VS2013 compiled with 1 gigalightyear mod requested in another thread.
celestia17-x64.exe; celestia17-x86.exe : VS2017(1.7) source modded and compiled with VS2013

The VS2013 branch is based on VS2013 because the other refused to build on it.
I have finally gotten the VS2017 branch to build with VS2013, and sent it to Alexell.
We will see what happens with that.

My builds have no sound support at all.
The fmod used does not work with my system, it crashes on launch.
There is discussion of changing sound over to openAL soft, but doing so is currently beyond my knowledge.

I hope this helps.


Janus

[john71]

Thanks! I'll try it right away!

[Chuft-Captain]

Thanks Janus,

For whom it may concern...

I've found a couple of bugs already.
1. The VS2013 1.6.1 version ( celestia-x64.exe ) crashes if I try to display the ABOUT screen.
2. The VS2013 1.7 version (celestia17-x64.exe) initially seemed to have some sort of problem with either LUA-execution or simulation clock being interfered with when I set the FOV, however after restarting I've been unable to replicate this one, so I'll report back if it re-occurs and I manage to get a handle on it.

However, the crash in the 1.6.1 version happens consistently.

Cheers
CC

Added after 3 minutes 49 seconds:
The other thing I noticed is that the 1.7 version does not have the new star rendering and orbit styles (trailing orbits) which I remember were added in to an experimental 1.7 build a few years ago:

Is this supposed to be the case?

[Janus]

@Chuft-Captain

All of the exe files should be 1.7.0 versioned.
I also found that the VS2017 branch code I tweaked to compile with VS2013 did not crash on the about screen, so I am going to ignore it.
The issue is a BEX64 fail, which has to do with far to many things to worry about given that the newer code does not do that.

If someone can point me to the fading orbit bit, I can add that and re upload if desired.

Alexell seems intent on VS2017 & QT 5.9, which I will not be able to use.
So my ability help on the master branch may be at an end.
VS2017 breaks my OS, a heavily tweaked W7 install made to look and work like 2K/XP.
And I cannot afford VS2015, so that is out until I can.

If that is so, I will continue working on my own branch using VS2013 as the compiler.
Using QT creator as well, and QT 5.4/5.6/5.8/5.9 in 32 and 64 bit as libraries allow.
Which I will continue to post as Source archives, and working directories.


Janus.

[Chuft-Captain]

Hi Janus,

Thanks for the exe's!
I'm a little confused by exactly what each one represents in terms of functionality...

All of the exe files should be 1.7.0 versioned.

If that's the case, what's the difference between celestia-x64.exe and celestia17-x64.exe ?
I had assumed that the first was simply 1.6.1 trunk tweaked and compiled for 64bit (however I couldn't confirm this via the About page because of the crash), and that the second was the 1.7 branch, again built for 64bit target.

I'm not sure where to find the fading orbit code .. In any case, IMO it's the enhanced rendering of the stars (as evident in the above screenshot) which is more worthwhile. There were a couple of experimental builds featuring one or both features back in the day. I can't remember who exactly was responsible, but Chris Laurel, Dirkpitt, or Fridger would be the most likely suspects.

CC

Added after 13 minutes 38 seconds:
PS.

FYI. At some point, I've named the executable I'm using "celestia-v1.7x-svn5213-newstar-neworbit.exe" so you may be able to work backwards from svn5213 to identify code (but don't take that as gospel, as I suspect the naming is mine, though probably accurate.)
Not sure what branching strategy if any was used at the time by whoever did the coding, or whether it was even publicly submitted to the repository. (May have just been a private build.)

Added after 1 hour 21 minutes:
Some screenshots of what I see with Star_style = "points", in each of 3 versions...

1. celestia-v1.7x-svn5213-newstar-neworbit.exe

2. celestia17-x64.exe

after changing [EDIT: to "scaled_discs"], then returning to "points" mode:

3. celestia-x64.exe

after changing [EDIT: to "scaled_discs"], then returning to "points" mode:

[selden]

CC,

What graphics hardware does your computer have?

My personal experience has been that square stars are seen on Windows systems which use Intel graphics hardware, but not on Windows systems which use Nvidia graphics hardware or (under Linux) Mesa OpenGL software. I don't have access to systems with AMD/ATI graphics hardware, so I dunno what happens on them. In other words, one could argue that Intel's OpenGL implementation has a bug in it. I dunno if there might be a workaround that could be implemented in Celestia.

[Janus]

@Chuft-Captain

From my work on old code brought up to VS2013 from the past:

celestia-x64.exe
celestia-x86.exe

My work with a gigayear star visibility.

celestia-x64-1Gy.exe
celestia-x86-1Gy.exe

From the VS2017 code that I finally managed to get working with VS2013 using my sln/vcxproj/pro setups.

celestia17-x64.exe
celestia17-x86.exe

As for the fading orbit thing, please update the local celestia.cfg file from the site.
I was still using the old one, the new one is from the current source.
I believe all of the versions of Celestia in the directory have fading orbits in the config file capability.

As for the square stars, you should look at:

viewtopic.php?f=15&t=17487

Where someone else had much the same problem.
I hope this helps.

Is anyone here looking at compiling Celestia for themselves?


Janus.

[CM1215]

I believe all of the versions of Celestia in the directory have fading orbits in the config file capability.

I looked through the config file for my Celestia installation and was unable to find a string relating to the fading orbits. If it is there, what would it be called, for I may be simply overlooking it.

[Janus]

@CM1215

As for the fading orbit thing, please update the local celestia.cfg file from the site.
I was still using the old one, the new one is from the current source.
I believe all of the versions of Celestia in the directory have fading orbits in the config file capability.

The fading orbits stuff is missing from the older config files.
Which is why I said to update with the one from the VS_2013 directory.
It contains the fading orbits stuff, which the older ones do not.

#------------------------------------------------------------------------
# The following lines are render detail settings. Assigning higher
# values will produce better quality images, but may cause some older
# systems to run slower.
#
# OrbitPathSamplePoints defines how many sample points to use when
# rendering orbit paths. The default value is 100.
#
# RingSystemSections defines the number of segments in which ring
# systems are rendered. The default value is 100.
#
# ShadowTextureSize defines the size* of shadow texture to be used.
# The default value is 256. Maximum useful value is 2048.
#
# EclipseTextureSize defines the size* of eclipse texture to be used.
# The default value is 128. Maximum useful value is 1024.
#
# * The ShadowTextureSize and EclipseTextureSize values should both be
# powers of two (128, 256, 512, etc.). Using larger values will
# reduce the jagged edges of eclipse shadows and shadows on planet
# rings, but it will decrease the amount of memory available for
# planet textures.
#------------------------------------------------------------------------
OrbitPathSamplePoints 100
RingSystemSections 100

ShadowTextureSize 256
EclipseTextureSize 128


#------------------------------------------------------------------------
# Orbit rendering parameters
#------------------------------------------------------------------------
# OrbitWindowEnd ->
# End of the orbit window relative to the current simulation time.
# Units are orbital periods. The default value is 0.5.
# The range of values 0.0 - 1.0.
#
# OrbitPeriodsShown ->
# Number of orbit periods shown.
# The default value is 1.0.
#
# LinearFadeFraction ->
# Fraction of the window over which the orbit fades from opaque
# to transparent. Fading is disabled when this value is zero.
# The default value is 0.0. The range of values 0.0 - 1.0.
#------------------------------------------------------------------------
OrbitWindowEnd 0.0
# OrbitPeriodsShown 1.0
LinearFadeFraction 0.2

So you can see where it goes if you just want to update what you have instead of replacing it.


Janus.

[Chuft-Captain]

Selden,

Thanks for your response, however I must apologise for wasting your time.
Yes you are correct regarding the Intel Graphics (mine's HD4000). This issue has been around for years now, and I was aware of that, which is why I use "fuzzy points" as my default star setting.
I wasn't putting those pictures up in order to get a solution to that issue, but merely to provide some sort of comparison of the rendering with that seen in the "newstars" code (first image) ... as at least in a couple of those alternate images, some stars are correctly rendered as points rather than squares.

Interestingly however, the first image does seem to suggest that there may be eventually a solution for the Intel issue.
It proves that whatever technique was used for the "newstars" rendering, it seems to have improved the situation wrt. the square artifacts. I still see those artifacts under some limited circumstances (eg. at ~1-lightyear distance) in the newstars executable, however it's very much improved.
Unfortunately, that executable also has a number of other issues/bugs which were never resolved at the time it was published about 5 years or more ago. (It was an experimental build after all).

Janus,

Thanks, but I'm still confused by your description of code versions. Maybe because I've been away from the forum for a long time I have not been following your activities in this respect, so exactly what you mean by "old code" and "VS2017 code" is a mystery to me.
It may be helpful if you advise a repository version/tag (eg. svn5213, 1.6.1, etc ... I don't know what system github uses for version control) rather than terms like "old code" and "VS2017 code" (especially as "VS2017" refers to a compiler version, rather than a code version).
I don't particularly care to know which compiler version was used to build an EXE, all I care to know is it's functionality.
Failing repository tags, a brief description of included and/or additional functionality in each EXE relative to the 1.6.1 baseline would help me to understand the difference (in terms of functionality) between the 2 builds.

Others who have been following what you are doing, may be aware of what's included in "old code" or "VS2017 code", but I'm not.

Regards
CC

[Janus]

@Chuft-Captain

The "old code" is essentially the 1.6 code from svn.
The "New code" is an updated branch someone did that updated Eigen and made a VS2017 sln out of.

I tried to use the VS2017 code initially, and failed.
It crashed VS2010 compiler, froze VS2012, and simply failed to compile on VS2013.

I then took the "old code", and brought the sln/vcxproj up to VS2010.
I then got it to compile in VS2012.
And finally VS2013.
At that point simply changing the toolset was enough to be able to compile with all three VS versions I had available.

Next I brought the "Old code" QT version up to QT5.
Fought QT5.1/5.2 and eventually gave up on them.
Got QT5.4 w/VS2013 as compiler/linker working.
Then added QT5.6/5.8 as well, all compiling and working in 32-bit.

After that, I began working on making a 64-bit port.
That was fun, NOT!!!
VS2010, no 64-bit that works.
VS2012, no 64-bit that works.
VS2013, initially no, then discovered MBCS missing.
Fixed that, then finally I was able to make a 64-bit version using VS2013.
Not really stable, but mostly worked.

VS2013 branch created. (Old code updated.)
VS2017 branch created (New code.)

Made VS projects out of support libs to make 32 & 64 bit libs.
Recompiled all support libs with VS2013.
Support lib projects still need some work.

Figured out how to modify QT project file to create 64-bit EXEs.

Was eventually able to get "New code/VS2017 branch" working with VS2013.
I did that by using my "old code/VS2013" sln/vcxproj, on the "new code"
Tweaked sln/vcxproj and new code both.
Able to compile with VS2013 in x86 & x64 both. (Fully static linked VS2013 redists only)
Able to compile with QT5.4/5.6/5.8/5.9, with most of those x86 & x64 both, though the newer ones are 64-bit only.
(QT versions require matching support DLLs which is a bit of a pain.)

Learned a lot doing all this.

Not sure what Alexell is going to do now.
He seems intent on using VS2017 w/QT5.9 from here on out.
I can not run VS2017, so my help may be at an end.

I hope this answers your questions.


Janus.

[Chuft-Captain]

Janus,

Thanks for the detailed history.
From what you say, it sounds like the celestia-x64.exe ("old code") does not include all 1.6.1 era code.

Do you know if the "VS2017" ("new code") ... ie. celestia17-x64.exe ... was also branched from 1.6.0 era code?
If so, then it may also be missing some 1.6.1 features/fixes.

Can you confirm that the celestia17-x64.exe includes at least all 1.6.1 functionality?
As 1.6.1 was the last stable official release, IMO it should be the minimum starting point (at least for any future 64bit builds).

I would much prefer to use a 64bit executable rather than a 32bit version, but not at the cost of losing significant 1.6.1 era functionality, or introducing serious new issues.

Great efforts by you, in any case.
Much appreciated.
CC

[Janus]

@Chuft-Captain

No problem on the history.
Large projects like this are complex, and complex problems require precision.

To the best of my knowledge the "old code" comes from the end of the SVN.
There should be nothing missing from it, but I have no proof one way or the other.
The changes I did to it for QT5 and other things were essentially the same as what I did for my personal version.
The one I use for recording things like my solar system tour DVD to be precise. (Still hoping for feedback on that, but so far, crickets.)

I did thing like move text from the edge of the screen to make it projector friendly.
Move the OBS distance to the lower right.
Add Ra/Dec/Dist to star info, and am working on adding it to planets/ minor planets/ asteroids/ comets/ moons etc based on display date.
Working on movie recording making MKV files with lossless frames via adding logarith or something like it.
This gets around the avi 2/4gb issue of indexing, and ties in with other projects down the road.

The exact parentage of the VS2017 code is unknown to me.
What I do know is that it has updated Eigen, which is beyond my knowledge level to do by the way.
Added sound support, which I had to disable since fmod dislikes my system, and I do not know how to add OpenAL myself, but I prefer a silent program.
Requires VS2017 to compile, without replacing the sln/vcxproj files and some tweaks.
There is also a bunch of stuff about SSE2 instructions in the sln/vcxproj files, but that may be normal for VS2017.
An unknown number of other changes as well.

You would need to ask Alexell to find out exactly where it came from.

At this point the github source archive is just the VS2017 code, setup for VS2017.
So it appears possible at this point that I will be taking my efforts back to my own blog & forum.
I hope my contributions help get things going for him.
I was able to compile 64-bit code from old & new code both, along with QT5 in 32 & 64 bit both as well.
So everything needed is present and working at this time.
He desires to use a single VS & QT version, dropping VS only support, no problem, have fun.

I will continue to work on VS stand alone, and QT as well.
I am hoping to have VS2015 soon <in the next year>, and will do everything I can to make the code portable between them.
I will also continue working with QT5.4/5.6/5.8, and maybe more.

And thank you for the thanks.
It has been a lot of work, and a learning experience.
I normally just dive into something like this for a customer, find the discontinuity, make it work, often by brute force, then hand them a work around that they can then work it or the idea back into their production work according their in house procedures.
You would not believe how many pieces of 'black box' code, even ones that are self contained OOP, respond to external stuff.
Binary blobs are evil, foul tempered, and prone to fits, avoid if it all possible.


Janus.

[Chuft-Captain]

Janus,

What I do know is that the original sourceforge repository AFAIK followed good CC conventions (had TAG's for main releases, branches, etc.)
From what I understand it's been moved onto github now. I don't know if versioning TAG's were preserved in the switch (in fact I haven't even looked at it in the last couple of years ... however if everything was preserved, then it should be relatively easy to investigate the repository to find out what's what.
That may not be the case however. I've been out of it for a couple of years, so I'm not sure who's doing what, and how they're going about it in terms of future dev.

CC

[Janus]

Chuft-Captain,

I do not know how to check the tags you are referring to.
However, looking over the VS2017 code, it does not feel incomplete compared to the end of the SVN.
I know that is not a scientific comparison.
However, other than changes for Eigen and some other minor stuff, the code has the same basic look and feel.

If you find functionality that is missing, I can add it back in, at least I believe I can anyway.

In the mean time, I am going to go back to work on my own fork.
Adding such things as looking stars etc up by Ra/Dec/Dist.
I use that to illustrate 3D to students.
Watching them as an arc of stars matching a single degree are highlighted in turn is fun.
I made a script that marks all stars from 0-359 degrees, (all Decs/Dists) one degree at a time for visualization.
Then it does the same starting at 0 for Dec (All Ra/Dists), doing 1/-1, and so forth to 180.
And finally it selects a group of stars based on being within a degree of some setting, and marks them.
Then it turns sideways, and backs away to show how the stars are arranged in 3d space.

To me, this is the sort of thing Celestia is great at.


Janus.

P.S. Your O'Neill colony link in your signature is broken.
As is the lagrange points, which should point here now. https://celestia.space/forum/viewtopic.php?f=23&t=17129

[Chuft-Captain]

Janus,
Thanks for letting me know about the signature.
Unfortunately, I have not been able to fix that ever since the forum became more restrictive about links in signatures.
I get an error: "You cannot use certain BBCodes: [url]" now whenever I try to edit the sig.

My sig is a hangover from the shatters.net days, when links in sigs were allowed. Maybe Alexell just hasn't got around to making this available yet (it's probably just a phpBB setting) but maybe he will think about re-enabling that feature.

[Janus]

Chuft-Captain,

I just checked my inactive forum while I was preparing to get it going again if need be.
I ran it some years ago, but got fifty or more spam sign ups a day even through the captchas, with not a single real sign up in several months, so I stopped.
If I go my own way, I am planning posting my stuff on it, and taking sign ups that contact me directly, if there are any.

In admin control panel.
General:Board Configuration:Signature settings:General settings:Allow use of links in user signatures

Though it should have been updated when the DB was swept to update the links in it.
Unless you were restored later and a sanity check was not done.
I would suggest a PM to Alexell.

The O'Neill link is no longer active at all.
You should also be able to keep the lagrange title, then follow it with an open link, outside of a bbcode.

LAGRANGE POINTS: viewtopic.php?f=23&t=17129


Janus.

[Alexell]

Chuft-Captain, If you remember, in the old SVN repository, even after Celestia 1.6.1 release, code changes were still made, in particular the fade orbits you wrote about above. The last commit was number 5229.

As Chris Lawrale pointed out, I moved the SVN repository (commit 5229) to GitHub with the entire history of the commits and continue working on the code changes.

Celestia code on GitHub did not lose anything from Celestia 1.6.1, because the problems with language files were fixed later, there are simply no other differences for the worse.

Further, the Celestia code has been changed and described in this topic. The topic is updated as the code is updated in the repository. The biggest achievement is the Eigen engine update and the Celestia code adaptation for it. Thanks for dbrant.

Now we are working on adapting QT, since it is the QT framework that will be the basis of the Celestia interface. Celestial Browser will soon be finalized, localization of the new interface is realized. But this will not be done as quickly as we would like, because we do not have enough programmers.

But in December 2017 you will see Celestia 1.7.0 beta release together with a new website and new forum design.