New 64 bit 1.7 version suggestions and bugs

Description: The place to discuss creating, porting and modifying Celestia's source code.

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#1by john71 » 16.07.2017, 05:40

As you know Alexell has released a new 64 bit version of Celestia.

https://apps.alexell.ru/celestia/bin/x64/

https://apps.alexell.ru/celestia/new-dll/

(new exe + new 64 bit dll file, you need both to run the new version from the old Celestia directory)

It is fantastic and we should thank Alexell for it!

:clap: :clap: :clap: :clap: :clap:

I think we should test it and share our experiences!

Added after 11 minutes 34 seconds:
First suggestion: in the 32 bit 1.6 Celestia version constellation diagrams (asterisms) can be seen from other exoplanets of the Milky Way,

In the 64 bit 1.7 version diagrams fade after a few light years.

I'm (and I think others too are) using diagrams to show stellar routes and alien constellations.

Please make it possible to have an option to switch on a "non-fading" diagram function.

It would make diagrams visible again from very far away (a hundred million light years would be nice, considering intergalactic routes too).

Added after 8 hours 6 minutes:
Issue number 2: some cmod models are bright red when the lightsource (star) is changing. They change back and forth as the planet rotates and the light is changing.

Goofy
Avatar
Goofy
Posts: 165
With us: 6 years 2 months
Location: Italy

#2by Goofy » 16.07.2017, 15:27

Hi.
Checking the 64 bit 1.7.1 version, I found that the keyboard commands "Points" (P) and "Fuzzy points" (f) do not work.
Can someone else check it, please?
Thanks.
Goofy :smile:
"Something is always better than nothing!"
ASUS G75VX4007H- Intel i7 3630QM, 2.4 GHz-SSD 250GB+SSD 1TB, SATA 3-32GB DDR3 1600 MHz- Nvidia GeForce GTX 780MX 3 GB

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#3by john71 » 16.07.2017, 15:48

The CTRL+S command works for me... :think:

Goofy
Avatar
Goofy
Posts: 165
With us: 6 years 2 months
Location: Italy

#4by Goofy » 16.07.2017, 16:11

You are right, John71, my fault, I was using keyboard commands as shown in the "render" window, and not the cycling "CTRL+s" as given in the Celestia controls instructions.
My apologies, but it's a lot of time I'm not checking Celestia... but anyway the "Render" information are uncorrect, right? :eh:
Bye.
Goofy :smile:
"Something is always better than nothing!"
ASUS G75VX4007H- Intel i7 3630QM, 2.4 GHz-SSD 250GB+SSD 1TB, SATA 3-32GB DDR3 1600 MHz- Nvidia GeForce GTX 780MX 3 GB

FarGetaNik M
Moderator
Avatar
FarGetaNik M
Moderator
Posts: 373
With us: 5 years 5 months
Location: Germany

#5by FarGetaNik » 16.07.2017, 18:39

I guess I propose one feature at a time.
Not really a bug, but desperately needed: Anti-aliasing. It works for orbits, so it shouldn't be that hard to make it work for everything else as well. Most noticeably edges (or horizons) of planets display step-artifacts, as well as detailed 3D models when viewed from a larger distance.

Added after 3 minutes 45 seconds:
john71 wrote:Issue number 2: some cmod models are bright red when the lightsource (star) is changing. They change back and forth as the planet rotates and the light is changing.

I experienced this issue with this addon. So it wasn't fixed yet. It seemed really random to me and I have no idea what's the problem.

Added after 2 hours 2 minutes:
Also I found that this version of Celestia lacks the fading orbis feature that was working in previous builds.

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#6by john71 » 16.07.2017, 21:09

I found it on an old thread:

"Objects turning red means that the OpenGL driver can't compile the texture shader code associated with them. (To see the details of the error message, enable Celestia's Shaders log.) Usually this happens when more vertex shaders are invoked simultaneously than the OpenGL standard allows. At one time Chris mentioned that he'd like to rewrite Celestia's shadow code to eliminate that limitation, but that hasn't happened. You may be able to work around the problem by turning off some of the shadows. E.g. disable one or more of Cloud Shadows, Ring Shadows or Eclipse Shadows, or redesign the planetary system so they don't happen."

It seems to be an OpenGL 2.0 problem.

So it would be nice if OpenGL 1.0 could be activated...I suppose Celestia 1.6 used OpenGL 1.0.

