Sign in to follow this  

Special effects textures, cache or not?

This topic is 4518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering, do you think it is a good idea to cache the proceduraly generated textures that will be used for special effects (basically just alpha blended with the scene) or just generate them frame by frame? I don't think that by doing tests I can find out the optimal way, because there are many different configurations out there, some with more powerful CPUs than video cards, and some with more powerful video cards than CPUs. I tend to lean on the non caching side, just generate them frame by frame, display them, then remove the frame. The thing is, this is for an MMORPG, so I do not expect a lot of them at once (on the screen). Of course, another way is to just generate them via photoshop (I guess they would look much better than done runetime, in a procedural way) and load them as needed. However, this will increase the size of the game quite a lot, and the download will be bigger.

Share this post


Link to post
Share on other sites
Regarding that they may look better... what about animating them? :) that way you would need TONS of premade textures... I'd go for a procedural approach, either by using a lower res texture, or simply pseudoprocedural (i.e blend between premade textures...)

But then again, using procedural textures you can reuse its values in heat distortion, refraction etc.. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
I was wondering, do you think it is a good idea to cache the proceduraly generated textures that will be used for special effects (basically just alpha blended with the scene) or just generate them frame by frame?

just use a standard particle system approach, dont cache the results its not necessary. also if u decide to add some sort of particle interaction eg fireglobs bouncing off walls its impossible anyway.
as your camera is quite a bit higher (thus particles systems wont take up the whole screen) than the action fillrate is not gonna be a slowdown cause

Share this post


Link to post
Share on other sites
Depends on what you mean by "procedurally generated". Caching can be viable, if the generation is very time consuming, and has to be performed in steps over many frames. Caching can also be useful, if the generated texture shows some kind of temporal coherency (eg. reflection or refraction textures).

What exactly are you generating, and with what kind of algorithm ? On the CPU or on the GPU ?

Share this post


Link to post
Share on other sites
They will be CPU gnerated, because we want to support lower end video cards as well.
I didn't decide all the special effects I want to do this way, but I have in mind for example a spiral (that will grow every frame and change it's shape a little), a few concentric circles that will also grow bigger (some sort of ripple), and various other stuff like that. Some textures will have to be generated by an artist. Did you play/see Warcraft 3?

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
They will be CPU gnerated, because we want to support lower end video cards as well.

Pretty much every visual effect generated on the CPU automatically qualifies as a caching candidate. On the CPU, the caching of such animations will almost always be a performance gain - at the expense of memory, of course.

Quote:

I didn't decide all the special effects I want to do this way, but I have in mind for example a spiral (that will grow every frame and change it's shape a little), a few concentric circles that will also grow bigger (some sort of ripple), and various other stuff like that. Some textures will have to be generated by an artist.

Well, it ultimately depends on how many frames we're talking about, the size of the cached area(s), how many areas will be cached within a given time frame, how much hits vs. missed you expect, etc.

Quote:
Original post by Raduprv
Did you play/see Warcraft 3?

Nope, sorry.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
I didn't decide all the special effects I want to do this way, but I have in mind for example a spiral (that will grow every frame and change it's shape a little), a few concentric circles that will also grow bigger (some sort of ripple), and various other stuff like that.

You can do some fantastic stuff with just static textures and animated texture coordinates, and those effects you mention would be easily done like that. Often you can even use a static set of (carefully crafted) texture coordinates and just mess with the texture matrix which requires absolutely minimal amounts of work (both CPU and GPU).

Additional variation can be added by adding noise to the animation - either with slightly perturbed texture coordinates or another texture layer on top scrolling in a different way. Noise or cellular textures tend to work well for this. This gives the impression of continually generated animations frame but most of the work is done during the loading phase.

