Celestia Forums

Inspired by discussions here in the forum, I have added the following
three AutoMag adjustments in the code (but not yet checked in):

1) If the automatic limiting magnitude setting (AutoMag) is active
(toggle CTRL+Y), the [ and ] keys now set the limiting magnitude at
the standard field of view of 45 degrees ("FaintestAutoMag45deg")
between 6.0m and 12.0m.

2) The actual values of "FaintestAutoMag45deg" are displayed via the new flash
messages during the adjustments, such that the best values may
easily be found for each hardware configuration.

3) The optimal value may be permanently entered into the configuration
file, celestia.cfg, from where it is read upon startup.
By default, I have lowered that value now from 10.5 to 9.5, which
is still a decent compromise as to the star display, but increases
the fps significantly. Even 8.5m is not too bad...
------------------------

4) As before, the /actual/ limiting magnitudes are displayed via flash
messages if the field of view is zoomed by means of 'SHIFT Left mouse
dragging' or the ,(<) and .(>) keys.

5) Under Linux, the actual limiting magnitude is also displayed in the
GUI options dialog and may also be set from there. This works both
for AutoMag on and off.


Please let me know about any further suggestions in this context...

Bye Fridger

t00fri wrote:Inspired by discussions here in the forum, I have added the following
three AutoMag adjustments in the code (but not yet checked in):

1) If the automatic limiting magnitude setting (AutoMag) is active
(toggle CTRL+Y), the [ and ] keys now set the limiting magnitude at
the standard field of view of 45 degrees ("FaintestAutoMag45deg")
between 6.0m and 12.0m.

I think that the best thing to do would be calibrate automag so that it turning it on doesn't change the current limiting magnitude. But simply being able to control it with [ and ] is certainly an improvement.

3) The optimal value may be permanently entered into the configuration
file, celestia.cfg, from where it is read upon startup.
By default, I have lowered that value now from 10.5 to 9.5, which
is still a decent compromise as to the star display, but increases
the fps significantly. Even 8.5m is not too bad...

It would also be good to make it settable with the set command in a script. This is easy to do . . . just look up the implementation of the set command in command.cpp and cmdparser.cpp. I'm trying to move away from the putting more options in the celestia.cfg file, and toward setting them in the start.cel script. Celestia.cfg is where things like the star database, constellation list, etc. are specified. My idea is for the .cfg file to eventually become a command line parameter to make it easy to switch 'universes'--one .cfg file for the default 'real' universe, another one for a fantasy universe, another that loads the 2.5 million star database, etc.

--Chris

chris wrote:I think that the best thing to do would be calibrate automag so that it turning it on doesn't change the current limiting magnitude. But simply being able to control it with [ and ] is certainly an improvement.

The strategy you suggest does not sound really convincing to me. The
AutoMag limiting magnitude is designed according to entirely different criteria as the "fixed mag scheme" limiting magnitude.
Of course, at a given fov, one may require the AutoMag=on and AutoMag=off limiting mags to be equal by adjusting each time the limiting magnitude at 45deg. But this would somehow upset the whole scheme and would make it rather contrived...

In my present code, switching from
AutoMag=off to AutoMag=on resets the actual limiting magnitude to that corresponding to the AutoMag limiting magnitude at this fov for the /preset/ value of the limiting magnitude at 45deg. The latter may be adjusted, by means of the [,] keys.

But if you still prefer your way, I can surely restrict the changes to
my private Celestia version;-)

It would also be good to make it settable with the set command in a script. This is easy to do . . . just look up the implementation of the set command in command.cpp and cmdparser.cpp. I'm trying to move away from the putting more options in the celestia.cfg file, and toward setting them in the start.cel script. Celestia.cfg is where things like the star database, constellation list, etc. are specified. My idea is for the .cfg file to eventually become a command line parameter to make it easy to switch 'universes'--one .cfg file for the default 'real' universe, another one for a fantasy universe, another that loads the 2.5 million star database, etc

--Chris

Yes, I know how to incorporate options via *.cel scripts, I did quite a few more there for my own Celestia version...I agree, this is easy to do, but I am not sure whether the inexperienced users can handle parameter settings via *.cel scripts equally well. For me it does not make a difference, so I'll do it as soon as I find some time.

Unfortunately, I will be gone on a conference for the rest of the
week...and then I will be in England for a while.

Bye Fridger

chris wrote: My idea is for the .cfg file to eventually become a command line parameter to make it easy to switch 'universes'--one .cfg file for the default 'real' universe, another one for a fantasy universe, another that loads the 2.5 million star database, etc.

