Celestia Development Roadmap
Re: Celestia Development Roadmap
Tell all of your windows friends to download combined community codec pack. They will have no problem playing those formats. It even comes with two players one of which is media player classic.
-
t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Re: Celestia Development Roadmap
Reiko wrote:Tell all of your windows friends to download combined community codec pack. They will have no problem playing those formats. It even comes with two players one of which is media player classic.
Yes Reiko,
that would be one solution. The other more elegant and cross-platform solution is to just install the VLC player along with its Mozilla-Firefox plugin and you can forget about all extra codec downloads. VLC just plays EVERYTHING very well.
http://www.videolan.org/
Right now there is a little problem with the Mozilla plugin. So for people using Firefox, this is the appropriate download:
http://nightlies.videolan.org/build/win32/latest/
Fridger
-
John Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
Re: Celestia Development Roadmap
--- edit ---
Last edited by John Van Vliet on 21.10.2013, 02:28, edited 1 time in total.
-
ElChristou
- Developer
- Posts: 3776
- Joined: 04.02.2005
- With us: 19 years 9 months
Re: Celestia Development Roadmap
As this thread is about the Celestia roadmap, Chris could you do a check of the roadmap in the wikibook? (seems some features are mixed now between the several next version but I'm not that sure.)
About 1.7, what about doing a version only for the QT change + some old time fixing and polishing? Then again we could have a strong basis for the future HDR and others implementation... Opinion?
About 1.7, what about doing a version only for the QT change + some old time fixing and polishing? Then again we could have a strong basis for the future HDR and others implementation... Opinion?
-
John Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
Re: Celestia Development Roadmap
--- edit ---
Last edited by John Van Vliet on 21.10.2013, 02:29, edited 1 time in total.
Re: Celestia Development Roadmap
I believe that Celestia can already be built 64-bit for Linux and Mac OS X.
Check the following. We might not want to forget:
viewtopic.php?t=10818&postdays=0&postorder=asc&start=15
Check the following. We might not want to forget:
viewtopic.php?t=10818&postdays=0&postorder=asc&start=15
Re: Celestia Development Roadmap
Wow!
Well, I just installed 1.5.1 since 1.4 was on a different partition on this OS X box and I could not run it off of that partition (probably because the CelestiaResources (as we call it here in Mac-Land) was not in the correct path anymore).
So, first of all, let me say I 100% agree with Qt. I have been using Qt 3.x for years for Windows development and I can tell you there is no way you'd find this GUI any different from any other Windows application. Indeed, with Qt, you can build a number of different UI Look-and-feels, including KDE (of course), Mac OS X and even IIRC OS 9. Thus, I could even make my WIndows application look like an OS X app. But, the point is, Qt's multi-platform support is very well integrated with supporting a Native look-and-feel and gets my vote for the unified GUI.
Now, as far as Cham's reticence to install any package that requires 'Additional Libraries', I suggest we simply provide Celestia in 2 formats for each platform: Dynamically linked with Qt and Statically Linked with Qt. The Statically linked version would be monolithic and not require any additional libraries. Obviously, the download page should not that the Dynamically linked version is preferred if Qt is already installed or might be installed some time in the future, but if you simply MUST have a stand-alone, then the statically linked version is just that.
The nice thing about this approach is that it becomes a link-time issue, since we can have pre-built Qt dynamically built and statically built libraries. In terms of building, I'm not sure if the Qt license allows us to include the static Qt library in the source package, but this would also solve the potential issue when someone wants to install from source without installing any additional libraries. Personally, I prefer the dynamic linking because of the potential for duplicated libraries installed, but so be. In the end, if someone wants a stand-alone, I say we simply give that person a statically linked version of Celestia. And in truth, I agree on a Mac OS X system, I really don't like installing extra libraries for applications. I'd rather there be redundant libraries in my .app file since if everything is contained in the .app file, I can easily toss the whole thing in the trash when I need to get rid of it and don't need to run some obscure uninstaller. Thus, static linking would suit me well on a Mac.
Now, I haven't personally dealt with KDElib and the APIs it exports above and beyond Qt but why do we need KDElib vs. Qt again? In my experience, Qt is pretty robust with respect to GUI development and in fact we choose Qt BECAUSE of it's ability to generate cross-platform native look-and-feel GUIs.
Also, as far as video playback, may I just say that personally, I want something that will play on my Apple TV, and even Matroska MKV files can't do that without a complete codec decode-recode. Mind you, Apple is mighty proprietary with their specific tweaks of the H.264 spec and the features they don't allow, but it would be nice if I could just drag my exports into iTunes and then watch them on my telly. If only I could run VLC on my Apple TV...
Oh, and BTW, 2012 is when the Mayan calendar resets, so it's a big joke that that is the end of the world -- IMHO, the dawning of the Age of Aquarius as we exit the Age of Pisces in our 26,000 year precession around our shifting Equinox is still the bigger news, though I suppose for folks 2000 years ago leaving the Age of Aries for Pisces it was bigger news.
Language could be implemented in at least 2 ways in Celestia: 1, Qt's Linguist will help generate a language database that can be used to generate the correct language for a given user. Otherwise, there is the ISO C++ std::message library which can be tied to a locale and is meant to perform the basic same purpose of a language library. There are of course other ways, and I know Celestia has partial support for dynamic languages, but as has been mentioned and being able to choose a language that contradicts the default system settings would be useful IMHO. And, like in ISO C++ I should hope these languages would be stored in the ISO canonical fashion as la_NA where la is the language code and NA is the national localization code, such as US or BRazilian.
Personally, I also like the idea of Python integration but I don't think wxPython is the way to go -- as I said, I prefer Qt -- but rather have Python as a scripting language back-end. Python scripts aren't that hard to write or learn and it has the added benefit of being one of the more legible scripting languages out there.
Then, I would like to touch the topic of Terrain generation. It seems to me we should NOT try and create accurate terrain models for the simple reason that, as has already been stated by scaddenp, the amount of data required -- at least until we start talking about Petabyte hard disks. However, a good Open-Source Fractal library may be a cheap and easy way achieve 'realistic' landscapes without having to go into the absolute detail of landscapes. Then, maybe a 'roughness' parameter could be provided for each landscape over a wide region of terrain that would be used as a parameter for the Fractal engine that would control how high the mountains in the specific region were. The Himalayas could have a very high roughness and the great western plains of North America could have 0 roughness. In any case, my vote would be for the distant time frame, e.g. 2.x+.
Oh, and I'll cast a vote for the binary star system POV problem. If I go to Alpha Centauri, I would generally expect to be sent to a point where my Field of View at 1.00 would allow me to view all 3 stars at once.
Finally, I have to bring up my topic from what, 2004 or something, namely the ability to observe relativistic effects when traveling fast as an option. Namely, allow near infinite speed from the POV of our zero-mass camera but do things like pinch the window and the FOV as we accelerate to simulate the Lorenz contractions. Then, add the ability to frequency-shift the view toward the red and blue for speeds that would not shift the view beyond the visible spectrum. Of course, it would be interesting if radio sources suddenly become visible as we reached sufficient speed, but let's not get carried away. Though, adding the ability to view stars and other astronomical bodies in Gamma, X-/R?ntgen-Ray, Ultra-Violet, Infra-Red, Microwave and Radio Wave frequencies [like Geordi from Star Trek: The Next Generation] would be neat. But I digress. Anyway, the other thing I think would be neat would be to manipulate the clock as we approached infinite speed to demonstrate time dilation from the POV of our zero-mass camera. That is to say, we could never travel faster than light with respect to an Earth observer, but it would SEEM like we were because our time would be dilated so our perceived velocity would be faster than light. I hope that makes sense. Also, I think we should allow times in access of 20 Gyr, since it looks like the Universe will be around for a LOT longer than that, and an inter-Galactic view may be interesting to simulate on those timescales as stars slowly burn out and get consumed by bigger and bigger black holes and then those black holes eventually evaporate. I know, that is currently beyond Celestia to animate galactic motion, but allowing the much larger timescale would allow for such features to be added eventually in say an add-on. Mainly, I just love seeing relativistic speeds simulated and hope that can one day be added to Celestia as it would also give a proper realism for people considering interstellar travel.
Well, those be my thoughts for things. I may check out the latest source and take a crack at some of these features myself as I still love Celestia!
Well, I just installed 1.5.1 since 1.4 was on a different partition on this OS X box and I could not run it off of that partition (probably because the CelestiaResources (as we call it here in Mac-Land) was not in the correct path anymore).
So, first of all, let me say I 100% agree with Qt. I have been using Qt 3.x for years for Windows development and I can tell you there is no way you'd find this GUI any different from any other Windows application. Indeed, with Qt, you can build a number of different UI Look-and-feels, including KDE (of course), Mac OS X and even IIRC OS 9. Thus, I could even make my WIndows application look like an OS X app. But, the point is, Qt's multi-platform support is very well integrated with supporting a Native look-and-feel and gets my vote for the unified GUI.
Now, as far as Cham's reticence to install any package that requires 'Additional Libraries', I suggest we simply provide Celestia in 2 formats for each platform: Dynamically linked with Qt and Statically Linked with Qt. The Statically linked version would be monolithic and not require any additional libraries. Obviously, the download page should not that the Dynamically linked version is preferred if Qt is already installed or might be installed some time in the future, but if you simply MUST have a stand-alone, then the statically linked version is just that.
The nice thing about this approach is that it becomes a link-time issue, since we can have pre-built Qt dynamically built and statically built libraries. In terms of building, I'm not sure if the Qt license allows us to include the static Qt library in the source package, but this would also solve the potential issue when someone wants to install from source without installing any additional libraries. Personally, I prefer the dynamic linking because of the potential for duplicated libraries installed, but so be. In the end, if someone wants a stand-alone, I say we simply give that person a statically linked version of Celestia. And in truth, I agree on a Mac OS X system, I really don't like installing extra libraries for applications. I'd rather there be redundant libraries in my .app file since if everything is contained in the .app file, I can easily toss the whole thing in the trash when I need to get rid of it and don't need to run some obscure uninstaller. Thus, static linking would suit me well on a Mac.
Now, I haven't personally dealt with KDElib and the APIs it exports above and beyond Qt but why do we need KDElib vs. Qt again? In my experience, Qt is pretty robust with respect to GUI development and in fact we choose Qt BECAUSE of it's ability to generate cross-platform native look-and-feel GUIs.
Also, as far as video playback, may I just say that personally, I want something that will play on my Apple TV, and even Matroska MKV files can't do that without a complete codec decode-recode. Mind you, Apple is mighty proprietary with their specific tweaks of the H.264 spec and the features they don't allow, but it would be nice if I could just drag my exports into iTunes and then watch them on my telly. If only I could run VLC on my Apple TV...
Oh, and BTW, 2012 is when the Mayan calendar resets, so it's a big joke that that is the end of the world -- IMHO, the dawning of the Age of Aquarius as we exit the Age of Pisces in our 26,000 year precession around our shifting Equinox is still the bigger news, though I suppose for folks 2000 years ago leaving the Age of Aries for Pisces it was bigger news.
Language could be implemented in at least 2 ways in Celestia: 1, Qt's Linguist will help generate a language database that can be used to generate the correct language for a given user. Otherwise, there is the ISO C++ std::message library which can be tied to a locale and is meant to perform the basic same purpose of a language library. There are of course other ways, and I know Celestia has partial support for dynamic languages, but as has been mentioned and being able to choose a language that contradicts the default system settings would be useful IMHO. And, like in ISO C++ I should hope these languages would be stored in the ISO canonical fashion as la_NA where la is the language code and NA is the national localization code, such as US or BRazilian.
Personally, I also like the idea of Python integration but I don't think wxPython is the way to go -- as I said, I prefer Qt -- but rather have Python as a scripting language back-end. Python scripts aren't that hard to write or learn and it has the added benefit of being one of the more legible scripting languages out there.
Then, I would like to touch the topic of Terrain generation. It seems to me we should NOT try and create accurate terrain models for the simple reason that, as has already been stated by scaddenp, the amount of data required -- at least until we start talking about Petabyte hard disks. However, a good Open-Source Fractal library may be a cheap and easy way achieve 'realistic' landscapes without having to go into the absolute detail of landscapes. Then, maybe a 'roughness' parameter could be provided for each landscape over a wide region of terrain that would be used as a parameter for the Fractal engine that would control how high the mountains in the specific region were. The Himalayas could have a very high roughness and the great western plains of North America could have 0 roughness. In any case, my vote would be for the distant time frame, e.g. 2.x+.
Oh, and I'll cast a vote for the binary star system POV problem. If I go to Alpha Centauri, I would generally expect to be sent to a point where my Field of View at 1.00 would allow me to view all 3 stars at once.
Finally, I have to bring up my topic from what, 2004 or something, namely the ability to observe relativistic effects when traveling fast as an option. Namely, allow near infinite speed from the POV of our zero-mass camera but do things like pinch the window and the FOV as we accelerate to simulate the Lorenz contractions. Then, add the ability to frequency-shift the view toward the red and blue for speeds that would not shift the view beyond the visible spectrum. Of course, it would be interesting if radio sources suddenly become visible as we reached sufficient speed, but let's not get carried away. Though, adding the ability to view stars and other astronomical bodies in Gamma, X-/R?ntgen-Ray, Ultra-Violet, Infra-Red, Microwave and Radio Wave frequencies [like Geordi from Star Trek: The Next Generation] would be neat. But I digress. Anyway, the other thing I think would be neat would be to manipulate the clock as we approached infinite speed to demonstrate time dilation from the POV of our zero-mass camera. That is to say, we could never travel faster than light with respect to an Earth observer, but it would SEEM like we were because our time would be dilated so our perceived velocity would be faster than light. I hope that makes sense. Also, I think we should allow times in access of 20 Gyr, since it looks like the Universe will be around for a LOT longer than that, and an inter-Galactic view may be interesting to simulate on those timescales as stars slowly burn out and get consumed by bigger and bigger black holes and then those black holes eventually evaporate. I know, that is currently beyond Celestia to animate galactic motion, but allowing the much larger timescale would allow for such features to be added eventually in say an add-on. Mainly, I just love seeing relativistic speeds simulated and hope that can one day be added to Celestia as it would also give a proper realism for people considering interstellar travel.
Well, those be my thoughts for things. I may check out the latest source and take a crack at some of these features myself as I still love Celestia!
Re: Celestia Development Roadmap
Not sure if this has been mentioned but something I would like to see in the roadmap is 3D mouse support like the Space Navigator from 3D Connexion (http://www.3dconnexion.com). There's a hundred supported apps (http://www.3dconnexion.com/solutions/ca ... up_app.php) includng Autocad, 3dsmax to Google Earth, Virtual Earth 3D and Nasa World Wind.
-
John Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
Re: Celestia Development Roadmap
--- edit ---
Last edited by John Van Vliet on 21.10.2013, 02:28, edited 1 time in total.
Re: Celestia Development Roadmap
What would be handy in movement would be spirals,
they can be used to simulate the falling of objects into black holes and onto other bodies
they can be used to simulate the falling of objects into black holes and onto other bodies
Re: Celestia Development Roadmap
I am anxiously waiting to see what's new?! There was no release post 1.6. What is next? 1.7, 2.0?
Re: Celestia Development Roadmap
Celestia v1.6.1 is expected momentarily. It will be strictly a bug-fix release with no new features except for some improved translations.
Celestia v1.7/2.0 is currently in development. I suspect it will be called 2.0 if the user interface change to QT actually happens. It's quite easy to build v1.7 under Windows if you follow the instructions that are in the Celestia reference manual on WikiBooks. See http://en.wikibooks.org/wiki/Celestia/D ... 2_platform
Celestia v1.7/2.0 is currently in development. I suspect it will be called 2.0 if the user interface change to QT actually happens. It's quite easy to build v1.7 under Windows if you follow the instructions that are in the Celestia reference manual on WikiBooks. See http://en.wikibooks.org/wiki/Celestia/D ... 2_platform
Selden
Re: Celestia Development Roadmap
Does the latest 1.7 have the new star rendering Chris made?selden wrote:Celestia v1.6.1 is expected momentarily. It will be strictly a bug-fix release with no new features except for some improved translations.
Celestia v1.7/2.0 is currently in development. I suspect it will be called 2.0 if the user interface change to QT actually happens. It's quite easy to build v1.7 under Windows if you follow the instructions that are in the Celestia reference manual on WikiBooks. See http://en.wikibooks.org/wiki/Celestia/D ... 2_platform
Re: Celestia Development Roadmap
Such code as there is is included but it is disabled by default because it is incomplete.
Selden
Re: Celestia Development Roadmap
That explains why I'm not seeing the new rendering.selden wrote:Such code as there is is included but it is disabled by default because it is incomplete.
Re: Celestia Development Roadmap
Hi everyone!
While I was manipulating the orbits of the planets of my fictional solar system I discovered the fact, that after a certain distance from the star the objects are not visible anymore (I was extending the orbit of an object to another solar system, simulating a "visiting" alien space ship...
)
Although it might sound stupid, I think solving this problem might contribute to making Celestia more and more realistic... So what about this:
- correct the program, so it simulates objects that are even on courses from galaxy to galaxy
- make it possible to generate a "one-way-course" for a space ship or asteroid... possibly with multiple "course-corrections" on the way (like for example a "manned asteroid", that travels between solar systems...)
- or, if this is impossible, give the option for an object to have "two" centers of gravity, like two different suns, an intersolar planet if you want...
PS: I totally have no idea of programming and such things, just enjoying the greatness of Celestia
While I was manipulating the orbits of the planets of my fictional solar system I discovered the fact, that after a certain distance from the star the objects are not visible anymore (I was extending the orbit of an object to another solar system, simulating a "visiting" alien space ship...
)Although it might sound stupid, I think solving this problem might contribute to making Celestia more and more realistic... So what about this:
- correct the program, so it simulates objects that are even on courses from galaxy to galaxy
- make it possible to generate a "one-way-course" for a space ship or asteroid... possibly with multiple "course-corrections" on the way (like for example a "manned asteroid", that travels between solar systems...)
- or, if this is impossible, give the option for an object to have "two" centers of gravity, like two different suns, an intersolar planet if you want...
PS: I totally have no idea of programming and such things, just enjoying the greatness of Celestia
Re: Celestia Development Roadmap
Could you attach the data you are working with so it can be debugged?Vorcha wrote:Hi everyone!
While I was manipulating the orbits of the planets of my fictional solar system I discovered the fact, that after a certain distance from the star the objects are not visible anymore (I was extending the orbit of an object to another solar system, simulating a "visiting" alien space ship...
Re: Celestia Development Roadmap
habitable zones?
3d supernovae, nebulae?
moar stars?
3d supernovae, nebulae?
moar stars?
Re: Celestia Development Roadmap
ni1s wrote:Could you attach the data you are working with so it can be debugged?Vorcha wrote:Hi everyone!
While I was manipulating the orbits of the planets of my fictional solar system I discovered the fact, that after a certain distance from the star the objects are not visible anymore (I was extending the orbit of an object to another solar system, simulating a "visiting" alien space ship...
Celestia does not display SSC objects if the viewpoint is more than one Light Year from the star or barycenter that they orbit. Unless they're in the middle of a cluster, most stars are separated by more than 1LY.
Selden