Oolite Bulletins

Screet wrote:

Simon B wrote:

... what causes this?

ATI has some magic that can cause a Hydra to be drawn normally and it's pods entirely black. Same applies for winged spacecraft....and sometimes it's just the other way around.

Not my issue - but may be worth testing in another videocard ...

I'm running on nvidia 6800 with the proprietary drivers. Not sure I want to pull the card just to test this.

Also - the subentity is always opposite lighting ... when the top surface is dark, the skiff is light.

Checked the FDL and it's engines don't share this effect - they behave.

Screet who just got "red" markings at a german tech magazine board for commenting that ATI does neither have OpenGL 3 support ready nor working drivers at all.

- the crysalis drivers test out ok over here... few have opengl3 "ready". It will be slow.

never had trouble with ati cards on proprietary or free drivers - and their free software support is pretty good.

Simon B's replacement ships for FighterHUD can be downloaded here

Finally came up with something for the front of the Viper that didn't look like a beak or a nose
I'm going to hopefully rearrange the flashers and their colours, so I would like to ask Simon for the glow map too if there is one for her yet.
I may use my original checked design for the Interceptor, or more rather combine the two so they suit each other.



I would like to point out that I optimised this PNG in photoshop to 256 colours without any noticeable visual difference, she dropped from just over 320k to a nip over 100k. If we did this for every skin (that would remain unaffected) we could reduce the RAM they use by two thirds.
EDIT (Assuming there isn't some element to memory usage that alters this?)

The GIMPs posterize tool lets me dynamically set the number of colors per channel - if I do 8 bits per channel, thats 512 colors, I get a more degraded image than that. 128 bits per channel gives similar grain and halves the filesize.

It's a good observation though, and may help people experiencing slowdowns without reducing the actual dimentions of the texture.

Hmmm... the stripe is not supposed to go behind the grill ... I see I have that on mine too. Dunno how I missed that. Have to fix.

ZygoUgo wrote:

I would like to point out that I optimised this PNG in photoshop to 256 colours without any noticeable visual difference, she dropped from just over 320k to a nip over 100k. If we did this for every skin (that would remain unaffected) we could reduce the RAM they use by two thirds.

Won't work. The image still has to be decompressed to be used; all that you're doing is to reduce the disk space used. (Though that's worthwhile in itself, in that it also means less to be downloaded.)

You want S3TC (and the requisite OpenGL support for it, which – on Linux, at least – requires libtxc-dxtn0).

_ds_ wrote:

Won't work. The image still has to be decompressed to be used; all that you're doing is to reduce the disk space used.

Are you sure? It did read to me that the space saved was not the result of compression, but of reducing from 3/4 byte/pixel to 1 byte per pixel, thus reducing the color depth of the image. If oolite can handle textures with a color depth of 1 byte, it can save a lot of space. However, it might require to have color index information...

Screet

The decompressed image will still be smaller - though the decompression itself will still cost.

Remember - we were expecting smaller pngs to result in smaller overhead.

aside: I've been tied up with helping get a local law repealed. Should be able to focus back on oolite soon.

Simon B wrote:

The decompressed image will still be smaller - though the decompression itself will still cost.

Remember - we were expecting smaller pngs to result in smaller overhead.

aside: I've been tied up with helping get a local law repealed. Should be able to focus back on oolite soon.

Been watching this story - Stephen Fry - our most famous twitterer has blacked out his avatar for this very reason...

Screet wrote:

_ds_ wrote:

It did read to me that the space saved was not the result of compression, but of reducing from 3/4 byte/pixel to 1 byte per pixel, thus reducing the color depth of the image. If oolite can handle textures with a color depth of 1 byte

As Ahruman has informed us a couple of times (probably even in this thread) Oolite uses 24-bit colour, period. So whatever you convert into 1 byte per pixel will be re-converted to 3 bytes per pixel by the engine.

That's my fault for bringing it up, I don't know how these wizardy shenanegans work so I'm easily confused.
I mis-interpreted it as the textures were read at 3 bytes (by the engine placing the texture on its object, so no improvement there), but could be stored at 1 byte to save RAM on low end machines.
Thanks for the answer.

EDIT I forgot to say what I originally came in for!
I thought it would give the game a better sense of travelling if there were different liveries for each of the galaxies, much as we can see the variations between different countries.
Seeing as you can have which (part of the) galaxy you are in effect which missions you receive I'm presuming this is possible.
I think my current livery looks pretty American, I don't see why we should give them the entire place to themselves

Simon B wrote:

I have a problem with the lighting - look:

... what causes this?

A possible reason is that one mesh is using shaders and the other isn’t, and there’s something interesting about the lighting situation – most likely, the ship’s in shadow, which currently isn’t reflected by shaders. I know of two cases where this can happen:

• When using “simple” shader mode, non-smooth meshes/materials with no custom material effects don’t use shaders. This can easily be seen in the standard Coriolis on the Demo2 screen.
• If a shader fails to compile, it’ll fall back to non-shader rendering for that material.

This problem should go away when I get around to fixing the lighting system.

Commander McLane wrote:

Screet wrote:

_ds_ wrote:

It did read to me that the space saved was not the result of compression, but of reducing from 3/4 byte/pixel to 1 byte per pixel, thus reducing the color depth of the image. If oolite can handle textures with a color depth of 1 byte

As Ahruman has informed us a couple of times (probably even in this thread) Oolite uses 24-bit colour, period. So whatever you convert into 1 byte per pixel will be re-converted to 3 bytes per pixel by the engine.

Wrong! I haven’t informed you of anything of the sort.

Most graphics hardware – effectively all graphics hardware – supports a limited set of colour formats. The ones used by Oolite are eight-bit greyscale (“luminance”) and 32-bit RGBA. Paletted colour textures are not supported (they’d require twice as many memory hits per pixel). 24-bit RGB textures aren’t either; I’m not sure why, since the overhead of multiplying by three instead of four is quite small compared to a 1/4 memory saving, but that’s the way it is.

There are 4:1 and 8:1 lossy compression schemes supported in most hardware from the last several years. These are currently not supported by Oolite.

Alas I fear I will never understand the realm of magic!

Ahruman wrote:

Simon B wrote:

I have a problem with the lighting - look:

... what causes this?

A possible reason is that one mesh is using shaders and the other isn’t, and there’s something interesting about the lighting situation – most likely, the ship’s in shadow, which currently isn’t reflected by shaders.

The ship is not in shadow - so I looked closely at the shaders, and discovered that there is a slight (spelling) mistake in the textures, preventing the normal map for the boa2 body being loaded ... I cannot see it for the life of me, but I see an error about a texture not found in the logs. When I copy it's filename to the shader, the funny problem goes away.

(appears - the shaders for the skiff are quite different from that for the body - so I have to bring the maps into agreement to be sure).

The boa (std) body is still unshaded.

I'll be going through all these to get some sort of consistency in the next week or so.

Simon B wrote:

The ship is not in shadow - so I looked closely at the shaders, and discovered that there is a slight (spelling) mistake in the textures, preventing the normal map for the boa2 body being loaded ... I cannot see it for the life of me, but I see an error about a texture not found in the logs. When I copy it's filename to the shader, the funny problem goes away.

Could it be that you accidentally used a shift-space in the filename?

Back in the old university days (early 90's) that was the way we used to create directories for exchanging files we didn't want the universities tech staff to find. It worked for years until most of the people went working for the university themselves

Screet