1.3.2 pre2 WinXP - Multiple Display Problems

[don]

1.3.2 p2 -- WinXP -- ATI Radeon 9700 Pro graphics card (128 MB)

Multiple Display problems

1. With Galaxy rendering ON ...
* When a nebula is in-view on the display ...
-- Stars display as Scaled Discs, instead of the selected option. If you use left-mouse to drag the nebula off-screen, the stars display as selected.

-- Select a star and retain the nebula on-screen. Goto the star. Make sure the nebula is still on-screen. Press End to move away from the star. A black square will appear around the star before it goes out of view.

* Nebulae are displayed with a visible black background (against a galaxy background).

* The edges of the nebulae texture (mesh?) have black borders.

* When the nebula fills the screen, stars appear as white pixelated blocks with partial, "L" shaped, black borders.

* If you fly edge-on into a nebula, the display does some very strange things, regardless of rendering path. For this example, it also shows a distance of 13 LY. First, the edge seems to last forever, with the rest of the nebula passing by behind and underneath it. Second, large "stretched triangles" appear, that look like dagger blades.


2. With Galaxy rendering OFF ...
Nebulae do not display


3. Magnitude / Auto-Magnitude problem ...
* Run Celestia
* Set magnitude to anything you like (using [ and ])
* Press Ctrl+Y to activate Auto-Mag. Note that the magnitude is automatically set to 8.5, regardless of where it might have been before.
* Press Ctrl+Y to deactivate Auto-Mag. Note that your current magnitude is now 9.57, instead of where you set it.

[chris]

If these problems do indeed only occur with multiple displays, then I strongly suspect that the driver may be at fault. As far as I know, there's no way at all for Celestia to tell that it's spanning multiple displays--it just thinks it's running in a really wide window.

--Chris

[don]

Sorry Chris, not "multiple displays" problems. Rather, "Multiple problems with the display".

All problems occur on a single monitor system. Even with the current CVS (as of 2am MST).

-Don G.

[don]

Here are some links to screen shots ...

http://s94992504.onlinehome.us/celestia/forum_pics/nebula.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula2.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula3.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula4.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula5.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula6.jpg

http://s94992504.onlinehome.us/celestia/forum_pics/nebula7.jpg

-Don G.

[Darkmiss]

Im having this same problem in a different way.

When I load Celestia, I have my stars set to fuzzy points, and auto mag set to 7.50.

Then If i turn Galaxys on and rotate the view around any object,
when a galaxy comes into view all my stars suddenly change to scaled disks at full brightness, (all of them at the same time)

and when all galaxies have gone from view the stars go back to how i had them.

Celestia looses all depth of view like this, it looks horrible.

[Kolano]

I'm also experiencing this, on my 9800.

[chris]

I checked in a a fix for the problem with star rendering. But, the other problems with the nebula are I believe due to a bug in the model--it was just happened to work right in an older version of Celestia. The problem with the Eagle nebula model is that only one of the layers is translucent and the rest are opaque. The 1.3.2pre2 version of Celestia actually respects the opacity setting and draws opaque layers. The right thing to do is to fix the model, not Celestia. I was only able to observe the black borders around the nebula image with the Eagle nebula model--the Rosette Nebula add-on showed no such artifacts. Does this jibe with your observations, Don?

Issue 2: The 'galaxy rendering' setting is actually 'deep sky object rendering', and it affects both galaxies and nebulae. It probably makes sense to allow them to be toggle independently, but I wouldn't really say it's a bug.

Issue 3: Yes, it's true that the star visibility limit isn't restored exactly right after switching back. It's been like that for a long time--perhaps since the feature was implemented. It's likely to remain that way for a long time, unless someone else chooses to work on it

--Chris

[chris]

1.3.2pre3 is now available, and it includes the nebula rendering fix:

http:://www.celestiaproject.net/celestia/files/celestia-win32-1.3.2pre3.exe

