Celestia 1.7.0 Development Thread

[Lafuente_Astronomy]

Just out of curiosity Janus, are you collaborating with onetwothree in making the fork for Celestia 1.7.0 or not?

[Janus]

@Lafuente_Astronomy

No, I am not involved with the project here.
Though I have posted and offered some code, I am not a member of the development team.

onetwothree and the others who are developing have made changes which are incompatible with how I work.
I am a casual C/C++ learning programmer, so I lack the knowledge to make any but the most simple contributions.
This project is just one I am using to learn more about C/C++, and so far, neither language impresses me.

They have shifted from using sln/vcxproj files, QT pro files, or whatever linux uses, to cmake.
Cmake does not work on any of my systems because of the way I have them setup.
It requires a specific kind of setup in order to find support libraries, which violate how I need things setup.
There is nothing wrong with how they are doing things, and I suppose it is the 'proper' way to do it.
I personally object to the way cmake puts itself in the middle of whatever project it creates, making calls to it a part of compilation.

However, I work a lot of other peoples stuff, nearly all of which contains protected IP.
Simply having the tools like cvs, svn, git, etc installed, would be seen as a potential leak by those customers.
On top of that, most of those projects I work on come in snapshot or stand alone form, which precludes common libraries.
It is normal for them to require specific library versions, often to support specific hardware versions or revisions.

I have my own sln/vcxproj and combination of binary downloaded static libraries or precompiled support libraries I use with Celestia.
One of my goals is get Celestia compiling with codeblocks, using mingw-w64, all static linked.
I do not support the use of DLL or other support libraries unless there is a specific need.
However, I also do not use the user profile on my systems, they annoy me. {I am always administrator or root. It is my computer, I own it.}
All of my software that can be is portable, and I often have multiple versions. each modified for a particular job.

I use their code as much as I can, particularly for public experiments like the modified fov.
I have a dozen or so personal forks for my own use, but they are all experimental.


Janus.

[Lafuente_Astronomy]

@Lafuente_Astronomy

No, I am not involved with the project here.
Though I have posted and offered some code, I am not a member of the development team.

onetwothree and the others who are developing have made changes which are incompatible with how I work.
I am a casual C/C++ learning programmer, so I lack the knowledge to make any but the most simple contributions.
This project is just one I am using to learn more about C/C++, and so far, neither language impresses me.

They have shifted from using sln/vcxproj files, QT pro files, or whatever linux uses, to cmake.
Cmake does not work on any of my systems because of the way I have them setup.
It requires a specific kind of setup in order to find support libraries, which violate how I need things setup.
There is nothing wrong with how they are doing things, and I suppose it is the 'proper' way to do it.
I personally object to the way cmake puts itself in the middle of whatever project it creates, making calls to it a part of compilation.

However, I work a lot of other peoples stuff, nearly all of which contains protected IP.
Simply having the tools like cvs, svn, git, etc installed, would be seen as a potential leak by those customers.
On top of that, most of those projects I work on come in snapshot or stand alone form, which precludes common libraries.
It is normal for them to require specific library versions, often to support specific hardware versions or revisions.

I have my own sln/vcxproj and combination of binary downloaded static libraries or precompiled support libraries I use with Celestia.
One of my goals is get Celestia compiling with codeblocks, using mingw-w64, all static linked.
I do not support the use of DLL or other support libraries unless there is a specific need.
However, I also do not use the user profile on my systems, they annoy me. {I am always administrator or root. It is my computer, I own it.}
All of my software that can be is portable, and I often have multiple versions. each modified for a particular job.

I use their code as much as I can, particularly for public experiments like the modified fov.
I have a dozen or so personal forks for my own use, but they are all experimental.


Janus.

Ahhhh. So you're not necessarily a collaborator but you make your own forks of Celestia 1.7.0. It's ok though. Whether it's by onetwothree or by you, I love how Celestia 1.7.0, despite being incomplete is already better than 1.6.1. Thanks a lot

Added after 2 minutes 4 seconds:
And actually, I'm worse off than you. I'm not really literate in any computer languages. But I know that it's people like you that make Celestia what it is today, so for that I salute you all

[vpontin]

So whats the current status of the project?

Is there any installer for 1.7?

What would be the best way to get celestia 1.7.x working?

[onetwothree]

So whats the current status of the project?

Slowly goes forward.

Is there any installer for 1.7?

No. Either compile yourself or if you use windows grab some archives from https://bintray.com/celestia/celestia-builds/celestia-dev

What would be the best way to get celestia 1.7.x working?

See above. If you use win archive then add a celestia.cfg from 1.6.1 I forgot to package it.

[vpontin]

Thanks.

Can i use the celestia.cfg from the github repository?

[onetwothree]

Can i use the celestia.cfg from the github repository?

yes.

[LukeCEL]

Is anyone else having this problem with the 1.7.0 version of Celestia?

If I open up Celestia, and cause the system to lag for a bit (e.g. by zooming out enough so enough stars are loaded, then moving my screen view or going to a distant object), it causes all the star points to become yellow. This effect persists until I quit Celestia. However, when I have nebulas turned off, it never seems to occur.

