Celestia 1.7.0 Development Thread

Janus · Post #141by **Janus** » 24.01.2019, 22:37

@cartrite

If all else fails, there is a fallback that should be usable for testing, but I warn you, testing only.

You can try extracting the opengl32.dll from Mesa3D into celestia's directory.
This will give you a pure software render, so the performance will be a joke, and a bad one at that.
On the other hand, it bypasses the hardware so it makes a good system test.

Janus.

cartrite · Post #142by **cartrite** » 25.01.2019, 02:16

I need to figure this stuff out. I thought I found a bug because star points looked like large disks. But onetwothree asked if I would take openpl32sw.dll from qt5 and copy it to the celestia folder and change its name to opengl32.dll. I did and it worked. I want to find out why. What code started working because of a shared lib that wasn't linked or compiled to link. Wierd.

Post #143by **Lafuente_Astronomy** » 25.01.2019, 08:49

onetwothree wrote:Haha, shame on me! I have forgotten to put celestia.cfg into celestia-data. Please take it from a previous snapshot or your current installation.

Yup! It can fully open now! Thanks a lot, man!!!

Post #144by **onetwothree** » 25.01.2019, 09:45

cartrite wrote:Anyhow I used that file and renamed it as you suggested earlier and the star points looked normal in VMWare too. Did that tell you something? I only tested that on your build. My build has extra dll's. More than yours. What setting did you have to have that file included in your deps?

Works on my builds too. Was that file included in deps with cmake files?

It file is usually installed when you execute windeployqt to install qt libs into your project's folder.

So it actually looks like a bug with vmware opengl driver.

Added after 1 minute 1 second:

Janus wrote:You can try extracting the opengl32.dll from Mesa3D into celestia's directory.

opengl32sw.dll is a part of mesa as well, but qt 5.10 has quite old version 12.0rc2

Added after 1 minute 58 seconds:

cartrite wrote:What code started working because of a shared lib that wasn't linked or compiled to link. Wierd.

opengl32 is actually linked to celestia as it's an opengl application

Putting another file near your exe you just tell windows to you it instead of a system one (windows behaves like as you have LD_LIBRARY_PATH='.').

cartrite · Post #145by **cartrite** » 25.01.2019, 12:47

I knew opengl32 was linked and it was part of visual studio. But not opengl32sw. Then renaming it. :weirdface:

I couldn't simply download cspice and build plus link. Had to rebuild it because of link errors. Then I can get another file and rename it. I guess both files use same symbols.
VMWare and / or Virtualbox, only work on my system because of a blacklisted driver that I had to allow. So yeah, I agree, probably a driver issue. Maybe missing glextension? Maybe a bad platform for testing anything.

Janus · Post #146by **Janus** » 31.01.2019, 05:10

Just grabbed 5394 and compiled it.
I used my libraries so I could static link it, and it is up in my downloads.
The archive is celestia-5394.7z, it contains x86 & x64 versions both.
I will be matching my support libraries to the new list as soon as I can.
Getting nasm to work with VS so libjpeg-turbo can use simd is hard, but I should have it soon.

The combination of vcpkg & cmake makes and uses DLL linkage only so far.
M$ have indicated the ability to force static linkage, but it does not appear to be stable yet.
At least it has not worked in the VM I am testing with so far.

A couple of notes for anyone on windows using VS2015 compiling for Win7 using the 8.1 SDK, there may be some issues.
I neither know nor care about W10, it is not a real OS in my opinion, and I do not care if anything I compile runs in it.
If you are having problems in W10, good luck, my test OS is W7 SP1.

The two big issues I ran into are missing definitions in
/src/celestia/win32/winsplash.cpp
which lacks ULW_ALPHA for line 185.
I added the whole set to /src/celestia/win32/winsplash.h

Then in /src/celutil/bytes.h
where WIN32 should be _WIN32 at line 20.
Once that is changed it compiles no problem.

Both of these are because VS differs from the C/C++ standard &| practices, or has incompletely implemented some sections.

Janus.

Post #147by **Lafuente_Astronomy** » 31.01.2019, 12:41

Janus wrote:Just grabbed 5394 and compiled it.
I used my libraries so I could static link it, and it is up in my downloads.
The archive is celestia-5394.7z, it contains x86 & x64 versions both.
I will be matching my support libraries to the new list as soon as I can.
Getting nasm to work with VS so libjpeg-turbo can use simd is hard, but I should have it soon.

The combination of vcpkg & cmake makes and uses DLL linkage only so far.
M$ have indicated the ability to force static linkage, but it does not appear to be stable yet.
At least it has not worked in the VM I am testing with so far.

A couple of notes for anyone on windows using VS2015 compiling for Win7 using the 8.1 SDK, there may be some issues.
I neither know nor care about W10, it is not a real OS in my opinion, and I do not care if anything I compile runs in it.
If you are having problems in W10, good luck, my test OS is W7 SP1.

The two big issues I ran into are missing definitions in
/src/celestia/win32/winsplash.cpp
which lacks ULW_ALPHA for line 185.
I added the whole set to /src/celestia/win32/winsplash.h

Then in /src/celutil/bytes.h
where WIN32 should be _WIN32 at line 20.
Once that is changed it compiles no problem.

Both of these are because VS differs from the C/C++ standard &| practices, or has incompletely implemented some sections.

Janus.

Well, since there's only 2 application files in the download, do I have to put it in an existing Celestia folder or not? I already added some addons to my Celestia 1.7.0, and thus, my 1.7.0 is not fully vanilla anymore.

Post #148by **onetwothree** » 31.01.2019, 13:42

Lafuente_Astronomy wrote:Well, since there's only 2 application files in the download, do I have to put it in an existing Celestia folder or not? I already added some addons to my Celestia 1.7.0, and thus, my 1.7.0 is not fully vanilla anymore.

