Oolite Bulletins

Ahruman wrote:

dajt wrote:

I have started a change so you can specify the size of texture you want in planetinfo.plist, but it isn't working yet. It should be a simple change but something has gone wrong... I tried it with 1024x768 textures earlier today and the desert planet looked great. It didn't make that much difference for the earth-like one.

1024x768? I’m assuming you meant 1024x512?

It ends up I did mean 1024 x 768, which is what the problem was. Me and the 2yo are both sick at present so I'm not thinking too well. I wasted about an hour on that last night before giving up. Tried using texture sizes that were both powers of 2 and twice as wide as they are high and it worked fine. When I say the desert planet looked good it was a test I did before the user sizing code where I must have got the texture sizing correct.

Ahruman wrote:

Have you considered detail textures? Just a bit of noise mapped over the main textures to hide the pixelation.

I haven't. I don't know how I'd generate them in or out of libnoise.

Ahruman wrote:

Arexack_Heretic wrote:

cities. they shine in the dark!

Sensible positioning of the cities is probably the hardest bit there. (Incidentally, Giles mentioned implementing glow maps with shaders, but they can be done without.)

Yes, the positioning is a problem. The earth-like planets don't have rivers which is where their cities would most likely be (either coastal or inland). The mars-like planets could have them scattered about due to "mining" or something. But in either case it isn't something I'm looking at. For my interest, how would you make cities on the dark side of the planet visible with the current rendering code? I don't know enough about OpenGL or texturing to know.

Ahruman wrote:

As for the sun, I think the current look is pretty good for the main disc. You can’t pick out sunspots on the sun. :-) (A more realistic corona is possible, though. And maybe full-screen bloom effects…)

Well, given the fiction of Elite says all views are through cameras you can imagine you'd see more detail of the sun surfaces than you would through a window. It also means lens-flares are actually a valid artifact in the Oolite views! Unless there is technology to get rid of them.

Anyway, I've checked in the changes to allow user selected texture sizes, with the defaults still being 512 x 256.

I've also posted a new exe wrapped in a zip with an example planetinfo.plist file). If you want to use the planetinfo.plist file, it goes in your AddOns/Config directory - note it isn't in any specific OXP.

I've installed the tp3 exe and the planets look excellent. Good job.

I've also noticed that, since I installed it, when I scoop escape pods, I no longer get the name of the person/sentient being captured, just an @ symbol. Similarly when docking afterwards the name and value are not shown, just @ symbols. I'll keep playing and post up the exact text when it happens again. Has this happened to anyone else?

dajt wrote:

For my interest, how would you make cities on the dark side of the planet visible with the current rendering code?

I haven’t actually done it, but there appear to be two approaches: the old-school two-pass rendering, first drawing the light map (with writing to Z buffer disabled) and then the standard (diffuse map) texture in GL_ZERO, GL_SRC_COLOR mode; or multitexturing, which multiplies the textures together in one pass.

http://www.google.com/search?&q=OpenGL+light+map

dajt wrote:

Anyway, I've checked in the changes to allow user selected texture sizes, with the defaults still being 512 x 256.

Does this mean that we are allowed bigger texture sizes as well, off the top of my head something like 3000 x 1500. (Graphics card permitting).

The width and height both have to be powers of 2, and the width should be twice the height. So 128x64, 512x256,1024x512, etc. 4096x2048 might work but you'll not have much RAM left and you'll be waiting a long time for the textures to be created.

grounded wrote:

I'll keep playing and post up the exact text when it happens again. Has this happened to anyone else?

I'm now using tp4 and the messages that come up are...

'scoop-capture-@' when you scoop an escape pod, then...

'rescue-reward-for-@ @-f-credits' or 'capture-reward-for-@ @-f-credits' when you next dock at a station.

Ahruman wrote:

dajt wrote:

For my interest, how would you make cities on the dark side of the planet visible with the current rendering code?

