Celestia Forums

Here is a cel://url of recent new holes in the sky.

Example: Mars:

cel://SyncOrbit/Mars/2006-11-22T22:11:3 ... 11&lm=2576

I've seen these holes also on Earth, recently.

Bye Fridger

What??s a sky hole?I can??t find anything unusual in this cel://url...

t00fri wrote:Here is a cel://url of recent new holes in the sky.

Example: Mars:

cel://SyncOrbit/Mars/2006-11-22T22:11:3 ... 11&lm=2576

I've seen these holes also on Earth, recently.

Bye Fridger

A skyhole is a hole in the sky . It's usually due to floating
point inaccuracies that the sky appears to open up along
certain wedges as you can see on this screendump from
Mars:



Usually it requires sufficiently big-scale textures, like this
32k one. You probably use too small Mars textures in
order to see the bug.

The point is that these black wedges in the sky
appeared only recently after one of Chris' many
updates...

Bye Fridger

I believe that the holes are caused by the fix to reduce the number of virtual texture tiles that get loaded. I need to change the calculation of the far plane to account for the way the new atmosphere code works.

--Chris

Ah,THIS sky hole.I saw it,but not only with VT textures.When you get very near the planet,this hole appears.Problem was that your cel://url GET ME to a point 200 AU FROM MARS.I didn??t understand...

t00fri wrote:A skyhole is a hole in the sky . It's usually due to floating
point inaccuracies that the sky appears to open up along
certain wedges as you can see on this screendump from
Mars:



Usually it requires sufficiently big-scale textures, like this
32k one. You probably use too small Mars textures in
order to see the bug.

The point is that these black wedges in the sky
appeared only recently after one of Chris' many
updates...

Bye Fridger

danielj wrote:Ah,THIS sky hole.I saw it,but not only with VT textures.When you get very near the planet,this hole appears.Problem was that your cel://url GET ME to a point 200 AU FROM MARS.I didn??t understand...
...

Do you perhaps use an older version that produces incompatible cel://urls?

With the latest Celestia-CVS (that I always use) a click on my above cel://url get's me right to the view I have shown one post up.

I always tend to check things that I publish.

Bye Fridger

Fridger,

Your URL places my viewpoint 39 km above Mars and the sky is entirely black. I have to go down to an altitude of less than about 15 km to see atmospheric effects.

What atmosphere definition are you using? Apparently it is not in CVS yet: I built from CVS this morning.

selden wrote:Fridger,

Your URL places my viewpoint 39 km above Mars and the sky is entirely black. I have to go down to an altitude of less than about 15 km to see atmospheric effects.

What atmosphere definition are you using? Apparently it is not in CVS yet: I built from CVS this morning.

Selden,

that sounds strange. I use the cel://urls from within Linux-KDE. I might check later for Windows. There might well be a difference, who knows

Find below my complete Mars .ssc. It's identical to Chris' latest submit apart from my 32k tiles for the base and normalmap textures.

Bye Fridger

Selden,

just checked the above cel://url with my standard 1.4.1 Windows installation. Indeed, there I end up quite a bit away from Mars with the aboce cel://url. So there is obviously a bug either in the Windows cel://url code or in the one for Linux (KDE).

That's all I can say at this point. Unfortunately, in Windows there seems to be no GOTO URL menue entry (?) , hence I cannot test the cel://url with the latest CVS compile that is NOT registered in the registry.

We both know that there might well be a change in cel://url compatibility due to Chris' recent mods.

Bye Fridger

Fridger,

I have the same definition for Mars as you posted. The strangeness with the url does seem to be the issue.

selden wrote:Fridger,

I have the same definition for Mars as you posted. The
strangeness with the url does seem to be the
issue.

Further tests:

the general view agrees in all cases that I tested: 39km
above Mars, two craters visible in the foreground and
SMC in the sky.


in celestia-gtk and celestia-kde:
------------------------------------
things tend to agree with what you described if I choose
as render path: OpenGL vertex program/NVIDIA combiners!

The sky is ~ black at 39km altitude and becomes quite
yellow-orange when moving to the surface. No black
skyhole visible.


++++++++++++++++++++++
But for the OpenGL 2.0 render path it's the same as in KDE. Including a clearly visible skyhole!
++++++++++++++++++++++

Did you make sure that you used the correct render path???


Bye Fridger

Unfortunately, I have no way to know which render path I was using. (I think that needs to be one of the status lines shown on the screen most of the time, perhaps using a Lua feature.)

I was using Basic just now, and might have been using Basic previously. *sigh*

However, although not as sophisticated, many of the atmospheric altitude effects should be similar in all render paths. (I'm not saying that the parameters actually are currently defined with the intent of making the effects similar, but rather that they ought to be, if at all possible.)

selden wrote:Unfortunately, I have no way to know
which render path I was using. (I think that needs to be
one of the status lines shown on the screen most of the
time, perhaps using a Lua feature.)

But this is flashed for some seconds after switching!?

I was using Basic just now, and might have been
using Basic previously. *sigh*

However, although not as sophisticated, many of the
atmospheric altitude effects should be similar in all
render paths. (I'm not saying that the parameters
actually are currently defined with the intent of making
the effects similar, but rather that they ought to be, if at
all possible.)

But I just tested that the atmospheric appearance and
the skyhole bugs are QUITE different in the various
render paths, notably OpenGL 2.0. Remember, Chris
made most of his recent changes in OpenGL 2.0!!!

I am also quite sure that Daniel above chose the
WRONG render path. Guys we need to test OpenGL
2.0. Everything else remained unchanged, recently!

Bye Fridger

Fridger--I checked in a fix for a hole in the sky problem. I was seeing the bug even without virtual textures, but I *think* it's the same problem that you've seen.

--Chris

chris wrote:Fridger--I checked in a fix for a hole in the sky problem. I was seeing the bug even without virtual textures, but I *think* it's the same problem that you've seen.

--Chris

Chris,

unfortunately, the hole in the sky I found is still there, unchanged...

Bye Fridger

Oops. The change didn't actually get checked in because I hadn't merged with the latest version of render.cpp in CVS. I resubmitted my change; if you sync again, hopefully the hole in the sky bug will disappear.

--Chris

chris wrote:Oops. The change didn't actually get checked in because I hadn't merged with the latest version of render.cpp in CVS. I resubmitted my change; if you sync again, hopefully the hole in the sky bug will disappear.

--Chris

Chris,

at first, I was happy to see that the hole in the sky at my above cel://url location has indeed gone. But then I discovered another one at a nearby perspective:

Here it is:



Bye Fridger

Chris,

wherever I look, still lots of "hole in the sky" bugs!

Note that these vanish if I switch to some render path other than OpenGL 2.0...

Bye Fridger