PDA

View Full Version : blitting problem



bitwise
07-06-2005, 10:27 AM
I've got what seems to me a hard problem:
Imagine I have a large quad (2 triangles) that has a background texture.
I also have another quad, with a "red ball" texture, which I can move with the arrow keys. the spacebar key is special:
How can I "blit" the red ball into the background texture so as to modify the background texture, so that when I press spacebar it blits the red ball where it is and as it is (it may have been rotated) and if I move the ball away after that I be able to see now 2 red balls (the real one and the one that was blitted into the background quad)?

07-06-2005, 10:55 AM
This would be easy with Pbuffers or FBOs (render to texture), but I'm not sure it's really necessary in your case.

You could render the combo to the frame buffer and grab it with glCopyTex*Image2D...

Hlz

bitwise
07-07-2005, 12:05 PM
let me explain my problem with a better example.
suppose it's a game where there is a guy to be shot by the player. when I shoot him, he bleeds off because of the fire burst, and some blood sticks on the walls around him. what I need to do is this: after I move the blood texture to the wall, I need to "blit" it to the wall texture itself, so that I don't need to create another texture everytime the player shoots the guy.

Now, could you explain your answer a little better for a beginner? :)

I need it to be fast enough so that the blood blits to the wall seamlessly, i.e. without affecting the game performance. I have the program working this far (there's already the guy and the player), it's really missing only that part where I blit one texture to another. I gathered that some of these methods you recommended are just render-to-texture methods? It's not exactly "rendering something to a texture" that I need, it's blitting, that would be "replacing some pixels on the destin (wall) texture for the pixels in the source (blood) texture. Of course, I don't know if that's the best alternative in openGL, and I don't even know how would I do that exactly, that's why I posted this question.

Thanks in advance.

07-07-2005, 06:25 PM
suppose it's a game where there is a guy to be shot by the player. when I shoot him, he bleeds off because of the fire burst, and some blood sticks on the walls around him.sounds delightful...

Well, what you typically have in games are what are known as "decals", little polygons that are projected onto the surrounding geometry and textured with an appropriate alpha masked/blended image. The trick here is generating the correct polygon, which is generally a quad, but could be anything depending on what it projects onto. This can be tricky if the surface is curved.

An alternative to this is baking the decal directly into the surrounding textures, through render to texture (RTT). This has the potential advantage of producing persistent, bumpmap correct disturbances (e.g. pitted bullet marks) on the surface, but can be costly to implement.

I rather think you'll be interested in the decal approach. This method is common and well understood. A search should produce good results.

Hlz

bitwise
07-08-2005, 07:17 PM
Hmmm, I know decals, they're not a good option for me, I'd have like 200 decals and this is too much to draw (we have yet all the visual effects and particles and glares &c).

I'll have to learn this RTT thing, it seems to be what I need (blitting a texture to another). Hope it's not too costly to implement.

bitwise
07-08-2005, 07:18 PM
Oh, and by the way, thanks for your helping me. :)

07-08-2005, 07:30 PM
You are welcome :)

Hey, ever played Quake3? Talk about hundreds of blood splats after a robust multi-gibbing... and all done with decals, bullet marks and rocket blasts to boot.

I think for the money decals are the most cost effective approach for this kind of stuff, even for hundreds of instances. Polygon count isn't a problem here with current hardware, it's the blending area that can smart if you're not careful...

Hlz

bitwise
07-09-2005, 02:34 PM
Oh! I thought you were mocking me when you said "sounds delightful... " :)

Yes, I've played it, it's a great game though I'm not so good at it.
Yes, it's really all decals, But if I remember well the decals begin to disappear when the threshold number of decals is reached.

With an example as such, all my arguments against using decals fall apart.
Nice arguing with you. :)

You're probably right, even more because in my case the game is not entirely 3D.
I did not get the "blending area" thing, though.

07-09-2005, 04:18 PM
I thought you were mocking me when you said "sounds delightful... "Not at all. There's nothing I enjoy more than a good fragfest ;)


But if I remember well the decals begin to disappear when the threshold number of decals is reached.That's a good point. One does need a practical limit on these things, else you're liable to end up sloshing around in a sea of chum at 2 fps. It's not perfect, but it's pretty darn good.


I did not get the "blending area" thing, though.I mean the per-pixel stuff is what hurts the frame rate, like alpha blending, or any fancy shader math. Modern hardware can T&L vertices like there's no tomorrow, but draw a handful of blended/shaded fullscreen quads and you'll bring the mightiest rig to its knees...

Anyways, I like the RTT idea, but I don't see a way to make it practical yet, not for a full blown shooter anyway. There's just too much stuff going on. I think it's doable though, maybe just for the stuff up close. Not likely to notice bullet pitts in the distance anyway, not while you're getting fried by a tesla tank :)

That might be a good solution, sort of a hybrid method. Decals for most of the stuff, and RTT for the stuff that's really close by, for that added detail to gawk at between reloads. And with FBO (frame buffer objects) now available (if supported by your card), RTT is a lot easier than it used to be :cool:

Hlz

bitwise
07-12-2005, 10:05 AM
Thank you again for your help, Hlz. :)