Yes you can put them into the folder with your 1.7.0

Post #149by **Lafuente_Astronomy** » 31.01.2019, 14:21

onetwothree wrote:Yes you can put them into the folder with your 1.7.0

That's great! Thanks a lot, man! Keep up the good work!

john71 · Post #150by **john71** » 31.01.2019, 14:32

Sorry for being little bit off topic, but in another thread it was more or less cleared, that the magnifying capability of Celestia is similar to the (future) James Webb Space Telescope.

Is it possible to implement some code changes to use different space telescopes as magnifying tools?

Like:

1.) Hubble (1/3 of current magnifying)

2.) James Webb (current values)

3.) Kilometer Space Telescope (maybe 150x current magnifying, for direct exoplanet observations)

4.) 100 Kilometer Space Telescope 2100 (15000x current magnifying, just for fun

).

It would be cool to have three "real" (plus one sci-fi) virtual telescopes inside of Celestia, because we would be able to simulate real life observations.

It does not seem to be a significant coding challenge. :think:

Post #151by **Lafuente_Astronomy** » 31.01.2019, 14:51

Man, that seems very interesting indeed. I do remember Selden having an addon in which you can add and take control of the Hale Telescope, and use it to magnify or focus on celestial objects. Guess if one can place the model of any of the telescopes you mentioned and give the commands and programming necessary, then it could be plausible. Hopefully it can also be used for space-based telescopes like the HST, JWST and many others.

john71 · Post #152by **john71** » 31.01.2019, 15:01

First it would be enough if the use of the "." and "," keys would activate a text on the screen, like "Hubble magnification capability" or "James Webb magnification capability" etc..

Maybe the key combinations of "SHIFT" + "." + "H" (or "J" or "K" or "1") would be sufficient ways to allow changing the virtual telescope.

Post #153by **Lafuente_Astronomy** » 06.02.2019, 10:51

Well, in addition to the ones you mentioned, how about some real life telescopes, 3 of them planned for the next decade as addons?

1: Extremely Large Telescope (ELT), Cerro Armazones Obs., Chile

2: Thirty Meter Telescope (TMT), Mauna Kea Obs., Hawaii

3: Giant Magellan Telescope (GMT), Las Campanas Obs., Chile;

4: Gran Telescopio Canarias (GTC), Roque de los Muchachos Observatory, La Palma, Garafía, Spain

And a canceled one for size:

5: Overwhelmingly Large Telescope

Sorry if it's a very late reply.

Post #154by **Lafuente_Astronomy** » 26.02.2019, 21:38

Just putting this topic back on Active Topics, just in case anyone of you may have some suggestions and questions regarding Celestia 1.7.0. Is that ok with you, onetwothree?

Post #155by **onetwothree** » 27.02.2019, 07:46

Be honest I have no idea where you have found telescopes in Celestia.

john71 · Post #156by **john71** » 27.02.2019, 08:04

OK.

Go to Earth.

Press ENTER. Write: Mars. Press ENTER and after that '"c".

Press the "," button (near the "M" button) for a few seconds, until Mars will fill your screen.

You will see a magnifying telescope focusing on Mars.

:biggrin:

Added after 5 minutes 22 seconds:
What we kindly ask is to change the scale of magnification in Celestia maybe a hundredfold. In that way you can simulate direct exoplanet observations.

It should be a simple task to change that in the code...maybe it is about changing a simple "magnification" number.

Janus · Post #157by **Janus** » 27.02.2019, 09:06

@john71

The setting is minimumfov, which is in celestiacore.cpp

/src/celestia/celestiacore.cpp line 76

static const float MinimumFOV = degToRad(0.001f);

Changing the value to 0.00001388 should give celestia the same angular sensitivity as the minimum image size the Hubble has.

In fact, just for fun I have attached commit 5421 VS2015 static linked celestia.
Two files are plain x86 & x64 as usual.
The other two are modified to use the above value as a minimum field of view {0.05 arc second} for testing.
You can zoom in to the point that Pluto takes up the whole screen when seen from earth.
If a real astronomer wants to duplicate hubble's actual view value by experimentation, I will put up a version to match its view.
Then anyone can look around seeing what hubble sees.

Janus.

john71 · Post #158by **john71** » 27.02.2019, 09:32

Janus, thanks very much, excellent! :clap:

Post #159by **Lafuente_Astronomy** » 27.02.2019, 23:52

Janus wrote:@john71

The setting is minimumfov, which is in celestiacore.cpp

/src/celestia/celestiacore.cpp line 76

static const float MinimumFOV = degToRad(0.001f);

Changing the value to 0.00001388 should give celestia the same angular sensitivity as the minimum image size the Hubble has.

In fact, just for fun I have attached commit 5421 VS2015 static linked celestia.
Two files are plain x86 & x64 as usual.
The other two are modified to use the above value as a minimum field of view {0.05 arc second} for testing.
You can zoom in to the point that Pluto takes up the whole screen when seen from earth.
If a real astronomer wants to duplicate hubble's actual view value by experimentation, I will put up a version to match its view.
Then anyone can look around seeing what hubble sees.

Well, I'm going to try this one out!

Janus · Post #160by **Janus** » 28.02.2019, 00:29

A word of warning to those who experiment with really high zoom factors.

Start at earth, hit enter, this opens a search subwindow.
Type 'Pluto' and hit enter, this shifts focus to pluto.
Next you type 'C', to center on the selection.
Then 'F' to follow it.
Now you can use ',' to zoom in as desired.

If you neglect to use 'F' then the target will move while the observation window will not.
The result, Pluto slowly drifts away.
You can either press 'C' a lot, or use 'F' to follow.

Janus.