Celestia Forums

There are a number of bugs that need to get fixed for 1.5.0 final but haven't been addressed yet. A big part of that has been lack of developer time. Another problem is that this forum and the developer list have been the only means of tracking bugs, and it's very easy to lose track of bug status. In the past, we've used SourceForge's bug tracking system, and I'd like to start using it again. The bug tracker is here:

https://sourceforge.net/tracker/?atid=1 ... unc=browse

There is a separate tracker for feature requests:

https://sourceforge.net/tracker/?group_ ... tid=371302

Anyone can browse the bug database, but you need to have a free SourceForge account to file new bugs and feature requests. If you've got a problem with the latest 1.5.0 prerelease and you want to see it addressed, the best way to do that is to open a new bug on the SourceForge bug tracker, even if it's already been discussed at some length on this forum.

Before filing a new bug, you should take a few steps to make the lives of the developers a little bit easier:

- Check the FAQ (http://www.shatters.net/forum/viewtopic.php?t=2291) to make sure that your issue isn't already addressed there.
- If you're reporting a problem that involves incorrect drawing--flashing, corrupt geometry, or other artifacts--update your graphics card drivers and see if that fixes things.
- Scan the bug list to see if someone else has already reported your problem.

The less time we have to spend eliminating spurious and duplicate bugs from the bug tracker, the more time we have to invest in fixing bugs and adding features.

--Chris

I'll try to make a list of bugs that I'm experiencing with the current CVS version, later this week. There are many annoying bugs (I've identified about 12 bugs), and IMHO, Celestia 1.5.0 is currently not ready for a general "final" release.

Cham wrote:I'll try to make a list of bugs that I'm experiencing with the current CVS version, later this week. There are many annoying bugs (I've identified about 12 bugs), and IMHO, Celestia 1.5.0 is currently not ready for a general "final" release.

Agreed that there's lots of stuff to fix. It'd be great for me if you could add your bugs and feature requests to the tracker. It should also make it easier for you to keep track of progress on fixes.

--Chris

I'm now giving my list of annoying bugs in Celestia CVS. I'll also publish it on the bug tracker page :


List of annoying bugs in Celestia 1.5.0 (latest CVS version), in random order :

1- Background orbital paths tends to have intermittent and moving "holes" or may shows onscreen as dashed paths, while moving around a model on the foreground (asteroid or spacecraft). This bug never occurs if there is no model showing on the foreground, so it's clearly related to the presence of a foreground object.

2- ??? All Models tends to have many tiny white dots (one pixel wide) around their edges. Those white dots are moving randomly. They may be related to the FSAA rendering of the video card, but they never occured with Celestia 1.4.2. This bug was also identified by Chris, with his new NVidia card. ???

3- The new atmosphere rendering may show some "interference like" patterns in the atmosphere's thickness. This bug was also identified by Chris. It's noticeable especially on "thick" atmosphere.

4- The new atmosphere code has some huge problems with multi sources of light. The atmosphere becomes vivid if there is more than one close range star to the planet.

5- The cloud shadows don't work at all on my system (with OpenGL 2 enabled). I get a crawling frame rate and a dark Earth instead, if the cloud shadows option is enabled.

6- There are some very large black "holes" on the sky rendering, while moving very close to a planet surface. This bug was also described by Fridger.

7- Stars are losing abruptly their glare effect if the observer is getting at some distance. This problem is general and affect all stars. The glare may still be there, at some distance, but I can clearly see a kind of "luminosity jump" if I move a bit farther or closer.

8- While not exactly a bug, I hate the new stars without any atmosphere. It feels very unrealistic at close range (surface too sharp, solid like), and the texture is lame, pale, without any contrast. The stars lost their "individuality" and are now boring to look at. A slim atmosphere should be added to the stars, so we don't get that sharp "solid like" surface, at close range. Maybe some editable options at the .STC level, like the atmosphere for the planets ?

9- There's a depth sorting problem with pure CMOD models with some transparency effect, when used around any opaque 3ds model (ex: magnetic field lines around an opaque 3ds model of a pulsar). The problem doesn't exist if the central object is a pure sphere defined by Celestia (a star or a planet), but occurs as soon as a spherical mesh (say) is placed around it. The lines doesn't draw in front of the model. This bug was discussed before on the forum.

10- There's still a precision problem with the PrecessionRate command (even after Chris changed the precision used for the rotation). It's extremelly hard to synchronize the rotation and the PrecessionRate, in the case of an high rotation rate (ex : pulsars). There's always a drift which destroys the alignment of, say, jets in precession around a rotating pulsar.

11- Orbits tends to disappears around many star systems. Example : the three planets around PSR 1257+12. As soon as I try to have a global view of that system, the orbits just disappears from the view, while the planets name are still showing. I'm also experiencing the same problem with many multi stars systems.

12- The orbital path of our Sun has a puzzling and unatural discontinuity. It's looking totaly unsatisfying. It may even lies completely outside the Sun itself, which isn't very interesting to show, in a classroom, since this will inevitably brings lots of embarrassing questions from the students !

13- I'm unable to have an atmosphere around any non-spherical model (an asteroid, say), without that annoying spherical gap at the surface. Chris as shown an example, on the forum, of an atmosphere around an asteroid, without the spherical gap. I'm unable to reproduce this effect.

14- While not a bug, it's very hard to add any NomralMap on an asteroid. I'm totally unable to make any model with an NM. This feature should be working at the SSC level (like for any planet or moon), and we should also have the ability to use a BumpMap, not just NM.

15- The markers are always on the foreground. They should hide behind the foreground objects (planets, stars, models...etc), until we get close to a marked object.

16- Celestia has some problems when we slow down time. Slowing down time by a factor of 1000 (or more) may completely halt the motion. This is particularly noticeable with fast spinning pulsars or models. Even if the motion isn't halted, it could become very laggy.

FEATURES REQUEST :

17- While not a bug, the stars labels should have the same "alpha effect" as for the galaxies. I understand it may be much more difficult to code, but I think that something similar should be implemented for asteroids and comets.

18- While not a bug, the comets tail is horrible. The mesh used is extremelly crude and should be scale dependant, as for the planets (the grid spacing is changing, depending on the observer's distance). Something similar should be done for the comets. I already tried changing the mesh parameters at the code level, before compiling, but it may have a significant bad effect on the frame rate, if there are many comets in the solar system. The mesh resolution should be scale dependant.

19- We URGENTLY needs a script menu (under the "File" menu), associated to a "scripts" folder located in the CelestiaRessources folder, and maybe also in the "extras" folder (like the "data", "textures" and "models" folders).

20- We URGENTLY needs a "layers" option, that we could turn ON and OFF at will using the keyboard, to show many kind of SSC objects defined as "custom classes" (magnetic field lines, particles trajectories, Selden's grids, etc). The various reference grids needs a permanent solution. For the moment, if I need to use a grid, I'm forced to quit Celestia, place the grid in the extras folder, and restart Celestia again, until I want to turn the grid OFF.

Sorry, I never used that system before, and may have made a small "goof" ! I don't know how to edit my profile on the CVS system (I don't like the name I'm using there, and "Cham" appears to be already used). I also posted the "request list" in the same message.

Cham wrote:Sorry, I never used that system before, and may have made a small "goof" ! I don't know how to edit my profile on the CVS system (I don't like the name I'm using there, and "Cham" appears to be already used). I also posted the "request list" in the same message.

Thanks for submitting them to the tracker. I'll probably split your giant bug into separate bugs for each item.

--Chris

About bug #2, I'm having great difficulties reproducing the bug. I believe it's gone, since the last CVS update I've done some time ago. I saw very few "white dots" today, and on two models only. Did you changed something recently, about the models rendering ?

Cham wrote:About bug #2, I'm having great difficulties reproducing the bug. I believe it's gone, since the last CVS update I've done some time ago. I saw very few "white dots" today, and on two models only. Did you changed something recently, about the models rendering ?

Well, that's good news, but I can't think of anything I've done that might fix the problem. I'll see if I notice anything different on my system.

--Chris

Cham,

I've split most of the items in the list for your one 'megabug' into individual bugs. The CVS version of Celestia now has fixes for a few of the problems:

9- There's a depth sorting problem with pure CMOD models with some transparency effect, when used around any opaque 3ds model (ex: magnetic field lines around an opaque 3ds model of a pulsar). The problem doesn't exist if the central object is a pure sphere defined by Celestia (a star or a planet), but occurs as soon as a spherical mesh (say) is placed around it. The lines doesn't draw in front of the model. This bug was discussed before on the forum.

Likely to have been fixed by a recent change. I'd need to test with your add-on to verify that I did in fact address the problem. If you want, you can attach the add-on to the bug to make it easy for me or other developers to test.

10- There's still a precision problem with the PrecessionRate command (even after Chris changed the precision used for the rotation). It's extremelly hard to synchronize the rotation and the PrecessionRate, in the case of an high rotation rate (ex : pulsars). There's always a drift which destroys the alignment of, say, jets in precession around a rotating pulsar.

There was a lingering single precision float in the code that converted from old-style rotation parameters to the new 1.5.0 rotation models. It's fixed in CVS now, but you should still use the new syntax when creating add-ons now. It's described on this page: http://en.wikibooks.org/wiki/Celestia/Rotation_Models

12- The orbital path of our Sun has a puzzling and unatural discontinuity. It's looking totaly unsatisfying. It may even lies completely outside the Sun itself, which isn't very interesting to show, in a classroom, since this will inevitably brings lots of embarrassing questions from the students !

Fixed in the CVS version--the Sun's orbit is treated as aperiodic and temporally unbounded, and is thus not rendered at all.

14- While not a bug, it's very hard to add any NomralMap on an asteroid. I'm totally unable to make any model with an NM. This feature should be working at the SSC level (like for any planet or moon), and we should also have the ability to use a BumpMap, not just NM.

Bump maps are deprecated. Normal maps require you to have generated tangents for the mesh. As you noted, they cannot currently be specified in the ssc file. I could change this, but I'd really rather rely on having surface properties specified inside the mesh file. What we need to figure out is how modeling tools export normal mapped meshes.

There are comments on more of your issues in the individual bug entries in the tracker on SourceForge.

--Chris

Thanks Chris,

Later this week, I'll recompile Celestia CVS to test the latest changes.

Chris,

I compiled the last CVS version, 10 min ago.

The new color used for the moon orbits is MUCH better now. Almost perfect (to my taste, at least). It just needs a slight increase in blue, so it can't be confused with the celestial grid and the galaxy labels. Just a slight increase in blue, no more.

The new depth sorting of meshes seems to work very well now. However, there's still a weird bug that I've experienced with the previous built. See the picture below. This pulsar is a simple spherical 3ds model centered on a star. The star is actually inside the mesh. But I still see that dark disk on the model, which shouldn't be there. Like I said, this bug was already present in the previous built.



Also, there's a new bug on the orbital path. For example, see my Taxi model below. It has this red bar, which is clipped by the front clipping plane at the left, and which is ending without reason at right. The same path is also shown normally behind the model (in red too, of course). This bug is new (I never saw this before) :



I suspect this bug may be related to the "holes" I've described, on orbits with a model on the foreground.

Cham wrote:The new depth sorting of meshes seems to work very well now. However, there's still a weird bug that I've experienced with the previous built. See the picture below. This pulsar is a simple spherical 3ds model centered on a star. The star is actually inside the mesh. But I still see that dark disk on the model, which shouldn't be there. Like I said, this bug was already present in the previous built.

Thanks for checking out the mesh sorting. It's still not perfect because Celestia is only doing coarse depth sorting, but many of the more obvious problems should now be fixed. I think that I understand what's causing the dark disk. Can you give me a link to your pulsar add-on so that I can test my fix?

Also, there's a new bug on the orbital path. For example, see my Taxi model below. It has this red bar, which is clipped by the front clipping plane at the left, and which is ending without reason at right. The same path is also shown normally behind the model (in red too, of course). This bug is new (I never saw this before) :

I suspect this bug may be related to the "holes" I've described, on orbits with a model on the foreground.

I agree that it's related--I don't think you should bother filing a separate bug.

--Chris

chris wrote:Can you give me a link to your pulsar add-on so that I can test my fix?

My pulsar addon is very big. However, stripping it to a simple mesh was easy and should be enough to reveal the dark disk bug. Here's a link :

http://nho.ohn.free.fr/celestia/Cham/Di ... r_test.zip

Just go to PSR B1841-04. It's a simple sphere centered on the star (if you already have selden's pulksars database).

Cham wrote:

chris wrote:Can you give me a link to your pulsar add-on so that I can test my fix?

My pulsar addon is very big. However, stripping it to a simple mesh was easy and should be enough to reveal the dark disk bug. Here's a link :

http://nho.ohn.free.fr/celestia/Cham/Di ... r_test.zip

Just go to PSR B1841-04. It's a simple sphere centered on the star (if you already have selden's pulksars database).

OK, this is different than I expected. The glare sprite from the star interescts the enclosing object, and there's not much that can be done about it. Is there a reason that you need the ssc file? Why not just modify the actual definition of the PSR B1841-04 and set the rotation, radius, etc. there?

Your pulsar add-on was causing Celestia to crash for me. I was able to track the problem down and commit a fix to CVS.

--Chris

The reason I'm puting the sphere around the star is two fold :

1- to give the star a nice atmosphere glow around it,

2- to control easily the precesion of the polar caps. Without the model around the star, it's very difficult to align precisely the jets (or the magnetic field) with the polar caps on the star.

EDIT : Chris, the problem is it appears the command "Orientation" doesn't work in a STC definition. I really nead to change the star's orientation to align its poles with the magnetic axis, without changing the rotation axis.

Chris,

this is urgent : I rediscovered an old bug which is hard crashing the video card. Using my particle clouds models without emissivity crash the whole computer. This is a systematic hard bug, very easy to reproduce. Here's a link to the model (edit the SSC to remove the emissivity, to reproduce the bug. I'm using OGL2 on an ATI card).

http://nho.ohn.free.fr/celestia/Cham/accretionTEST.zip (820 KB zip file)

EDIT : I've just tested the models by removing all emissivity in BOTH the SSC and the CMOD files. Celestia (and the computer) doesn't crash, but the rendering is all messed up in Celestia. Something wrong is happening with the emissivity.

Cham wrote:I'm now giving my list of annoying bugs in Celestia CVS. I'll also publish it on the bug tracker page :


List of annoying bugs in Celestia 1.5.0 (latest CVS version), in random order :

Cham, I just wanted to tell you that I can reproduce most of the bugs on my system (which is no surprise, as my system is very similar to yours). However, on my system activating the cloud shadows always leads to an immediate shutting down of the program.

Thank you for submitting such an extensive bug list. It's great to see that the first bugs are starting to be solved by Chris.

I also fully agree with your four feature requests. These features would improve Celestia a lot and in my eyes are almost as important as getting rid of the bugs. In addition, I would like to see Fridger's transparency effect for locations on planet and moons.

Cham wrote:Chris,

this is urgent : I rediscovered an old bug which is hard crashing the video card. Using my particle clouds models without emissivity crash the whole computer. This is a systematic hard bug, very easy to reproduce. Here's a link to the model (edit the SSC to remove the emissivity, to reproduce the bug. I'm using OGL2 on an ATI card).

http://nho.ohn.free.fr/celestia/Cham/accretionTEST.zip (820 KB zip file)

EDIT : I've just tested the models by removing all emissivity in BOTH the SSC and the CMOD files. Celestia (and the computer) doesn't crash, but the rendering is all messed up in Celestia. Something wrong is happening with the emissivity.

I don't see the problem on my machine, but I have an idea where the problem might be. The cmod that you gave me to test has just positions for the vertices and no surface normals. This is fine, as long as you understand that all lighting will come from the emissive color specified in the ssc file. However, the shader still references the normals even when none are provided. I'm not completely sure what is supposed to happen in this case, but it's probably best that Celestia not do it. I'll have a fix for you to test out very soon.

--Chris

Chris,

then, how can I make CMOD models made of points (particles) and yet be able to have shadow on them, without using any emissivity ?

For example, suppose I'm building a dust ring around an exoplanet. I want the planet to cast a shadow on its dust ring. I can't use any emissivity in this case, since this will interfere with the shadow. Is it possible to cast a shadow on particles ?

Cham wrote:Chris,

this is urgent : I rediscovered an old bug which is hard crashing the video card. Using my particle clouds models without emissivity crash the whole computer. This is a systematic hard bug, very easy to reproduce. Here's a link to the model (edit the SSC to remove the emissivity, to reproduce the bug. I'm using OGL2 on an ATI card).

http://nho.ohn.free.fr/celestia/Cham/accretionTEST.zip (820 KB zip file)

EDIT : I've just tested the models by removing all emissivity in BOTH the SSC and the CMOD files. Celestia (and the computer) doesn't crash, but the rendering is all messed up in Celestia. Something wrong is happening with the emissivity.

With my checkin this morning, the problem should be fixed. CMOD files without normals should behave sensibly.

--Chris