Floor Rainbow
- pie goes moo
- Round Winner
- Posts: 306
- Joined: Wed Aug 12, 2009 10:42 pm
- Location: San Antonio, Texas, USA
Re: Floor Rainbow
Does it have to do with the moviepack? The floor.png?
Re: Floor Rainbow
yes, and he probably changed the setting for its size (i know that effect from some of my mps)
Re: Floor Rainbow
Thats rad!
Re: Floor Rainbow
The mipmaps for the floor get calculated wrongly. Not our fault, we delegate that to GLU
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Floor Rainbow
I think I got something like that with grayscale textures once. But not always. Don't remember much more.
ˌɑrməˈɡɛˌtrɑn
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Re: Floor Rainbow
No, nothing to do with floor.png or the GRID_SIZE[_MOVIEPACK], and occurs with both moviepack and regular textures. It's apparently caused solely by the floor_a/b.png's that are involved, with "dual texture plane" and alpha blending enabled. I guess it's something to do with what Z-Man and Jonathan are describing.
What I don't get is this: With the default floor_a/b.png's, changing [MOVIEPACK_]FLOOR_RGB only affects the gridlines—the space in between remains black. On the other hand, with the floor_a/b.png's I've used, changing floor color affects the entire floor. That's with "dual texture plane" and alpha blending enabled, as mentioned.
Here are a few more shots, plus the floor_a/b textures involved.
What I don't get is this: With the default floor_a/b.png's, changing [MOVIEPACK_]FLOOR_RGB only affects the gridlines—the space in between remains black. On the other hand, with the floor_a/b.png's I've used, changing floor color affects the entire floor. That's with "dual texture plane" and alpha blending enabled, as mentioned.
Here are a few more shots, plus the floor_a/b textures involved.
- Attachments
-
- floorlines.zip
- (737 Bytes) Downloaded 158 times
Last edited by Phytotron on Wed Sep 30, 2009 11:41 pm, edited 3 times in total.
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Re: Floor Rainbow
And here's what happens with the floor_a/b that I've included here. If you take a look at the floor lines, you'll see they didn't quite work out the way I had anticipated. The only difference between these two sets of pics is with the MOVIEPACK_FLOOR_RGB—all 0.5 in the darker ones, and 1 in the lighter.
- Attachments
-
- otherlines.tar.bz2
- (5.14 KiB) Downloaded 153 times
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Floor Rainbow
The coloring of the floor works by component-wise multiplication in normalized RGB. So if part of the floor is white, the floor color will show through unmodified. If the texture is gray like your textures, it'll be darkened. If the texture is black like most of the default textures, you'd better like black because nothing will change it (perhaps a division by zero, if that gets your hopes up). If the texture is red, you're filtering the red channel of the floor color, and you'll just get brighter or darker red (down to black) depending only on the red part of the floor color. Walls are exactly the same, except the input color can be modified a bit if the game thinks it might work as camouflage. Cycle textures work a bit differently; they're blended over the (again possibly tweaked) cycle color using the alpha channel.Phytotron wrote:What I don't get is this: With the default floor_a/b.png's, changing [MOVIEPACK_]FLOOR_RGB only affects the gridlines—the space in between remains black. On the other hand, with the floor_a/b.png's I've used, changing floor color affects the entire floor. That's with "dual texture plane" and alpha blending enabled, as mentioned.
Okay, back to business before I get to real color management.
Summary of PNG types:
floor lines/floor_a.png: 8-bit RGB
floor lines/floor_b.png: 8-bit RGB
otherlines/floor_a.png: 8-bit RGBA
otherlines/floor_b.png: 8-bit RGB
Seeing this, the grayscale problem might actually be the reverse.
/me is too lazy to go testing.
ˌɑrməˈɡɛˌtrɑn
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Floor Rainbow
There, happened again. This time I think I figured it out, and it turns out mipmaps are more of a victim than a cause. Try getting your glPixelStorei(GL_UNPACK_ALIGNMENT, ...) right, as well as your GL_PACK_ALIGNMENT. Testing in my own code confirmed that's how it works, both for glTexImage2D and gluBuild2DMipmaps. Only the dual floor was affected because floor_a is the only texture < 4 wide, rendering it vulnerable if each pixel is smaller than 4 bytes.
ˌɑrməˈɡɛˌtrɑn
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Re: Floor Rainbow
Right on. It would mean more to me if I knew what any of that...meant. But, is the upshot that you've found that this is something that could be avoided in some manner, be it through code correction or something the user can do?
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Floor Rainbow
If I'm reading the code correctly, as texture maker you should make an RGBA or gray-alpha texture, and enable truecolor textures, to work around the problem. In more detail:
RGB/grayscale with truecolor textures enabled: width should be a multiple of 4
RGBA/gray-alpha with truecolor textures enabled: width should be a multiple of 1 (anything is fine)
Anything with truecolor textures disabled: width should be a multiple of 2
Edit: Scratch that. I was reading the wrong part and ignored how it didn't make sense. This looks more correct and is what I suspected before investigating Arma's side:
Grayscale: 4
Gray-alpha: 2
RGB: 4
RGBA: 1
Some spec hunting to confirm GLU uses GL's unpack mode:
Hmmm, I wonder about SDL_Surface now. Edit: Alignment bytes are apparently supported, but the docs don't tell if IMG_Load does any alignment. Another edit: SDL surfaces are, guess what, aligned to 4 bytes, the same as OpenGL's default. This is becoming confusing.
RGB/grayscale with truecolor textures enabled: width should be a multiple of 4
RGBA/gray-alpha with truecolor textures enabled: width should be a multiple of 1 (anything is fine)
Anything with truecolor textures disabled: width should be a multiple of 2
Edit: Scratch that. I was reading the wrong part and ignored how it didn't make sense. This looks more correct and is what I suspected before investigating Arma's side:
Grayscale: 4
Gray-alpha: 2
RGB: 4
RGBA: 1
Some spec hunting to confirm GLU uses GL's unpack mode:
That's clear. Only it's the wrong function.gluScaleImage wrote:gluScaleImage will scale an image using the appropriate pixel store modes to unpack data from the input image and pack the result into the output image.
A bit vague. "The same meaning" should imply the unpack mode is used. Which makes sense; just wanted to confirm.gluBuildnDMipmaps wrote:target, internalFormat, format, type, width, height, depth, and data define the level 0 texture, and have the same meaning as the corresponding arguments to glTexImage1D, glTexImage2D, and glTexImage3D.
Hmmm, I wonder about SDL_Surface now. Edit: Alignment bytes are apparently supported, but the docs don't tell if IMG_Load does any alignment. Another edit: SDL surfaces are, guess what, aligned to 4 bytes, the same as OpenGL's default. This is becoming confusing.
ˌɑrməˈɡɛˌtrɑn
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Floor Rainbow
Some more testing. I've linked it to SDL_Image 1.2.3 which shipped with 0.2.8.2.1. Plopping in the current SDL_Image 1.2.10 fixes it. Oh well.
Still, the screenshots. make_screenshot (the flipping part, which is redundantly executed when saving PNG, by the way) and SDL_SavePNG (an Arma function which, because it flips, doesn't only not deserve that name because it isn't SDL) don't use the pitch (bytes per row) of the surface. At least in 0.2.8.2.1; there's a chance this was also fixed in the meantime. I should learn to check current versions.
Still, the screenshots. make_screenshot (the flipping part, which is redundantly executed when saving PNG, by the way) and SDL_SavePNG (an Arma function which, because it flips, doesn't only not deserve that name because it isn't SDL) don't use the pitch (bytes per row) of the surface. At least in 0.2.8.2.1; there's a chance this was also fixed in the meantime. I should learn to check current versions.
ˌɑrməˈɡɛˌtrɑn
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Re: Floor Rainbow
So, you're saying that, at least in the case of my rainbows above, it's because the floor_a/b textures are in plain RGB (no alpha channel), but only 1 pixel [wide or high, respectively] when it should have been 4 pixels?