Celestia 1.7.0 Development Thread

Post #1321by **Art Blos** » 29.12.2022, 19:44

onetwothree wrote:Put shaders.log here

Done.

Added after 9 hours 44 minutes:
Please note that letters "B" in the object parameters have not disappeared.

john71 · Post #1322by **john71** » 30.12.2022, 07:17

Can you please insert a text into the Celestia website main page (and into any other Celestia page), that you are actively seeking Windows developers?

TheLostProbe · Post #1323by **TheLostProbe** » 30.12.2022, 12:34

john71 wrote:Can you please insert a text into the Celestia website main page (and into any other Celestia page), that you are actively seeking Windows developers?

https://twitter.com/CelestiaProject/status/1607760112965550084

Post #1324by **Art Blos** » 01.01.2023, 08:49

onetwothree wrote:Put shaders.log here

Have you reviewed my file? There are any considerations?

Post #1325by **onetwothree** » 01.01.2023, 12:19

Art Blos wrote:Have you reviewed my file? There are any considerations?

It looks good. What I suspect is that the system doesn't handle large textures. Please do the following:
1. Post The first part of Help->OpenGL Info (extensions are not required)
2. Play with different texture sizes to see if with smaller textures the planet is shown. If it doesn't help, then
3. Disable all additional features like atmospheres, clouds and so on to if it helps. If it helps then
4. Enable them one by one to see what feature causes a glitch.
5. Do the steps 2-4 with 64-bit build and Qt5 32- and 64-bit builds.

Post #1326by **Art Blos** » 01.01.2023, 15:50

onetwothree wrote:1. Post The first part of Help->OpenGL Info (extensions are not required)

: OpenGL.PNG (7.24 KiB) Viewed 29126 times

On the same laptop, version 1.6.2 works with textures up to 4K.

onetwothree wrote:2. Play with different texture sizes to see if with smaller textures the planet is shown. If it doesn't help, then

Useless. Tried even smallest sizes.

onetwothree wrote:3. Disable all additional features like atmospheres, clouds and so on to if it helps.

Useless. Disabled everything possible.

onetwothree wrote:5. Do the steps 2-4 with 64-bit build and Qt5 32- and 64-bit builds.

Qt5 32- and 64-bit builds and native 32- and 64-bit builds is load objects correctly on 64-bit Windows.
In general, this problem is only on a 32-bit system, as already written on GitHub.

Post #1327by **onetwothree** » 01.01.2023, 19:20

Do you see any errors in Celesatia console (`)? Do you observe the same for other planets?

Post #1328by **Art Blos** » 01.01.2023, 21:07

onetwothree wrote:Do you see any errors in Celesatia console (`)? Do you observe the same for other planets?

No errors in console (at least the textures are loading correctly). There is no daylight on any object.

Post #1329by **Art Blos** » 03.01.2023, 10:11

onetwothree < If localization works in artifacts, then you need to transfer corresponding code to the main branch.

Post #1330by **onetwothree** » 03.01.2023, 12:46

it's there already

Post #1331by **Art Blos** » 03.01.2023, 15:01

onetwothree wrote:it's there already

This is good. Unfortunately, another problem has been identified. Maybe you know about it, maybe you don't.

Previously, to localize binary stars from file "stars.dat", we moved all content from "starnames.dat" to a separate SSC-file. My experience has shown that this is no longer necessary. However, now is not possible to translate stars with Bayer designation: ALF, BET, GAM, etc.

Post #1332by **Art Blos** » 05.01.2023, 17:50

onetwothree < Can you remind me how to properly use binary vector trajectories in the current build? What format to write in SSC, and what in the file name?

Post #1333by **onetwothree** » 05.01.2023, 18:35

In current 1.7 builds you should use filenames with .xyzvbin extension. In ssc files you can use either .xyzvbin or .xyzv.

Post #1334by **Art Blos** » 05.01.2023, 18:59

onetwothree wrote:In current 1.7 builds you should use filenames with .xyzvbin extension. In ssc files you can use either .xyzvbin or .xyzv.

Tried various combinations. The object either becomes with a diameter of 1 kilometer, either is in center of the Sun. This happens on Windows and Unix.

Added after 11 hours 34 minutes:
Here is an example. Test for yourself, maybe I did something wrong?

Post #1335by **Art Blos** » 07.01.2023, 08:18

Still, I think that this problem is on Celestia's side. If everything is done correctly on my part, and converter used by me remains relevant.

An object can be in center of the Sun only in one case: if simulator incorrectly perceived starting point of vectors.

What will you do? Fix code in Celestia or change structure of binary format? I need to know about this as soon as possible because all development has stalled. Also, I've already converted all Solar System trajectories to binary. :nervious:

However, I will redo it from the text sources, if will be necessary.

Post #1336by **onetwothree** » 07.01.2023, 09:39

Please send me the original text file. I converted your binary back to text and it contains wrong numbers:
-1792668111692977178477093058717173335026018321514129638671875000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000 0.0000000 123022526551936389083152789680752903223037719726562500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000 -0.0000000 602553560663478800051962025463581085205078125000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000 -735381235260751246755717147607356309890747070312500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000 -0.0000000

Post #1337by **Art Blos** » 07.01.2023, 09:57

With a text file, everything worked correctly. All trajectories in Origin are made according to the same principle.

Added after 1 hour 26 minutes:
onetwothree < Could be reason an error in the converter itself?

Post #1338by **onetwothree** » 07.01.2023, 13:58

What converter do you use? Binary (.exe) or in perl written (.pl)? Using binary one I made conversion xyzv -> bin -> xyzv and everything is fine.

Post #1339by **Art Blos** » 07.01.2023, 14:44

onetwothree wrote:What converter do you use? Binary (.exe) or in perl written (.pl)? Using binary one I made conversion xyzv -> bin -> xyzv and everything is fine.

Binary (.exe). Can you share your version? And also check mine.

Added after 12 minutes 14 seconds:
A successful test was done with my Neptune?

Post #1340by **Art Blos** » 08.01.2023, 06:22

onetwothree< What is your verdict? What is reason for inoperability of trajectory? In the Celestia code or in the converter?
In any case, give the tool with which you all succeeded.

At the same time, can you comment on this change? Is this something to do with the fact that you were getting strange numbers from my trajectory? I definitely need to make sure that it was actually defective.
https://github.com/CelestiaProject/Celestia/pull/1494