Here's an example of what it looks like:

Stars within 1 ly seem to be fine, which is why Izar looks fine in this picture. Also, if you zoom in, you can see a tinge of green on the lower left corner and red on the top right corner.

[onetwothree]

Something OSX specific. What happens if you change start color (black body <> classic)? Do you have any errors in /tmp/celestia-shaders.log?

[LukeCEL]

What happens if you change start color (black body <> classic)?

Unfortunately, that doesn't seem to prevent the problem from occurring.

Do you have any errors in /tmp/celestia-shaders.log?

I am not sure about the exact identity of this "celestia-shaders.log" file, but typing "open /tmp/celestia-shaders.log" into Terminal gave me this file:

Code: Select all

Vertex shader source:
  1: #version 120
  2: uniform float opacity;
  3: uniform vec3 light0_diffuse;
  4:
  5: void main(void)
  6: {
  7:     gl_TexCoord[0].st = gl_MultiTexCoord0.st;
  8:     gl_FrontColor = vec4(light0_diffuse, opacity);
  9:     gl_Position = ftransform();
 10: }

Fragment shader source:
  1: #version 120
  2: uniform sampler2D diffTex;
  3:
  4: void main(void)
  5: {
  6:     gl_FragColor = gl_Color * texture2D(diffTex, gl_TexCoord[0].st);
  7: }

Vertex shader source:
  1: #version 120
  2: // static shader
  3: uniform sampler2D normTex;
  4: uniform float pointScale;
  5: attribute float pointSize;
  6: varying vec4 color;
  7:
  8: void main(void)
  9: {
 10:     gl_PointSize = pointSize;
 11:     color = gl_Color;
 12:     gl_Position = ftransform();
 13: }

Fragment shader source:
  1: #version 120
  2: uniform sampler2D normTex;
  3: varying vec4 color;
  4:
  5: void main(void)
  6: {
  7:     gl_FragColor = texture2D(normTex, gl_PointCoord) * color;
  8: }

Vertex shader source:
  1: #version 120
  2: uniform float opacity;
  3: uniform vec3 light0_diffuse;
  4: uniform float pointScale;
  5: attribute float pointSize;
  6: varying float pointFade;
  7:
  8: void main(void)
  9: {
 10:     gl_FrontColor = vec4(gl_Color.rgb, opacity);
 11: float ptSize = pointScale * pointSize / length(vec3(gl_ModelViewMatrix * gl_Vertex));
 12: pointFade = min(1.0, ptSize * ptSize);
 13: gl_PointSize = ptSize;
 14:     gl_Position = ftransform();
 15: }

Fragment shader source:
  1: #version 120
  2: varying float pointFade;
  3:
  4: void main(void)
  5: {
  6:     vec4 color = gl_Color;
  7:     gl_FragColor = color ;
  8: }

Vertex shader source:
  1: #version 120
  2: uniform float opacity;
  3: uniform vec3 light0_diffuse;
  4: uniform float pointScale;
  5: attribute float pointSize;
  6: varying float pointFade;
  7:
  8: void main(void)
  9: {
 10:     gl_FrontColor = vec4(gl_Color.rgb, opacity);
 11: float ptSize = pointScale * pointSize / length(vec3(gl_ModelViewMatrix * gl_Vertex));
 12: pointFade = min(1.0, ptSize * ptSize);
 13: gl_PointSize = ptSize;
 14:     gl_Position = ftransform();
 15: }

Fragment shader source:
  1: #version 120
  2: uniform sampler2D diffTex;
  3: varying float pointFade;
  4:
  5: void main(void)
  6: {
  7:     vec4 color = gl_Color;
  8:     gl_FragColor = color * texture2D(diffTex, gl_TexCoord[0].st);
  9: }

Vertex shader source:
  1: #version 120
  2: uniform float opacity;
  3: uniform vec3 light0_diffuse;
  4:
  5: void main(void)
  6: {
  7:     gl_FrontColor = vec4(light0_diffuse, opacity);
  8:     gl_Position = ftransform();
  9: }

Fragment shader source:
  1: #version 120
  2:
  3: void main(void)
  4: {
  5:     gl_FragColor = gl_Color ;
  6: }

It doesn't look like there are errors here.

[BernardineBull]

Talking for myself, I have by no means whatsoever, quit tinkering. Matters direct here have been slanting towards entropy, and I got so little examination I finished the way toward annoying. So in the mean time I would perhaps not think about the vast majority of the choices, there at any rate advancement to discuss.

[onetwothree]

<sarcasm>BernardineBull, please keep us updated, it's very important!</sarcasm>

[Janus]

For anyone keeping track, the current commit when I write this is 5429.

For anyone who wants to keep up, here is commit 5429 in static linked portable.

I have also uploaded an extract and run archive to my downloads. My Downloads
It is 5429 with a small addition.
I substituted the 2M star db for the 180K star db.
Don't worry though, the original db is still present, just with a different extension.

In addition to those, I have also put up a ready to compile src archive of 5429.
This one is straight VS2015, all support libraries included.
This is derived from 5429, but is not official.
I did not use cmake to create the sln/vcxproj files. they are the ones I have been using, and use on my own forks.
This is so that anyone who wishes to experiment, can, without going through the mess of getting cmake to work.