Added after 7 minutes 35 seconds:
It is definitely an Eclipse Shadow and a Cloud Shadow problem. But it is absent in Celestia 32 bit 1.6. But why?

selden
Avatar
selden
Posts: 10117
With us: 15 years 2 months
Location: NY, USA

#7by selden » 17.07.2017, 10:11

I don't know what you mean by
So it would be nice if OpenGL 1.0 could be activated...I suppose Celestia 1.6 used OpenGL 1.0.
.

Celestia's use of OpenGL 2.0 can be disabled by typing Ctrl-V an appropriate number of times. That dis/enables features which depend on specific versions of OpenGL. Render Path: Basic is one which uses only OpenGL 1.0 features.
Selden

John Van Vliet
Avatar
John Van Vliet
Posts: 2660
With us: 15 years 2 months

#8by John Van Vliet » 17.07.2017, 16:16

right now my test builds use qmake ( celestia.pro) to build using qt 5.6

the autltools and macros still need work ( remaking the AC files and IN files

still uses lua 5.1
and uses png 16.8

the only REAL annoying bug is celestia crashes if you delete the last bookmark
i think this is do to a missing bracket ? but i really have not looked

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#9by john71 » 17.07.2017, 19:15

Selden: yes, typing CTRL+V was what I meant, you got it right. I just forgot this function...it would be nice to see the actual status of OpenGL somewhere permanently, as a reminder.

The "red color bug" is definitely an OpenGL bug in the 1.7 version.

I found this bug in the earlier version of Alexell's 32 bit Celestia 1.7 too.

Some textures are bright red when Eclipse Shadow and Cloud Shadow is on under OpenGL 2.0.

This is a bug, because Celestia 32 bit 1.6.1 didn't produce this result under OpenGL 2.0.

selden
Avatar
selden
Posts: 10117
With us: 15 years 2 months
Location: NY, USA

#10by selden » 17.07.2017, 19:19

I wouldn't call red objects a bug, but rather a limitation in how OpenGL allows multiple shaders to be applied. It's due to a design decision which probably would take quite a bit of work to fix. Red objects can easily be generated in Celestia v1.6.1, too.
Selden

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#11by john71 » 17.07.2017, 19:41

Selden: my problem is that I experience "red objects" in Celestia 64 bit 1.7 where earlier there were none. So the same textures and same objects worked just fine under 32 bit Celestia 1.6. :think:

Added after 3 minutes 22 seconds:
OK, I solved the "red" cmod problem: I forgot to apply texture to the "base" blender model. So "red" means there is no texture... :think:

Added after 35 minutes 46 seconds:
Selden: you were (of course) right, this is not a bug. (Sorry Alexell).

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#12by john71 » 18.07.2017, 16:11

OK, a few ideas:

1.) richer atmosphere options with up to 5 layers of colored "cloud" layers within one planet's parameters

2.) automatic orbit data correction using Kepler's laws

3.) more anti-aliasing

4.) mirror effects on textures

5.) automatic correction of atmospheric light corresponding with the lightsource star (red dwarf etc.)

6.) secondary constellation diagrams (asterisms) as interstellar and intergalactic routes, which can be easily drawn

7.) markers which remain "on" after exiting Celestia and running it again

8.) fading orbits as an option

9.) real time editing of ssc stc dsc files

10.) space distortion effect (wormhole, black hole, warp bubble)

11.) jumping to a spatial coordinate (not "getting there" in space slowly)

12.) real visual effects of near lightspeed travel

13.) automatic habitable zone detection (visual).

John Van Vliet
Avatar
John Van Vliet
Posts: 2660
With us: 15 years 2 months

#13by John Van Vliet » 18.07.2017, 18:46

2.) automatic orbit data correction using Kepler's laws

for planets,moons,minor bodies and asteroids , and spacecraft this is already done using SPICE data

5.) automatic correction of atmospheric light corresponding with the lightsource star (red dwarf etc.)
this is already done by setting the star type

8.) fading orbits as an option
already in the code , just enable it and rebuild

12.) real visual effects of near lightspeed travel
do you have a supper computer in your house , something in the terraflop range

john71
Topic author
john71
Topic author
Posts: 283
With us: 1 year 3 months

#14by john71 » 18.07.2017, 20:42

2.) automatic orbit data correction using Kepler's laws
for planets,moons,minor bodies and asteroids , and spacecraft this is already done using SPICE data

I meant for every orbit, even for imaginary ones too. I have to "manually" calculate periods. It should be automatic.