And for just the exe (recommended if you've alreay installed 1.3.2pre2)

http://www.celestiaproject.net/celestia/files/ ... e3-exe.zip

--Chris

[don]

I was only able to observe the black borders around the nebula image with the Eagle nebula model--the Rosette Nebula add-on showed no such artifacts. Does this jibe with your observations, Don?

Of all the nebula models I have (Eagle, California, Trifed, Rosette, some NGCs), from various people, only the Rosette nebula does not show this behavior. Sounds like a lot of fixing will need to be done by the nebula makers -- some of which don't even hang out here anymore <frown>.

Regarding #2 and #3, I'm sorry, I guess I had not noticed these before -- or forgotten about them.

Thank you for looking into these things Chris.

-Don G.

[don]

Thank you for the pre3 version Chris.

I am happy to report that stars now render as selected when a nebula is present on the display.

-Don G.

[Kolano]

Thanks for the quick release but...

I'm unhappy to report that there still seems to be something wrong with the handling of alpha transparency and nebulae. Although stars appear correct now I am still getting white boxes around nebula. Depending on the viewing angle this sometimes switch to an untextured semi transparent shape.

This is on a 9800 using DDS textures.

[selden]

Unfortunately, I'm seeing the same failure with my original Billboard object when using an Nvidia graphics card.

The "Celestial Grid" is no longer visible through the billboard image.

The object is a flattened cube. Its diffuse surface material is specified to be an image. I'm using a PNG image file with an alpha channel.

I could reluctantly accept that all the models I've created are malformed, but it'll be a pain to fix them all once I learn what has to be done.

They all were created using Anim8or and accepting its default surface characteristics. The only change was the addition of a surface texture image file as the objects' diffuse material. The models were then exported to 3DS format. The file spec then was edited appropriately.

System:
256MB 500MHz P3, WinXP Pro, SP1
128MB Ti4200, Nvidia drivers v44.03
Celestia v1.3.2pre3

[chris]

Actually, I think that this problem may be fixable in Celestia. The reason that the nebula models worked at all in earlier versions of Celestia was due to a bug (one in which all nebula models would be rendered as if they were translucent--but a bad assumption for nebula, but still . . .) Another bug may be preventing them from working now. Celestia assumes that alpha blending should be turned off for any mesh with an opacity of 1.0, which is the case for most of the nebula models. It completely ignores the fact that the texture might have alpha information--it should be a simple matter to detect alpha textures and enable blending if they're present, regardless of the base opacity of the model.

--Chris

[selden]

Chris,

That'd be great.

I'd been assuming the opacity value was essentially a multiplier, so that a value of 1.0 would leave all the opacity control to the alpha channel, while 0.5 would make an otherwise opaque image semi-transparent. I've never actually changed it, except to set it to 0.0 for "protective shells" to counteract the clipping bug.

[t00fri]

Multiple Display problems

...

3. Magnitude / Auto-Magnitude problem ...
* Run Celestia
* Set magnitude to anything you like (using [ and ])
* Press Ctrl+Y to activate Auto-Mag. Note that the magnitude is automatically set to 8.5, regardless of where it might have been before.
* Press Ctrl+Y to deactivate Auto-Mag. Note that your current magnitude is now 9.57, instead of where you set it.

Well since I coded the Automag scheme, here are some comments in reference to your findings:

First of all, as most people know, the Automag scheme correlates the limiting star magnitude with the actual field of view (FOV).

Due to Chris' explicit wish at the time, I took the Automag presetting out of celestia.cfg, where I had put it originally and where people would find it immediately;-), into a CEL (start) script command, e.g.

setfaintestautomag45deg { magnitude 7.0 }

So if you want to adjust it permanently, you have to do it via the start.cel script.

Later, however, further presets made their way again into celestia.cfg ( RotateAcceleration 120.0, MouseRotationSensitivity 0.5) without Chris interfering;-). In my view, 'setfaintestautomag45deg' should also have been located there, together with the other presets...The present choice is all but systematic;-)

-- Note:

ONLY at the reference FOV, the Auto magnitude is set to the preset value (e.g. 7.0). Upon pressing CTRL+Y at some other FOV, the new limiting magnitude value that appears is the Automag result, corresponding to the preset value (7.0) at the reference FOV (it was 45 degrees before Christophe modified it).

That seems to make sense to me.

Next, upon switching Automag off (CTRL+Y), I found it more sensible to take the last Automag value at the respective FOV as the new fixed magnitude limit, rather than returning to the preset fixed magnitude limit! This also assures continuity in the limiting magnitude, when switching back...

Only Automag 'enemies', who would never switch Automag on, always get the preset fixed magnitude limit.

So, Don, your findings are not a bug, but rather a design feature. We have actually discussed the pros and cons of this choice extensively in the forum, before you were a member of the Celestia crowd...Of course, we can discuss it again if people are dissatisfied now...

Bye Fridger

[don]

First of all, as most people know, the Automag scheme correlates the limiting star magnitude with the actual field of view (FOV).

Howdy Fridger,

That's what I thought. However, regardless of the FOV when when Ctrl+Y is pressed, it is *always* set to 8.50 (not 7.00 as you wrote). Was this changed because the default Celestia FOV has been decreased from 45 to 25/26?

Next, upon switching Automag off (CTRL+Y), I found it more sensible to take the last Automag value at the respective FOV as the new fixed magnitude limit, rather than returning to the preset fixed magnitude limit!

Why would this be "more sensible" since they are two different functions -- Normal magnitude and Auto Magnitude? When switching between two different functions, I would expect the previous settings to be reset accordingly. Just me I guess.

This also assures continuity in the limiting magnitude, when switching back...

But, the Magnitude limit setting, when AutoMag is ON, is supposed to be based on the current FOV, which could certainly have changed since being turned on-off. Thus, a NEW Magnitude limit would be necessary.

We have actually discussed the pros and cons of this choice extensively in the forum, before you were a member of the Celestia crowd...

That was then, this is now ... the default FOV has changed since I became a user, from 45 to 25/26. Has the AutoMag default value and operation been adjusted accordingly?

Of course, we can discuss it again if people are dissatisfied now...

