Using jpgs as alpha channels

(DickDastardly) #1

Hi all,
Something I’ve wondered about for a while: Would it be possible to add a feature to q3map2 to enable mappers to use jpgs as alpha channels in shaders?

The idea is u could have an image called, say, “texture.jpg” and q3map2 would check for the existence of another file called “texturealpha.jpg” and use that for the alpha channel in shaders referencing “texture.jpg” (in the absence of a “texture.tga” file).

Obviously the advantage would be a potentially large saving in tex memory compared to tgas but I’m not sure if this is even implementable without a change to q3 itself. Ydnar?
Cheers,
DD

(BoltyBoy) #2

As I understand it , whether you use tgas or jpgs they both require the same amount of memory once loaded byQ3 engine.

But then of course jpgs would make for smaller pk3s

(Tweety) #3

Hi…

Might be difficult. You need a grayscaled jpg for alpha. Then you have to read this information and put it together with the other jpeg (the rgb one) to have a 32 bit rgba texture that can be used on a polygon. You have to generate a new texture from two different ones. A 32 bit tga can be used “as is”.
Perhaps this conversion costs performance.

And what happens if this alpha-jpg is rgb. What color should be used? red, green…you have to define a standard for it.

:slight_smile:
Tweety

(DickDastardly) #4

I’m guessing q3 reads the main tga and stores it somewhere and then does the same with its alpha channel, it’s not obvious that this would necessarily be faster than reading 2 jpgs, particularly if the 2 jpgs are significantly smaller (mem wise) than the tga. As for the alpha channel jpg, that would be greyscale just like the alpha channel in a tga.

(Tom Cleghorn) #5

If I understand it correctly, that wouldn’t really be of any advantage at all, since jpeg uses lossy compression - so the ‘alpha channel’ jpeg would lose detail, and probably cause problems. Also, I don’t think greyscale jpegs can exist anyway - just jpegs that look like they’re black and white, if you see what I mean.

(Grand Nagus) #6

I don’t think that two jpgs could be used as a texture and an alpha for that texture. Or, at least, easily. Unless I’m wrong, I think that the alpha blending functions that Quake3 uses are directly called from open-gl, which means that doing something that isn’t hard-coded into open-gl wouldn’t be possible (unless you emulate the function, which would slow down the game). In other words, open-gl deals with the alpha textures ‘as-is’, rather than trying to code the ability to separate the alpha from the texture and then blending them manually… It just makes things easier for the programmer!

Just out of curiousity, I wonder if Doom3 is going to be written for open-gl or Direct3D? There’s just so many new rendering functions in Direct3D that Carmack could play with! Unfortunately that would limit the game’s portability… Well, we’ll see (hopefully soon) !

(Tweety) #7

Yes…I agree with you. It´s OpenGl specific.
That´s what I meant by making one 32 bit tga of those two jpg´s.

:slight_smile:
Tweety

(r3tina) #8

It will use OpenGL. Note that OpenGL does not have less features as D3D, because all the “DX9 features” are accessable from OGL too.

(G0-Gerbil) #9

Definately. I’ve used beta software that allowed JPGs for alpha channels and the functionality was disabled because of the glitches it introduces - too many people thought alpha channels were bugged, but it was simply the result of JPG artifacts. Any decent paint package can use alpha channels in TGA - if you really wanted seperate import, it would only make sense to use a format with lossless or no compression.

(DickDastardly) #10

Oh well, cheers for the info guys.
DD

(ydnar) #11

This really isn’t a compiler issue.

The engine texture loading code could theoretically be changed to load a grayscale JPEG as a texture’s alpha channel, but that would require, well, engine code changes. :slight_smile:

y

(cloudscapes) #12

A better solution would be DDS support in an upcoming Q3 PR for example. DDS is D3D-native but I believe OGL engines can be modified to load these as well. The compression is mostly lossless (except for some extreme ranges of colors, eg: nearly black and nearly white can be lost or modified in the conversion) You’d get texture files which are one-fourth the size of the normal TGA. :slight_smile:

Oh well, I can still dream.