Thread: [Celestia-developers] The LookBack feature
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Clint W. <cwe...@ad...> - 2003-01-11 01:32:18
|
Hi All, Fridger, I have a minor problem with how the "LookBack" feature works. Basically, I presumed looking back meant just rotating the observers orientation about any axis by 180 degrees. The feature does do this, but it does more which I suspect is an unintended side effect. LookBack also causes the velocity vector to be reversed. So if I'm flying away from an object and press the * key, my direction of motion is reversed and I begin flying toward it. I thought the intention was to only modify the observer orientation vector. My apologies if I've misunderstood this feature. Cheers. Clint Weisbrod. |
From: Fridger S. <t0...@ma...> - 2003-01-11 12:15:54
|
Clint Weisbrod wrote: > > Hi All, > > Fridger, I have a minor problem with how the "LookBack" feature works. > > Basically, I presumed looking back meant just rotating the observers > orientation about any axis by 180 degrees. The feature does do this, but it > does more which I suspect is an unintended side effect. LookBack also > causes the velocity vector to be reversed. So if I'm flying away from an > object and press the * key, my direction of motion is reversed and I begin > flying toward it. I thought the intention was to only modify the observer > orientation vector. > > My apologies if I've misunderstood this feature. > > Cheers. > > Clint Weisbrod. > I am not sure what exactly you are referring to, since I cannot reproduce the reversal of the motion: 1) Go to Callisto, say. Put it at some distance and approach it after hitting F3 with 1000km/sec, watching the altimeter. Now push '*'. You are looking back now, but the altitude continues to decrease. Pushing '*' again, you'll see Callisto again and it is much closer now... 2) Same with using the HOME key for the approach. At least that's how things work under Linux, but this should be the same in Windows. Cheers Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-11 19:23:53
Attachments:
celestia.spec
|
Hi all, I have SuSE binary rpm's ready for the new 1.2.5 celestia version. However, since uploading is pretty messy in my case, I'd first appreciate some feedback, what we should do with the various leftover bugs that incidentally I pointed out before Chris issued 1.2.5. For some reason Chris ignored all these issues (right now he seems to be away?): 1) Chris applied Grant's texture|solarsys.ssc corrections for some reason only to a /fraction/ of the bodies, which led him to issue another patch for the rest just now... Also there are further adjustments necessary in solarsys.ssc: -- re-correct the orientation of the Galilean satellites of Jupiter, now that their orbits have been corrected. -- correct the orientation of Jupiter, so that the Great Red Spot appears in the right position (using the default jupiter.jpg). -- add a suitable RotationOffset to Saturn (a pretty theoretical manoeuvre, but it's put there just for consistency with the information provided for the other gas giants' prime meridians). ...too bad;-). My textures|solarsys.ssc here are all corrected since quite some time; Chris, let me know whether you want me to /reintroduce the bugs/ when packaging the SuSE-rpm, please;-). 2) Here are some further ignored buggies that I mentioned the night before the release: > 2) celestia.iss still uses version number 1.2.4 > 3) What about the missing icons for Windows in the res directory? > 4) There is still this superfluous trivial startup error > "Parent body 'TYC 5503-946-1' of 'b' not found." > that confuses Newbies, for example. I have just commented the > relevant entry out in extrasolar.ssc, but there sure is a better way;-). > > Only if you run out of work;-): Why not replacing the incomplete control > explanations in README by the /up-to-date/ contents of controls.txt? I have iterated and upgraded my original SuSE celestia.spec file to be as close as possible to Christophe's spec file for Mandrake. In order not to be confined to the most recent SuSE installations, I inserted the specific SuSE paths rather than variables that were not recognized earlier. The SuSE celestia.spec is attached. Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-13 00:47:58
|
Great Progress: Hires bumping with DDS (8:1) NORMAL maps ========================================================== At last, I got it right;-). Since quite some time, I have tried to associate the hires bump files with highly compressed DXT format, too. The essential /slowing-down/ of the fps rate in the display of hires bumped textures came from the fact that up-to-now one had to use *.png or *.jpg bump files in Celestia 1.2.5. Here is how the solution works: In the Celestia code (texmanager.cpp, texture.cpp), the bumpmap files are converted into /normal maps/ and stored as such internally, provided a non-vanishing BumpHeight is entered in solarsys.ssc; i.e. from adjacent pixels, in each point, the normal is computed that characterizes the bumpyness of the texture. The trick is now to use NVIDIA's Windows command-line utility, 'NormalMapGen', for converting /externally/ a hires bump.tga file first into the corresponding NormalMap.tga file. The latter is a standard 24bit rgb file and in a second step, is then converted into DXT1c (8:1) format. All one has to do in solarsys.ssc is to put for Earth BumpHeight 0.0 BumpTexture "earth-normal.dds" and analogously for Mars BumpHeight 0.0 BumpTexture "mars-normal.dds" whence internally the conversion step to a normalMap is /skipped/ and earth|mars-normal.dds is correctly interpreted as a normal map;-). Besides the amazing 8:1 compression, also the lacking conversion from bump to normal map saves a lot of storage and time, respectively. The art is now to generate the cleanest and smoothest possible normal map. For Earth, for example, I start from the original 24bit grayscale 10k SpaceGraphics earth-bump.jpg's and reduce them (cubically) to 8k,4k,2k with GIMP. Without saving the JPG file, I create a new 8k,4k,2k transparent grayscale file and compose a RGBA earth-bump.tga file with the earth-bump.jpg as alpha channel for each resolution. Then the command is NormalMapGen earth-bump.tga earth-normal.tga <scale> -w 5x5 which generates the output earth-normal.tga NormalMap file from the height info in the alpha channel using 5x5 sampling. The 24bit DDS conversion call subsequently reads nvdxt -file earth-normal.tga -24 dxt1c As result, earth-normal.dds is written. With the scale factor <scale> one has to play a little. I found <scale> = 7.5, 4.5 satisfactory for 8k, 4k normal maps of Earth, for example. That's it! As an illustration, I list below 2 hires Earth shots and one from Mars. The 1st earth shot has a /16k earth.dds/ texture and a /8k earth-normal.dds/ texture, the second earth shot has a /8k earth.dds/ texture and the same /8k earth-normal.dds/. The Mars shot was a 8k mars.dds texture with a 8k mars-normal.dds texture. Most importantly, watch the /fps-rates/ (~20) in the lower left of the shots!!! This is just amazing, given my old 32MB GF2 card...Moreover, as you may e.g. judge from the second earth image, the display of the elliptical plane ground is completely free of pixel trash that is so often visible there upon normal bumpmapping! Of course, Grant's corrections are incorporated for Mars. Bye Fridger A similar text & the images below are also posted in the Forum in the Textures department. http://www.shatters.net/~t00fri/images/earth16k-8k-normal.jpg http://www.shatters.net/~t00fri/images/earth8k-1-normal-test.jpg http://www.shatters.net/~t00fri/images/mars8k-normal-test.jpg |
From: Chris L. <cl...@ww...> - 2003-01-13 19:38:37
|
On Sat, 11 Jan 2003, Fridger Schrempp wrote: > Hi all, > > I have SuSE binary rpm's ready for the new 1.2.5 celestia version. However, > since uploading is pretty messy in my case, I'd first appreciate some feedback, > what we should do with the various leftover bugs that incidentally I pointed > out before Chris issued 1.2.5. For some reason Chris ignored all these issues > (right now he seems to be away?): I was away for the past four days . . . I thought I would have email access in my hotel room, but alas no. > > 1) Chris applied Grant's texture|solarsys.ssc corrections for some reason only > to a /fraction/ of the bodies, which led him to issue another patch for the > rest just now... I thought that I got nearly of these corrections in . . . > Also there are further adjustments necessary in solarsys.ssc: > > -- re-correct the orientation of the Galilean satellites of Jupiter, now > that their orbits have been corrected. I fixed the RotationOffset and adjusted the textures for all of the Galilean moons. Do you find that their orientations are still wrong? > -- correct the orientation of Jupiter, so that the Great Red Spot appears > in the right position (using the default jupiter.jpg). Oops. I did neglect Jupiter . . . > -- add a suitable RotationOffset to Saturn (a pretty theoretical > manoeuvre, but it's put there just for consistency with the information > provided for the other gas giants' prime meridians). I don't think anyone is going to notice :> But feel free to check in the change if you like. Are there other omissions? > > ...too bad;-). My textures|solarsys.ssc here are all corrected since quite some > time; Chris, let me know whether you want me to /reintroduce the bugs/ when > packaging the SuSE-rpm, please;-). > > 2) Here are some further ignored buggies that I mentioned the night before the > release: > > > 2) celestia.iss still uses version number 1.2.4 I changed this. > > 3) What about the missing icons for Windows in the res directory? I did include them in the source package, though I haven't fixed CVS yet. > > 4) There is still this superfluous trivial startup error > > "Parent body 'TYC 5503-946-1' of 'b' not found." > > that confuses Newbies, for example. I have just commented the > > relevant entry out in extrasolar.ssc, but there sure is a better way;-). This was deliberate. In 1.2.6, I want to add a logging feature that writes loading error messages to a file. This will be useful for add-on authors, but invisible to ordinary users. Commenting out the entry in extrasolar.ssc means that users who download the Tycho star catalog won't see this planet, so I didn't want to remove it. > > > > Only if you run out of work;-): Why not replacing the incomplete control > > explanations in README by the /up-to-date/ contents of controls.txt? I simply ran out of time to do this before my trip . . . > > I have iterated and upgraded my original SuSE celestia.spec file to be as close > as possible to Christophe's spec file for Mandrake. In order not to be confined > to the most recent SuSE installations, I inserted the specific SuSE paths > rather than variables that were not recognized earlier. > > The SuSE celestia.spec is attached. > > Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-13 20:52:34
|
Chris Laurel wrote: > > I was away for the past four days . . . I thought I would have email > access in my hotel room, but alas no. > Aha, welcome back;-)... > > > > 1) Chris applied Grant's texture|solarsys.ssc corrections for some reason only > > to a /fraction/ of the bodies, which led him to issue another patch for the > > rest just now... > > I thought that I got nearly of these corrections in . . . Well,... see http://www.shatters.net/forum/viewtopic.php?t=1601 > > > Also there are further adjustments necessary in solarsys.ssc: > > > > -- re-correct the orientation of the Galilean satellites of Jupiter, now > > that their orbits have been corrected. > > I fixed the RotationOffset and adjusted the textures for all of the > Galilean moons. Do you find that their orientations are still wrong? > Grant finds they are still wrong;-): http://www.shatters.net/forum/viewtopic.php?t=1577 > > -- correct the orientation of Jupiter, so that the Great Red Spot appears > > in the right position (using the default jupiter.jpg). > > Oops. I did neglect Jupiter . . . > > > -- add a suitable RotationOffset to Saturn (a pretty theoretical > > manoeuvre, but it's put there just for consistency with the information > > provided for the other gas giants' prime meridians). > > I don't think anyone is going to notice :> But feel free to check in the > change if you like. Are there other omissions? > > > > > ...too bad;-). My textures|solarsys.ssc here are all corrected since quite some > > time; Chris, let me know whether you want me to /reintroduce the bugs/ when > > packaging the SuSE-rpm, please;-). > > > > > 2) Here are some further ignored buggies that I mentioned the night before the > > release: > > > > > 2) celestia.iss still uses version number 1.2.4 > > I changed this. But not in CVS: [Setup] AppName=Celestia AppVerName=Celestia 1.2.4 AppPublisher=Shatters Software AppPublisherURL=http://www.shatters.net/celestia/ > > > > 3) What about the missing icons for Windows in the res directory? > > I did include them in the source package, though I haven't fixed CVS yet. > Given my slow line from home, I did not download the Windows version yet. > > > 4) There is still this superfluous trivial startup error > > > "Parent body 'TYC 5503-946-1' of 'b' not found." > > > that confuses Newbies, for example. I have just commented the > > > relevant entry out in extrasolar.ssc, but there sure is a better way;-). > > This was deliberate. In 1.2.6, I want to add a logging feature that > writes loading error messages to a file. This will be useful for add-on > authors, but invisible to ordinary users. Commenting out the entry in > extrasolar.ssc means that users who download the Tycho star catalog won't > see this planet, so I didn't want to remove it. > OK, if there is no other easy way to get rid of the error... > > > > > > Only if you run out of work;-): Why not replacing the incomplete control > > > explanations in README by the /up-to-date/ contents of controls.txt? > > I simply ran out of time to do this before my trip . . . > I have had this experience, too, on times;-). But in this context, see the (largely unjustified) complaint about README of the user MB (Anonymous): http://www.shatters.net/forum/viewtopic.php?t=1609 .... So Chris, what do you want me to do after all concerning the above left over corrections when I do the SuSE rpms? Since in my system at home the corrections are all done since quite a while, I would have to reintroduce the bugs ... Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-01-14 06:16:17
|
On Mon, 13 Jan 2003, Fridger Schrempp wrote: > > > > > > > > Only if you run out of work;-): Why not replacing the incomplete control > > > > explanations in README by the /up-to-date/ contents of controls.txt? > > > > I simply ran out of time to do this before my trip . . . > > > > I have had this experience, too, on times;-). But in this context, see the > (largely unjustified) complaint about README of the user MB (Anonymous): > > http://www.shatters.net/forum/viewtopic.php?t=1609 Aha . . . If you've already got the corrections, go ahead and check them in. Otherwise, I'll take care of it. > > .... > > So Chris, what do you want me to do after all concerning the above left over > corrections when I do the SuSE rpms? Since in my system at home the corrections > are all done since quite a while, I would have to reintroduce the bugs ... Don't reintroduce the bugs . . . While it would be ideal to have consistency across all 1.2.5 distributions, I think some slight inconsistency is preferable to you spending time making the SuSE RPM bug compatible with other packages. --Chris |
From: Chris L. <cl...@ww...> - 2003-01-15 00:51:20
|
I thought that I'd share the list of features that I want to get into version 1.2.6 of Celestia. Christophe, I know that you already made a list . . . Fridger and Clint--I'd like to hear your interests and priorities too, so I can compile a complete list. Multiview This was discussed on the list before . . . Allow multiple simultaneous views. The camera position, orientation, and FOV may be different in each view. Time is the same in each view, but only the UI imposes this limitation. After all, once we implement light time delay, the whole concept of simultaneity gets rather confusing, so the renderer and simulation classes should be flexible in their handling of time. While implementing multiview, the notion of what items constitute the state of Celestia will necessary be clarified. There are implications for cel:// URLs . . . Nebulae Celestia needs to have better support for rendering nebulae with 3DS meshes. Rassilon's NGC1999 add-on works by making a really large planet in an .ssc file. The problem is that Celestia isn't designed to handle planets on the order of one light year in diameter :> My plan is to generalize the galaxy rendering to handle meshes as well as fuzzy blob galaxy shapes. This could be a straightforward change or a more involved on depending on how far we want to take the generalization. We could make a general Object class from which Star, Planet, Galaxy, etc. derive. At the very least, there should be a new superclass introduced for galaxies and nebulae. Having separate file types for galaxies, planets, and nebulae is starting to seem unncessary. The format of .ssc files could be modified slightly to accomodate any text-defined object (we still need binary star database files, though.) Lots of things to think about . . . Labels I want to implement a flexible labeling and marking system for Celestia. It should handle labeling locations on the surface of an object (or above the surface e.g. text marking the Cassini Division in Saturn's rings.) Markers could be placed on any object selected by a user, either directly or through a filter ("mark all stars with planets"). New OpenGL extension support I'm going to move from using the NVIDIA specific GL extensions for vertex and pixel programs to the generic ARB_vertex_program and ARB_fragment_program. I will leave the NVIDIA extension stuff in place, as lots of people haven't upgraded to recent drivers that support the new extensions. Custom orbits The orbits of the Saturnian moons aren't accurate enough to simulate mutual phenomena. I *think* the Uranian moon orbits are pretty good, but I need to check. There is no data on mutual phenomena of Uranus's satellites, but it's possible to compare the custom orbits with Horizons trajectories. XYZ trajectories .xyz files are currently read as single precision. In many cases, this is not enough precision, so there needs to be a way to specify double precision. This should be optional, as single precision trajectories take only half the space. Linear interpolation between points is inadequate; higher order interpolation methods are required. Improved cel:// URL support on Windows I'd like cel:// URLs to work as well on Windows as they do on KDE/Konqueror. This may or may not be possible, but it's something that should at least be investigated. Bug fixes: Double eclipse shadows Crashes with MS OpenGL 1.1. driver Probably not until 1.2.7 . . . New atmosphere rendering: I'd like to fix up atmosphere rendering to get rid of the 'hole in the sky' problem, dark shadows in daytime skies, and the inability to render atmospheres for oblate planets. I have in mind a technique that would fix at least the first two problems, in addition to allowing more realistic skies with more color variations. That's my list for now . . . I'm sure the bug fixes section needs to get bigger tnough :> --Chris |
From: Chris L. <cl...@ww...> - 2003-01-15 18:46:24
|
On Tue, 14 Jan 2003, Chris Laurel wrote: > I thought that I'd share the list of features that I want to get into > version 1.2.6 of Celestia. Christophe, I know that you already made a > list . . . Fridger and Clint--I'd like to hear your interests and > priorities too, so I can compile a complete list. I forgot an important one . . . Rework the directory structure The fact that textures all must reside in the textures directory, meshes in the models directory, and .xyz trajectories in the data directory impedes organization of add-ons. With multiple directories now supported for add-ons, it would be useful if textures/models/trajectories could be loaded from the same directory in which the .ssc file is located. I checked in a couple small changes today. One adds a NormalMap field to .ssc files so that you don't have to use the BumpHeight 0.0 trick anymore (though this was a nice find Fridger :) ). The other change prevents Celestia from crashing when using CompressedTexture true with a DXT texture. --Chris |
From: Clint W. <cwe...@ad...> - 2003-01-27 06:02:49
|
Sorry for taking so long to reply to this. Here's my short feature wish-list for Celestia: - I'm in agreement with Fridger. It would be wonderful to have the ability to clamp the observers orientation axes to a number of different coordinate systems including alt-azimuth, ra-decl with a display of the current coordinates of the center of the view. - Perhaps this is counter to the general paradigm of Celestia, but I'd someday like to see a gravity mode in Celestia where objects are given the correct position and velocity for a particular time and are then subject to the laws of gravity, rather than obeying (albeit highly accurate) functions of position. This would be a large undertaking because the observer position would also be subject to gravity and some facility to generate varying amounts of "thrust" would seem like a desirable feature. As I said, perhaps this kind of feature has no place in the Celestia paradigm. - Need to fix the missing bitmaps in CVS for menu items. I could easily check in new versions of these bitmaps under different names and modify the .rc file accordingly. Chris, let me know if you feel this is likely to be the only way to work around the CVS problem, if it can't be fixed. - Store the state of the window when Celestia is closed. If I close Celestia when it is maximized, the next time I open Celestia, it should return to the maximized state. A simple enhancement. - Removal of Altitude/Distance displays. Beyond 4 radii, the distance to an object is measured from the center of the object. I'm not sure this is ever relevant information. Perhaps it would be better to always display the altitude value, but just call it distance. Maybe there is some argument for leaving things as they are. Anyone? - Display of local sidereal time. If I was back in University again with access to the observatory, I would really appreciate having a reliable sidereal clock available. Local sidereal time implies knowledge of geographical location. Once we have added facilities to store canned locations and user-specified ones, the exact lat/long of a selected location could be used to optionally display the local sidereal time. As an aside, providing the local sidereal time is just the tip of the iceberg in how we could cater to people using Celestia in observatories. I spent a lot of late nights and early mornings in an observatory and there are other features that could be added to Celestia that I would have really appreciated. For instance, instead of just giving the local sidereal time, it would have been great to have had the hour angle computed automatically for any object. This would allow for very quick alignment to the object. I suppose these days fewer amateur astronomers depend on sidereal clocks and hour angles with the advent of self-aligning, smart telescopes that point themselves at any object you want. Takes all the fun out of being in an observatory, I think. Anyway, I'm starting ramble. Next item. - Addition of some well-known terrestrial objects on Earth. OK, maybe not for 1.2.6. But I think it would be very cool to have some terrestrial objects around that help to put the scale of the Earth in perspective. I don't know if anyone ever had the PC-based simulation called; "Shuttle" (early 90s), but there is an animation in it that pans around the globe and eventually centers in on Cape Canaveral where a Shuttle is sitting on the launch pad. The animation really added some perspective to how big the Earth is. Having various well-known objects here and there. Space Needle, CN Tower, Eiffel Tower, Pyramids, etc. would be pretty cool. Of course, I'm being completely ignorant regarding the feasability of such a feature. If I think of more, I'll let you know. Clint Weisbrod. At 02:36 PM 1/15/2003, Chris Laurel wrote: >On Tue, 14 Jan 2003, Chris Laurel wrote: > > > I thought that I'd share the list of features that I want to get into > > version 1.2.6 of Celestia. Christophe, I know that you already made a > > list . . . Fridger and Clint--I'd like to hear your interests and > > priorities too, so I can compile a complete list. > >I forgot an important one . . . > >Rework the directory structure >The fact that textures all must reside in the textures directory, meshes >in the models directory, and .xyz trajectories in the data directory >impedes organization of add-ons. With multiple directories now supported >for add-ons, it would be useful if textures/models/trajectories could be >loaded from the same directory in which the .ssc file is located. > > >I checked in a couple small changes today. One adds a NormalMap field to >.ssc files so that you don't have to use the BumpHeight 0.0 trick anymore >(though this was a nice find Fridger :) ). The other change prevents >Celestia from crashing when using CompressedTexture true with a DXT >texture. > >--Chris > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: A Thawte Code Signing Certificate >is essential in establishing user confidence by providing assurance of >authenticity and code integrity. Download our Free Code Signing guide: >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en >_______________________________________________ >Celestia-developers mailing list >Cel...@li... >https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Chris L. <cl...@ww...> - 2003-01-27 06:38:21
|
On Mon, 27 Jan 2003, Clint Weisbrod wrote: > Sorry for taking so long to reply to this. > > Here's my short feature wish-list for Celestia: > > - I'm in agreement with Fridger. It would be wonderful to have the ability > to clamp the observers orientation axes to a number of different coordinate > systems including alt-azimuth, ra-decl with a display of the current > coordinates of the center of the view. Yes . . . this could become the most compelling new feature of Celestia 1.2.6. I think it could broaden the audience for Celestia quite a lot. > - Perhaps this is counter to the general paradigm of Celestia, but I'd > someday like to see a gravity mode in Celestia where objects are given the > correct position and velocity for a particular time and are then subject to > the laws of gravity, rather than obeying (albeit highly accurate) functions > of position. This would be a large undertaking because the observer > position would also be subject to gravity and some facility to generate > varying amounts of "thrust" would seem like a desirable feature. As I said, > perhaps this kind of feature has no place in the Celestia paradigm. Celestia is designed around a simulation where the state of the universe is dependent only upon the time. This is convenient for planetarium program where you want to recreate and observe events in the distant past or future. It's not so great for integrating the paths of objects over time as they're affected by gravity . . . Celestia depends on random access of time. The only thing that isn't dependent only on time is the position of the observer--it might be possible to do something with the observer, or with some sort of observer-like entities that move in real-time, not simulation time. > - Need to fix the missing bitmaps in CVS for menu items. I could easily > check in new versions of these bitmaps under different names and modify the > .rc file accordingly. Chris, let me know if you feel this is likely to be > the only way to work around the CVS problem, if it can't be fixed. Ugh . . . I still haven't found a fix for this. I'll look at it some more tonight. > - Store the state of the window when Celestia is closed. If I close > Celestia when it is maximized, the next time I open Celestia, it should > return to the maximized state. A simple enhancement. Simple, yet useful . . . It'd be nice to save the last full-screen mode used as well. > - Removal of Altitude/Distance displays. Beyond 4 radii, the distance to an > object is measured from the center of the object. I'm not sure this is ever > relevant information. Perhaps it would be better to always display the > altitude value, but just call it distance. Maybe there is some argument for > leaving things as they are. Anyone? I agree . . . this is pretty pointless, and I think it's quite reasonable to define distance as "distance from surface" instead of "distance from center." > - Display of local sidereal time. If I was back in University again with > access to the observatory, I would really appreciate having a reliable > sidereal clock available. Local sidereal time implies knowledge of > geographical location. Once we have added facilities to store canned > locations and user-specified ones, the exact lat/long of a selected > location could be used to optionally display the local sidereal time. As an > aside, providing the local sidereal time is just the tip of the iceberg in > how we could cater to people using Celestia in observatories. I spent a lot > of late nights and early mornings in an observatory and there are other > features that could be added to Celestia that I would have really > appreciated. For instance, instead of just giving the local sidereal time, > it would have been great to have had the hour angle computed automatically > for any object. This would allow for very quick alignment to the object. I > suppose these days fewer amateur astronomers depend on sidereal clocks and > hour angles with the advent of self-aligning, smart telescopes that point > themselves at any object you want. Takes all the fun out of being in an > observatory, I think. Anyway, I'm starting ramble. Next item. This fits in the category of features that would make Celestia a better program for simulating Earth-based observing. Many of Fridger's wish list items are in this area, and a local sidereal time would complement them well. > - Addition of some well-known terrestrial objects on Earth. OK, maybe not > for 1.2.6. But I think it would be very cool to have some terrestrial > objects around that help to put the scale of the Earth in perspective. I > don't know if anyone ever had the PC-based simulation called; "Shuttle" > (early 90s), but there is an animation in it that pans around the globe and > eventually centers in on Cape Canaveral where a Shuttle is sitting on the > launch pad. The animation really added some perspective to how big the > Earth is. Having various well-known objects here and there. Space Needle, > CN Tower, Eiffel Tower, Pyramids, etc. would be pretty cool. Of course, I'm > being completely ignorant regarding the feasability of such a feature. This is a great feature for the future. I'm actually most interested in adding terrain patches, but human made landmarks would be cool too. I think it's something that will happen later than 1.2.6, however, as I'm still hoping to have the new version ready some time in February. I've compiled all of the wish lists in a single text file: http://www.shatters.net/~claurel/wishlists.txt If I find the time (ok, that's unlikely . . .) I may try and convert it to an HTML document, updating it steadily as features are completely. --Chris |
From: Fridger S. <t0...@ma...> - 2003-01-15 21:22:36
|
Chris, Christophe: > I thought that I'd share the list of features that I want to get into > version 1.2.6 of Celestia. Christophe, I know that you already made a > list . . . Fridger and Clint--I'd like to hear your interests and > priorities too, so I can compile a complete list. A number of my plans for 1.2.6 I have sent around partly several times already, but they apparently fell "under the table"; so here we go again;-): After the precision of Celestia has turned out so amazing, I want to spend considerable efforts to the important issue of "easy maneuvering and quantitative displays": a) Locations (data base <=XEphem, UI dialog, on Earth and elsewhere: Mars, Moon, landing sites,...) b) Macros for smooth landing on any location of any extended object + "lookback" (sky observer mode). c) /Time-setting/ optionally including /light travel time/ from observer to selection, very handy for precise "rare or delicate event display" (e.g. mutual Galilean events, Saturn moons, Uranus' moons...) d) 2 key easy (forward-backward) maneuvering by switching between coordinate systems and then moving in parallel to the respective coordinate axes: e.g. Alt-Azimuth: <= => azimuth; up, down: altitude Equatorial: <= => RA; ; up, down: declination Object Long-Lat : ... Ecliptical: ... e) RA, Dec (Alt-Az, lat-long),.../cursor readouts/; some of the present info in upper left corner of the display should go into Info popups (a la KDE-interface, pushing right mouse button, XEphem fans will like it;-)) f) Improved grids with subdivisions and orientation auto-adapting to FoV and to chosen coordinate system! g) Thinking about further clever applications of cel:// url's ! h) Searching for and /marking/ (invisible) objects on the display using name input including wildcards! i) Rework the unsystematic key-shortcut assignments if not yet too late.... --------------- (a): After I initiated this issue and Christophe & I already got on with it, we should probably continue our "proven" intensive interaction + debugging cooperation here;-)...I also plan to get more familiar with KDE such that I will not only be a "passenger" as to KDE-coding in the future. Should not be too hard given my background and Chrsitophe's patient explanations... The gtk(Gnome) interface should be largely rewritten, but I am not very hot about it for now...KDE is simply more fun and more popular (despite my intrinsic reservations;-)) (c) Since the VSOP87 calculations require quite a bit of floating point power, a /general/ incorporation of light travel delays might be too much (efficiency!) and actually not necessary for merely browsing through space! But when it comes to specific events, everyone of us who has been playing with them, will know what a tedious affair it is to first get the LT-delay from horizons, subtract it by hand from the earth-bound observer time and enter it in Celestia! I am thinking of a neat addition in the time setting dialog (based on the known distance between the observer and the selected object): Selection: xxxxx Light travel time to observer: xx:xx:xx Subtract Clicking "subtract" sets the exact UT time at the location of the object. I have quite a number of further ideas, but since 1.2.6 is supposed to come out within a month;-) I essentially shut up for now. Of course, we should at last complete a new default set of 2k textures, given the new possibilities, including separate dds normal maps for bumping, specs ... BUGS: ==== I really would appreciate if we could tackle at least these two nasty issues: 1) The "RIGHT-shift problem at small FoV (I take it that everyone knows what I mean!). The selection precision at the smallest FoV's could then become excellent given my recent algorithm. 2) The Linux "freeze" problem under full-screen switching (YES, Christophe has confirmed it;-)) and Chris promised a loooooooooooooooooong time ago: Dec 11:(Chris) I'll try and find out from one of them today why the driver is behaving so poorly in this circumstance. Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-27 20:44:25
|
Second thought's about DeepSkyObjects: -------------------------------------- On the one hand, I find Chris' plans of attacking the galaxy/nebulae rendering issue most challenging and worth considerable effort from all of us. On the other hand, thinking about possibilities for an actual realization of this challenge myself, confronts me with all sorts of doubts, warnings etc... Some thoughts that came up, might be useful to other minds as well;): 1) Introducing a new DepSky Object superclass etc in Celestia may involve big changes but this is nothing breathtaking. It simply can be done and makes a lot of sense in the long run. 2) 1st Warning: ------------ So far, deep sky objects led an "unspectacular life" in Celestia to the dismay of many;-). But looked at differently, this in a way was a very clever compromise, not unlike certain paintings, where faces of people are merely sketched rather than painted with a sophisticated expression and including many details. Have you ever looked at paintings with completely "rendered" faces? Very delicate, indeed! One touch to much may destroy the whole picture... The idea in this deep sky project is clearly to render deep sky objects in much more detail. Again: one touch to much might well destroy the professional overall impression of Celestia! The Orbit program for me is a good illustration of how things might go wrong along these lines. Some graphics is certainly comparable to Celestia. But certain things like buildings, airports etc. look like from a "Kindergarden" kit. That does it, at least for me... These remarks are NOT meant as discouragement, but I would be very eager to hear something that has a chance of bypassing/overcoming this danger. 3) Individually "handicrafted" deepsky objects along the lines of the various space vehicles we have in Celestiam, are clearly NOT what is required. In order to retain the necessary degree of "professionalism", we should think about a scheme allowing "mass production";-) of such objects from catalogs and/or image data bases! I have not read so far /any ideas/ from Chris in this context!? Am I dreaming or is the answer merely trivial?;-). Since my letters to Chris often end in "Nirwana", I rarely know.... 4) I do have a number of ideas myself, but since Chris has started off this topic, I would very much like to hear his ideas first. ...possibly to be continued... Bye Fridger |
From: Chris L. <cl...@ww...> - 2003-01-27 21:54:30
|
On Mon, 27 Jan 2003, Fridger Schrempp wrote: > Second thought's about DeepSkyObjects: > -------------------------------------- > > On the one hand, I find Chris' plans of attacking the galaxy/nebulae > rendering issue most challenging and worth considerable effort from > all of us. On the other hand, thinking about possibilities for > an actual realization of this challenge myself, confronts me with all > sorts of doubts, warnings etc... > > Some thoughts that came up, might be useful to other minds as well;): > > 1) Introducing a new DepSky Object superclass etc in Celestia may involve > big changes but this is nothing breathtaking. It simply can be done > and makes a lot of sense in the long run. In fact, I have all the necessary changes ready to check in. I was hoping to hear some opinions on the galaxies.dat backward compatibility issue first though. > > 2) 1st Warning: > ------------ > So far, deep sky objects led an "unspectacular life" > in Celestia to the dismay of many;-). But looked at differently, > this in a way was a very clever compromise, not unlike certain paintings, > where faces of people are merely sketched rather than painted with a > sophisticated expression and including many details. Have you ever > looked at paintings with completely "rendered" faces? Very > delicate, indeed! One touch to much may destroy the whole > picture... The idea in this deep sky project is clearly to > render deep sky objects in much more detail. Again: one touch to much > might well destroy the professional overall impression of Celestia! > > The Orbit program for me is a good illustration of how things might > go wrong along these lines. Some graphics is certainly comparable > to Celestia. But certain things like buildings, airports etc. look > like from a "Kindergarden" kit. That does it, at least for me... > > These remarks are NOT meant as discouragement, but I would be very > eager to hear something that has a chance of bypassing/overcoming this > danger. First of all, the new code is very flexible . . . Right now, there are two subclasses of DeepSkyObject: Galaxy and Nebula. Each overrides just two methods of the base class, load() to read in parameters from a file, and render() to display something. Galaxy's render() method uses code bulled from render.cpp for the fuzzy blob style rendering. The render method for Nebula just displays a 3DS mesh. But it would be simple to add new rendering techniques, either by updating Nebula::render or adding a new DeepSkyObject subclass. I don't expect 3DS meshes to be the last word in nebula rendering. But they do seem to produce satisfactory results. The best way to demonstrate this is for me to check in the deep sky object code and supply some test files to try yourself. > 3) Individually "handicrafted" deepsky objects along the lines of the various > space vehicles we have in Celestiam, are clearly NOT what is required. > In order to retain the necessary degree of "professionalism", we should > think about a scheme allowing "mass production";-) of such objects > from catalogs and/or image data bases! > > I have not read so far /any ideas/ from Chris in this context!? Am I > dreaming or is the answer merely trivial?;-). Since my letters to > Chris often end in "Nirwana", I rarely know.... I have a few ideas to try . . . There are plent of images of nebula to use, and some from sky surveys even have consistent orientation. But stars would still need to be removed from the images. We could apply the images to meshes modified by noise, generating texture coordinates that give exactly the right appearance from Earth, and a 3D appearance from other viewpoints that might not be corret, but will at least look better than a flat square :) Some sort of volumetric rendering technique would be ideal, but this could be incorpolrated later. With planetary nebula, the 3D structure is usually more apparent . . . When looking at Hubble pictures, it's easy to get a good mental picture of what the geometry of the object is. However, I don't know how to automate the creation of a mesh from just the picture; it seems like it would have to be done by hand to get the best results. > 4) I do have a number of ideas myself, but since Chris has started off > this topic, I would very much like to hear his ideas first. Now let's hear your ideas . . . :> --Chris |
From: Christophe T. <ch...@te...> - 2003-01-24 01:51:19
|
On Saturday 11 January 2003 13:12, Fridger Schrempp wrote: > 1) Go to Callisto, say. Put it at some distance and approach it after > hitting F3 with 1000km/sec, watching the altimeter. Now push '*'. You are > looking back now, but the altitude continues to decrease. Pushing '*' > again, you'll see Callisto again and it is much closer now... I knew there was a trick to it. It does work this way as long as you don't change the orientation of the observer using the arrow keys (or keypad), but using the mouse is ok. Once the orientation has been altered this way, as Clint noted, reversing the orientation does reverse the velocity. -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-01-25 15:02:04
|
Christophe Teyssier wrote: > > On Saturday 11 January 2003 13:12, Fridger Schrempp wrote: > > 1) Go to Callisto, say. Put it at some distance and approach it after > > hitting F3 with 1000km/sec, watching the altimeter. Now push '*'. You are > > looking back now, but the altitude continues to decrease. Pushing '*' > > again, you'll see Callisto again and it is much closer now... > > I knew there was a trick to it. It does work this way as long as you don't > change the orientation of the observer using the arrow keys (or keypad), but > using the mouse is ok. > > Once the orientation has been altered this way, as Clint noted, reversing the > orientation does reverse the velocity. > > -- > Christophe > Christophe: thanks, this was a tricky one;-). The bug is not in my routine Simulation::reverseObserverOrientation(). Actually, the problem arose from within the method 'Simulation::setTargetSpeed(float s)' which is called when the orientation is changed by means of the UP, DOWN etc keys. In setTargetSpeed(), observer.getOrientation() (that is /flipped/ after pushing '*') is used to set the target speed vector...that's where it happens! To get things right, I have merely added in the '*' key command (celestiacore.cpp) the reverse action, i.e. case '*': addToHistory(); sim->reverseObserverOrientation(); sim->setTargetSpeed(-sim->getTargetSpeed()); <============= break; Here is my test case: cel://Follow/Sol:Jupiter:Callisto/2003-01-25T14:20:33.41?x=iDhtqWJ9/e+EDA&y=0rG73wAvJQQB&z=BQguZ4uNFunB/////////w&ow=0.940383&ox=0.218265&oy=0.256437&oz=-0.047757&select=Sol:Jupiter:Callisto&fov=45.000000&ts=1.000000&rf=22231&lm=0 Get Callisto moving by hitting F3. It will approach you as the distance display shows. If you hit '*' you merely turn back, but the distance continues to /decrease/. Hit '*' once more to return to the initial configuration. Next use the UP or DOWN key to move onto the opposite site of Callisto. It now /increases/ its distance, which is correct. Next hit '*' you are looking /towards/ Callisto now and it continues to /move away/, which is new and also correct;-)... After some further testing and awaiting your confirmation, I shall commit the fix. I am happy to see your nice Goto Long/Lat code finally committed as well as your Mandrake RPM's & Sources at last on SourceForge;-). Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-25 15:24:14
|
Christophe: just for completeness: since a long time, I am getting the following warning when I am running libtoolize --automake --force aclocal -I macros autoheader automake autoconf in my sandbox: src/celestia/Makefile.am:14: celestia_DEPENDENCIES was already defined in condition ENABLE_GTK_FALSE ENABLE_KDE_TRUE, which is implied by condition TRUE celestia_DEPENDENCIES (User, where = 14) = { ENABLE_GTK_FALSE ENABLE_KDE_TRUE => kde/libkdegui.a } Any ideas? My packages are automake 1.5 autoconf 2.5.2 Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-01-25 15:31:59
|
On Saturday 25 January 2003 16:21, Fridger Schrempp wrote: > Christophe: > src/celestia/Makefile.am:14: celestia_DEPENDENCIES was already defined in > condition ENABLE_GTK_FALSE ENABLE_KDE_TRUE, which is implied by condition > TRUE > > celestia_DEPENDENCIES (User, where = 14) = > { > ENABLE_GTK_FALSE ENABLE_KDE_TRUE => kde/libkdegui.a > } > > > Any ideas? My packages are > > automake 1.5 > autoconf 2.5.2 Mines are 1.6.3 and 2.5.3. I don't get this warning, I had to add celestia_DEPENDENCIES = kde/libkdegui.a in src/celestia/Makefile.am because otherwise this dependency wasn't satisfied. May be you can try commenting out that line and see if after a touch src/celestia/kde/libkdegui.a celestia is rebuild. By the way on my system the other .a dependencies are not satisfied either, if celengine/libcelengine.a is modified I have to manualy do a rm src/celestia/celestia to get it rebuild. -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-01-26 13:20:33
|
Christophe: sorry, now the subtraction of the LT-delay works in the time setting dialog. I simply cannot get used to this "automatic" philosophy in KDE: Only after doing a full new install, the time setting works... Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-01-25 15:23:54
|
On Saturday 25 January 2003 15:58, Fridger Schrempp wrote: > After some further testing and awaiting your confirmation, I shall commit > the fix. Yes, that works! Now what'd be nice is to have similar look left/right/up/down/forward functions. > I am happy to see your nice Goto Long/Lat code finally committed as well as > your Mandrake RPM's & Sources at last on SourceForge;-). But sadly the textures are still missing, Chris had some problems with the SF upload system... -- Christophe |
From: Fridger S. <t0...@ma...> - 2003-01-25 17:40:51
|
Christophe: As I have detailed in my list for 1.2.6, I think an entry in the time setting dialog (KDE of course;-)) that allows an easy inclusion of the light-travel-delay to the selected object would be very useful: (c) Since the VSOP87 calculations require quite a bit of floating point power, a /general/ incorporation of light travel delays might be too much (efficiency!) and actually not necessary for merely browsing through space! But when it comes to specific events, everyone of us who has been playing with them, will know what a tedious affair it is to first get the LT-delay from horizons, subtract it by hand from the earth-bound observer time and enter it in Celestia! I am thinking of a neat addition in the time setting dialog (based on the known distance between the observer and the selected object): Selection: xxxxx Light travel time to observer: xx:xx:xx Subtract Clicking "subtract" sets the exact UT time at the location of the object. I have experimented with the accuracy of getting the LT-delay from the known distance in Celestia: double lt = astro::lightYearsToKilometers(distance)/astro::speedOfLight; and confirmed by comparison with horizons that the result from Celestia is very accurate within the solar system. So what do you think: it should be very easy to incorporate the above addition to the time setting dialog. I simply hesitate to fiddle around with the KDE-stuff which I do not understand well enough. Bye Fridger |
From: Fridger S. <t0...@ma...> - 2003-01-26 10:48:47
Attachments:
light-travel.patch.bz2
|
Christophe: I attach what I have been doing yesterday, for anyone to play with. It is an OS-independent, handy, key-shortcut implementation of a light travel (LT) delay scheme: If the selection is not empty, '?' : displays the LT-delay in [hr:min:sec] (for hr > 0, LT-delay < 1day) or [min:sec] (for hr = 0, LT-delay < 1day) or [yr] (for LT-delay >= 1day) from the /observer to the selection/, as a 2 sec /flash/ message. If the selection is a 'body', '-' : subtracts the LT-delay from the actual (JD) time. The modified time is displayed as usual in the top right corner. Moreover, a 2 sec flash message displays again the LT-delay that has been subtracted. I have conducted extensive tests of the LT accuracy computed via the known distance in Celestia for bodies within the Solar system versus horizons and found it practically /perfect/. Given its simplicity and mnemnonical key-assignment ('?' (LT?), '-' (subtract)), I found this /very/ handy for doing quantitative work, e.g. like mutual satellite events etc. I am thinking of realizing the '-' operation as a toggle? Note: that my patch /includes/ the previous patch to 'lookback' ('*'-key) Please, let me know what you think, Bye Fridger PS: The patch defines two new public methods void CelestiaCore::getLightTravelDelay(double distance, int& hours, int& mins, float& secs) void CelestiaCore::setLightTravelDelay(double distance) that you might also use in the GUI implementation |
From: Chris L. <cl...@ww...> - 2003-01-26 19:02:56
|
On Sun, 26 Jan 2003, Fridger Schrempp wrote: > Christophe: > > I attach what I have been doing yesterday, for anyone to play with. It is an > OS-independent, handy, key-shortcut implementation of a light travel (LT) delay > scheme: > > If the selection is not empty, > > '?' : displays the LT-delay in [hr:min:sec] (for hr > 0, LT-delay < 1day) > or [min:sec] (for hr = 0, LT-delay < 1day) > or [yr] (for LT-delay >= 1day) > > from the /observer to the selection/, as a 2 sec /flash/ message. > > If the selection is a 'body', > > '-' : subtracts the LT-delay from the actual (JD) time. The modified time > is displayed as usual in the top right corner. Moreover, a 2 sec > flash message displays again the LT-delay that has been subtracted. > > > I have conducted extensive tests of the LT accuracy computed via the known > distance in Celestia for bodies within the Solar system versus horizons and > found it practically /perfect/. Given its simplicity and mnemnonical > key-assignment ('?' (LT?), '-' (subtract)), I found this /very/ handy for doing > quantitative work, e.g. like mutual satellite events etc. > > I am thinking of realizing the '-' operation as a toggle? > > Note: that my patch /includes/ the previous patch to 'lookback' ('*'-key) > > Please, let me know what you think, Nice work, Fridger . . . I think that these additional keyboard commands are a reasonable compromise between convenience when viewing celestial phenomena and calculation time. At some point, I would like to introduce an option to turn on light time delay, but your change solves a big part of the problem. You should check in the light time addition. --Chris |
From: Fridger S. <t0...@ma...> - 2003-01-26 19:18:46
|
Chris Laurel wrote: > > On Sun, 26 Jan 2003, Fridger Schrempp wrote: > > > Christophe: > > > > I attach what I have been doing yesterday, for anyone to play with. It is an > > OS-independent, handy, key-shortcut implementation of a light travel (LT) delay > > scheme: > > > > If the selection is not empty, > > > > '?' : displays the LT-delay in [hr:min:sec] (for hr > 0, LT-delay < 1day) > > or [min:sec] (for hr = 0, LT-delay < 1day) > > or [yr] (for LT-delay >= 1day) > > > > from the /observer to the selection/, as a 2 sec /flash/ message. > > > > If the selection is a 'body', > > > > '-' : subtracts the LT-delay from the actual (JD) time. The modified time > > is displayed as usual in the top right corner. Moreover, a 2 sec > > flash message displays again the LT-delay that has been subtracted. > > > > > > I have conducted extensive tests of the LT accuracy computed via the known > > distance in Celestia for bodies within the Solar system versus horizons and > > found it practically /perfect/. Given its simplicity and mnemnonical > > key-assignment ('?' (LT?), '-' (subtract)), I found this /very/ handy for doing > > quantitative work, e.g. like mutual satellite events etc. > > > > I am thinking of realizing the '-' operation as a toggle? > > > > Note: that my patch /includes/ the previous patch to 'lookback' ('*'-key) > > > > Please, let me know what you think, > > Nice work, Fridger . . . I think that these additional keyboard commands > are a reasonable compromise between convenience when viewing celestial > phenomena and calculation time. At some point, I would like to introduce > an option to turn on light time delay, but your change solves a big part > of the problem. You should check in the light time addition. > > --Chris Chris: Christophe and I worked much of today together, testing and improving also the KDE GUI implementation of this, as you may read yourself in the bulk of list mail exchanged...;-) I can't deny it, I quite like it as it it is and it is really practical and most accurate for entering the time setting for precision events...So what is missing, is the Windows implementation in the time setting dialog;-)... Bye Fridger |
From: Christophe T. <ch...@te...> - 2003-01-26 00:31:54
Attachments:
lt.patch.bz2
|
On Saturday 25 January 2003 18:37, Fridger Schrempp wrote: > Christophe: > Selection: xxxxx Light travel time to observer: xx:xx:xx Subtract > > Clicking "subtract" sets the exact UT time at the location of > the object. > > I have experimented with the accuracy of getting the LT-delay from the > known distance in Celestia: > > double lt = > astro::lightYearsToKilometers(distance)/astro::speedOfLight; > > and confirmed by comparison with horizons that the result from Celestia is > very accurate within the solar system. So what do you think: it should be > very easy to incorporate the above addition to the time setting dialog. I > simply hesitate to fiddle around with the KDE-stuff which I do not > understand well enough. If that compiles it basically does what you asked. The option is available only if the selection is a 'Body'. -- Christophe |