Don't know if anyone is "dissatisfied" or not. I haven't used it because it just doesn't look right when it's on.

Cheers,

-Don G.

[t00fri]

Don,

First of all, as most people know, the Automag scheme correlates the limiting star magnitude with the actual field of view (FOV).

Howdy Fridger,

That's what I thought. However, regardless of the FOV when when Ctrl+Y is pressed, it is *always* set to 8.50 (not 7.00 as you wrote). Was this changed because the default Celestia FOV has been decreased from 45 to 25/26?

But I explicitly wrote the reason for this above. The 8.5 is of course the hardcoded value, and if you want it at 7.0 (what I use for reasons of speed), then you must do it in the start.cel script. If my CPU was as fast as yours, I would use the 2million star data and put it at 8.5! Looks gorgeous...

Next, upon switching Automag off (CTRL+Y), I found it more sensible to take the last Automag value at the respective FOV as the new fixed magnitude limit, rather than returning to the preset fixed magnitude limit!

Why would this be "more sensible" since they are two different functions -- Normal magnitude and Auto Magnitude? When switching between two different functions, I would expect the previous settings to be reset accordingly. Just me I guess.

Clearly a matter of taste.
The Automag is an "intelligent scheme" and provides a more sensible setting at non-standard FOV's. It was coded with the idea to make it the default (which it was in Linux, but not in Windows...). Then one would switch back only for special applications to the fixed mag scheme for a limited range of FOV's. From this point of view my setup is more sensible.

You may for instance set the Automag reference value equal to the default value for fixed magnitude. Then you get back to the fixed mag value at the reference FOV
while you get a most reasonable fixed mag when exploring a region of FOV's near 120 degrees, for example.

That was then, this is now ... the default FOV has changed since I became a user, from 45 to 25/26. Has the AutoMag default value and operation been adjusted accordingly?

No, there seems to be little need. Just slightly reset the reference value in start.cel if you please.... That's essentially it. The flush text ( showing with [,] adjustments) and the reference setting still refer to 45 degrees but this may be not too bad. In my case, Christophe's reference FOV is 36,... degrees, well not too far away from 45. 45 degrees is easier to remember, though;-)

Christophe's FOV modification is simply a redefinition of the reference FOV (as a dependent variable calculated from the screen resolution and the observing distance from the monitor).

The Automag is based on the idea to keep the star density (i.e. # stars within your window area) approximately constant over a wide range of FOV's. This has a nice physical background, but I am too lazy to repeat it now. We have developed the Automag scheme years ago with great success for XEphem.

Of course, we can discuss it again if people are dissatisfied now...

Don't know if anyone is "dissatisfied" or not. I haven't used it because it just doesn't look right when it's on.

Sounds surprising.

It probably is due to the fact that you have set it up incorrectly (depending on your monitor and resolution). I think it works just great.

When I zoom to very small FOV's for example, I always have the appropriate star mags in view. However, one needs a really large data base (2 million is great) to make it work best! I bet, when you zoom to a few arc minutes FOV to inspect e.g. a planet and its moons from earth, you will never see any of the dim stars in your field besides the moons.

In my case it just looks like through my telescope at narrow FOV as viewed from my backyard. Yet, when zooming quickly out (or resetting the FOV to standard with Mouse2 click), the sky is never over crowded with stars! It is just right...

Bye Fridger

[don]

Howdy Fridger,

Ahhhh, okay, with the 2 million star database it makes much more sense and looks better. I've been using mostly the base distribution package lately, doing testing with Chris' new stuff, where AutoMag makes the sky look "empty" at narrow FOVs. I just added a note in the keyboard list entry for AutoMag, that it works best with the 2 million star database add-on.

Thanks Fridger,

-Don G.

[t00fri]

Howdy Fridger,

Ahhhh, okay, with the 2 million star database it makes much more sense and looks better. I've been using mostly the base distribution package lately, doing testing with Chris' new stuff, where AutoMag makes the sky look "empty" at narrow FOVs. I just added a note in the keyboard list entry for AutoMag, that it works best with the 2 million star database add-on.

Thanks Fridger,

-Don G.

Don,

now I am confused: you said that with the Automag =ON the sky looks more empty at narrow FOV than with a fixed mag setting, 6.0 by default???

Just the opposite is true. Because at narrow FOV, in my case the limiting magnitude of displayed stars moves up from 6-7 to 10-14!! So unlike your fixed mag setting of 6.0, say, you see stars of mag=7,8,9,10,11,12... provided of course, you got some in your base...

The number of dim stars increases very strongly, but the Automag scheme just keeps the balance for you;-)

The design goal of having about the same number of stars showing up in your window at any FOV, can only be realized in practice, if your data base also comprises lots of very dim stars! => 2 million gives the most pleasing view.

But with any number of stars you will be better off at small FOV than with a fixed mag setting of 6.0!!

Bye Fridger

[don]

Sorry. Of course there are fewer stars at a narrower FOV, and AutoMag makes them brighter <sigh>. So, never mind what I wrote. Busy day in the house here today so my mind is elsewhere.

-Don G.