New Tour of Mars Script.

[Bob Hegwood]

Here's a shot from MY system Don.



What's the difference?

Confused Bob

[Bob Hegwood]

Howdy Bob,

After spending a couple hours testing and debugging, it appears that 1.3.1 p11 has problems with the SetAmbientLight script command and my ATI graphics card. This command is not executed and then the menu-based Ambient Light setting doesn't work either. Celestia has to be exited and re-started for the menu-based Ambient Light setting to function.

I tried your script with a 2-day old CVS version and the brightness is quite bright. So it appears that Chris has located and squashed this bug.

-Don G.

Just to remind you, Mr. Goyette...

As shown above, you brought this same problem up before when *no one* else had a problem with it as far as I know. Re-read page two of this topic for more information.

Love ya (Even if you *do* have a piece of crap graphics card.) Heck, I don't even *have* a graphics card.

Take care, Bob

[don]

Howdy Bob,

Think I finally figured it out.

What Render path options do you see when you press Ctrl-v repeatedly? Only Basic? Or maybe Basic and Multitexture?

I bet you do NOT get OpenGL vertex program, right? If you DO, then try running your script with this setting. This is my *normal* setting, which renders things quite differently than Basic and Multitexture.

When I set the Render path to Basic or Multitexture, combined with your script's Ambient Light setting, the dark side of the planet becomes fully illuminated, WITH the texture actually being visible.

Soooo, you might want to add some text at the beginning of your script instructing the user to press Ctrl-v until the Render path is either Basic or Multitexture.

Cheers,

-Don G.

[selden]

Don,

I'm sorry to say that it appears that you've found another bug in ATI's OpenGL drivers.

In other words, it looks fine on my work system in all render modes.

System:
512MB 2.4GHz P4, WinXP Pro SP1
128MB FX 5200, Nvidia drivers v 45.23
Celestia v1.3.1-1 final.

[selden]

Bob,

FWIW, I created an AltSurface of the texture maps that you provided. I had to forgo the clouds, of course.

Code: Select all

AltSurface "MarsTour" "Sol/Mars"
{
   Texture "RedMars1k.*"
   # Texture "mars8k.dds"
   BumpMap "marsbump.*"
   BumpHeight 2.5
   Color   [ 1 0.75 0.7 ]
   HazeColor [ 1 1 1 ]
   HazeDensity 0.45

}
AltSurface "MarsTour" "Sol/Mars/Phobos"
{
   Texture "Phobosc1k.*"

}

AltSurface "MarsTour" "Sol/Mars/Deimos"
{
   Texture "Deimosc1k.*"

}


[don]

Don,

I'm sorry to say that it appears that you've found another bug in ATI's OpenGL drivers.

Thank you Selden. I'm happy to at least know what it is. This was the only time I've noticed it, with the Ambient Light cranked up via script. I am running an older version of the drivers, so maybe I'll see what they have now.

Cheers,

-Don G.

[Bob Hegwood]

What Render path options do you see when you press Ctrl-v repeatedly? Only Basic? Or maybe Basic and Multitexture?

As we have discussed previously, Don, I only have the Basic and Multitexture options available on my poor, limited Intel machine.

Why is this a problem only for the Mars script though? Wouldn't you also have the same problem for the Size Comparison script and the the JupiterTour script? I'm using the same ambient light settings for all of my scripts.

Just thought I'd ask... and just so's I understand you correctly; you think I need to put some text in the script to make ATI card users aware that their graphics cards don't work correctly? Surely they already know that don't they?

Take care, Bob

[Bob Hegwood]

Bob,

FWIW, I created an AltSurface of the texture maps that you provided. I had to forgo the clouds, of course.

I thought about using an altsurface for the script, Selden, but these textures are clearly superior to anything else I've ever used on my machine, and I just thought that the user would want to install them as the default textures. I suppose that I could give them a choice...

I'll revise the package - again - so this option is available. Thanks for the advice.

Take care, Bob

[don]

Why is this a problem only for the Mars script though? Wouldn't you also have the same problem for the Size Comparison script and the the JupiterTour script? I'm using the same ambient light settings for all of my scripts.

I just checked every planet texture (standard Celestia distribution) with this ambient light setting. The only two that have "lousy" dark sides are Mercury and Mars.

Just found that these are the only two that have bumpmaps. I commented out the mars bumpmap and OpenGL vertex program Render path works fine. This sounds similar to the 3rd message in the thread http://ennui.shatters.net/forum/viewtopic.php?t=2194 posted by Gordon, where he too commented out the bumpmaps.

Just thought I'd ask... and just so's I understand you correctly; you think I need to put some text in the script to make ATI card users aware that their graphics cards don't work correctly?

No. The text suggestion was before Selden's message saying that the OpenGL vertex program Render path worked fine with his card.

Cheers,

-Don G.

[selden]

Bob,

Unfortunately, although it does look quite good on its own, the Space Graphics surface texture image has highlights and shadows drawn on the map. This can be confusing, since they're pointing in the wrong direction at sunset.

[Guest]

Bob,

Unfortunately, although it does look quite good on its own, the Space Graphics surface texture image has highlights and shadows drawn on the map. This can be confusing, since they're pointing in the wrong direction at sunset.

Sorry, Selden... I didn't even NOTICE that. I was just sooo... happy to be able to see previously UNSEEN features of Mars that I installed the image as my only Mars texture. Heck, at this point I don't even care about the shadows. Come to think of it though, I believe that Mario has another normal map version of the planet, so maybe I'll take a look at using THAT image.

