Celestia 1.7.0 Development Thread

[onetwothree]

Any owners of old videocards here (old means with gl2.1 only)? could you test https://ci.appveyor.com/project/375gnu/celestia/builds/30267442/artifacts

Added after 4 minutes:
radeon >=9500, X8xx, X1xxx
Intel Pentium G6000/P6000/U5000, Celeron P4000/U3000. G35, G41, G43, G45, GM45, GL40, GS40, GS45, Q43, Q45, B43, 4 Series Express Chipsets

[onetwothree]

With this change - https://github.com/CelestiaProject/Celestia/pull/608/files i'm gonna disallow semi-axes for stars. Incorrect means any value > 1 or all < 1. Note: this doesn't affect planets. Any concerns?

[SevenSpheres]

With this change - https://github.com/CelestiaProject/Celestia/pull/608/files i'm gonna disallow semi-axes for stars. Incorrect means any value > 1 or all < 1. Note: this doesn't affect planets. Any concerns?

Since all responses have been on Discord I might as well port them over. I agree with Luke/Fafers/Pedro here.

(Edit: 200th post!)

Wait, so what would happen to stars with correct semi-axes as given?
I have just recently started making binary black hole addons, and I am still learning what to do with some of those measurements, and data, including semi axis

@onetwothree no real concern but I don't see the point? It doesn't fix any bug, just prevents it from happening.

@onetwothree possible concern: backwards compatibility

Wait, so what would happen to stars with correct semi-axes as given?

@Lafuente_Astronomy Nothing changes for them.

@onetwothree no real concern but I don't see the point? It doesn't fix any bug, just prevents it from happening.

@SevenSpheres let's be on the safe side

@onetwothree possible concern: backwards compatibility

@LukeCEL please see https://en.wikibooks.org/wiki/Celestia/1.6.0_Features: "For stars, we specify the shape with SemiAxes [ x y z ] and this is multiplied by the radius.", "even if the radius is omitted in the stc file, a star always has an implicit radius based on the blackbody calculation."
for me that clearly means that for stars semi-axes no values greater than 1 are allowed and at least one of them must be equal to 1

otherwise we have an absurd case when actual star is larger or smaller then its bounding sphere defined by its radius

@onetwothree One alternative to disallowing could be normalizing the values, dividing the three of them by the greater one. Then it would work with whatever values are in the Semiaxes. Well, providing no one starts using negative values. You know, the users allways can push the developers beyond their limits...

that's was one of my idea, but i rejected it cause better to clearly manifest error, so that it will be noticed and fixed

Should we really break things on purpose? Other than render bugs, over-unity semiaxes worked fine. Also, this change only hides the bug instead of fixing it.

That is what I was thinking. Also, some add-ons like this one (http://www.celestiamotherlode.net/catalog/show_addon_details.php?addon_id=1552) have definitely used over-unity (this one uses SemiAxes [ 1.5 1 1 ])

That's why the idea suggested by Fafers_br would be the best solution IMHO, since it would automatically fix the problem, as well as keeping compatibility

[Lafuente_Astronomy]

Well, I have to agree with all of the above. But perhaps we may also have to consider the Dev's position as well? We will await their response

[onetwothree]

I strongly oppose idea that Celestia code should have fixes and workarounds for incorrect addons. So, taking into account that the community is against the proposed change, it won't be implemented.

[Janus]

A suggestion.
Go ahead and test for out of range options, and log them if logging is turned on.
That way, all a developer has to do is turn logging on to test data and rendering.
No need to restrict it to just this, anything out of range or any bad combination could trigger a log note.
Include the entire entry that causes the issue to make it easier to find.


Janus.

[SevenSpheres]

Just so everyone knows; in response to this post, onetwothree has made Askaniy, LukeCEL, and myself part of the dev team. Askaniy and I are the closest to Windows maintainers Celestia has at the moment.

[Lafuente_Astronomy]

Just so everyone knows; in response to this post, onetwothree has made Askaniy, LukeCEL, and myself part of the dev team. Askaniy and I are the closest to Windows maintainers Celestia has at the moment.

I jguess we just have to wait for Alexell to put you all in the Developers role in the Forum.

[SevenSpheres]

Suggestion: Chris Laurel's other astronomy program, Cosmographia, apparently has an iOS version. Since there has been some discussion about porting Celestia to iOS (and Android) the developers might want to look at Cosmographia's code for pointers.

[Anthony_B_Russo10]

That would be a good idea SevenSpheres.

[onetwothree]

Chris' cosmografia doesn't support ios. Only later versions were ported, but their source is not available.

[onetwothree]

today i applied small but important change which affects sprite models rendering
please test sprite models using files from https://ci.appveyor.com/project/375gnu/celestia/builds/31271178/artifacts
or build them from fix/glsl-particles-drawing branch

[SVision]

today i applied small but important change which affects sprite models rendering
please test sprite models using files from https://ci.appveyor.com/project/375gnu/celestia/builds/31271178/artifacts
or build them from fix/glsl-particles-drawing branch

Hello onetwothree
I decided to test this update on my nebula.
Everything works, but what are the updates?

If the changes concern the rendering speed, no .It's the same.
The visibility of the right-hand models remains the same.

open cluster nebula 1860-20

[SevenSpheres]

Everything works, but what are the updates?

When I tested that build your black hole disk/jets models didn't render, as I said on the pull request page.

[onetwothree]

Everything works, but what are the updates?

The old code uses GL1 way to apply textures to points. The new one is GL3/ES compatible. Also that GL1 compatible code has issues on macOS.

When I tested that build your black hole disk/jets models didn't render, as I said on the pull request page.

This is fixed already.

[Lafuente_Astronomy]

Hello onetwothree
I decided to test this update on my nebula.
Everything works, but what are the updates?

If the changes concern the rendering speed, no .It's the same.
The visibility of the right-hand models remains the same.

Would that somehow be related to the reason why jets are not rendered at very high radii?

[onetwothree]

i have no idea what are you talkin' about. any screenshots?

[Lafuente_Astronomy]

i have no idea what are you talkin' about. any screenshots?

Sorry for late reply. But here it is:

Because 3C 273's jet is measured at around 60 kpc long, I gave it that estimate in its radius. But because of that, it is no longer rendered

Added after 1 minute 20 seconds:
Anyways, this was before I gave it the correct inclination, so do not worry

[onetwothree]

please test this build, especially if you have an old video card.
@Anthony_B_Russo10 this is something for your laptop collection

[selden]

It has problems on my laptop:

1. no GUI (corner) text is visible whether terse or verbose is selected.
2. There's a gap in the orbit next to the Earth.
3. Note that the OpenGL info window is improperly formatted, too.

I copied all of the files from the .7z archive into (a copy of) the same directory where I'd been running Janus' ttf and txf versions, so I don't think any fonts are missing.

I do have an old video card, which supports only up to OpenGL 3.3. (see the OpenGL info in the attached screengrab.)

screengrab showing problems