I need to know if there is a performance difference between the examples below
Key: black triangle = polygone
green thing = leaf texture applied to polygon (with cutout shader, white is transparentcy)
example 1
example 2
So does size of polygon matter?
My wild speculation says it does, but i have no idea why or how much; My basis is that the GPU has to calculate more about what is visible and what is not (which = more GPU load)
bump
Good question. I think the same thing could be asked about billboarded terrain trees, right?
Also, there’s a difference between the actual size of the mesh, and also how much screen space it’s taking up as well, so possibly two different’ answers there.
Since everything is drawn back to front right, it’s not like it’s occluding anything either, which by making it bigger would actually improve performance (although since it’s mostly transparent that point is probably moot…).
If your object is taking up more space on the screen, ie bigger triangle, then yes it is going to be slower. Even if there are more empty pixels due to you making the green leaf part proportionately smaller than the triangle, the hardware still has to a) generate fragments for every single pixel in the interior (these are kind of like new-born pixels that are candidates for being processed), b) cut-out alpha tests have to be performed on every one of those pixels in order to decide whether to keep it or omit it, c) the pixels that are kept continue through the pipeline and turn into rendered pixels while the rest are then dropped and no longer affect performance. But as you can see, before you can get to where the transparent pixels are dropped there are still tests to perform, so the bigger your number of pixels are being covered, the more tests are needed, thus performance will go down. But by how much, is another matter, as to whether its enough to be important.
What if you scaled it by 2x, so it was twice as large, but then moved it back so that it was taking up the same screen space as 1x scale.
Thanks a ton imaginaryhuman! That was very helpful.
One last thing: should i use a single tris or a quad. The specific question is: “is a single tris better for performance than a quad when the tris takes twice the screen space of the quad (While Their texture takes the same screen-space)”
The quad will end up being two triangles anyways.
I think the answer is that you want the least amount of alpha space as possible!
yes, I get that; my second question was basically: does the overhead double the alpha space out-way the overhead of double the triangles triangles.
Edit: im not really expecting anyone to answer this so don’t trouble yourself unless you happen to already know;
Need to do a test to find out.
GPUs typically spend the same amount of time processing 1 triangle as they do 1000 triangles. Your whole reasoning here is utterly flawed. Don’t use single triangles: you will be slowing it down for no reason at all due to it processing all those pixels you can’t see that make up the surface of the mesh.
Yes - they’re all processed.
The worry is also how many meshes you want the GPU to draw. These are called draw calls, and they soak up CPU time.
This is why things like Unity sprites make a higher poly shell around the sprite to fit it closer, so less pixels are processed.
Thanks hippocoder, i have over a thousand instances of this mesh, and unity’s “batching” system doesn’t take care of everything. I recommend people use a plugin from the asset store for combining meshes in a scene.
i.e Unity Asset Store - The Best Assets for Game Making
Question is: why the hell doesn’t unity do this out of the box? would be a great addition :). I believe udk comes with an option for this.
What you want is instancing, and it’s pretty stupid that Unity doesn’t support fundamental technology used in all AAA titles since 2002.
I’m really interested why it doesn’t support instancing, since it would save a lot of bother and heartache all round. Possibly due to mac origins which no longer hold true.
@ I’m confused… isn’t that what Static Batching is??
@hippocoder What is the difference between instancing and Static Batching?
I used to think that as-swell, and although i don’t know the details of how static batching works, I know (for me) it did not reduce the draw-calls as much as combining the meshes into one object.
Last checked static batching in unity 4.2
Instancing is on GPU. Batching has to be done on the CPU then passed to the GPU, which incurs draw calls. Instancing doesn’t. Geometry instancing - Wikipedia
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter03.html
If you don’t know why instancing is so much better than batching (which doesn’t really exist - it’s just one merged mesh taking tonnes of ram and hogging your CPU) then probably you’re not really interested in having thousands of detailed meshes take up virtually no ram which are dynamic & super fast! TLDR - instancing is great, and still the best thing before DX12. I’m guessing a lot of people won’t be massively confident about 12 only support for at least 6 years or more…
Also have fun batching the 5000 spiders you want chasing your player. Or not, since you can’t 
aka why do AAA games with endless grass run faster than my Unity game with with 5 bits of rubbish grass?
OK @hippocoder , you just made me go crazy here… I WANT INSTANCING!! Lol
I made a farming game for Android/iOS, and you plant fields of corn lets say. So I have a field with 3000 quads (with corn texture).
With static batching, it has combined all those quads into one big mesh and therefore takes up more memory and CPU time.
With instancing, it could upload a single quad, with the location of all 3000 of them, and the GPU will “batch” them all together and render?
So this can’t be done in Unity even on desktop? Is this even possible with OpenGL on mobiles regardless of engine?
ME WANTS IT TOO! Looks like people have wanted this in unity for a long time.
Until it gets implemented Im going to combine all my objects into one using a plugin from asset-store… PC ram isn’t too big an issue these days.
I really really think that using a script to combine multiple meshes into one mesh, is almost the same thing that Unity does when static batching, although maybe slightly different/inefficient?
I would do some serious profiling (you might have to test it out on 10,000 meshes or something to get big enough numbers in a test scene) using a combine mesh script and then static batching.
Here is from the docs on static batching:
Notice another thing in that description, if I’m understanding it correctly… it’s still only drawing visible objects within the batch. If you made your own combined mesh, it will draw the entire mesh, not just what’s visible.
Someone please correct me if I’m wrong about all this.
Didn’t think about the lighting issue… I would create a test scene and try out a few different methods and see which one is most performant, taking into account having lights and shadows and everything as well I guess.