Thread: [Celestia-developers] Finishing 1.6.0
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Chris L. <cl...@gm...> - 2008-12-31 01:58:12
|
Please have a look at this list of items that need to be resolved before we can make the first Celestia 1.6.0 release candidate. As I see it, most remaining issues fall into three categories: 1. Globular Clusters Fridger, I know you have been working on this. Can you give your latest progress report? Here are the areas of globular cluster rendering that I believe are still in development: * Globular cluster scaling problems - Star sprites shouldn't be scaled by globular radius - Globulars seem to be larger than they should be * Globular clusters are culled too aggressively * Black stars in globular clusters at high zoom - Need to fix blending of stars in globular clusters (without messing up the brightness profiles.) 2. Translation Vincent, thanks for adopting this important area of Celestia development. I've been following your thread in the forum, and it looks like the translation work is proceeding well. According to the Wikipedia page, 7 translations are 100% complete. 9 more are > 90% complete, but it doesn't appear that any of these translations have been updated since the 1.5.1 release. Thus, it doesn't seem worth postponing a release to wait for further updates. Do es that seem reasonable? We could make a 1.6.1 release to incorporate further translation work if there are significant developments after 1.6.0. It's probably already clear, but we should definitely consider that Celestia is in the 'string freeze' phase of development (and has been for a while.) 3. Packaging * On Mac OS X, we need to make sure that user add-ons directories are working OK and that the new recommendations for installing add-ons are documented properly. * On Windows, I'd like to make it possible to install Celestia without being an administrator. This is becoming a real problem for people with limited rights on their computers. The only part of installation that requires administrator permissions is modifying the registry for the celx file type and cel URL associations. I'm trying to see if it's possible to get InnoSetup to make the required registry modifications globally if the user is an administrator and user-specific if he or she is not. Also, I'd like the Windows version of Celestia to look for add-ons in the user's APPDATA directory. This would allow users to install add-ons without having to modify the Celestia installation. This is basically the same thing that we're doing on Linux and the Mac. * On Linux: I think we're OK. Other things: - New Iapetus texture from Fridger - New Enceladus texture (Enceladus is the last major Saturnian satellite that still has a pre-Cassini map) - Add clarifications about the reference frames of the commented orbital and rotation elements in solarsys.ssc Have I forgotten anything? --Chris |
From: Steve P. <car...@ya...> - 2008-12-31 02:27:18
|
Chris, With linux, there is still a little problem with acinclude.m4.in. Line 897. It causes gtk and gnome builds to fail. I've been commenting this line out. Don't get me started with KDE and the newest build system available on openSuse11.1. That is broken for 11.1. Not sure if this is because of 11.1 or outdated code in Celestia. There is also that pesky bug thay affects all systems. Level11 and level12 VT's crash Celestia. Remember that 1 character change in lodspheremesh.cpp? Steve --- On Tue, 12/30/08, Chris Laurel <cl...@gm...> wrote: From: Chris Laurel <cl...@gm...> Subject: [Celestia-developers] Finishing 1.6.0 To: "Celestia Developers" <cel...@li...> Date: Tuesday, December 30, 2008, 8:49 PM Please have a look at this list of items that need to be resolved before we can make the first Celestia 1.6.0 release candidate. As I see it, most remaining issues fall into three categories: 1. Globular Clusters Fridger, I know you have been working on this. Can you give your latest progress report? Here are the areas of globular cluster rendering that I believe are still in development: * Globular cluster scaling problems - Star sprites shouldn't be scaled by globular radius - Globulars seem to be larger than they should be * Globular clusters are culled too aggressively * Black stars in globular clusters at high zoom - Need to fix blending of stars in globular clusters (without messing up the brightness profiles.) 2. Translation Vincent, thanks for adopting this important area of Celestia development. I've been following your thread in the forum, and it looks like the translation work is proceeding well. According to the Wikipedia page, 7 translations are 100% complete. 9 more are > 90% complete, but it doesn't appear that any of these translations have been updated since the 1.5.1 release. Thus, it doesn't seem worth postponing a release to wait for further updates. Do es that seem reasonable? We could make a 1.6.1 release to incorporate further translation work if there are significant developments after 1.6.0. It's probably already clear, but we should definitely consider that Celestia is in the 'string freeze' phase of development (and has been for a while.) 3. Packaging * On Mac OS X, we need to make sure that user add-ons directories are working OK and that the new recommendations for installing add-ons are documented properly. * On Windows, I'd like to make it possible to install Celestia without being an administrator. This is becoming a real problem for people with limited rights on their computers. The only part of installation that requires administrator permissions is modifying the registry for the celx file type and cel URL associations. I'm trying to see if it's possible to get InnoSetup to make the required registry modifications globally if the user is an administrator and user-specific if he or she is not. Also, I'd like the Windows version of Celestia to look for add-ons in the user's APPDATA directory. This would allow users to install add-ons without having to modify the Celestia installation. This is basically the same thing that we're doing on Linux and the Mac. * On Linux: I think we're OK. Other things: - New Iapetus texture from Fridger - New Enceladus texture (Enceladus is the last major Saturnian satellite that still has a pre-Cassini map) - Add clarifications about the reference frames of the commented orbital and rotation elements in solarsys.ssc Have I forgotten anything? --Chris ------------------------------------------------------------------------------ _______________________________________________ Celestia-developers mailing list Cel...@li... https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2009-01-02 18:36:28
|
Steve Popovich wrote: > With linux, there is still a little problem with acinclude.m4.in. Line > 897. It causes gtk and gnome builds to fail. I've been commenting this > line out. Don't get me started with KDE and the newest build system > available on openSuse11.1. That is broken for 11.1. Not sure if this is > because of 11.1 or outdated code in Celestia. I do believe I wrote to you about that being a misconfiguration on your end. You were using the wrong moc from the wrong version of Qt. I'm not overly worried about the acinclude problem, since it just means you're using the wrong version of autoconf. In the posted tarball, there will be a properly generated configure script anyway. --Pat |
From: Steve P. <car...@ya...> - 2009-01-02 19:25:06
|
There was quite a few people who had to comment out line 897 in acinclude.m4.in in order to build the gtk or gnome versions. http://www.shatters.net/forum/viewtopic.php?p=109988#p109988 Steve --- On Fri, 1/2/09, Pat Suwalski <pa...@su...> wrote: From: Pat Suwalski <pa...@su...> Subject: Re: [Celestia-developers] Finishing 1.6.0 To: car...@ya... Cc: "Celestia Developers" <cel...@li...>, "Chris Laurel" <cl...@gm...> Date: Friday, January 2, 2009, 1:36 PM Steve Popovich wrote: > With linux, there is still a little problem with acinclude.m4.in. Line 897. It causes gtk and gnome builds to fail. I've been commenting this line out. Don't get me started with KDE and the newest build system available on openSuse11.1. That is broken for 11.1. Not sure if this is because of 11.1 or outdated code in Celestia. I do believe I wrote to you about that being a misconfiguration on your end. You were using the wrong moc from the wrong version of Qt. I'm not overly worried about the acinclude problem, since it just means you're using the wrong version of autoconf. In the posted tarball, there will be a properly generated configure script anyway. --Pat |
From: Pat S. <pa...@su...> - 2009-01-02 20:46:41
|
Steve Popovich wrote: > There was quite a few people who had to comment out line 897 in > acinclude.m4.in in order to build the gtk or gnome versions. > http://www.shatters.net/forum/viewtopic.php?p=109988#p109988 Ah, very true. I just checked in a workaround. The problem was that it was doing a conditional check, but only if some KDE options were being set. So, I defined it explicitly in configure.in for now. --Pat |
From: vincent <vin...@fr...> - 2008-12-31 12:11:35
|
Chris Laurel wrote: > 2. Translation > Vincent, thanks for adopting this important area of Celestia > development. I've been following your thread in the forum, and it > looks like the translation work is proceeding well. According to the > Wikipedia page, 7 translations are 100% complete. 9 more are > 90% > complete, but it doesn't appear that any of these translations have > been updated since the 1.5.1 release. I just received the completed Romanian and Japanese translations, so for now, 9 translations are 100% complete. I should also receive the German and Italian translation files in the incoming days. > Thus, it doesn't seem worth > postponing a release to wait for further updates. Do es that seem > reasonable? We could make a 1.6.1 release to incorporate further > translation work if there are significant developments after 1.6.0. I didn't get any news from other translators, so that definitely sounds reasonnable to me. Now, there is still the issue about the translation of alternative names for ssc bodies that need to be adressed. Unless we find a fix very soon, this can be delayed to the 1.6.1 release too. > It's probably already clear, but we should definitely consider that > Celestia is in the 'string freeze' phase of development (and has been > for a while.) Yes, the string freeze phase was 'officially' declared at the end of october. @+ Vincent > 3. Packaging > > * On Mac OS X, we need to make sure that user add-ons directories are > working OK and that the new recommendations for installing add-ons are > documented properly. > > * On Windows, I'd like to make it possible to install Celestia without > being an administrator. This is becoming a real problem for people > with limited rights on their computers. The only part of installation > that requires administrator permissions is modifying the registry for > the celx file type and cel URL associations. I'm trying to see if it's > possible to get InnoSetup to make the required registry modifications > globally if the user is an administrator and user-specific if he or > she is not. Also, I'd like the Windows version of Celestia to look for > add-ons in the user's APPDATA directory. This would allow users to > install add-ons without having to modify the Celestia installation. > This is basically the same thing that we're doing on Linux and the > Mac. > > * On Linux: I think we're OK. > > > Other things: > > - New Iapetus texture from Fridger > - New Enceladus texture (Enceladus is the last major Saturnian > satellite that still has a pre-Cassini map) > - Add clarifications about the reference frames of the commented > orbital and rotation elements in solarsys.ssc > > Have I forgotten anything? > > --Chris > > ------------------------------------------------------------------------------ > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Martin C. <mar...@sy...> - 2008-12-31 15:50:54
|
> 3. Packaging > > * On Mac OS X, we need to make sure that user add-ons directories are > working OK and that the new recommendations for installing add-ons are > documented properly. Chris, the new OS X directory structure is highly unsatisfaying. I still strongly feel that hiding stuff inside the application is a mistake. The only files that I agree that should be located inside the application are these : - "logo.png" file - "shaders" folder (with all its files) - "fonts" folder (with all its files). All the rest should stay clearly accessible to any user. The user should have a choice : place its "CelestiaResources" folder inside the Library folder (in the apps support folder), or next to the app itself (which is what I prefer). I already gave many reasons before, why it's highly preferable to leave the folowing files and folders of easy access, OUTSIDE the app : - "models" folder - "data" folder - "scripts" folder - "celestia.cfg" file - "extras" folder - "textures" folder - "start.celx" file -Martin. |
From: Chris L. <cl...@gm...> - 2008-12-31 17:16:53
|
Martin, The files will remain inside the app. I've given many reasons why this is the right approach. It is the *standard* organization for Mac applications, and there's nothing special about Celestia that makes it necessary to do something different. We will make efforts to make sure that the new organization works, is easy to use, and is well-documented. --Chris On Wed, Dec 31, 2008 at 7:50 AM, Martin Charest <mar...@sy...>wrote: > > 3. Packaging > > > * On Mac OS X, we need to make sure that user add-ons directories are > > working OK and that the new recommendations for installing add-ons are > > documented properly. > > > Chris, > > the new OS X directory structure is highly unsatisfaying. I still strongly > feel that hiding stuff inside the application is a mistake. The only files > that I agree that should be located inside the application are these : > > - "logo.png" file > - "shaders" folder (with all its files) > - "fonts" folder (with all its files). > > All the rest should stay clearly accessible to any user. The user should > have a choice : place its "CelestiaResources" folder inside the Library > folder (in the apps support folder), or next to the app itself (which is > what I prefer). I already gave many reasons before, why it's highly > preferable to leave the folowing files and folders of easy access, OUTSIDE > the app : > > - "models" folder > - "data" folder > - "scripts" folder > - "celestia.cfg" file > - "extras" folder > - "textures" folder > - "start.celx" file > > > > -Martin. > > > > > |
From: Martin C. <mar...@sy...> - 2008-12-31 17:36:43
|
> Martin, > > The files will remain inside the app. I've given many reasons why > this is the right approach. It is the *standard* organization for > Mac applications, and there's nothing special about Celestia that > makes it necessary to do something different. We will make efforts > to make sure that the new organization works, is easy to use, and > is well-documented. > > --Chris Chris, I don't agree. There are files, and there are files ! Some needs to be placed inside the app, some don't. I have TONS of Mac OS X apps on my computer, and have used Macs since years (actually, since the first Mac+ around 1984 !). Most of my apps don't even use the library folder at all, except for their preferences file. For example, Photoshop is using the library for some registration and preferences files, but its plug-ins folder is sitting next to the app itself. Not inside, not even in the Library/apps support ! And yet, most users don't even mess with that folder. I can give you many examples of OS X applications which are using different organisations on OS X. Cheetah3D is another good example, which places files at several locations, while most of them are sitting next to the app (ressources files, plug-ins, help files, etc). The main problem to me is this : I'm using several hundreds MB of files (textures and models) in the standard folder, since many addons are using the same files. I don't want to duplicate all these files for each addon, since this would end in several GB on the HD. Placing all these files inside the app would give a monster app. This is the main reason why I'm asking to leave the Ressources folder outside the app. But since you already decided the new organisation once and for all, without even asking the OS X users, I'm now forced to leave the Celestia community. I'm unable to accept that change, because of all the complications it's implying. So from now on, I'll stop producing any new addon for Celestia. Nomore test and bug repports, suggestions, etc. I'll announce my departure from the community on the forum during the following days. I'm really sorry that we came to this state. -Martin. |
From: Chris L. <cl...@gm...> - 2008-12-31 19:38:51
|
On Wed, Dec 31, 2008 at 9:36 AM, Martin Charest <mar...@sy...>wrote: > Martin, > > The files will remain inside the app. I've given many reasons why this is > the right approach. It is the *standard* organization for Mac applications, > and there's nothing special about Celestia that makes it necessary to do > something different. We will make efforts to make sure that the new > organization works, is easy to use, and is well-documented. > > --Chris > > > Chris, I don't agree. There are files, and there are files ! Some needs > to be placed inside the app, some don't. I have TONS of Mac OS X apps on my > computer, and have used Macs since years (actually, since the first Mac+ > around 1984 !). Most of my apps don't even use the library folder at all, > except for their preferences file. For example, Photoshop is using the > library for some registration and preferences files, but its plug-ins folder > is sitting next to the app itself. Not inside, not even in the Library/apps > support ! And yet, most users don't even mess with that folder. I can give > you many examples of OS X applications which are using different > organisations on OS X. Cheetah3D is another good example, which places > files at several locations, while most of them are sitting next to the app > (ressources files, plug-ins, help files, etc). > We could put the Celestia files in /Library/Celestia. But, the drawback to this approach is that an installer is necessary to copy the files here. It's better if Celestia can be run right from a disk image without installation. This is a better user experience, and we don't have to invest the time in creating a Mac installer. Also, the Library folder is almost as invisible to the average user as the application folder. The main problem to me is this : I'm using several hundreds MB of files > (textures and models) in the standard folder, since many addons are using > the same files. I don't want to duplicate all these files for each addon, > since this would end in several GB on the HD. Placing all these files > inside the app would give a monster app. This is the main reason why I'm > asking to leave the Ressources folder outside the app. > So what if the app folder gets large? That shouldn't cause any problems. Just copy the files there and you'll be fine. > But since you already decided the new organisation once and for all, > without even asking the OS X users, I'm now forced to leave the Celestia > community. I'm unable to accept that change, because of all the > complications it's implying. So from now on, I'll stop producing any new > addon for Celestia. Nomore test and bug repports, suggestions, etc. I'll > announce my departure from the community on the forum during the following > days. I'm really sorry that we came to this state. > Two points: DW was the one who implemented the new organization. I *have* weighed your opinions (and those of other Mac users) and reached the conclusion that DW made a good choice with the new packaging. So please don't think that you've been ignored on this. There is still some opportunity for compromise. But, the following things will not change for 1.6.0: - Installing and running the application must be a one-click operation. Requiring the user to manually copy the CelestiaResources folder into their home directory is *not* an option--it's clunky, and only installs the app for a single user. - The primary location for add-ons must be a location in user's home directory (or subdirectory of it.) --Chris |
From: Martin C. <mar...@sy...> - 2008-12-31 20:19:22
|
Chris said : > The main problem to me is this : I'm using several hundreds MB of > files (textures and models) in the standard folder, since many > addons are using the same files. I don't want to duplicate all > these files for each addon, since this would end in several GB on > the HD. Placing all these files inside the app would give a > monster app. This is the main reason why I'm asking to leave the > Ressources folder outside the app. > > So what if the app folder gets large? That shouldn't cause any > problems. Just copy the files there and you'll be fine. The problem will be the upgrades. I will have to remove all my files from inside the app, then place the new app, and then replace back all the ressources inside the new app. For every upgrade. The risk of error is very high and it isn't an elegant procedure. I'm also constantly upgrading the data files directly from SVN, without changing the app (of course, I know what I'm doing). I'll then have to dig inside the app itself to replace the files (I can live with this, though). And if the addons folders are located in the user's Library folder, I'll have my files splited in two parts : the Library, and inside the app. To me, it's a mess. I also have to frequently edit my config and start.celx files (and so the new users). Where are they supposed to be located now ? And managing the computers at my work place will be a pain in the butt. I'll have to frequently add some ressources to the installation there. Especially since I now have to build a new astrophysics course at my institution, using Celestia. Giving some small addons to my students (by email, for their homeworks) may be complicated : I'm not even sure I'll do that anyway, since the students may have all sorts of technical problems with them on their home computer. If the managing process gets too complicated in the computer lab (considering the bad technical support there), I may have to change the astronomy app, using a poor Stellarium or GoogleEarth like app, or something else >:-( This is the last thing I want to do. I see one solution to get out of this mess : make the app smart enough to recognise a ressource folder placed next to the app (anywhere on the user's directory), in the Library folder too, and inside the app itself, with a priority hierarchy for loading at launch time (in case of duplicates). If the ressource folder isn't in the app (I'll remove it from there), Celestia find and loads the one located in the Library. If none is there, then it loads the one sitting next to the app itself. The user could then remove the internal ressource folder from the app itself, so all the ressources are located next to the app with all his addons (as with the previous versions). That way, the user could setup the best configuration on his computer, according to taste and experience. Of course, if no ressources folder is found inside the app, in the Library folder and next to the app, Celestia should report an error at launch time and gracefully quit after the user press the button on the error dialog box. -Martin. |
From: Da W. J. <dir...@gm...> - 2009-01-01 01:17:17
|
Celestia already does what you're suggesting, at least if I implemented things correctly. It looks for CelestiaResources inside the app, then beside the app, then in the Library folders of the user and system (user first). DW On Thu, Jan 1, 2009 at 5:19 AM, Martin Charest wrote: > > I see one solution to get out of this mess : make the app smart enough to > recognise a ressource folder placed next to the app (anywhere on the user's > directory), in the Library folder too, and inside the app itself, with a > priority hierarchy for loading at launch time (in case of duplicates). If > the ressource folder isn't in the app (I'll remove it from there), Celestia > find and loads the one located in the Library. If none is there, then it > loads the one sitting next to the app itself. The user could then remove > the internal ressource folder from the app itself, so all the ressources are > located next to the app with all his addons (as with the previous versions). > That way, the user could setup the best configuration on his computer, > according to taste and experience. Of course, if no ressources folder is > found inside the app, in the Library folder and next to the app, Celestia > should report an error at launch time and gracefully quit after the user > press the button on the error dialog box. |
From: Martin C. <mar...@sy...> - 2009-01-01 01:47:13
|
> Celestia already does what you're suggesting, at least if I > implemented things correctly. > It looks for CelestiaResources inside the app, then beside the app, > then in the Library folders of the user and system (user first). > > DW > > On Thu, Jan 1, 2009 at 5:19 AM, Martin Charest wrote: >> >> I see one solution to get out of this mess : make the app smart >> enough to >> recognise a ressource folder placed next to the app (anywhere on >> the user's >> directory), in the Library folder too, and inside the app itself, >> with a >> priority hierarchy for loading at launch time (in case of >> duplicates). If >> the ressource folder isn't in the app (I'll remove it from there), >> Celestia >> find and loads the one located in the Library. If none is there, >> then it >> loads the one sitting next to the app itself. The user could then >> remove >> the internal ressource folder from the app itself, so all the >> ressources are >> located next to the app with all his addons (as with the previous >> versions). >> That way, the user could setup the best configuration on his >> computer, >> according to taste and experience. Of course, if no ressources >> folder is >> found inside the app, in the Library folder and next to the app, >> Celestia >> should report an error at launch time and gracefully quit after >> the user >> press the button on the error dialog box. I also suggest another solution : lets define a field in Celestia's preferences window, so the user could tell Celestia what Ressources folder to use by default on his HD. An empty field would mean to use the default folder located inside the application. This way, the Ressources folder could be located anywhere. -Martin. |
From: Martin C. <mar...@sy...> - 2009-01-02 00:04:17
|
> Celestia already does what you're suggesting, at least if I > implemented things correctly. > It looks for CelestiaResources inside the app, then beside the app, > then in the Library folders of the user and system (user first). > Yep, it appears to work ! Removing the Ressources folder from inside the app, placing it in the same folder as the app itself works ! THANKS !! 8-) Now, this is a huge problem solved ! Now, I already noticed two glitches after 30 sec of play : - Clicking on the splash screen while Celestia is loading gives a system beep ! ??? (OS X version) - There's a contextual menu item which isn't translated to French : "Reference Marks" (while the sub-menu content is properly translated). It should read something like "Éléments de référence". -Martin. |
From: Martin C. <mar...@sy...> - 2009-01-02 00:07:25
|
About finishing Celestia 1.6.0, I suggest to remove completely the Demo menu item and free the "D" key. The Demo is a script and should be presented in the script sub-menu, IMHO. Oh, and HAPPY NEW YEAR 2009 ! ;-) -Martin. |
From: Martin C. <mar...@sy...> - 2009-01-02 00:14:39
|
... and what about that useless "flare.jpg" file in the textures folder ? Should be removed, I presume. -Martin. |
From: Fridger S. <fri...@de...> - 2009-01-01 15:32:15
|
Chris, -- Happy New Year! -- Unfortunately my update schedule on the globulars was much delayed by my forced absence from home during the last 3.5 weeks, as I wrote to you about. -- Although I had only very little time for coding during the last 4 weeks for the reasons mentioned, I am essentially done. Fortunately, the hardest part was completed before that period. Chris Laurel wrote: > Please have a look at this list of items that need to be resolved > before we can make the first Celestia 1.6.0 release candidate. As I > see it, most remaining issues fall into three categories: > > 1. Globular Clusters > Fridger, I know you have been working on this. Can you give your > latest progress report? Here are the areas of globular cluster > rendering that I believe are still in development: > > * Globular cluster scaling problems > - Star sprites shouldn't be scaled by globular radius > - Globulars seem to be larger than they should be -- The globular size issue was completely and elegantly resolved. I invented and used a new highly efficient statistical generation method of sprite stars (according to the exact King profile) out to the largest distances < r_t. This part I completed already before leaving Hamburg and explained it to you in private. My original /approximate/ rescaling method, using only the inner generated King profile for efficiency reasons, has thus been entirely replaced. -- The actual size scaling of globulars in Celestia was extensively tested by means of ringed custom "galaxy" templates using the independent /galaxy/ rendering code. -- the maximal star sprite radius is now of a fixed size, a factor of >~ 10 smaller than originally. That size (red giants) is still considerably larger than the typical physical red giant size, since -- the dynamical range of displays is so poor and -- for reasons of performance. This remaining radius exaggeration is closely related to the familiar /general/ problem of rendering stars in Celestia that are to cover >23 orders (!) of magnitude in brightness! For normal Celestia stars, this problem does not arise so badly (still badly enough!), since the HIP star data base happens to end around stars of 9th mag. already ;-). In contrast, the globular cluster stars cover a much larger and MUCH fainter range of app. mags down to m ~ 23, as I wrote to you. Here is a reminder of the /measured/ visual app. mag distribution of M 13 stars for example http://www.shatters.net/~t00fri/images/ngc6205cmd.jpg (taken from the authoritative ground-based database: http://dipastro.pd.astro.it/globulars/databases/ground/grnd-database.html) The second reason for exaggerating the star sprite radius is to compensate for the fact that the number of distinct globular stars in Celestia has to be MUCH smaller (< 8192) than in reality ( 10^4 .. 10^7!!) for reasons of performance! -- I resolved the visual mismatch of the mu25-isophote-radius-based red selection cursor size with the new /apparent/ globular size in Celestia (see previous problematics, since the mu25 isophote radius strongly depends on faint stars that cannot be rendered). Here is what I did after our respective private discussion: I retained the mu25 isophote radius in the display of the /scientific physical/ cluster radius (top left on canvas). However, for the red selection cursor display, I used the approximate formula for the half-mass radius ~= half-light radius in terms of the available r_c and c parameters (method: getHalfMassRadius()). This looks good throughout, since the 4 red selection cursor arrows now specify the /apparent/ visual globular size to good approximation in Celestia! Compared to the mu25 isophote radius, the half-mass radius is MUCH less dependent on cluster stars too faint (or too numerous) to be rendered in Celestia... This new code is also finished and tested. That's what I could do so far after my return to Hamburg. > * Globular clusters are culled too aggressively Don't remember what's on your mind here?? > * Black stars in globular clusters at high zoom > - Need to fix blending of stars in globular clusters (without messing up > the brightness profiles.) After plenty of respective experiments, I decided that your suggested blending patch was presently the best /compromise/, albeit being not entirely correct for the star sprite distribution, as you also noted. So, at least the black stars are gone. ;-) . I would be happy however, if after all my efforts, a blending scheme could be implemented eventually that does NOT distort the King profile to some extent... > Other things: > > - New Iapetus texture from Fridger That texture I will commit very soon to SVN, once there are no further suggestions for improvement from users (or myself ;-)) anymore. > Have I forgotten anything? As I wrote to you earlier: Since your red selection arrows are along 0 and 90 degrees in screen coordinates, there is often a /nasty overlap/ of your arrows with the DSO names that are displayed along the 0 degree axis (i.e. horizontally)! I suggest therefore to rotate your four red arrows by 45 degrees! This might also improve aliasing effects... --------------------------- Planning: As soon as I get some more coherent hours of working on the globular project, I will be able to finish off the update and submit the patch. Unfortunately, for various reasons you might guess, my available time is still uncertain. Currently, I am trying to improve the visual experience when flying across the globular core. Apart from this little task, only the implementation of the code into the latest SVN version remains to be done along with a final code inspection, which is not too much work. Let me know what schedule for the first 1.6.0 release candidate you have in mind. I'll try to fit in as much as currently possible... Fridger |
From: Fridger S. <fri...@de...> - 2009-01-01 17:49:26
|
Chris, Christian (aka Guckytos) has asked me to cross-check the README file in SNV which he is currently revising. In his PM to me, he was mainly interested to get feedback from me as to my own work related to texture creation for Celestia in the "Other Contributors" section. When reading across that file, I stumbled over various issues that should be discussed here and eventually be modified, I think: -- under CELESTIA RESOURCES, I noted: ** Christophe Teyssier's site was inaccessible for many months. Since a few days, it is now used for things /unrelated/ to Celestia. Hence, that reference should be deleted now. Have a look ... All this does not affect my deep concern about what happened to Christophe Teyssier since his last appearance on March 27!? ** Pat Suwalski's site really does NOT offer any concrete resources about Celestia apart from some screenshots. That site has not been updated since a long long time. It is stated there that the current Celestia version is 1.4.1!! Again, unless Pat fills it significant content about Celestia before 1.6.0 is due, the link to this site should be deleted. -- next I feel since a long time that the whole /logical/ setup of the README file is strange... ** first question: who really thanks whom in README? After assigning now correctly the Celestia Copyright to "The Celestia Development Team", should it be still Chris Laurel who signs the README or rather "The Celestia Development Team"? ** under "Further Contributors", a large number of credits go to official /co-authors/ (Grant, myself) of Celestia and members of "The Celestia Development Team" (Andrew, Grant, myself), which all seems /logically/ inappropriate to me. I have never seen a (scientific) publication, where one author thanks his co-authors for their contributions to that publication!! ;-). Really this is absurd... ** My proposal therefore would rather be to modify the misleading heading "Other Contributors" appropriately. There should instead be a section where the creators of the Celestia textures and other resources are listed along with the scientific data on which they were based. However, NOT in form of credits from Chris, but as an /exhaustive documentation listing/ of the used resources and the people who sign /responsible/ for the resulting textures. Special thanks can of course be added to contributors who are not Devs and|or co-authors. ** for better structuring of the references to "Celestia Resources", one might want to introduce further subsections, like "Textures and Models", "Data Base" etc... Moreover, it should be settled what further major contributions of Devs should be included in README. Andrew's thorough reworking of the star data base for example, Grant's and my extensive work on the planetary and DSO data base? Vincent's work on celx and internationalization? It seems important to provide this way a /direct/ interface to the responsible people (emails!) in case of questions, bug reports, suggestions by Celestia users... Before getting to missing details like e.g. my new Iapetus texture reference, we should bring the logical structure of the README into a cleaner form. My main concern is that all this is done in a /self-consistent/ manner. Fridger |
From: Chris L. <cl...@gm...> - 2009-01-03 20:07:34
|
On Thu, Jan 1, 2009 at 9:49 AM, Fridger Schrempp <fri...@de...>wrote: > Chris, > > Christian (aka Guckytos) has asked me to cross-check the README file in SNV > which he is currently revising. In his PM to me, he was mainly interested to > get feedback from me as to my own work related to texture creation for > Celestia in the "Other Contributors" section. > > When reading across that file, I stumbled over various issues that should > be discussed here and eventually be modified, I think: > > -- under CELESTIA RESOURCES, I noted: > > ** Christophe Teyssier's site was inaccessible for many months. Since a > few > days, it is now used for things /unrelated/ to Celestia. Hence, that > reference should be deleted now. Have a look ... > > All this does not affect my deep concern about what happened to > Christophe Teyssier since his last appearance on March 27!? > > ** Pat Suwalski's site really does NOT offer any concrete resources about > Celestia apart from some screenshots. That site has not been updated > since a long long time. It is stated there that the current Celestia > version is 1.4.1!! > > Again, unless Pat fills it significant content about Celestia > before 1.6.0 is due, the link to this site should be deleted. I'll let Pat address this one--if he'd like his site to remain in the README, I'm happy to leave it there. But the version number on the web page should be updated :) > > -- next I feel since a long time that the whole /logical/ setup of the > README > file is strange... > > ** first question: who really thanks whom in README? > > After assigning now correctly the Celestia Copyright to "The Celestia > Development Team", should it be still Chris Laurel who signs the > README > or rather "The Celestia Development Team"? Agreed. My name and email address should be removed from the end of the file. Somewhere in the README, I'd still like credit for starting Celestia, but the thank yous should be from the Celestia Development Team > > ** under "Further Contributors", a large number of credits go to > official /co-authors/ (Grant, myself) of Celestia and members of "The > Celestia Development Team" (Andrew, Grant, myself), which all seems > /logically/ inappropriate to me. > > I have never seen a (scientific) publication, where one author thanks > his co-authors for their contributions to that publication!! ;-). > Really this is absurd... > > ** My proposal therefore would rather be to modify the misleading > heading > "Other Contributors" appropriately. There should instead be a section > where the creators of the Celestia textures and other resources are > listed along with the scientific data on which they were based. > > However, NOT in form of credits from Chris, but as an > /exhaustive documentation listing/ of the used resources and the > people > who sign /responsible/ for the resulting textures. Special thanks > can of course be added to contributors who are not Devs and|or > co-authors. Agreed. "Other Contributors" is not the right heading, so let's remove that and just have a list of sources for the textures, models, and other data used in Celestia. > > ** for better structuring of the references to "Celestia Resources", one > might want to introduce further subsections, like "Textures and > Models", "Data Base" etc... I made this same suggestion to Christian. The sections could be Textures, Models, and Catalog Files. Moreover, it should be settled what further major contributions of > Devs > should be included in README. Andrew's thorough reworking of the star > data base for example, Grant's and my extensive work on the planetary > and DSO data base? Vincent's work on celx and internationalization? > > It seems important to provide this way a /direct/ interface to the > responsible people (emails!) in case of questions, bug reports, > suggestions by Celestia users... That sounds reasonable to me. --Chris |
From: Pat S. <pa...@su...> - 2009-01-04 00:36:46
|
Chris Laurel wrote: > I'll let Pat address this one--if he'd like his site to remain in the > README, I'm happy to leave it there. But the version number on the web > page should be updated :) I'll side with Fridger on this one. If the readme is to be modified anyway, go ahead and remove it. --Pat |
From: Andrew T. <ajt...@go...> - 2009-01-04 13:11:18
|
There are various other files that should be checked - are the AUTHORS and TRANSLATORS files up-to-date? What about the TODO file - perhaps the contents of that file should be replaced with a link to the SVN buglist/feature requests? Andrew 2009/1/4 Pat Suwalski <pa...@su...>: > Chris Laurel wrote: >> I'll let Pat address this one--if he'd like his site to remain in the >> README, I'm happy to leave it there. But the version number on the web >> page should be updated :) > > I'll side with Fridger on this one. If the readme is to be modified > anyway, go ahead and remove it. > > --Pat > > ------------------------------------------------------------------------------ > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: vincent <vin...@fr...> - 2009-01-04 13:34:31
|
Andrew wrote: > There are various other files that should be checked - are the AUTHORS > and TRANSLATORS files up-to-date? I'm planning to update the TRANSLATORS file when the translation process is over. That should be done in a couple of days. I have a question about the utility of this file, though: is it meant to credit all translators, or to keep the contact of currently active translators? In the first case, we should keep the names of all translators for a specific language, whereas in the second case, only the name of the latest translator should appear. @+ Vincent > 2009/1/4 Pat Suwalski <pa...@su...>: > > Chris Laurel wrote: > >> I'll let Pat address this one--if he'd like his site to remain in the > >> README, I'm happy to leave it there. But the version number on the web > >> page should be updated :) > > > > I'll side with Fridger on this one. If the readme is to be modified > > anyway, go ahead and remove it. > > > > --Pat > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Celestia-developers mailing list > > Cel...@li... > > https://lists.sourceforge.net/lists/listinfo/celestia-developers > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: PR@Celestia <pr-...@ar...> - 2009-01-04 17:58:16
Attachments:
README_Redesign
|
Hi guys, here is an updated version of the README with a new design for the credits. Please take a look and tell me what you think about it. Pat, I have removed the reference to your site. Best regards, Christian vincent schrieb: > Andrew wrote: > >> There are various other files that should be checked - are the AUTHORS >> and TRANSLATORS files up-to-date? > > I'm planning to update the TRANSLATORS file when the translation process > is over. That should be done in a couple of days. I have a question about > the utility of this file, though: is it meant to credit all translators, > or to keep the contact of currently active translators? In the first case, > we should keep the names of all translators for a specific language, whereas > in the second case, only the name of the latest translator should appear. > > @+ > Vincent > > >> 2009/1/4 Pat Suwalski <pa...@su...>: >>> Chris Laurel wrote: >>>> I'll let Pat address this one--if he'd like his site to remain in the >>>> README, I'm happy to leave it there. But the version number on the web >>>> page should be updated :) >>> I'll side with Fridger on this one. If the readme is to be modified >>> anyway, go ahead and remove it. >>> >>> --Pat >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2009-01-04 20:52:27
|
Hi Christian, logically I find your new setup of the README already much better than the old one. Here are a few smaller remaining issues and proposals for improvement: *** I think the authors of Celestia deserve to be mentioned here explicitly, too, after everybody else is named ... It takes an additional effort to load the AUTHORS file, which will be skipped by many! *** There is a apparent (visual) "hierarchy clash" between the "Texture maps" header and the subsequent names of the people who made texture contributions /under/ that header. You might want to invent a modified heading style to make clear that the people are hierarchically /below/ the "Texture maps" header and not on equal footing. *** To me there is no logical reason why the /texture/ resources and their creators are to be mentioned explicitly, while the people who did most extensive work on the Celestia /scientific data base/ are not even mentioned. Let alone, the respective scientific catalog references remain entirely "in the dark". This would mainly concern: Grant Hutchison: ---------------- lots of stuff over the years... solarsys.ssc, nearstars.stc, extrasolar.ssc, extrasolar.stc, earth_locs.ssc, ... The reference to Grant H. under "Other work" should then go here! Andrew Tribick: --------------- -- significant update of the star.dat base based on new HIP Reduction of the Raw data, Floor van Leeuwen, 2007. -- CHARM2 stellar radii (charm2.stc) Fridger Schrempp: ----------------- -- complete NGC/IC galaxy database + local group galaxies (galaxies.dsc), -- data base on globular clusters (globulars.dsc), -- data base on visual and spectroscopic binaries (visualbins.stc, spectbins.stc), -- world-capitals.ssc, -- asterisms.dat. The scientific sources are precisely listed in the boiler plates of my respective data files. *** Since you have a header named "Thanks" (the correct wording in scientific publications would rather be "Acknowledgements"), I suggest to place the credits for the "Father of Celestia" in there on first position! Like so: Acknowledgements: ('Credits' would also be OK) ----------------- Chris Laurel started this program in the year 2001 (wording should be somewhat more enthusiastic! ;-) ) <cl...@gm...> http://www.shatters.net/~claurel/ http://www.shatters.net/celestia/ A special thank you goes to (better: Special thanks go to...) all Celestia users who submit bug reports, suggestions, and fixes. Celestia wouldn't be the program it is today, without your (better: their) help. The Celestia Development Team Cheers, Fridger PR@Celestia wrote: > Hi guys, > > here is an updated version of the README with a new design for the > credits. Please take a look and tell me what you think about it. > > Pat, I have removed the reference to your site. > > Best regards, > > Christian > > > vincent schrieb: >> Andrew wrote: >> >>> There are various other files that should be checked - are the AUTHORS >>> and TRANSLATORS files up-to-date? >> >> I'm planning to update the TRANSLATORS file when the translation process >> is over. That should be done in a couple of days. I have a question about >> the utility of this file, though: is it meant to credit all translators, >> or to keep the contact of currently active translators? In the first >> case, >> we should keep the names of all translators for a specific language, >> whereas >> in the second case, only the name of the latest translator should appear. >> >> @+ >> Vincent >> >> >>> 2009/1/4 Pat Suwalski <pa...@su...>: >>>> Chris Laurel wrote: >>>>> I'll let Pat address this one--if he'd like his site to remain in the >>>>> README, I'm happy to leave it there. But the version number on the web >>>>> page should be updated :) >>>> I'll side with Fridger on this one. If the readme is to be modified >>>> anyway, go ahead and remove it. >>>> >>>> --Pat >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: PR@Celestia <pr-...@ar...> - 2009-01-05 18:37:02
Attachments:
README_Redesign2
|
Hi Fridger, thanks for your feedback. Okay, I think I have tsckeld most of the points you mentioned. If I have forgotten someones contributions, please tell me so, and I will include them (of course only if someone tells me what they did, as I don't know for most things, up to now I was just an ignorant user ;-) ) See attached file Regards, Christian Fridger Schrempp schrieb: > Hi Christian, > > logically I find your new setup of the README already much better than the old > one. Here are a few smaller remaining issues and proposals for improvement: > > *** I think the authors of Celestia deserve to be mentioned here explicitly, > too, after everybody else is named ... It takes an additional effort to > load the AUTHORS file, which will be skipped by many! > > *** There is a apparent (visual) "hierarchy clash" between the "Texture maps" > header and the subsequent names of the people who made texture > contributions /under/ that header. You might want to invent a modified > heading style to make clear that the people are hierarchically /below/ the > "Texture maps" header and not on equal footing. > > *** To me there is no logical reason why the /texture/ resources and their > creators are to be mentioned explicitly, while the people who did > most extensive work on the Celestia /scientific data base/ are not even > mentioned. Let alone, the respective scientific catalog references remain > entirely "in the dark". > > This would mainly concern: > > Grant Hutchison: > ---------------- > lots of stuff over the years... solarsys.ssc, nearstars.stc, extrasolar.ssc, > extrasolar.stc, earth_locs.ssc, ... > > The reference to Grant H. under "Other work" should then go here! > > Andrew Tribick: > --------------- > -- significant update of the star.dat base based on new HIP Reduction of the > Raw data, Floor van Leeuwen, 2007. > -- CHARM2 stellar radii (charm2.stc) > > Fridger Schrempp: > ----------------- > -- complete NGC/IC galaxy database + local group galaxies (galaxies.dsc), > -- data base on globular clusters (globulars.dsc), > -- data base on visual and spectroscopic binaries > (visualbins.stc, spectbins.stc), > -- world-capitals.ssc, > -- asterisms.dat. > > The scientific sources are precisely listed in the boiler plates of my > respective data files. > > *** Since you have a header named "Thanks" (the correct wording in scientific > publications would rather be "Acknowledgements"), I suggest to place the > credits for the "Father of Celestia" in there on first position! Like so: > > Acknowledgements: ('Credits' would also be OK) > ----------------- > > Chris Laurel started this program in the year 2001 (wording should be somewhat > more enthusiastic! ;-) ) > <cl...@gm...> > http://www.shatters.net/~claurel/ > http://www.shatters.net/celestia/ > > A special thank you goes to (better: Special thanks go to...) all Celestia > users who submit bug reports, suggestions, and fixes. Celestia wouldn't be the > program it is today, without your (better: their) help. > > > The Celestia Development Team > > > Cheers, > Fridger > > > PR@Celestia wrote: >> Hi guys, >> >> here is an updated version of the README with a new design for the >> credits. Please take a look and tell me what you think about it. >> >> Pat, I have removed the reference to your site. >> >> Best regards, >> >> Christian >> >> >> vincent schrieb: >>> Andrew wrote: >>> >>>> There are various other files that should be checked - are the AUTHORS >>>> and TRANSLATORS files up-to-date? >>> I'm planning to update the TRANSLATORS file when the translation process >>> is over. That should be done in a couple of days. I have a question about >>> the utility of this file, though: is it meant to credit all translators, >>> or to keep the contact of currently active translators? In the first >>> case, >>> we should keep the names of all translators for a specific language, >>> whereas >>> in the second case, only the name of the latest translator should appear. >>> >>> @+ >>> Vincent >>> >>> >>>> 2009/1/4 Pat Suwalski <pa...@su...>: >>>>> Chris Laurel wrote: >>>>>> I'll let Pat address this one--if he'd like his site to remain in the >>>>>> README, I'm happy to leave it there. But the version number on the web >>>>>> page should be updated :) >>>>> I'll side with Fridger on this one. If the readme is to be modified >>>>> anyway, go ahead and remove it. >>>>> >>>>> --Pat >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > |