No announcement yet.

Cost of Alphas

  • Filter
  • Time
  • Show
Clear All
new posts

    Cost of Alphas

    As I am designing my game it becomes apparent to me that I may have many actors in my scenes that utilize alpha transparencies. Many of them I could transform into the binary transparencies (I forget the term, but I am differentiating between having a transparency with gentle fading and a transparency that turns certain pixels exactly invisible and exactly opaque) but I hesitate to do so because it takes a bit of work to change the textures and they don't look as nice.

    Now I recall from days of yore where we were cautioned to use the binary transparencies over the fading transparencies where possible, because the fading transparencies were more expensive on the system.
    But that was in ye olden days. How true is it today?

    1) What is the real cost of transparency effects on a modern system? Am I adding to the computational load, or is that handled such that I only add the memory costs needed to save the transparency data?
    1a) Are these costs taken out per-pixel, or per-texture, or per-texel? (That is to say, I might be better with transparencies that are far away instead of close, or with one large texture instead four smaller textures, or the increases purely by how many texels of transparency exist in the textures, etc.)

    2) What real advantage do I gain by using a binary transparency as opposed to a fading transparency? (And what are the real terms?)

    3) If I had a scene that was just totally loaded with a bajillion transparency effects, what would I want to cut down on (outside of transparencies) to keep my scene running smoothly?

    Ive tried to answer as best as I can, it would be easier to show what kind of images you are working on to get a bit better idea of why you seem to be needing so many transparencies.

    when it comes down to it, use whatever you need to make it run and have it look good.if its a portfolio piece optimization takes a back seat, if its for an ipad, youll have to make sacrifices on textures and polys.

    1) it really depends on the system that you are aiming for, even 'modern' systems have a great deal of variety in hardwere specs. my recommendation would be to have a secondary computer that is on the low end of your specs and keep testing it on there to see how it performs. 32 bit alphas are 4(?) times the amount of instructions as a single 16 bit alpha.
    1a) if im understanding your question, you should read about mip mapping and take a look at how speedtree saves out the billboards for long range LOD's. I think that would give you a good understanding..

    2) speed. speed and looks, if it blends, use a higher bit alpha, if its a silhouette, use a lower bit alpha. Take a look at how many instructions the material uses depending on 8/16/32 bit alphas being used.

    3) well, are the bajillion textures instanced or no? are there a bajillion DIFFERENT transparencies, or do you have 3 that are being re-used a bajillion different times? if you look at udk's foliage they use alphas pretty much exclusively, and theres a video online someplace with like 300k ferns in it, so you can get away with a lot, if you are smart in your usage. pics of everything would help a lot.


      In UDK you can use an alpha in two ways, Opacity Mask (which is like a binary alpha) or just regular Opacity, so you don't have to do any changes to your texture to be able to use it either way. I would think there would be advantages in memory and processing speed between the two options.


        Oh, some folks DID reply! I'm sorry; for some reason my control panel had this thread greyed out like no one ever posted anything new. Thank you for your replies!

        If I was unclear about 1a), then let me rephrase it a little bit.
        If the costs were taken out per-material, then the cost would rise according to the number of unique materials I have in the scene. If I had two instances of the same texture, viewed from any angle, it would have the same impact. But if I had two different materials with transparencies, then the costs go up. (I would assume that such added cost is only for the cost of memory, but I've been wrong before.)
        If the cost was taken out per-pixel, then the cost would rise with the more pixels on the screen that have a transparency on it. If I had one transparency it would cost less if it were far away from the camera than if it were close up, because the engine doesn't have to account for as much render data to turn invisible. (My understanding of how the engine works makes me believe this is not the case.)
        If the cost were per-texel then the more texels in the scene the greater cost. (I'm not normally **** about not calling texels pixels, but for this subject we would need to differentiate between the two. Texels are the "pixels" of a texture, and a pixel are a single dot of the screen.) Thus if I had a texture of a specific size and 25% of it was transparent it would cost less than one with 50% being transparent.
        These were just the first three possible costs that came to my head; I don't presume that the answer can only lie between them. But in each case there are very simple things a person can do to build a scene that costs a bunch, when they could have done something different that would turn the whole thing around.

        As far as what I am trying to build...
        I don't have any screenshots to demonstrate it yet, but basically I am building a 2D sidescroller, but the plane upon which where the player exists will mostly be flat 2D art, billboarded to look like an old sprite-based game. (The platformers that are built in 3D just never feel right.)
        So a good portion of the world will use transparencies; any part of the playable-world that is not an exact square will need to contain a transparency. Mostly these will be smaller textures, but there will be a lot of them. I doubt I'm going to reach any numbers that will truly inhibit gameplay on most machines, but it might save me a lot of performance costs to combine world geometry into larger chunks with single textures that don't repeat very often. Or maybe that would kill performance and I am better off staying with smaller textures that I can instance more often. Or maybe it doesn't make a difference and I should stick to the method that saves me the most time in building assets.

        But even if the costs are negligible, I still would like to know how transparencies are handled and where they add costs, just for good reference for any project.