I just finished, well sort of , my perpixel bump map demo (probably my millionth perpixel bump variation ) which uses arb vertex programs (my first REAL arb_v_p prog) and well it looks all bumpy and whatnot but there is a wierd problem. I load all the md2 stuff in correctly, it’s being done the same as everyone else so that part is fine. But for some reason the texture is not oriented like it should be. I used the textures from the md2bump demo on nvidia’s site so it should look just like, well pretty much, the md2shader demo. Oh ya I’m using the knight model. Ok anyway, when it’s running the part of the texture that is the knight’s shield is on his FACE! Ok and his face from the texture is on his SHIELD! It’s kind of funny looking though. Oh and his face is upside down. Is there anything kind of wierd or funky about md2 texturing that I may not know about. From what I could tell everything should be right. I’m going to write a quick md5mesh loading function later and try that. But I would like the md2 to work properly.
I know it’s not much to go on but I’m not at home now so I cant post any kind of code. So if there is any kind of wierd thing that has to be done to md2’s to texture them I would like to know. Cuz something is gimped.
-SirKnight
[This message has been edited by SirKnight (edited 12-06-2002).]
You must use 1-t for t texture coordinate if you use glTexCoord2f(floating point coords are stored in glcommands) or skinheight-t if you use glTexCoord2i(these short coords are stored in dstvert_t struct).
use glTexCoord2f(floating point coords are stored in glcommands) or skinheight-t if you use glTexCoord2i(these short coords are stored in dstvert_t struct).
Oh so that’s what the problem is. Hmm I had no idea about that. Well I’ll try it later when I get home. I knew there had to be something screwy with the texcoords somehow. I don’t use the glcommand thing in the md2 file, so I guess I am using the other coords, the short coords as you say in the vert struct. Thanks!
-SirKnight
[This message has been edited by SirKnight (edited 12-06-2002).]
Ok just wondering. Why would the texture be upside down? I noticed also that even with the doom 3 md5mesh file they do a 1-v when loading the texture coords. I have never had a problem of upside down textures before. Is it just something wierd that Carmack does to his stuff?
I’m not sure that it has something with how TGAs are stored because Q2 originally used PCX files for models. In TGAs there is bit flag for picture orientation (in Image Descriptor) but I never seen anyone actually use it.
Most TGA images are stored from bottom to top. OpenGL likes bottom to top also, so they work well together. PCXs are stored from top to bottom, so in an Md2 file, loading a PCX would map correctly, whereas a TGA would be upsidedown.
Instead of flipping the image flip the V coordinate.
V=1.0f-V
LightWave likes to store TGAs from top to bottom :/. PaintShop Pro saves the from bottom to top.
Ohh I see. I wasn’t sure if tga’s were stored bottom-top or not. I never wrote any code that saves them, actually my code that loads them isn’t even mine.
Well I just tried the one minus thing and it works. And now that this was pointed out, I can obviously see why it works. I wonder why I never thought of this before.
For some reason my model seems a little dark, quite a bit darker than the md2shader demo’s models for some reason. Maybe my normal map is just crappy.
Welp solved the dark problem. I just added a base pass so I can add in the ambient term. I totally forgot about that. I guess that’s what happens when I have tons of finals comming up sooner than I would like.
-SirKnight
[This message has been edited by SirKnight (edited 12-06-2002).]
>>Ohh I see. I wasn’t sure if tga’s were stored bottom-top or not.<<
perhaps
Field 5.1 (2 bytes) - X-origin of Image: These bytes specify the absolute horizontal coordinate for the lower left corner of the image as it is positioned on a display device having an origin at the lower left of the screen (e.g., the TARGA series). Field 5.2 (2 bytes) - Y-origin of Image: These bytes specify the absolute vertical coordinate for the lower left corner of the image as it is positioned on a display device having an origin at the lower left of the screen (e.g., the TARGA series).
That’s not actually the part that specifies whether the image is top-to-bottom or bottom-to-top.
I believe it’s bit 0x20 in the image descriptor (that also contains alpha bit count) that is set if the image is top-to-bottom, but it’s been a while. I agree that you should check the spec.
You can use glPixelZoom(1,-1) to flip a texture image on upload. You can use the texture matrix to flip texture coordinates when drawing.
u are correct
Bits 5 & 4:These bits are used to indicate the order in which pixel data is transferred from the file to the screen. Bit 4 is for left-to-right ordering and bit 5 is for topto- bottom ordering as shown below. Table 2 - Image Origin Image Origin bit 5 bit 4 0 0 0 1 1 0 1 1 Screen destination of first pixel bottom left bottom right top left top right
, my perpixel bump map demo (probably my millionth perpixel bump variation 
) which uses arb vertex programs (my first REAL arb_v_p prog) and well it looks all bumpy and whatnot but there is a wierd problem. I load all the md2 stuff in correctly, it’s being done the same as everyone else so that part is fine. But for some reason the texture is not oriented like it should be. I used the textures from the md2bump demo on nvidia’s site so it should look just like, well pretty much, the md2shader demo. Oh ya I’m using the knight model. Ok anyway, when it’s running the part of the texture that is the knight’s shield is on his FACE! 
Ok and his face from the texture is on his SHIELD! It’s kind of funny looking though. Oh and his face is upside down. Is there anything kind of wierd or funky about md2 texturing that I may not know about. From what I could tell everything should be right. I’m going to write a quick md5mesh loading function later and try that. But I would like the md2 to work properly.