Thanks again for all of your excellent advice.

Take care, Bob

[Bob Hegwood]

Okay,

I've modified the MarsTour for the LAST time (At least for this week!)

I've incorporated Harry's excellent advice concerning the use of the orbit command, and I've broken the script into two downloadable components.

If you just want the updated script, then you can download just the script and the locations file HERE.

If you wish to get all of the textures, the cloudmap, and the altsurface definitions - as well as the script and the locations file, then I now have another, larger package available for the entire collection of MarsTour associated items. This package can be downloaded HERE.

Take care, Bob

[don]

Looks much better than going *through* the planet <smile>. Good work Bob.

[Bob Hegwood]

Bob,

FWIW, I created an AltSurface of the texture maps that you provided. I had to forgo the clouds, of course.

Code: Select all

AltSurface "MarsTour" "Sol/Mars"
{
   Texture "RedMars1k.*"
   # Texture "mars8k.dds"
   BumpMap "marsbump.*"
   BumpHeight 2.5
   Color   [ 1 0.75 0.7 ]
   HazeColor [ 1 1 1 ]
   HazeDensity 0.45

}
AltSurface "MarsTour" "Sol/Mars/Phobos"
{
   Texture "Phobosc1k.*"

}

AltSurface "MarsTour" "Sol/Mars/Deimos"
{
   Texture "Deimosc1k.*"

}


Selden,

Please forgive my ignorance here, but I thought I could just name the above altsurface code to "MarsTour.ssc" and place it in the extras folder to get it to work.

After some experimentation though, it doesn't seem to have *any* affect on the display of Mars during the tour. In other words, if I simply leave the "solarsys.ssc" alone, and just add the "MarsTour.ssc" to the extras directory - when I run the MarsTour script, I'm seeing the old textures rather than those defined in the altsurface definitions.

Is there something else I need to know to use this approach to Altsurface?

Thanks, Bob

[selden]

Bob,

Sorry: I left out the operational details.

AltSurface textures have to be selected before they'll be displayed.
I do this manually by right-clicking on Mars and selecting MarsTour from the list of Alternate Surfaces. I'm not sure how to do this from a script -- I haven't tried to figure that out.

Also, the textures have to be put into the folder textures/medres.

On my system, the ssc and cel files are in the folder MarsTour, which also contains the folder textures/medres.

Does this help?

[Harry]

AltSurface textures have to be selected before they'll be displayed. ... I'm not sure how to do this from a script

You must first select the object (like "select { object "Earth" }" ), and then you can use the setsurface command:

Code: Select all

setsurface { name "Name of Surface" }

where "Name of Surface" must be the exact name of the Alternate Surface, as given in the context-menu or in the .ssc directly after "AltSurface".

Harald

[Bob Hegwood]

Thanks, Harry...

I finally figured that out after I viewed Don's scripting guide for a while. This issue bothers me though...

Does this mean that I should write *every* script with a "setsurface" command when I'm including better (at least to me) textures?

I don't know, but I think it would be simpler just to tell the user to either use the textures they have, or install the new ones included with the script.

Sorry, this is just causing me more headaches when I really want to do a script for Saturn.

Thanks again for the advice Harry.

By the way, Chris told me to thank YOU for the new timing of the opening Celestia logo, so THANK YOU. The opening process is a *lot* nicer now.

Take care, Bob

[Harry]

Does this mean that I should write *every* script with a "setsurface" command when I'm including better (at least to me) textures?

I guess so if you want to make sure the script runs with that texture, i.e. if you depend on some specific property of your texture.

I don't know, but I think it would be simpler just to tell the user to either use the textures they have, or install the new ones included with the script.

AFAIK a setsurface doesn't do harm if the named texture isn't available (but I didn't test that). But some users may prefer their own textures.

By the way, Chris told me to thank YOU for the new timing of the opening Celestia logo, so THANK YOU. The opening process is a *lot* nicer now.

Funny, this must be the smallest change (1 line) that has gone into the new version - but sometimes the small things are important

Harald

[ANDREA]

About the MarsTour.cel I have decided to insert a sight of Mars with a survey probe, so I searched in the enormous number of satellites/probes actually available.
Well, I found the MGS and MarsOdissey (shroxmars), that are nice but a bit "crude", and by Jack Higgins's I found the MER probe that, alas!, is with the lander, and the Mariner 9, clearly old and not so detailed.
Am I missing some other model?

Moreover I'm trying to put the scripting in the Tour a bit differentiated, I mean not always starting from the lower left, and I found very important the possibility to "Justify" the script from the center and to the right edge.
I know it's a minor problem, but due to the growing interest that .cel files are obtaining, could it be possible to have this improvement, please?

Thank you for your help.

By

Andrea

[don]

... I found very important the possibility to "Justify" the script from the center and to the right edge.
I know it's a minor problem, but due to the growing interest that .cel files are obtaining, could it be possible to have this improvement, please?

Howdy ANDREA,

This really would be a good addition. However, even with my limited knowledge of programming in Windows, I know it is not an easy addition. Why? Because text in Windows is not text -- it is graphics displayed to look like text. The size and position of graphical text is all relative, to things like font face and spacing, screen resolution, current window size, etc. And, all of the graphical display code in Celestia is written using OpenGL, which few folks here know much about.

In the "good old days" of programming fixed-width text output, it was simple to calculate the beginning horizontal position of a line of centered text. Not so in any windowed environment. BUT, maybe there is already an OpenGL routine to do this?

Cheers,

-Don G.