Where to make optimizations in Celestia

The place to discuss creating, porting and modifying Celestia's source code.
Topic author
Brendan
Posts: 296
Joined: 15.07.2003
With us: 21 years 4 months
Location: Bellows Falls, VT
Contact:

Where to make optimizations in Celestia

Post #1by Brendan » 10.01.2005, 22:29

Cham wrote:I have the impression that Celestia is the most heavily demanding piece of software ever wrote.

maxim wrote:It's simply not very optimized. I think the initial design didn't cover the current usage load.


What optimizations could be made and where? :? The easiest place for me to help out may be loading addons.

Brendan

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 7 months
Location: Hamburg, Germany

Re: Where to make optimizations in Celestia

Post #2by t00fri » 10.01.2005, 23:32

Brendan wrote:
Cham wrote:I have the impression that Celestia is the most heavily demanding piece of software ever wrote.

maxim wrote:It's simply not very optimized. I think the initial design didn't cover the current usage load.

What optimizations could be made and where? :? The easiest place for me to help out may be loading addons.

Brendan


Well /culling/ of objects is the main issue.

Quite some time ago I spent weeks scanning through the code of render.cpp. Since there are so many objects to render, culling is crucial. For certain configurations I managed to get speed-ups by a factor of 30!

The frustration is due to the fact that any objects outside the field of view need not be rendered. Yet, in order to find out whether an object (e.g. an asteroid) is outside the FOV, one needs to solve Kepler's equation first. That takes time...
I devised all sorts of approximations thereof. Yet due to our /exponential/ zooming, those have a tendency to break down easily...

This is really tedious and most delicate matters. So,
at some point, I gave up, well aware that there is still much room for further work...

Bye Fridger

Avatar
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 10 months
Location: Montreal

Post #3by Cham » 10.01.2005, 23:55

My only complains about Celestia performances is when I show nebulae. I then have all the galaxies rendered with all the nebulae billboards. If I have the bad luck of turning my FOV in direction of the Milky Way, Celestia slow down to a crawl ! 8O and it gets reaaaaally painfull !

There should be two commands here : one for the galaxies alone, and another for the nebulae (billboards) alone. PLEASE ?
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years 1 month

Post #4by dirkpitt » 11.01.2005, 01:26

Cham wrote:My only complains about Celestia performances is when I show nebulae. I then have all the galaxies rendered with all the nebulae billboards. If I have the bad luck of turning my FOV in direction of the Milky Way, Celestia slow down to a crawl ! 8O and it gets reaaaaally painfull !


That, and the 1+ second disk read whenever the textures for a freshly visible object need to be loaded (got a particularly slow notebook hard disk, unfortunately :-(. Perhaps this could be solved by threaded texture loading. Also I'm not entirely familiar with the engine code so I may very well be wrong but it feels like textures aren't cached in an LRU but in an unlimited list because after I zoom into a mega hires virtual textured sun that exceeds my physical memory, my disk is still thrashing when I'm 50,000 light years away because of previously-loaded textures that are no longer visible. There could be room for improvement here.

Harry
Posts: 559
Joined: 05.09.2003
With us: 21 years 2 months
Location: Germany

Post #5by Harry » 11.01.2005, 10:07

dirkpitt wrote:That, and the 1+ second disk read whenever the textures for a freshly visible object need to be loaded (got a particularly slow notebook hard disk, unfortunately :-(

In my experience this is not so much the time needed to load a texture, but the time to decode JPG/PNG images. Converting all textures to DDS improved things for me, and it reduces the amount of memory needed too. However you should check first if your notebook actually displays DDS textures, and you may get smaller improvements if you got a very fast CPU and a really slow HD.

Harald

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years 1 month

Post #6by dirkpitt » 11.01.2005, 12:22

Harry wrote:
dirkpitt wrote:That, and the 1+ second disk read whenever the textures for a freshly visible object need to be loaded (got a particularly slow notebook hard disk, unfortunately :-(
In my experience this is not so much the time needed to load a texture, but the time to decode JPG/PNG images. Converting all textures to DDS improved things for me, and it reduces the amount of memory needed too. However you should check first if your notebook actually displays DDS textures, and you may get smaller improvements if you got a very fast CPU and a really slow HD.

Harald


That's good to know. DDS indeed works for me but I've never benchmarked it. I'll have to try that, thanks.

Avatar
John Van Vliet
Posts: 2944
Joined: 28.08.2002
With us: 22 years 2 months

re

Post #7by John Van Vliet » 19.01.2005, 10:51

also if you use .png's like i do try resaving them with a compresion of 1 and not 7 or 9 like my dl's are

i have found that using a comp. of 1 will speed it up -aprox. 25 to 50 %


Return to “Development”