--Chris

This sounds great at first, but soon or later I think Celestia (and its programmers) will have to "confess" what Celestia's real purpose is to be;-)

"scientific", fantasy or game or...

As we say over here:

The "Eierlegendewollmilchsau" does not exist...

Bye Fridger

From a users point of view, I would tend to agree with Chris's point here. It feels more natural if switching on AutoMag would keep the limiting magnitude in the current field of view, and then change it according to your scheme when the fov changes. Similarly, when AutoMag is switched off it should just leave the limiting magnitude unchanged. I can't imagine it to be too difficult to normalise your scheme to the current magnitude?

I'm interested in how your scheme works. When I implemented a similar "lock-mag-to-fov" feature, I plainly counted the stellar space angle density at different limiting magnitudes as seen from Earth, fitted a function and inverted it to obtain the limiting magnitude for a given stellar space angel density. Is this how you also did it, or something more advanced? Your posts hint you made something more involved.

/Alexis

alexis wrote:From a users point of view, I would tend to agree with Chris's point here. It feels more natural if switching on AutoMag would keep the limiting magnitude in the current field of view, and then change it according to your scheme when the fov changes. Similarly, when AutoMag is switched off it should just leave the limiting magnitude unchanged. I can't imagine it to be too difficult to normalise your scheme to the current magnitude?

:?: I'm interested in how your scheme works. When I implemented a similar "lock-mag-to-fov" feature, I plainly counted the stellar space angle density at different limiting magnitudes as seen from Earth, fitted a function and inverted it to obtain the limiting magnitude for a given stellar space angel density. Is this how you also did it, or something more advanced? Your posts hint you made something more involved.

/Alexis

Chris' suggestion may appear more user friendly, but
actually it is not, at least for a certain kind of users;-). The 45deg limiting magnitude is just one
of several parameters. The actual limiting magnitude is a /non-linear/ function of the fov and the parameters also depend
significantly on the available catalogues , etc. My parameters that I incorporated into Xephem, for example, assume the Hubble guide star catalogue which means that the star density is ~ realistic up to mags of O(15-16)!

This is to illustrate that adapting the 45deg limiting magnitude at
each switching will upset the complex coordination of the various
(partly empirical parameter settings) and worse than a mediocre
compromise will be the result for many fov's...

Suppose I have set the limiting mag to 12m in the "fixed mag" scheme and now switch to Automag=on at 120 deg, since my screen is entirely /white/ there (2M stars);-). Chris' suggestion would mean that the AutoMag parameters are to be adjusted such that the limiting mag /remains/ crazy, i.e 12m at 120deg! This is simply not useful, sorry. In my case, there would be a reset to 6.5m, instead at 120deg, which is perfect.
This is what /I/ call user friendly...

Many people will not realize this at all;-) I do, however, and that is why I suggested to leave that part my code "private".

Bye Fridger

I take it you're on a tight time schedule, but we can discuss AutoMag further when you come back from England.

Let d(m) be the stellar space angle density d (e.g. "stars per square arc second") as a function of limiting magnitude m, and let m(d) be its inverse (it exists because d(m) is monotonous). With AutoMag you're interested in keeping the number of stars on screen approximately constant, that is f^2 * d(m) = c, where f is the field of view and c an arbitrary constant (proportional to the number of stars on screen).

Now, the scenario is as follows. The user has m and f in fixed mode when he turns on AutoMag. AutoMag computes c = f^2 * d(m). Then two things of interest to AutoMag may happen:

1) The user changes field of view to f': AutoMag calculates a new limiting magnitude m = m(c/f'^2).

2) The user changes limiting magnitude to m': AutoMag calculates a new density constant c = f^2 * d(m').

When user quits AutoMag, it leaves f and m unchanged. Now you tell me, what's so strange with this scheme.

If the user starts with m=12 and f=120, finds the screen completely white with stars, and then switch on AutoMag, well, changing the fov after would still keep the screen white of stars entirely consistent with your AutoMag idea. If the user wants a crazy number of stars on screen, let him. If he decides that m=12 and f=120 doesn't make sense, he can always change m, in perfect harmony with ordinary non-AutoMag operation.

t00fri wrote:This is to illustrate that adapting the 45deg limiting magnitude at each switching will upset the complex coordination of the various (partly empirical parameter settings) and worse than a mediocre compromise will be the result for many fov's...

When you find time, I would be interested in your AutoMag theory. It sounds to me as if you have parametrised d(m) and m(d) (defined above) in some unexpected way. Or you have proceeded along an entirely different path.

/Alexis