gamma - grayscale filter
Blitz3D Forums/Blitz3D Programming/gamma - grayscale filter
| ||
| is it possible to produce a B/W filter ? |
| ||
| Not by altering the gamma tables, no. I can't think of any way to do it with the normal blending modes either. There is one possiblity however. It may be possible to do it with the dot3 blending mode. Dot 3 works by mulltiplying two vectors together and producing a grayscale result. This is then blended which pixels for lighting. The dot 3 blend works like so. The color of the pixel, R, G, B represents a vector, V1xyz. The color of the object that the dot 3 blend is set on is also converted to a vector. A dot product is then performed: Dot# = V1x#*V2x# + V1y#*V2y# + V1z#*V2z# The resulting color is computed by multiplying Dot# by 255. If the RGB color of the pixel is 255,255,255 that would result in a vector of 1,1,1. 1*1 + 1*1 + 1*1 = 3. 3*255 is too high a value. So, you want to blend a plane over the scene using dot 3 whose color is 255/3.0, ie, (85, 85, 85) so that the maximum greyscale value will be 1.0. I think that should work! :-) [edit] Hm, just thought of something. The vectors can have negative values. Any color channel less than 127 goes negative... Hm... Not sure how that will affect the result. You may have to add 127 to the color of the dot 3 overlay quad. And you may have to first add blend a 127,127,127 quad over the scene to obliterate the values which are so low they are negative. But that would obliterate all values which ended up being positive... Leading the image to appear overexposed. Perhaps you could reach a compromise with an add plane of 64,64,64. Negative values are clamped to 0, so you would end up with a scene that has some "overexposed" dark areas and some "overexposed" light areas, But the midrange would be okay. [/edit] |
| ||
| if yu can code a snippet... :) |
| ||
| I was mistaken. There is apparently no dot 3 blend mode for entityblend in Blitz, only for textureblend. I do not think there is any reason for this limitation... I think Mark simply chose not to support it for whatever reason. Regardless, without a Dot 3 entityblend mode there is no way to do the effect I described above. I'll see if I can think of any oher way to accomplish this effect, but don't hold your breath! |
| ||
| Best i can think of is creating a wash out effect using camera fog, range -100 to 100. Probably nothing that you want though.... |
| ||
| Make all your textures black and white. :D Seriously, you should not rely on automatic processing to set your saturation and brightness levels. |
| ||
| I did a working grayscale function a long time ago in 5 min. Since all grayscale pictures has equal RGB values (very obvious), you can do this perfectly by taking each pixel from the src image, find the middlevalue (basic math: m=rgb/3) of RGB, and write that value as RGB to dest image at same pixel. 20,10,60 at org pic would ie be 30,30,30 on dest pic. I'm sure u understand. |
| ||
| Yes, ChrML, but that's very slooooooooooooooooow! :) I guess Ed wants it for rendering a light/shadow map or something. I could do with this as well. Tried farting around with gamma tables but, frankly, they're a bloody mystery to me - the docs being about as much use as an ashtray on a motorbike, as they are. :P |
| ||
| That sounds slow. |
| ||
| I think Halo must be sick and freebasing cough syrup, because he actually offered a helpful suggestion and put a smiley face after it. Either that, or this is an imposter. |
| ||
| Yes, if only I knew what "you should not rely on automatic processing to set your saturation and brightness levels" meant, I'd be quids in! :P |
| ||
| That would be cool if you could get the greyscale working. I'd like to do a black-and-white to color transition in my game. There is also a lib around somewhere that does real-time fullscreen pixel processing. It might be okay for some situations. |
| ||
| "Yes, if only I knew what "you should not rely on automatic processing to set your saturation and brightness levels" meant, I'd be quids in!" All Halo was saying is instead of processing the image in realtime, just make grayscale textures to texture the geometry with when you want to put the game in a grayscale mode. And that doing this would give you more control over what the final image looked like, than simply converting the image to greyscale based on how bright each pixel is automatically. |
| ||
| Wasn't there a tech demo made recently (see the online magazine) - you know, the one with the spikey balls - that was balck and white and greyshades and seemed awfully fast to me. Mike |
| ||
| what about "Graphics3D 1024,768,4,1" ?? sorry, just joking..... |
| ||
| unfortunataly the setgamma command can only set the intenity of each channel, there is no way to assign an individual color to a default RGB 24Bit Value. You can filter out one or 2 Colors, eg. show only the red colors, but that's all. Maybe the easiest way would be to use BW-Textures. One could write a funtion that will clone a scene and create BW Versions of all textures on the fly... |
| ||
| Here is a little demo I wrote to show how I would roughly go about it. Hope it helps :-) http://members.iinet.net.au/~pmerwarth/Color2BandW.zip |
| ||
| well, basicly you are using BW textures. Of course, it's the easiest thing. Problem is: when you have loaded some meshes and don't know what textures they use etc. and simply want to "switch" to BW, without any prepared content. I'd suggest to keep all meshes accessible in an array, or as types. Then you only need to parse all meshes (recursively with children, if LoadAnimMesh was used). The app will then track down the used textures by GetsurfaceBrush and GetBrushTexture Commands, use some (r+g+b)/3 pixel manipulation in the texturebuffers (note: the texture returned by GetBrushTexture is a Copy of the original, so you may edit it without to edit the origninal one, but you need to paintsurface the surface with this edited brush). So you would clone every mesh, hide the original and alter the textures of the clones. I think it's possible to manage it in 2 functions: BWinit() and BWexit(). DX-lights are a further problem. If they (and their colors) are kept in arrays, then it will be easy to set them to something grey, and to restore them in the BWexit function. This is a typical example of how a Program can be a dead end if you forgot to implement some basic features (like storing all content in an accessible list). |
   |