CVS bugs (stars, atmosphere,...)

[Boux]

This one is neat

Any compressed normalmap applied to Mars {Don Edward's Mars VT old and new} ... and the Earth's specular map kicks in.
The funny thing is that it happens only with Mars. Go figure...
All other bodies with compressed normal maps exhibit the ugly "spotlight" effect. They are a bunch.
There are more add-ons compressed normalmaps than uncompressed out there.
Looks like there is a major breakage of the program here.

[buggs_moran]

Not sure if this has been seen yet... Wile playing with Fridger's titan atmosphere, I noticed that Saturn's moons "show through" the planet with the 9/13 build.

cel://Follow/Saturn/2006-09-13T23:39:41 ... 9&lm=49222

[Kolano]

It is something that I'd like to fix though. It sounds like there are more DXT compressed normal maps out there than I'd thought, and I'd hate to break them all.

What about my suggestion to simply use another file name extension for compressed normalmaps in DDS files, something like ".cnm" or ".dxt5nm"?

That's a very sensible idea . . . I think that might be the best solution.

--Chris

I generated many of my compressed normal maps myself, so I may actually be a fairly odd case. I realize that compressed normal maps did have some fidelity issues up to 1.5, but the performance increase seen from using them was enough to merit using them.

When possible, not breaking compatibility with existing add-ons should be a priority. I think we can remember the annoyances caused when the galaxy update outdated some of the galaxy add-ons.

[Kolano]

Also, I don't really know that much about the DDS format, but is there any meta-data embeded or could there be, that could help distinguish compressed vs uncompressed files.

Using an alternate extension seems easiest, but keep in mind that, to some degree, will complicate things for add-on creators. On many platforms the uncommon file extension is not likely to be recognized by file editors for instance.

[steffens]

I generated many of my compressed normal maps myself, so I may actually be a fairly odd case. I realize that compressed normal maps did have some fidelity issues up to 1.5, but the performance increase seen from using them was enough to merit using them.

When possible, not breaking compatibility with existing add-ons should be a priority. I think we can remember the annoyances caused when the galaxy update outdated some of the galaxy add-ons.

That's the point of using another file name extension for the new compressed file format for normal maps.
Ordinary normalmaps that were just saved in some kind of a DXT format will keep the extension ".dds" and will work without touching them.
Normalmaps in the new DXT5nm format however get a new extension, so that Celestia can recognize them and handle them different from other DXT files.

steffens

[ElChristou]

Got a clipping problem on comet tails with a fresh 1.5 build... someone confirm?

[Vincent]

Got a clipping problem on comet tails with a fresh 1.5 build... someone confirm?

ElChristou,
I don't know if the bug I can see on my system is related to yours, but there seems to be indeed something strange with comet tails...

Here's a shot :


And here's a CelURL... Right drag on the comet to reproduce the bug...
cel://Follow/Borrelly/2006-09-19T19:02: ... 5&lm=-1792

[symaski62]

Got a clipping problem on comet tails with a fresh 1.5 build... someone confirm?

ElChristou,
I don't know if the bug I can see on my system is related to yours, but there seems to be indeed something strange with comet tails...

Here's a shot :


And here's a CelURL... Right drag on the comet to reproduce the bug...
cel://Follow/Borrelly/2006-09-19T19:02: ... 5&lm=-1792

:p mouahahah celestia 1.5.0 BETA comet ERROR

[Cham]

Yes, I'm also experiencing comets tail problems. Actually, it's completely messed up and I forgot to tell about it.

Also, is it possible to give the user a choice about tail precision, with a parameter in the config file ? Currently, comets are really crude ! I would MUCH prefer a smoother tail front, even if it's decreasing a bit the frame rate (my computer can largely handle that).

[Vincent]

Also, is it possible to give the user a choice about tail precision, with a parameter in the config file ? Currently, comets are really crude ! I would MUCH prefer a smoother tail front, even if it's decreasing a bit the frame rate (my computer can largely handle that).

In Celestia patch, Boux and I have increased consequently the number of points and slices used to draw the comet tails,
and we didn't notice any difference in the FPS. But maybe there are some other parameters that we are missing...

- CVS version :

Code: Select all

static const int MaxCometTailPoints = 20;
static const int CometTailSlices = 16;

- Celestia patch version :

Code: Select all

static const int MaxCometTailPoints = 64;
static const int CometTailSlices = 32;

[Cham]

Why don't you integrate this in CVS ?

or how can I change that myself in the code ? Which file needs to be edited ?

[ElChristou]

Got a clipping problem on comet tails with a fresh 1.5 build... someone confirm?

ElChristou,
I don't know if the bug I can see on my system is related to yours, but there seems to be indeed something strange with comet tails...

Here's a shot :

Yep, that's it... ok, then it's another bug to solve...

[ElChristou]

...Which file needs to be edited ?

If I recall it's in render.cpp; search for the lines shown in Vince's post...

[chris]

I just committed a fix for the comet clipping bug. Nothing magjor, just more growing pains with the new depth sorting code.

--Chris

[Vincent]

I just committed a fix for the comet clipping bug. Nothing magjor, just more growing pains with the new depth sorting code.

--Chris

No more problem with comet tails on my system with the last CVS version.
Thanks Chris.

[Cham]

Confirmed. No more comet problems.

Let me resume all the bugs which I've experienced with the current CVS Celestia 1.5.0 (test compilation for MacOS X) :

1- Planetary orbits may get some fluctuating "holes", a bit like a dashed curve. The "holes" are "moving" and changing, depending on the observer's movement. Also, an orbit may be "clipped" by an imaginary foreground plane (front clipping plane ?). Those two orbit bugs are clearly noticeable and easily reproducible on my system, but they needs to be confirmed by other users.

2- Star glare texture is suddenly disappearing while moving to a star. This bug is occuring since version 1.4.1.

3- Sometimes, a far away star may "blinks" rapidly (or "pulsating") on the black background.

4- Orbits tends to disappear abruptly when the observer is moving far away, way before the orbits are shrinked to a point. This bug is especially noticeable with star binaries.

5- Skies tends to have huge triangular black "holes", if the observer is moving very close to a planetary surface.

6- Moons are visible (as points) behind their parent planet.

7- There's a dark straight line in the middle of most galactic templates, as seen from the side. That line is too straight and looks very unatural, especially as seen from within our solar system. It should be wavy in thickness.

8- Most DDS textures don't work anymore (and I mean almost all DDS textures !). I'm getting some weird looking shadows on planets and moons which are using a DDS texture. Very very annoying !

9- Major crashing bug with some CMOD model, if Emissive option isn't enabled in SSC, and OpenGL 2 is used. A spherical grid in CMOD format, placed around Earth, crashes Celestia only if Emissive isn't used.

10- Minor bug on models : tiny white dots may appear on edges, "spikes" and contour of a mesh (3ds and CMOD formats). Wasn't present with Celestia 1.4.1. The dots are scale independant, and may disappear momentarily if the object moves relative to the observer.

[symaski62]

http://www.purebytes.de/stuff/celestia/

09/20/2006 UPDATE CELESTIA 1.5.0 BETA

THX

[Chuft-Captain]

With this talk about comet tails, I was just wondering if anyone's ever attempted to create a comet model with both tails?

[Malenfant]

I've found a possible bug in the version of 1.5.0 that I have...

First, copy the code in these links to separate STC files in your extras directories.

http://www.celestiaproject.net/forum/viewtopic.php?t=10151 - quad system
http://www.celestiaproject.net/forum/viewtopic.php?t=10054 - trinary system

Edit the names of the stars in the Quad file so that they don't have "a" at the end of them (so you have StarS, StarC, StarN1, and StarN2 in the quad system)

Now fire up Celestia and go to "QuadABCD" (the quadruple system barycentre). The type "StarS". It should then display the info for the StarS that is in the TRINARY system, not the one in the Quad system (which is what it should be showing you). Is this a bug?

I thought in previous versions Celestia kept things "local", so that if you had two stars or planets with the same name in different systems loaded as addons then it would take you to or point you to the one in the system that you're currently in. Has this changed in 1.5.0, and is it deliberate?

[chris]

Now fire up Celestia and go to "QuadABCD" (the quadruple system barycentre). The type "StarS". It should then display the info for the StarS that is in the TRINARY system, not the one in the Quad system (which is what it should be showing you). Is this a bug?

I thought in previous versions Celestia kept things "local", so that if you had two stars or planets with the same name in different systems loaded as addons then it would take you to or point you to the one in the system that you're currently in. Has this changed in 1.5.0, and is it deliberate?

Star name searches are always global. Planet searches are local to whatever system you're closest to or have selected.

--Chris