Film Grain
Blitz3D Forums/Blitz3D Beginners Area/Film Grain
| ||
| For a film grain effect, I could make an animated texture and apply it to the camera, right? If so, how would I go about applying it to the camera? |
| ||
| position the texture in front of the camera using the camera cords |
| ||
| hey IKG, just curiuos, what kind of project are you working on? |
| ||
| Heh heh. Can't say yet. Right now I'm just trying to learn some new techniques. Thanks, Nicoust. Edit: What if the player chooses 1024x480 instead of 800x600? How would I make the sprite adjust to the new camera resolution? In fact, how would I even do that with everything else 2D (inventory, etc.) Sorry to go off topic but I need to know =/ |
| ||
| But aren't when you're on 3d mode, all distances in worldspace, so that the resolution has no effect on it ? The best thing to do for the grain effect would be creating a box, with the camera as a parent. box = CreateBox(camera) then moving it a bit further away from the camera with MoveEntity. If you move the camera, the box should stay in front of it. Later on, replace the box with a quad, using CreateMesh and Addvertex. |
| ||
| Er didn't really understand your post, Bram. You're saying that anything I place in 2D will automatically adjust in different resolutions? |
| ||
| I believe 3D is allways scaled the same way, independant from the resolution selected. So "2D-in-3D" (using a texture) will be rescaled automatically. Textures should be allways square and have a width 2^something, like 64x64,128x128,256x256,512x512 etc. If an texture image has a different size, it will be resized at load. |
| ||
| sprites work better. Create a sprite parented to the camera, move it about 1 unit forward, add a simple 64x64 static texture and jsut update the UV's on the sprite to random values like so. PositionTexture static,Rand(1,64),Rand(1,64) And that will work to! |
| ||
| Very large texture fills, textures filling 70+% of the screen, take a huge performance hit on Blitz. A full screen textured sprite will scale according to screen but be quite a slowdown, which on older cards could be a killer. The alternative is to randomly 2D draw grain particles on the backbuffer. You'd only need to draw to some 5% or the screen which should be a lot faster. If you want every pixel to have a variation, like a random alpha on a black texture, the sprite method might well be no slower than full-screen per pixel processing. |
| ||
| I suppose drawing random dots on the screen would be more natural than a sprite. |
| ||
| Maybe you could draw a masked 2D imagestrip on top of the rendered scene with black and white noise. |
| ||
| Now that I think of it, I'm probably just going to go for a "grainy" effect. I'll either draw it randomly by code, or load an animated sprite. Thanks all! |
| ||
| What could work is something I tried with a parallax starfield. Rather than one big sprite with noise, create a few dozen smaller sprites with randomised noise and position them fairly randomly over the screen each frame. This avoids the large-texture problem, keeps it 3D which is faster than 2D in many cases, and scales with resolution. |
| ||
| So you say when I cover the screen with lots of small sprites this ill be faster than to cover it with one big sprite? Maybe it would also be faster to use blendmode 3 (Add) instead of alpha for the texture ? I mostly like the PositionTexture solution. It allows a lot of fx, such as a nightview google greenish grain/noise. |
| ||
| That's what I've found. I first noticed then when running my program on a lowly 266 MHz K6, and it was really, really slow, when commenting out various things I removed the sphere-with-texture backdrop and suddenly increased the speed 5 to 10 times. First I thought it the sphere complexity (though only CreateSphere(12) in resolution) but replacing the backdrop with a full-screen quad had the same problem. I then tried a half-size quad and the spped was back up to fast and smooth. I raised this with Mustang in the atmosphere thread and he found similar slowdowns, but of course it was rendering a lot more pixels. So it could have been on this old GPU (ATi Rage I think) there was a dramatic fillrate bottleneck that isn't as present on newer GPUs. A quick test program shows increasing backdrop fill doesn't have this dramatic drop-off threshold I experienced on the slower PC, but has a proportional change in render speed relative to quad size, whether that's made of multiple quads or one big one. It might not be an issue if you don't care to support anything older than maybe a GeForce 2/3. |
| ||
| http://blitzbasic.com/codearcs/codearcs.php?code=1183 |
| ||
Oh, btw, when positioning the texture:PositionTexture static,Rand(1,64),Rand(1,64) Won't do anything, unless you've set your uv co-ords weird. PositionTexture static,Rand(0,1),Rand(0,1) might be better ;) |
| ||
| actually that might be alot worse since Rand() returns an integer :P Might be better to use Rnd(), returning a float.. hoho |
| ||
| Thats what i get for copy and pasting a guess ;o) |
| ||
| CreateSphere(12) Is it me or would that create a super-high res mesh? |
| ||
| 12 segments for a sphere isn't that much, i believe the default is 8 - i usually use 32 when a nice smooth sphere is needed.. |
   |