5.) automatic correction of atmospheric light corresponding with the lightsource star (red dwarf etc.) this is already done by setting the star type

Well, I don't know, but I had to manually correct Specular Color for TRAPPIST-1 planets...

8.) fading orbits as an option already in the code , just enable it and rebuild

Yes, but a graphic interface option would be nice.

12.) real visual effects of near lightspeed travel do you have a supper computer in your house , something in the terraflop range

:think:

Added after 13 minutes 2 seconds:
I found a new "red texture" bug: it is rather strange.

If two planetary orbits are too close to each other, then the nearby cloud textures of these planets are becoming red.

Strange. :think:

FarGetaNik M
Moderator
Avatar
FarGetaNik M
Moderator
Posts: 373
With us: 5 years 5 months
Location: Germany

#15by FarGetaNik » 19.07.2017, 06:59

john71 wrote:1.) richer atmosphere options with up to 5 layers of colored "cloud" layers within one planet's parameters

Multiple could layers would be usefull. I think it would be even better if cloud layers would be defined seperately from the atmophere like any other texture, maybe:

Code: Select all

CloudLayer 1
{
   Texture ""
   Height <>
}
Atmophere
{...}

This would also allow for multiple cloud layers (possibly).

john71 wrote:2.) automatic orbit data correction using Kepler's laws
for planets,moons,minor bodies and asteroids , and spacecraft this is already done using SPICE data
I meant for every orbit, even for imaginary ones too. I have to "manually" calculate periods. It should be automatic.

So you mean orbits defined by parameters (not spice, custom or sampled). This can't be that hard, but this can only work if a "mass" parameter is introduced for the parent body.

john71 wrote:5.) automatic correction of atmospheric light corresponding with the lightsource star (red dwarf etc.) this is already done by setting the star type
Well, I don't know, but I had to manually correct Specular Color for TRAPPIST-1 planets...

I also think that currently this isn't properly calculated, possibly just assuming white light. Atmospheric light scattering is very limited right now, we will need much more accurate models for it to work properly. There are more bugs. It doesn't account for eclipse or ring shadows, rings are not affected by it, it seems to only render the far side of the atmosphere at a planet's rim etc.

John Van Vliet wrote:8.) fading orbits as an option
already in the code , just enable it and rebuild

An option in Celestia's GUI would be nice though...

john71 wrote:9.) real time editing of ssc stc dsc files

Would be increadibly usefull, but possibly very difficult to implement. Also how about uniting all catalogue files into one file type (ssc, stc, dsc -> sc?) like it's done in space engine?

john71 wrote:10.) space distortion effect (wormhole, black hole, warp bubble)
12.) real visual effects of near lightspeed travel

I think that's a few steps to far right now. Can Celestia's engine even attempt to do that?

Joe
Avatar
Joe
Posts: 152
With us: 13 years 8 months
Location: United Kingdom

#16by Joe » 21.07.2017, 07:27

FMOD is not, to my knowledge, in open source. Why should this version of Celestia has FMOD functions embedded in the code? :(
Joe
8O

John Van Vliet
Avatar
John Van Vliet
Posts: 2660
With us: 15 years 2 months

#17by John Van Vliet » 21.07.2017, 17:05

FMOD ?

as far as i know there are no sound effects in the code

now there are CMOD meshes
"Celestia MODel "

K.A.V M
Avatar
K.A.V M
Age: 27
Posts: 15
With us: 1 year 3 months
Location: Marseille

#18by K.A.V » 24.07.2017, 09:14

Joe, Probably you need to remove FMOD and make OpenAL, or even remove support for audio.

John Van Vliet
Avatar
John Van Vliet
Posts: 2660
With us: 15 years 2 months

#19by John Van Vliet » 25.07.2017, 01:33

the default code has no sound support

there is a branch ( an old one) that did

there is a variable called "pfmod" in the orbit / particle /rendering calculations and rendering
( a positive always math function )
see:
http://www.cplusplus.com/reference/cmath/fmod/

it is part of the math lib

K.A.V M
Avatar
K.A.V M
Age: 27
Posts: 15
With us: 1 year 3 months
Location: Marseille

#20by K.A.V » 28.07.2017, 15:41

John Van Vliet, The New standard code is here: https://github.com/CelestiaProject/Celestia
Builds for Windows from this code have audio support in the cel and celx scripts, but Celestia sometimes crashes(


Return to “Development”

Who is online (over the past 5 minutes)

Users browsing this forum: 1 guest