Planet Texture Coloring (Was: Planet Texture bug?)

[Micha]

Between my current Linux x64 builds of Oolite 1.72 and 1.73, there's a huge difference in the way planetary textures (from Famous Planets) are being rendered.

In 1.72 they look ok, but in 1.73, they are very much blue.

In the "Ruining the Classics" thread there was a discussion on blue objects 2 years ago, however in my case it's only png-wrapped textured planets which are affected - procedurally-generated planets are fine as are all other objects except nebula, which are also extremely dim in 1.73.

My system runs an ATI 9600 XT gfx card, a similar card was mentioned as having similar issues. However, as the planets look alright in 1.72, I'm suspecting it's not a driver issue? I've tried several recent drivers, including the latest, but no real difference between them.

Any suggestions?

[Screet]

My system runs an ATI 9600 XT gfx card, a similar card was mentioned as having similar issues. However, as the planets look alright in 1.72, I'm suspecting it's not a driver issue? I've tried several recent drivers, including the latest, but no real difference between them.

Any suggestions?

RMA your card and switch to nVidia. That's what I did with my 4870x2, however, the same problems it did show where also to be seen with a X1550 and X800XTPE.

As for the planets, I didn't notice yet, but I also almost didn't play in the past due to lack of time. However, the nebulae look just fine in the trunk version for me.

Also my ATI card had sometimes wrong colorings of ships due to a driver fault...maybe something similar is happening for you with the nebulae. Some other ships never did show proper textures with my ATI cards and subentities sometimes were black, white or red instead of showing up properly...all the troubles are gone since I got rid of ATI. I doubt that they soon will fix their drivers.

Screet

[Griff]

I remember that blue tinted objects problem, Ahruman tracked it down to the fragment shader - the vec4 that contained the final colour for the fragment needed to be cleared out with 0.0's before doing anything else, otherwise the ATI cards would colour the objects with a blue tint - Nvidia cards didn't seem to be affected, their drivers must re-initialise vec's automatically or something *shrug*
Maybe the shader used for planets needs this line? it looked like this
for the ship fragment shader:
void main(void)
{
vec4 diffuse = vec4(0.0), specular = vec4(0.0);

[_ds_]

RMA your card and switch to nVidia. That's what I did with my 4870x2, however, the same problems it did show where also to be seen with a X1550 and X800XTPE.

I wouldn't do that: it involves switching to taintware. (Unless nouveau is adequately usable these days…)

[Micha]

Ok, I just threw an Nvidida 6800 GT card into the machine (it's unstable which is why I don't normally run it). It's also quite a few FPS (10-20) slower than the ATI for some reason, 'on paper' it should be at least twice as fast.

Planets are still blue, definitely ruling out the ATI card as an issue there.

But at least the Griff Cobra is now coloured and not just grey (I get shader errors with the ATI card - probably the shader is too complex for it).

[Micha]

Found it - Interaction between Lave.oxp and FamousPlanets2.0.oxp, but it's hinting at a bug anyways.

Basically, Lave.oxp sets some parameters for the procedural-generator including colours. Those colours should, but don't, get reset when there's an actual texture specified.

Looks like the recent planet-rewrite introduced this one

[Micha]

Ok, hopefully fixed.. couple of rather strange coincidences there which led me up the garden-path for quite a while!!

[pagroove]

Thanks Micha,

I saw this too but didn't yet report it. It appeared only at Lave. So the bug is in the Lave.OXP?

[Micha]

The bug is basically that whenever you have a texture -and- override the colours for a planet for the same planet, then the texture is recoloured with the specified colours.

And that's what happens when you install Lave.oxp (overrides planet colours) and Famous Planets (sets a texture)


It just happend to coincidentally recolour the texture quite blueish which led me on that wild goose chase from that other thread..

[Kaks]

Hmmm, I didn't see it as a bug, but as a compromise between what all the various OXPs tried to do: you can get 5-6 distict planetary looks with the same texture & using different colour overrides!

I suppose it could be a potahto potayto thing!

[Micha]

I did actually put that in as a comment

Perhaps we need multiple colour overrides - one for untextured/procedurally textured, and one for supplied-texture?

That way an OXP that -expects- to only recolour the plain planet can do so, and an OXP which wants to recolour its own textures can do so as well, without the two interfering with each other.

[Kaks]

I've got no problem with the idea, but how do we differentiate between the two different types of colour overrides? A_C, what do you think?

[another_commander]

At first impression, I would agree with Kaks that this can be considered a non-bug. Differentiating between the two coloring actions (planet vs texture) sounds like a nice idea. Differentiating could probably be done by making an extra key in planetinfo? Not sure, just throwing the idea here. Obviously it will need some more thought.

[Micha]

I missed the fact that it was designed this way - certainly a big difference in behaviour between 1.72 and 1.73.

Since it's easier to make a new key than coding every OXP to check whether colours have been specified / OtherOXP is installed, I'd like to see a new key.

--> Existing:
land_hsb_color = "1 2 3"; // Sets the colour of land masses
sea_hsb_color = "1 2 3"; // Sets the colour of seas

--> Proposed new:
texture_hsb_color = "1 2 3"; // Adjusts the colour of a supplied textured

[Kaks]

Sounds good to me. What about polar_color_factor, clear_sky_color, cloud_color , polar_clear_sky_color, polar_cloud_color & cloud_alpha, though?