(The galaxy in my journal shows a not too complicated example of this, but it doesn't look nearly as good when still).

Share this post


Link to post
Share on other sites
Well, basically pretty much all the cached textures will be reused at some point or another, especially in combat maps.
The textures will probably be 256x256x4 (32 bps) So that manes, 4 frames is 1 mb.
Now, if a texture has, say, 24 frames, that means 6 mb only for a special effect.
So 10 special effects, all with their textures cached, is 60 MB. That's kind of a lot of memory, given the fact that there are many other things in the memory, not only those textures.
BTW, do you think it would be good to cache them on the CPU side (leave them in the memory, and assign a texture to them when they are needed) or cache them on the OpenGL side (just assign them a texture, and let them as they are, so openGL will do the extra caching)?

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
Quote:
Original post by Raduprv
I didn't decide all the special effects I want to do this way, but I have in mind for example a spiral (that will grow every frame and change it's shape a little), a few concentric circles that will also grow bigger (some sort of ripple), and various other stuff like that.

You can do some fantastic stuff with just static textures and animated texture coordinates, and those effects you mention would be easily done like that. Often you can even use a static set of (carefully crafted) texture coordinates and just mess with the texture matrix which requires absolutely minimal amounts of work (both CPU and GPU).


So what you mean is, make a texture with a big circle, and then just shrink it by either shrinking the square, or just playing with the UV, in order to appear that the circle is growing/shrinking? Hmm, sounds like an interesting idea, but it works only with some special effects.

Share this post


Link to post
Share on other sites
Quote:

Well, basically pretty much all the cached textures will be reused at some point or another, especially in combat maps.
The textures will probably be 256x256x4 (32 bps) So that manes, 4 frames is 1 mb.
Now, if a texture has, say, 24 frames, that means 6 mb only for a special effect.
So 10 special effects, all with their textures cached, is 60 MB.

Whoa, wait a second, I thought we were talking about small tiles here ! At those sizes, forget about caching your animations. The additional memory bandwidth, not even talking about possible texture thrashing due to unsufficient VRAM, will easily negate any beneficial effect of caching. You'd probably even lose speed.

Do everything on the fly instead, if possible using OpenGL. When working on the CPU on images of sizes like that, the bottleneck will often be the transfer to the graphics card.

The best approach would be to add a high performance code path for people with advanced 3D cards, where your special effects are done entirely on the GPU. For everybody else, do whatever you can on the GPU (and that's already a lot, even on OpenGL 1.1, if you are creative - use blending tricks, UV warping, etc), and offload to the CPU only if absolutely necessary.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
So what you mean is, make a texture with a big circle, and then just shrink it by either shrinking the square, or just playing with the UV, in order to appear that the circle is growing/shrinking? Hmm, sounds like an interesting idea, but it works only with some special effects.

Thats the basic idea. Obviously it's limited when compared to generating each frame on the CPU, but it's much more flexible than first seems, and the examples you gave are a pretty close match for what's possible.

If you think of using geometry to define the shape of an effect (like an expanding circle or arc) then your UVs become 'time' across it. Scroll along u or v with the texture matrix and you're all set. A nice approach is to have the texture full alpha and use vertex colours to fade in/out the texture as it moves. Add a bit of semi-random vertex colours as well for more variety.

Plenty of life left in unextended OpenGL for this kind of stuff. [grin]

Share this post


Link to post
Share on other sites
Yeah, I thought so too :)
I need them big because I plan them to be scene wide, not just a small circle on top of a player. So anything smaller than 256x256 might look bad.

Share this post


Link to post
Share on other sites
The problem I see with this techique is that there are only 4 vertices in my quad, so if I want a nice noise in the texture I would have to add more squares, or else it might look too jerky.

Share this post


Link to post
Share on other sites
Depends on the effect. For circular expand-y things I find a triangle fan (with the root at the center of the circle) works nicely. Your u coord becomes the radial distance, while v gets set based on the angle. This tends to make the texels spread out more as they move away from the center, which is quite a pleasing effect (and this combined scaling/rotation/translation makes the whole thing look very non-repetative).

Share this post


Link to post
Share on other sites

This topic is 4518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this