PDA

View Full Version : Video RAM and a blending question



09-02-2004, 03:21 AM
Is video memory "general purpose?"

For instance, assume my video card has 256MB of RAM onboard. I'll guess that while my application is running, some of that is used up by a few things. But can I use what's available to my program to hold anything that can be stored in server local memory? Like textures, buffer objects, vertex/fragment programs?

Additionally, without using a fragment program, would it be possible to bind four different animation images to each of four texture units, and then render in one pass and over time the visible image changes to produce an animated result?

09-02-2004, 10:40 AM
Is video memory "general purpose?"with vbo/pbo this is increasingly the case.


But can I use what's available to my program to hold anything that can be stored in server local memory? Like textures, buffer objects, vertex/fragment programs?[quote]

what do you mean?

[quote]Additionally, without using a fragment program, would it be possible to bind four different animation images to each of four texture units, and then render in one pass and over time the visible image changes to produce an animated result?yes, but you dont need to do it this way. use 2 units and lerp using combiners.

09-02-2004, 10:41 AM
Is video memory "general purpose?"with vbo/pbo this is increasingly the case.


But can I use what's available to my program to hold anything that can be stored in server local memory? Like textures, buffer objects, vertex/fragment programs?what do you mean?


Additionally, without using a fragment program, would it be possible to bind four different animation images to each of four texture units, and then render in one pass and over time the visible image changes to produce an animated result?yes, but you dont need to do it this way. use 2 units and lerp using combiners.

09-02-2004, 11:45 AM
But can I use what's available to my program to hold anything that can be stored in server local memory? Like textures, buffer objects, vertex/fragment programs?what do you mean?I have a 256MB card. Does this mean I can expect my program to have a fair amount of video memory (~200MB) for uploading vertex buffers, textures and the like to the card for faster performance?



Additionally, without using a fragment program, would it be possible to bind four different animation images to each of four texture units, and then render in one pass and over time the visible image changes to produce an animated result?yes, but you dont need to do it this way. use 2 units and lerp using combinersRight, but I want to lerp across four cells of animation so that a four cell animation will play over time, each blending into the next as time goes on. I suppose it could be done using two, and then switching the textures up as the second frame comes completely into view, but that would require a shader switch at precisely (T/2) where T is the total length of the animation... Hmm..

09-02-2004, 12:02 PM
I have a 256MB card. Does this mean I can expect my program to have a fair amount of video memory (~200MB) for uploading vertex buffers, textures and the like to the card for faster performance?of course. if the driver's worth its salt, it will cache as much as it can in video memory, so i wouldnt loose any sleep over that. though, i dont know what percentage of video memory is dedicated to what. i think only high-end workstation cards specify this quantity.


I suppose it could be done using two, and then switching the textures up as the second frame comes completely into view, but that would require a shader switch at precisely (T/2) where T is the total length of the animationactually, you would switch at t = 1. at t = 0, you have a0*(1-t) + a1*t = a0. at t = 1, you have a0*(1-t) + a1*t = a1. so you start your anim with a0 in unit 0, and a1 in unit 1. when t = 1, set t = 0, set a1 int unit 0, and a2 in unit 1. continue this ad nausium.

you could also do this with simple multi-pass rendering with alpha blending.

09-02-2004, 12:20 PM
I suppose it could be done using two, and then switching the textures up as the second frame comes completely into view, but that would require a shader switch at precisely (T/2) where T is the total length of the animationactually, you would switch at t = 1. at t = 0, you have a0*(1-t) + a1*t = a0. at t = 1, you have a0*(1-t) + a1*t = a1. so you start your anim with a0 in unit 0, and a1 in unit 1. when t = 1, set t = 0, set a1 int unit 0, and a2 in unit 1. continue this ad nausium.

you could also do this with simple multi-pass rendering with alpha blending.Yes, multipass rendering would make it easy but that's not the system I'm using.

I've come up with another way; blending between frames looks neato but in retrospect the effect I want to achieve will probably not have the speed I want with blending, so I will just do a standard "flip" animation.

09-02-2004, 12:46 PM
whats a "standard flip animation" ?

09-02-2004, 01:32 PM
Where one frame changes to the next and then the next...

09-02-2004, 02:07 PM
with no blending? sounds kinda lack-luster ... going for the clay-mation look? 4 animation frames will look pretty rough, unless they differ only slightly, or you play it at very high speed.

anyway, single pass blending isnt expensive, unless youre rendering lots of fullscreen quads. many game engines use this technique to animate explosions, torch flames, ... and all sorts of cool effects. in fact, i know for sure quake3 uses the multi-pass approach (have a look at the *.shader files). although, they may combine passes internally, dunno.

09-02-2004, 03:03 PM
The four frames was a limitation of only using the four texture units once. If I slice up each texture into a series of frames then I can have a decent number of frames. Even a 512x512 texture sliced into a 4x4 grid gives me 64 128x128 cells, which is more than enough for what I need. At render time, it's simply a matter of doing a couple quick integer divisions to find which texture, row and column holds the right image. And then it's just a matter of supplying the proper texcoords.

These animations will be used for things like explosions, smoke, and muzzle flare blooms. So the possibly low resolution and "claymation effect" will have minimal effect.

As for not wanting to do multipass, multipass is all well and good, but I don't think I'll need it for this project--nor do I want to need it.

09-02-2004, 03:09 PM
like i said, one pass in a combiner is all you need.

09-02-2004, 03:13 PM
And like I said the animation, probably 16 frames in length or so will play to completion and be gone in a second or less, so the eye will somewhat take care of blending the frames together for me.

09-02-2004, 03:18 PM
somewhat, yes, but not totally. you need 24 frames a second for smooth animation (film), preferably 30+ (games). but if youre content with that, then ill leave it be. :(

09-02-2004, 03:40 PM
I knew it! I KNEW you would bring up the 24 frames per second!

That's why I specified "a second or less" because I knew you're picking out every little thing I say! :mad:

09-05-2004, 11:29 AM
3D texture! Why didn't I think of it before?!

Load the animation into a 3D texture and set the blending to linear mode and the texture filtering will do it for me in one pass, one stage.