A Forking Commit Thread.

[pirogronian]

I think about nake every object potentially relative, with orbit and barycenter or just offset parent. It would be next step in my branch astrodb.

[Lafuente_Astronomy]

Well, is it also possible to include grids for other stars and galaxies in Celestia? It could be beneficial for that

[Kochav Israel]

To Janus: (idk how to tag people here and idk if this function even exists)

If I can do even a brute force version, would you mind testing it with your auto generated data to see how it looks?

I wouldn't mind this. Here is the addon and Python code:

[Janus]

@Kochav Israel

While I appreciate the files, and I will study them.
I do not have python installed on my system, nor do I know how to run it.
The few programs I have that use it, or parts of it, have their own copy included within their own space.

@onetwothree

The ratio is only 1:4 for my hardware, and I have enough to take it.
I avoid one particular brand of GPU because I hate their drivers, and most especially the way they do business.
I am not naming names because no one will gain anything from a flame war, which is what it would devolve to.
SP is great for games, but DP is more precise, and I will always go for precise.


On the topic of going DP in memory, what a mess.
I started poking at that problem, and it is bad.
One to three dozen lines of template errors, that only contains the source code line number about half the time.
I do not know who designed templates, but although I can understand the appeal of the concept.
The people who are implementing it need to go back to school and take some 1A communication classes.

I am going to keep poking at it between other jobs however.
I am trying to be precise rather than using notepad++ to do a search and replace every in every source file at once.
" float " to " double ", "gl_float" to "gl_double", "vector3f " to "vector3d " and so on, I am sure there are more.
While it would be satisfying to do that, luminosity and many other measurements do not need DP.


Janus.

[pirogronian]

@Janus

After several iterations, I did find&replace and then revert changes where needed. Seems to be less work than with precise approach...

[Janus]

Interesting, and I may try it.
What I am wanting {Though probably won't get} is to do the next iteration of my solar system tour dvd with DP positioning.
Currently positioning data is stored in 'micro light years'.
What this means is that you don't have to go very far {15.8Ly} before you start getting AU or better errors in stellar positioning.
{Changing to double moves the AU offset problem to the edge of the currently observable universe.}
While those offsets are small by themselves, it means that applying motion over time is problematic at best.

I am looking for all the precision I can get for one of my side projects, building a simulation of the milkyway.
Not as a collection of 2-4x10^14 stars, but as a fluid.
In order to build the fluid map however, I need really good resolution snapshots of high and low density regions, from which I can approximate.
{While I can approximate, it amounts to guessing, and I will feel better about it anyway.}
This should enable me to build density vector maps, which I will do at multiple resolutions.
This is a long term goal however, not something I expect to do this year, or next, it may take several more.


Janus.

[onetwothree]

@Janus

you still don't need double for GL.

[Janus]

@onetwothree

I will take your word for that as I do not know opengl hardly at all.
However, putting doubles into a single routine seems like a lot of overhead to me.

@pirogronian

If you finish making a double change, I would like to play with the source if you do not mind.
Tracing down template errors is frustrating since appear to be designed to be deceptive.


Janus.

[pirogronian]

@Janus

I'll submit PR as soon as I'll get successfull compilation. However I proceed with trial and error method, moreover I'm not familiar with renderer code. Consequently my changes are chaotic a lot. But maybe for "playing" it would enough

[Janus]

@pirogronian

I look forward to a chance to play with it.

P.S.
I am currently finishing a compilation run of 5466, which appears to have fixed the greek letter issues.
I will be posting it in my forked thread with all the same tweaks as 5445.

Janus.

[Janus]

Okay, here we go again.
This time it is Commit 5466 with all the previous bells and whistles.

The greek letter situation appears to be under control.
All I look forward now is the ability to turn them off, but that is just me and I know it.

Looking forward to feedback.


Janus.

[pirogronian]

@Janus

Here is my branch with double precision star position: https://github.com/CelestiaProject/Celestia/tree/double.
However, it's unusable. Stars are invisible and background is filled with blinking halos. Probably I seriously broke something by mistake inside renderer.
I even don't know if main problem with precision, entitled in this topic, has been solved by these changes..
So, I abandon this subject for now. Debugging render code, changed in such a number of places at once, is beyond my abilities...

[Lafuente_Astronomy]

Well, have you found a solution to the texture octee problem that prevents the 100 GLY star field limit from being fully realized? Just curious

Added after 2 hours 12 minutes:
Also another question:

Where do you place your code in your forks and commits, just in case I wanna tinker with it for some time? Thanks in advance

[Janus]

I have not yet even looked at octree as of yet.
That is a project that looks to take time, and I have several underway already.

As for my tweaks, try in MyDownloads, where I have snapshots labelled by the commit number they are taken from.

You can search for "// Janus" via ztree, grep, or whatever, to see what I have done.
You can also use winmerge or diff to compare with the main source tree of the matching commit number.
I keep my tweaks labelled so they can be found.
Of course, any of them the maintainers want to use, they are welcome to.


Janus.

[pirogronian]

Well, apparently I lied. Just finished new, much more efficiently changed version without halo bug (in the same branch as above). Anyone wants to test?

[Janus]

@pirogronian

Took very little work to get winstarbrowser working.
Over all it looks much better without the ghost lights.
Asterisms are still a mess, but that was expected.

Should I see about making a DP star database?
And if so, would you mind if I included the RA, Dec & Dist, as well as proper motion in it.
I ask because part of my tweaks use RaDecDist directly, and storing it in the star DB is faster than computing it.

The proper motion is for an old project.
Using a tweaked version and a script.
The script sets the date, checks for a year crossing in which case it applies proper motion to recompute star positions, calls record frame, then repeats.
The idea is to record a "Movie" showing the stars from 3600BC to 3600AD at various intervals.
I wanted to start with 6 months to the frame, and see how it looks.
However, I ran into the resolution limits of SP positioning, so I put it down until that limitation could be addressed.

I will post an archive once I have checked a few more things.


Janus.

[onetwothree]

The idea is to record a "Movie" showing the stars from 3600BC to 3600AD at various intervals.

VSOP87 guarantees for Mercury, Venus, Earth-Moon barycenter and Mars a precision of 1" for 4000 years before and after the 2000 epoch. The same precision is ensured for Jupiter and Saturn over 2000 years and for Uranus and Neptune over 6000 years before and after J2000.[1]

[Janus]

@onetwothree

Other than conjunctions with stars, I am uninterested in the planets for this particular project.

In part, I wish to produce star charts for various periods.
Gobekli Tepe, Stone Henge, Cheops, The flood of Mesopotamia, Perhaps go crazy and try the rottnest down under, that sort of stuff.
Then make negative comparison plates to highlight the {subtle} differences that have occurred over time.

That is going to require the DP version which is being toyed with.


Janus.

[onetwothree]

Celestia doesn't support start orbits.

[Janus]

Understood.

My plan is to use the stars position in RaDec{Dist} as a base, then add or subtract the proper motion as relevant.
It is a crude method, but it should be enough to answer my question(s).


Janus.