iDevGames Forums
DDS Textures - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: DDS Textures (/thread-2842.html)

Pages: 1 2


DDS Textures - TomorrowPlusX - Jan 10, 2008 02:19 PM

I had the good luck to find a link to a pile of DDS textures from NVIDIA the other day. They're pretty nice, and would save me some time making my own textures. Of course, they're not really public domain, but I'm just fooling around anyway.

http://developer.nvidia.com/object/IO_TTVol_01.html

I've found sample code to load them into OpenGL. The trouble is, I don't have a viewer which can view them. And I don't think photoshop ( on OS X at least ) will export DDS textures either.

So, I'm wondering if anybody knows of viewers for DDS, and if there are exporters for DDS either.

Secondly, if I go through the trouble of writing a loader, would anybody be interested if I wrote a quicklook plugin to display them?

Part of me thinks I might just be wasting my time. Wacko


DDS Textures - ThemsAllTook - Jan 10, 2008 02:31 PM

I've been working on an image editor with DDS support planned, but I haven't written the I/O code for DDS yet. If you write a loader, I could definitely get some use out of it as a reference.


DDS Textures - TomorrowPlusX - Jan 10, 2008 02:46 PM

The sample code I found was on mindcontrol.org ( the author a contributor to ODE ). That being said, it just unpacks the raw data into a struct reverse engineered from DX headers and passes it on to gl via glCompressedTexImage2D. So, even if I get it working, it's not a decompressor. GL is doing the work. And it wouldn't be any use for compressing, either.

I figure that if I wrote a QL plugin it would work by rendering the texture to an offscreen context and then use glReadPixels to fill an NSImage.


DDS Textures - Frank C. - Jan 10, 2008 03:40 PM

You guys might want to check out SOIL. I haven't tried it yet myself but it looks to have decent DDS support.

Edit: Almost forgot! There's the Squish framework and Graphic Converter has supported dds for a while now.


DDS Textures - OneSadCookie - Jan 10, 2008 06:26 PM

Graphic Converter does *not* support DDS. It is unable to read valid DDS files, and unable to write valid DDS files.


DDS Textures - Terrydil - Jan 10, 2008 06:48 PM

I was able to use Graphic Converter to open the DDS files at the link TomorrowPlusX provided.

According to the website it should be able to import and export DDS. Are these somehow not valid?


DDS Textures - OneSadCookie - Jan 10, 2008 07:03 PM

Well, maybe he's fixed it recently, but there was a long time when it claimed support, wrote corrupt files, and was unable to read correct files.


DDS Textures - TomorrowPlusX - Jan 11, 2008 08:02 AM

Wow! SOIL looks frakking awesome.

I'd been planning to replace my use of libPNG with stb_image for a while... SOIL looks like a nice rational wrapper to stb_image. Awesome!


DDS Textures - macnib - Jan 11, 2008 10:01 AM

Hmm, Soil looks useful. Particularly, the stb_image_aug stuff. Though, would be nice if you could query for w,h, and components without the decode. They have the call in there but its not implemented.

Was using FreeImage. But I had some problems on Leopard and had to ditch it. They want to link against old sdks. Just seemed a little odd. Seems geared towards php. Not sure if it was a 64 vs 32 bit thing either.

Currently back to Quartz. Problem with this boils down to the CGBitmapContextCreate call. They just have to premultiply alpha. kCGImageAlphaLast does not seem to work and just get a black image. But kCGImageAlphaPremultipliedLast does. Thats fine in most cases. Problem is if I want to pass a gray scale map in the alpha channel to a glsl shader -- now I don't want premultiply! eg. using the alpha channel in a normal map. Yet, now you have to use another texture unit to get around the premultiply issue!

Hmm, sub out the Quartz and replace it with stb_image_aug stuff. Possible. Grin


DDS Textures - TomorrowPlusX - Jan 11, 2008 12:06 PM

That's exactly why I don't use Quartz for image loading. I have several bumpmap shaders which treat the normal map's alpha channel as a specular map. I could use another texture unit, but why?


DDS Textures - reubert - Jan 11, 2008 01:37 PM

Me too. premultiplied alpha is an outdated optimization that just pisses programmers off and does little good. GLSL is the main case where it's an annoyance, but it also causes an extra divide or multiply when creating and loading your own data buffers. Photoshop's lack of proper alpha support doesn't help matters much either.

Even worse is what Quartz does when loading PNGs with any of the gamma or other profiling chunks. It's dead easy to create a grey buffer all at 127, then save it, load it again and see all 110s or something. Just what people want. :/

Sorry, I always jump at the chance to rant about the stupidity of the image loading world Wink Don't get me started on color profiles.


DDS Textures - arekkusu - Jan 14, 2008 05:04 PM

Guys, please file radars with your grievances about [Quartz, image loading, premultiplied alpha].

IMHO, if Quartz isn't going to support non-premultipled bitmap contexts, there ought to be a way to get canonical format data out of a CGImage without compositing it.


DDS Textures - sohta - Jan 14, 2008 05:36 PM

reubert Wrote:Even worse is what Quartz does when loading PNGs with any of the gamma or other profiling chunks. It's dead easy to create a grey buffer all at 127, then save it, load it again and see all 110s or something. Just what people want. :/

No offense, but if you are using a gamma-corrected format, how can you complain about it being gamma-corrected?


DDS Textures - Skorche - Jan 14, 2008 06:00 PM

reubert Wrote:Me too. premultiplied alpha is an outdated optimization that just pisses programmers off and does little good.

Outdated? There are still good reasons to load (or save) textures with premultiplied alpha. It's the only good way that I know of to avoid fringes when scaling textures.


DDS Textures - reubert - Jan 14, 2008 06:07 PM

Granted, the real problem is that PNG even stores gamma information. Quartz pretty much had to observe PNG's stupidity.

Unfortunately every second application does not observe the gamma information, the quartz api gives no ability to ignore it or not, some applications (I'm looking at you photoshop) store gamma information but do not respect it on load, the gamma information stored could come from any number of places, including your monitor's color profile, some applications will acumulate the gamma information when converting between formats...

I use PNG because it compresses well, is widely supported, and handles alpha. There really aren't any alternatives. It's just a shame someone decided it would be a good idea to store gamma in the file.

Basically if I set my monitor to make everything look like it's on TV, then I want everything to look like TV. PNGs included. That the format thinks it should be able to override a user's monitor setting and look different to everything else is plain broken.