Sigh…I think the DDS gamma mess is now fixed. This mess had two parts:
- Since X-Plane treated DDS as having a gamma of 1.8, all DDS material had to be gamma corrected. As it turns out, the error from gamma correcting a DXT-compressed texture is surprisingly small, but it was still silly to use anything other than sRGB given today’s computing environment.
- In investigating this, I discovered that XGrinder/DDSTool from the scenery tools distro are inconsistent; they write out DDS using a gamma of 1.8 on Mac and 2.2 on Windows, resulting in overly bright DDS for authors using Windows.
This is now all fixed in the new DDSTool/XGrinder:
- A bit in the DDS file is used to specify what gamma the file was written with: 1.8 (v9) or 2.2 (good for v10).
- X-Plane 10 will look at this flag and correct gamma accordingly.
- The choice of gamma is a menu setting, and is selectable on both Mac and Windows.
I’m not sure when we’ll have a binary distribution, but the code is in the public GIT repo if anyone wants it. The new tool should be better for both authors targeting v9 and v10.
(begin rant)
And for those who want to know why we aren’t communicating more, this is the reason why. A release is made up of a huge number of small details all of which have to be made right, none of which is particularly sexy, and all of which have to be fixed to create an overall effect that is immersive and beautiful.
The saying in aviation is: “aviate, navigate, communicate”; that seems like a good policy for X-Plane 10 too. I’m going to try to fix as many of these small issues as possible so we can have a functional beta, then we can talk about it.
(end rant)
“I’m going to try to fix as many of these small issues as possible so we can have a functional beta, then we can talk about it.”
If we’re truly into the ‘fixing the small issues’ development phase, then I am happy enough. I just won’t ask how long the ‘small issues’ list is!
It’s not that simple. Sometimes a big issue (next-gen road system) is the sum of a huge number of small issues.
Sorry for the off-topic, but I haven’t heard anything about compatibility between X-Plane 9.70 and Lion. Maybe now that Apple has made public that the product is arriving tomorrow, you could share any specifics? Is there any issue we should be aware of?
It’ll probably work – we’ll see soon. If not, we’ll patch it.
I thought apple switched to using 2.2 gamma since OS X10.5?
I thought the change was 10.6, but the old 1.8 gamma goes back a long time, that’s where X-Plane picked it up.
I would urge you to take a second look into the DDS specification.
There are pixel formats explicitly reserved for sRGB encoding, but you need to support the DirectX10 variant of DDS to encode them.
For instance there is DXGI_FORMAT_BC1_UNORM and there is DXGI_FORMAT_BC1_UNORM_SRGB, to specifically denote sRGB color space.
That said, there is a lack of tools do deal with DDS on the mac platform.
Hrm – those formats probably don’t do what we’re doing – I think they’re like OpenGL – they tell the texture sampler to convert to linear color space on texel fetch. We’re just changing the gamma. We could use those enums…but it might make the toolset we can use even thinner since most Windows encoders will write out DXT5 with a gamma of 2.2 by default.
The value in the DDS file is only for information. It is not passed as enumerant to OpenGL (how?). You can, of course, take this information and use the equivalent OpenGL internal formats (that would be GL_COMPRESSED_SRGB_S3TC_DXT1 et al). But that’s not what I was saying. I was saying, before introducing non-standard flags for x-plane into the DDS files, why not stick with the signaling that already exists, to a maximum extent.
The flag is standard – like the enumerant it is a piece of DX spec that has no direct meaning for an OpenGL app and interpreting it mean something in particular.
What we have running now (and this will probably be the shipping impl) is:
– The “complex” surface flag indicate a gamma of 1.8.
– When it is missing, we us a gamma of 2.2.
Why this works:
– The complex flag should never have been set, in hindsight.
– The gamma never should have been 1.8.
So the flag acts as a signal that the file was built using the old version of DDSTool, which is the only tool out there that sets the gamma weirdly, I think.