My way of trying to encourage people.


Janus.

[selden]

Sadly, it wants me to do things that I can't.

For example, the "console log" is flooded with warnings about deprecated SSC Albedo declarations for all of my SSCs. As I mentioned in another post, that requirement is incompatible with all published SSC addons. The Albedo code should be changed to use the optional <units> qualifier to specify which type of Albedo value is being used and should use the old type if the qualifier isn't specified in the SSC file.

[Janus]

Here, try this one instead.

Now it silently accepts Albedo as GeomAlbedo, no whining.
BondAlbedo uneffected.

/src/celengine/solarsys.cpp:818 for the curious.


Janus.

[Lafuente_Astronomy]

Janus, out of curiosity and a lack of understanding in programming, how does your latest fork work? What are the differences between it and the previous forks you submitted?

[Janus]

Let me clear up something first.

When I include a commit number, it is that commit number with as few of changes as possible to make it compile.
In the case of celestia-5429, it is the latest commit as of this writing.
To compile it, I used an sln/vcxproj I made from an earlier commit before it and everything compilation related except cmake were eliminated.
I then added the support libraries that were also deprecated.
After that I patched winsplash.h with some values that are included in mingw, but not VS.
I then compiled it in x86 & x64 with everything set for static linking.
Basically, if my post has a commit number, it is as generic or vanilla as I can keep it and have it compile.

I rarely post any of my personal forks.
I have one where I added celx comands to look up stars by Ra/Dec/Dist, by separation in real space, by RaDec difference.
There are two versions of this one, one of them uses an alternate star.db I made that preserves RaDecDist, the other computes it in real time.

I have one where the frame rate when recording is locked to the frame rate of the recording.
For instance, I used it for my solar system tour, where I had it locked to 30fps, period.

I have another where I moved the obs distance measure to the lower right.
Several variations where RaDec of an object is shown in real time.

I have another set where I am working on being able to define lines between stars to show interstellar journeys.

Then there is the one where I mapped a kinect so I could navigate by waving my hands around.

The list goes on, but none of those have commit numbers.
My personal forks go from VS2010 up through VS2015, all static linked.

I put up stuff like I do here so people can test changes that are being made.
An example being the Albedo command that was deprecated despite it being in constant use.
All I did was make it fail in a backwards compatible manner without complaining about it.


Janus.

[LukeCEL]

Stupid question, why is it that my 1.7.0 build seems to read earlier versions of my files? I've noticed that changes I make to files don't appear in Celestia 1.7.0.

For example, even though I've finished my Carina Dwarf add-on, it still displays a previous version where I was playing around with the distributions and marking the stars as M-type or O-type stars:

[Lafuente_Astronomy]

Let me clear up something first.

When I include a commit number, it is that commit number with as few of changes as possible to make it compile.
In the case of celestia-5429, it is the latest commit as of this writing.
To compile it, I used an sln/vcxproj I made from an earlier commit before it and everything compilation related except cmake were eliminated.
I then added the support libraries that were also deprecated.
After that I patched winsplash.h with some values that are included in mingw, but not VS.
I then compiled it in x86 & x64 with everything set for static linking.
Basically, if my post has a commit number, it is as generic or vanilla as I can keep it and have it compile.

I rarely post any of my personal forks.
I have one where I added celx comands to look up stars by Ra/Dec/Dist, by separation in real space, by RaDec difference.
There are two versions of this one, one of them uses an alternate star.db I made that preserves RaDecDist, the other computes it in real time.

I have one where the frame rate when recording is locked to the frame rate of the recording.
For instance, I used it for my solar system tour, where I had it locked to 30fps, period.

I have another where I moved the obs distance measure to the lower right.
Several variations where RaDec of an object is shown in real time.

I have another set where I am working on being able to define lines between stars to show interstellar journeys.

Then there is the one where I mapped a kinect so I could navigate by waving my hands around.

The list goes on, but none of those have commit numbers.
My personal forks go from VS2010 up through VS2015, all static linked.

I put up stuff like I do here so people can test changes that are being made.
An example being the Albedo command that was deprecated despite it being in constant use.
All I did was make it fail in a backwards compatible manner without complaining about it.


Janus.

Ahhhh. So each commit you have only has a few changes that make it different from the others. I see. Say, will you make a commit that uses most, if not all of your features that you placed in other commits and forks?

I'm looking forward to more of your commits. The x86 ones are actually compatible with the opengl32.dll file that I installed on my Celestia just to make stars appear as points without any problems.

[Janus]

@Lafuente_Astronomy

I try not to step on to many toes here.
There are some significant differences between my style, and those who actually run the forum and project.
I will be putting my personal forks up on my own site over time.

However, before I can do that, I need to create a better tool for comparing differences between files and directories.
I am working on making winmerge useful on diffing directories, not just individual files.
I need that because of the number and type of comparisons I need to do, and no usable tools for windows currently exist to do it.

Is there a particular thing you would like to see or try out?


Janus.