Page 22 of 48
Posted: 10.06.2019, 14:28
pirogronian, I have multiple star barycenters orbiting a black hole, gas giants with many moons, the Earth-like moons have sometimes hundreds of spacecrafts around them + large cities on the surface.
Posted: 10.06.2019, 14:33
john71 wrote:I have multiple star barycenters orbiting a black hole, gas giants with many moons, the Earth-like moons have sometimes hundreds of spacecrafts around them + large cities on the surface.
It would be useful to know exactly when lagging occurs: what kind of objects are in field of view (and their average numbers).
Posted: 10.06.2019, 14:37
And very large textures, but dds types.
Added after 4 minutes 7 seconds:
pirogronian, The lagging occurs when there are a lot of objects in visible range and you change the view rapidly. It is not a "freezing", it is a very visible "lagging" of a lot of objects.
Added after 4 minutes 32 seconds:
It usually happens near planets with very high resolution textures (3 levels, 32k) and dozens of starships or space stations.
Posted: 10.06.2019, 21:23
Lafuente_Astronomy wrote:And also, if done, will it greatly increase the performance of Celestia as a whole?
It depends on OS, video card and drivers used. On my old system with fullhd monitor I had ~40 fps on GNU/Linux with free drivers while on Win7 with proprietary drivers there were ~70 fps. Perf said that CPU was mostly occupied by memory coping functions. With modern OpenGL we can greatly decrease number of such copy invocations (not for star field however).
Posted: 10.06.2019, 21:30
onetwothree wrote:It depends on OS, video card and drivers used. On my old system with fullhd monitor I had ~40 fps on GNU/Linux with free drivers while on Win7 with proprietary drivers there were ~70 fps. Perf said that CPU was mostly occupied by memory coping functions. With modern OpenGL we can greatly decrease number of such copy invocations (not for star field however).
That's good to know. In this way, Celestia will be able to handle much more items better. With regards to star field, Janus was able to increase its size on some of his forks, so there must be another aspect of Celestia's programming that can be fixed to increase star field size.
Posted: 10.06.2019, 22:45
What I reset was a limit designed to keep rounding errors in positioning from getting out of hand.
Changing the underlying limit requires doing positioning in double instead of single. DOUBLE replacing FLOAT to be exact.
Doing that is a lot of work.
There are places where bit sized variables are assumed, so all of those need to be switched.
I made a fork with DOUBLE in the database and starting on switching everything over, but I never got any feedback on it, so I dropped the work.
It will be several weeks, or maybe months, before I can start on Celestia again.
My current job is a massive P.I.T.A., teaching programmers and engineers to communicate.
Engineers have no respect for stack space, memory, explaining things that are implicit to them.
Programmers have no respect for units actually used in the field being used in the program, why the UI needs to be based on the actual machine, or explaining things that are implicit to them.
It would be faster to just do the whole job myself, but they need to be able to maintain it after I leave.
The pay is great though, even if I do feel more like a referee than anything else.
Posted: 11.06.2019, 01:08
Janus wrote:made a fork with DOUBLE in the database and starting on switching everything over, but I never got any feedback on it, so I dropped the work.
Perhaps you can ask the devs to try that out and maybe it can be used in the development of Celestia 1.7.0
Posted: 11.06.2019, 06:43
john71 wrote:It usually happens near planets with very high resolution textures (3 levels, 32k) and dozens of starships or space stations.
Modern graphics engines optimizes multiple objects and complex meshes view by dedicated octrees. In Celestia octrees are only for stars and dsos. So, Celestia wll render all objects within current planetary system. At least I think so.
Posted: 11.06.2019, 10:37
, As I know Celestia won't load any textures or meshes if it does not "see" them. But the problem is surely not with the very large meshes or textures, because they work fine after loading them into memory.
The problem is with a lot of objects, orbits etc., which are simultaneously present.
So it should be an octree or an inner processing problem. Celestia is not able to use more CPU power to process more data.
Posted: 30.06.2019, 11:05
Are there any new builds? If there are, can we get a new exe file here?
It would be appreciated.
Posted: 30.06.2019, 17:35
Not yet, i'll recheck if we have something "user-visible".
Posted: 30.06.2019, 18:14
Posted: 30.06.2019, 20:48
We don't have many changes since the last build: luajit is supported on all platforms not only GNU/Linux and it's preferred over "usual" Lua. Some OpenGL1.0 code was rewritten using OpenGL2.0/OpenGL2.0+ functions, basically it's not worth compiling.
Posted: 02.07.2019, 10:46
Sorry for this, it's surely my fault, but I got lost among the lot of messages and updates here.
So my request: could you please release the actually final and TOTAL version, including all the changes performed till now?
This would be very appreciated by me, and surely by many other people.
Thank you anyway for what you are doing.
Posted: 02.07.2019, 14:15
Final and total version does not apply to an open source program, especially a work in active progress.
However, if you are referring to the current version, that I can help with.
Here is Commit 5528 vanilla.
As usual for my stuff, this is a non official release.
VS2015, static linkage, no dependencies.
I do not have a QT version, I do not currently have QT installed.
If my schedule permits I will bring a few of my tweaks into this and post it in my forking thread.
EDIT: Had to flex my bad spalling.
Posted: 03.07.2019, 12:33
Hi Janus, don't worry, English is not my language too.
Yes, that's what I was asking for, thanks a lot, appreciated.
Posted: 09.07.2019, 14:54
In the past few months I made a lot of videos using Celestia. My question is: is it possible to implement a higher level anti-aliasing option, plus a saturation, color editing and contrast/brightness function? It would make the look and feel of Celestia much more professional in my opinion.
Posted: 10.07.2019, 08:28
We don't have enough human power for this unfortunately. You can write a more expanded feature request and we'll add it to our issue tracker in hope that somebody will pick it up for implementation.
Posted: 10.07.2019, 11:35
Oh I see. OK, my feature requests are the following:
1.) more anti-aliasing ((we have powerful graphic cards in 2019)
2.) real time fps monitoring
3.) saturation, color editing and contrast/brightness function
4.) real time stc, ssc, dsc file editing without restarting Celestia
5.) larger magnification capability ("," and "." keys on my keyboard) with some kind of real time measuring numbers on the screen
6.) more key command speed options for c velocities (0.1, 0.3, 0.5, 0.9 c)
7.) real time celx scripting/programming
8.) ESA Gaia data integration from Gaia Sky database.
Posted: 10.07.2019, 12:31
john71 wrote:1.) more anti-aliasing ((we have powerful graphic cards in 2019)
We still need to keep compatibility with GL2.1 and older hardware. On the other hand, AA is useless on 4k screens and "retinas"
(No, I don't have any).
john71 wrote:2.) real time fps monitoring
What's wrong with the currently implemented one (press ` (Shift+~ on my keyboard))?
john71 wrote:4.) real time stc, ssc, dsc file editing without restarting Celestia
Partially implemented in 1.7 (celx:load_fragment function). Partially because Celestia doesn't allow to remove objects.
[I wish you describe your requirements as Croc did with images and so on.]