From: Georg Z. <geo...@un...> - 2011-10-20 14:28:26
|
Dear core team, I finally found some time again to work on extinction, please see my extinction branch, based on trunk 4970. Currently it works for all point-like sources (stars (I finally got it!), planet "halos", satellites, minor planets, comets. Those are dimmed (getVmagnitude()), and I also changed the infostrings accordingly. I propose a different solution for the magnitudes of the planets, and implemented the ring dependency of Saturn's brightness. I also changed skyDrawer so that light pollution is switched off (BortleIndex=1) if atmosphere is off. What is missing: extinction for extended objects: Milky Way and nebula images. This requires OpenGL knowledge surpassing mine. I think that the vertex array in MilkyWay needs vertex colors which can then be dimmed one-by-one by extinction. I assume this comes too late for 0.11.1, but maybe one of you with better knowledge of the internals of those classes can put some effort in MilkyWay and StelSkyLayerMgr to complete this task? In September, I attended the SEAC conference, and can report that Stellarium is in use by many researchers in the field of ethnoastronomy, given especially the nice skyculture features. On the other hand, others are concerned about computational accuracy, see below. From the field of education, Rosa Doran of the "Global Hands-on Universe" (http://www.globalhou.net) and the Galileo Teacher Training Program told me how many teachers with thousands of pupils she introduced to astronomy using Stellarium, so it's an important educational tool, and she wants to express her gratitude to the team (YOU :-) which I am happy to deliver. My other branch is the scenery3d walkthrough plugin, which was quite successfully demonstrated at SEAC. This undergoes further improvements by a student until January, then I would like to contribute it to the project. For optimal integration I have a few questions: Where in the branch shall I put plugin data files, i.e. some demo sceneries? I know plugin data files in the final application should go into <USER_DATA>/modules/scenery3d/<scene_name>. There is however currently no directory <BZRbranch>/modules/<plugin_name> in the project structure, the other plugins just create new files in the user's <USER_DATA>/modules/<plugin_name>. For walkaround with keyboard controls, I had to modify StelMovementMgr::getCallOrder(), thereby breaking the pure "plugin" concept. However, I feel that plugins should be allowed keyboard interaction intercepting the main application. A few months ago, there was discussion on the list on the buttons behaviour of plugins. Has there been a decision/solution yet? It would be helpful to have a right-click behaviour like "open config panel" - currently I must use 2 buttons. The PDF manual is somewhat outdated (10.2). Is there documentation on the scripting language? The files on sourceforge SVN are about 3 years old. Where are the (Are there?) current LaTeX/LyX files, maybe I can add some details on landscapes, refraction, extinction and scenery3d. The LaTeX sources could be likewise developed on the BZR. I think, one complete, up-to-date english manual should always be available, and new visible features could be easily added by the respective author if this manual was also on BZR. Some time ago I had understood Stellarium moved from Sourceforge to Launchpad. Now I understood something is still kept at Sourceforge. What is the reason for the dichotomy BZR/SVN? Stellarium has high potential as education tool, and I think the scenery3D plugin is opening new possibilities for archaeoastronomy. For the latter, however, astronomical accuracy need to be improved for times long gone. I hope I can contribute something more in this field. Generally however, some source files need better documentation of algorithms and data sources (papers, books?). If you know more than is currently available, please consider improving documentation to help contributors. On Launchpad, most branches are in state of "Development". However, many of the branches have no description, and some seem to be dead. Consider marking "Abandon" for those, "Mature" for the ready-to-merge ones, and "Merged" for, well, merged ones without further use. The description can include a description of current state. Of course, only the branch owners should do that. Finally, is there a repository or website for uploading contributed sky cultures, similar to the landscape collection? I currently can only provide "Western" variants. For now, I have processed the built-in ones into outlines (simply Sobel filtered, but I prefer those over "thick" paintings), but I have long ago started work on others which may at some time be ready. Kind regards, Georg -- Georg Zotti Archaeoastronomy / ASTROSIM VIAS-Vienna Institute for Archaeological Science University of Vienna |
From: Alexander W. <ale...@gm...> - 2011-10-20 14:50:32
|
Hi, Georg! I can answer for some questions. 2011/10/20 Georg Zotti <geo...@un...>: > Where in the branch shall I put plugin data files, i.e. some demo > sceneries? I know plugin data files in the final application should go into > <USER_DATA>/modules/scenery3d/<scene_name>. There is however currently no > directory <BZRbranch>/modules/<plugin_name> in the project structure, the > other plugins just create new files in the user's > <USER_DATA>/modules/<plugin_name>. You can look at other plugins but you're right - folder <USER_DATA>/modules/<plugin_name> contains data for thier plugin. For bzr you need create a folder resources and put your files into, after you need create a qrs-file (Qt Resources) and set links to your data files. As final - you need update cmake files > The PDF manual is somewhat outdated (10.2). Is there documentation on the > scripting language? The files on sourceforge SVN are about 3 years old. > Where are the (Are there?) current LaTeX/LyX files, maybe I can add some > details on landscapes, refraction, extinction and scenery3d. The LaTeX > sources could be likewise developed on the BZR. I think, one complete, > up-to-date english manual should always be available, and new visible > features could be easily added by the respective author if this manual was > also on BZR. Latest version of Guide is here: stellarium.org/wiki/index.php/Stellarium_User_Guide > Some time ago I had understood Stellarium moved from Sourceforge to > Launchpad. Now I understood something is still kept at Sourceforge. What > is the reason for the dichotomy BZR/SVN? svn used only as archive of old code > Finally, is there a repository or website for uploading contributed sky > cultures, similar to the landscape collection? I currently can only > provide "Western" variants. For now, I have processed the built-in ones > into outlines (simply Sobel filtered, but I prefer those over "thick" > paintings), but I have long ago started work on others which may at some > time be ready. for skycultures you can use related project - http://launchpad.net/stellarium-skycultures or you can upload culture on own site and put link in wiki -- With best regards, Alexander |
From: Georg Z. <geo...@un...> - 2011-10-20 17:17:07
|
On Do, 20.10.2011, 16:50, Alexander Wolf wrote: > Hi, Georg! > > I can answer for some questions. > > > > Latest version of Guide is here: > stellarium.org/wiki/index.php/Stellarium_User_Guide Ah, thanks! > for skycultures you can use related project - > http://launchpad.net/stellarium-skycultures Oh, I was not aware of this... OK, I added a new branch. If you like, please merge it. Kind regards, Georg -- Georg Zotti Archaeoastronomy / ASTROSIM VIAS-Vienna Institute for Archaeological Science University of Vienna |
From: Bogdan M. <dag...@gm...> - 2011-10-24 19:40:23
|
On Thu, Oct 20, 2011 at 5:28 PM, Georg Zotti <geo...@un...> wrote: > Dear core team, > [snip] > My other branch is the scenery3d walkthrough plugin, which was quite > successfully demonstrated at SEAC. This undergoes further improvements by > a student until January, then I would like to contribute it to the > project. For optimal integration I have a few questions: > > Where in the branch shall I put plugin data files, i.e. some demo > sceneries? I know plugin data files in the final application should go into > <USER_DATA>/modules/scenery3d/<scene_name>. There is however currently no > directory <BZRbranch>/modules/<plugin_name> in the project structure, the > other plugins just create new files in the user's > <USER_DATA>/modules/<plugin_name>. This is a good question. As Alex Wolf said, you can put the files in a resource file. There is a problem, though - this will embed the files in Stellarium's executable file. While this is OK for small files like button textures, adding everything to the executable will continue to bloat it in the long run. We need a standardized file locations and install scripts for the plug-in resources. > For walkaround with keyboard controls, I had to modify > StelMovementMgr::getCallOrder(), thereby breaking the pure "plugin" > concept. However, I feel that plugins should be allowed keyboard > interaction intercepting the main application. There is something like that done in the Oculars plug-in. I haven't looked at your code yet, so I don't know if you have used the same mechanism. > A few months ago, there was discussion on the list on the buttons > behaviour of plugins. Has there been a decision/solution yet? No. Timothy Reaves wrote some code in this direction, but in the discussion, different people turned out to have different ideas on what exactly it should look like. I was going to write a resume of the positions and post it here or on the Wiki, but got distracted with "real life" issues, including the lack of a permanent Internet connection. > It would be > helpful to have a right-click behaviour like "open config panel" - > currently I must use 2 buttons. Overriding the right click will be tricky, because it is currently used to de-select objects. You can have a look at my branch for plug-in GUI improvement - https://code.launchpad.net/~daggerstab/stellarium/plugins-gui-improvement Using the same method you can add a command GUI on the screen similar to the existing toolbars. > > The PDF manual is somewhat outdated (10.2). Is there documentation on the > scripting language? The files on sourceforge SVN are about 3 years old. > Where are the (Are there?) current LaTeX/LyX files, maybe I can add some > details on landscapes, refraction, extinction and scenery3d. The LaTeX > sources could be likewise developed on the BZR. I think, one complete, > up-to-date english manual should always be available, and new visible > features could be easily added by the respective author if this manual was > also on BZR. "Outdated" is an understatement. It was decided to migrate the manual to the Wiki, supposedly to make it easier to use/edit/translate. Alex Wolf did a lot of work on importing it in the Wiki, but a lot of the information is still either not up-to-date, incomplete or misleading. One of the reasons of the migration is that there is a MediaWiki extension that can export a collection of wiki pages as a PDF file. Unfortunately, it doesn't work with our site because of SourceForge's hosting policies. The Wiki was supposed to be moved together with the site on a seprate server When We Enable the DSS Background, but I don't know what's the current state of this, as Fabien has dropped off the radar. > > Some time ago I had understood Stellarium moved from Sourceforge to > Launchpad. Now I understood something is still kept at Sourceforge. What > is the reason for the dichotomy BZR/SVN? The SVN repository is kept mainly as an archive, the same way the CVS repository is. There is also some code that wasn't in the trunk and wasn't migrated to Bazaar or elsewhere - the telescope servers and the last surviving examples of stand-alone, dynamically loaded plug-ins. > > Stellarium has high potential as education tool, and I think the scenery3D > plugin is opening new possibilities for archaeoastronomy. For the latter, > however, astronomical accuracy need to be improved for times long gone. I > hope I can contribute something more in this field. Generally however, > some source files need better documentation of algorithms and data sources > (papers, books?). If you know more than is currently available, please > consider improving documentation to help contributors. That will be somewhat hard. Stellarium is optimized for fast rendering, not accuracy. There are some fudge factors included in the code, as well as some outright "nobody will care about that". Hight accuracy generally means more calculations and a lower frame-per-second rate. When Fabien was working on the Nokia N900 port, he even made some parameters to use a lower precision format (float instead of double). Also, I think that the person responsible for some of the orbital modeling code no longer hangs around. :) > > On Launchpad, most branches are in state of "Development". However, many > of the branches have no description, and some seem to be dead. Consider > marking "Abandon" for those, "Mature" for the ready-to-merge ones, and > "Merged" for, well, merged ones without further use. The description can > include a description of current state. Of course, only the branch owners > should do that. Only the branch owners _can_ do that. :) There are also some apparently abandoned branches and merge proposals that should have been done ages ago. I'll try to comment/update my branches anyway. Regards, Bogdan Marinov |
From: Georg Z. <geo...@un...> - 2011-10-25 10:57:34
|
Dear Bogdan, thank you for you answers, commented further below. On Mo, 24.10.2011, 21:40, Bogdan Marinov wrote: > On Thu, Oct 20, 2011 at 5:28 PM, Georg Zotti <geo...@un...> > wrote: >> Dear core team, >> [snip] > >> Where in the branch shall I put plugin data files, i.e. some demo >> sceneries? >> [snip] > This is a good question. As Alex Wolf said, you can put the files in a > resource file. There is a problem, though - this will embed the files > in Stellarium's executable file. While this is OK for small files like > button textures, adding everything to the executable will continue to > bloat it in the long run. We need a standardized file locations and > install scripts for the plug-in resources. OK, so the resource file is a clear no-go here. I speak of 3D models, which are large, exchangeable and loadable via a GUI list similar to "Landscapes". I think an install script is not necessary, just unpack and copy into your Stellarium data folder. The question is, shall I add a folder "modules" into the main folder, in which I now add "scenery3d" (because it's a plugin and plugin data go into subfolders of "modules"), or shall I add a "scenery3d" folder directly, because it's a concept similar to "landscapes". >> For walkaround with keyboard controls, I had to modify >> StelMovementMgr::getCallOrder(), thereby breaking the pure "plugin" >> concept. However, I feel that plugins should be allowed keyboard >> interaction intercepting the main application. > > There is something like that done in the Oculars plug-in. I haven't > looked at your code yet, so I don't know if you have used the same > mechanism. Ah, I have to look inside there! >> A few months ago, there was discussion on the list on the buttons >> behaviour of plugins. Has there been a decision/solution yet? > > No. Timothy Reaves wrote some code in this direction, but in the > discussion, different people turned out to have different ideas on > what exactly it should look like. I was going to write a resume of the > positions and post it here or on the Wiki, but got distracted with > "real life" issues, including the lack of a permanent Internet > connection. Sounds difficult... >> It would be >> helpful to have a right-click behaviour like "open config panel" - >> currently I must use 2 buttons. > > Overriding the right click will be tricky, because it is currently > used to de-select objects. Then maybe with double-click? Or can a button "grab" the right-click event before forwarding to the main app? > You can have a look at my branch for plug-in GUI improvement - > https://code.launchpad.net/~daggerstab/stellarium/plugins-gui-improvement > Using the same method you can add a command GUI on the screen similar > to the existing toolbars. OK, must look inside. >> [Manual is outdated] > "Outdated" is an understatement. It was decided to migrate the manual > to the Wiki, supposedly to make it easier to use/edit/translate. Alex > Wolf did a lot of work on importing it in the Wiki, but a lot of the > information is still either not up-to-date, incomplete or misleading. Yes, following Alex' response I added some details on recent changes in Landscapes. > One of the reasons of the migration is that there is a MediaWiki > extension that can export a collection of wiki pages as a PDF file. > Unfortunately, it doesn't work with our site because of SourceForge's > hosting policies. The Wiki was supposed to be moved together with the > site on a seprate server When We Enable the DSS Background, but I > don't know what's the current state of this, as Fabien has dropped off > the radar. Uh, that's bad to read! Who else in the team is OpenGL expert now? >> [accuracy, documentation] > That will be somewhat hard. Stellarium is optimized for fast > rendering, not accuracy. There are some fudge factors included in the > code, as well as some outright "nobody will care about that". Hight > accuracy generally means more calculations and a lower > frame-per-second rate. When Fabien was working on the Nokia N900 port, > he even made some parameters to use a lower precision format (float > instead of double). I had seen this change, but did not know exactly why. OK, it's not a problem for landscapes, but definitely for long-term computations. It will be an important point to consider for me. > Also, I think that the person responsible for some of the orbital > modeling code no longer hangs around. :) Yes, what a pity! >> [unmerged/"dead"(?) branches] > Only the branch owners _can_ do that. :) There are also some > apparently abandoned branches and merge proposals that should have > been done ages ago. I'll try to comment/update my branches anyway. OK, thanks! Kind regards, Georg -- DI Dr Georg Zotti Archaeoastronomy / ASTROSIM VIAS-Vienna Institute for Archaeological Science University of Vienna |
From: Bogdan M. <dag...@gm...> - 2011-10-25 15:43:26
|
On Tue, Oct 25, 2011 at 1:57 PM, Georg Zotti <geo...@un...> wrote: > [snip] > OK, so the resource file is a clear no-go here. I speak of 3D models, > which are large, exchangeable and loadable via a GUI list similar to > "Landscapes". I think an install script is not necessary, just unpack and > copy into your Stellarium data folder. The question is, shall I add a > folder "modules" into the main folder, in which I now add "scenery3d" > (because it's a plugin and plugin data go into subfolders of "modules"), > or shall I add a "scenery3d" folder directly, because it's a concept > similar to "landscapes". I think that adding it directly under the main directory, together with "landscapes"/"stars"/"nebulae", would be the best variant for now. I'm not sure about the name, though. You can try asking Fabien directly for input. >[snip] >>> It would be >>> helpful to have a right-click behaviour like "open config panel" - >>> currently I must use 2 buttons. >> >> Overriding the right click will be tricky, because it is currently >> used to de-select objects. > Then maybe with double-click? Or can a button "grab" the right-click event > before forwarding to the main app? I think that you can make a button that will open a drop-down menu on clicking it. Look at the current code of the Oculars plug-in for an example of a drop-down menu, though it works with a keyboard shortcut instead of a button click. >[snip] >> One of the reasons of the migration is that there is a MediaWiki >> extension that can export a collection of wiki pages as a PDF file. >> Unfortunately, it doesn't work with our site because of SourceForge's >> hosting policies. The Wiki was supposed to be moved together with the >> site on a seprate server When We Enable the DSS Background, but I >> don't know what's the current state of this, as Fabien has dropped off >> the radar. > Uh, that's bad to read! Who else in the team is OpenGL expert now? Well, Fabien hasn't given up on the project yet. :) AFAIK, it's just that he has a new job now and still hasn't settled down, so he doesn't have time for Stellarium. I also think that Nokia's decisions about MeeGo/Maemo/Qt have caused him some disappointment. I think that the only OpenGL expert that we have at the moment is hikiko/Eleni Maria Stea, our Summer of Code in Space student. :) > >>> [accuracy, documentation] >> That will be somewhat hard. Stellarium is optimized for fast >> rendering, not accuracy. There are some fudge factors included in the >> code, as well as some outright "nobody will care about that". Hight >> accuracy generally means more calculations and a lower >> frame-per-second rate. When Fabien was working on the Nokia N900 port, >> he even made some parameters to use a lower precision format (float >> instead of double). > > I had seen this change, but did not know exactly why. OK, it's not a > problem for landscapes, but definitely for long-term computations. It will > be an important point to consider for me. > >> Also, I think that the person responsible for some of the orbital >> modeling code no longer hangs around. :) > Yes, what a pity! Due to my work on the Solar System Editor plug-in I may need to dive into that code and try to figure out what it does exactly. Regards, Bogdan Marinov |
From: Alexander W. <ale...@gm...> - 2011-10-25 15:57:36
|
25.10.2011 22:43 пользователь "Bogdan Marinov" <dag...@gm...> написал: > > On Tue, Oct 25, 2011 at 1:57 PM, Georg Zotti <geo...@un...> wrote: > > [snip] > > OK, so the resource file is a clear no-go here. I speak of 3D models, > > which are large, exchangeable and loadable via a GUI list similar to > > "Landscapes". I think an install script is not necessary, just unpack and > > copy into your Stellarium data folder. The question is, shall I add a > > folder "modules" into the main folder, in which I now add "scenery3d" > > (because it's a plugin and plugin data go into subfolders of "modules"), > > or shall I add a "scenery3d" folder directly, because it's a concept > > similar to "landscapes". > > I think that adding it directly under the main directory, together > with "landscapes"/"stars"/"nebulae", would be the best variant for > now. I'm not sure about the name, though. You can try asking Fabien > directly for input. Maybe "models"? |
From: Georg Z. <geo...@un...> - 2011-10-25 16:14:14
|
Hi! On Di, 25.10.2011, 17:57, Alexander Wolf wrote: > 25.10.2011 22:43 пользователь "Bogdan Marinov" <dag...@gm...> > написал: >> >> On Tue, Oct 25, 2011 at 1:57 PM, Georg Zotti <geo...@un...> > wrote: >> > [snip] >> > OK, so the resource file is a clear no-go here. I speak of 3D models, >> > which are large, exchangeable and loadable via a GUI list similar to >> > "Landscapes". I think an install script is not necessary, just unpack > and >> > copy into your Stellarium data folder. The question is, shall I add a >> > folder "modules" into the main folder, in which I now add "scenery3d" >> > (because it's a plugin and plugin data go into subfolders of >> "modules"), >> > or shall I add a "scenery3d" folder directly, because it's a concept >> > similar to "landscapes". >> >> I think that adding it directly under the main directory, together >> with "landscapes"/"stars"/"nebulae", would be the best variant for >> now. I'm not sure about the name, though. You can try asking Fabien >> directly for input. > > Maybe "models"? I think "models" is too unspecific. "landscapes3d", "scenery", "environment" or such would be fitting names, on the other hand if the plugin is called "scenery3d", what's wrong with that? Kind regards, Georg -- DI Dr Georg Zotti Archaeoastronomy / ASTROSIM VIAS-Vienna Institute for Archaeological Science University of Vienna |