I haven’t actually done it, but there appear to be two approaches: the old-school two-pass rendering, first drawing the light map (with writing to Z buffer disabled) and then the standard (diffuse map) texture in GL_ZERO, GL_SRC_COLOR mode; or multitexturing, which multiplies the textures together in one pass.

http://www.google.com/search?&q=OpenGL+light+map

This is the second sentence behind that link:

"A 2D light map can be generated analytically, creating a bright spot in luminance or color values that drops off appropriately with increasing distance from the light center. As with other lighting equations, a quadratic drop off, modified with linear and constant terms can be used to simulate a variety of lights, depending on the area of the emitting source."

Even feeling my best I couldn't understand that ;)

I'll have a read anyway, so thanks for the link. I have googled various words before when thinking about glowing stuff and OpenGL but never seemed to choose the right ones. Never heard of a light map before. I normally write programming tools, so OpenGL and grapgics programming are a long way outside my area of operation and understanding.

You can't see sun spots or any detail from Earth because of the atmosphere and the galare of the sun. They can be seen through an earth bound telescope. A space bound telecope picks out all the sun in full detail, although you could not look at it with the naked eye. Polasised glass alows you to see the detail (see NASA's S.O.L.A. probe). Oolite ships would surley have a filter to stop the Commander's eyes being damaged and so the detail would appear.

Not true about the atmosphere. Point a telescope or even binoculars on a tripod at the sun but DON'T LOOK IN IT!!!

but instead put a white sheet behind the oculaire, (sorry, eyepiece...) move it so you get a picture of the sun in focus, if there's high spot-activity, you can clearly make them out.

dajt wrote:

This is the second sentence behind that link:

"A 2D light map can be generated analytically, creating a bright spot in luminance or color values that drops off appropriately with increasing distance from the light center. As with other lighting equations, a quadratic drop off, modified with linear and constant terms can be used to simulate a variety of lights, depending on the area of the emitting source."

That’s about generating light maps for realistic light sources, not applying them.

This one summarises the calls required for the multitexturing method, plus some windows-specific technicalities regarding the use of extensions. This one does the same (at the bottom) for the multipass method. Off the top of my head, I think the multitexture extensions are supported by Rage 128-class hardware and later.

And yes, I know that with proper camera filtering or projection you can see sunspots. I don’t see why ships would go through the extra effort.

Ahruman wrote:

I don’t see why ships would go through the extra effort.

Solar flares= increased risk of radiationdamage to your equipment perhaps?

In space astronauts and sats are quite at a risk of these, so much there's now early warning sats monitoring the sun. You get a visual clue waaaay before the slower moving particles hit you...

(too much realism perhaps, but just mentioning it for the heck of it)

It just struck me that the light map stuff above won’t work for glow maps, it’s for using light maps as a replacement for the GL lighting model.

However, the same basic technique should work, just using a different blend mode to get additive blending rather than multiplying.

Hi,

Berlios is down so this will have to wait until tomorrow.

I've brought the textured-planets branch up-to-date with the SVN trunk, fixed the addPlanet bug, and fixed the OOS parsing bug which caused a crash whenever an OOS file was parsed.

I'll post the exe tomorrow, same place as the others.

Its all checked in - it would be great if someone with a Mac could have a go at building it. The libnoise code itself is pretty clean C++ and should not cause you any trouble.

Yeeeehaaaaa.......

I really want to get the textured planets patch to work.

I found Berlios down the other night as well ( and it's still down now at 20.30 GMT)

OK, berlios is still unreliable - in the last 3 or 4 days I've managed to get to the Oolite-PC twice, and couldn't actually use it.

I have posted the new textured planets exe, and a zipped version of it, to a free file sharing service.

The exe can be got from http://www.filefactory.com/file/eb6203/
The zip can be got from http://www.filefactory.com/file/e9c0f2/

The exe goes in your oolite.app folder, and replaces the current oolite.exe. Save your existing one, and ensure the new one is named oolite.exe, not oolite-1.65-tp6.exe.

Same goes for the zip - unzip it to get the exe and then do the above.