Is this Single Surface?
Blitz3D Forums/Blitz3D Programming/Is this Single Surface?
| ||
| I am so sorry to bring this subject up again, but I am trying to Optimise my game "LunaC" as much as possible. I have read about having as fewer surfaces as possible is the key to speed gain. 1) If my model has 8 textures, will there be a surface for each texture. If I map all my textures onto 1 image and redo the UVMap, will my model have 1 surface. 2) Every time i create a sprite, is this a new surface 3) Please can someone once and for all; explain surfaces to me :-( |
| ||
| 1a) 8 textures = 8+ surfaces 1b) It should do. Whether its worth reducing 8 surfaces down to one in this way is another matter. 2) Yes. Definitely worth a reduction here (for particles etc). 3) A Surface is just collection of verts and tris that share the same common characteristics: texture, shininess, color, etc. It might help to imagine them as seperate 'entities', and that the Blitz Entity system is merely a convenient way of grouping them together. |
| ||
| 1) If my model has 8 textures, will there be a surface for each texture Yes. Every time i create a sprite, is this a new surface Sort of. The surface mechanism in Blitz automatically discards redundant renderstate changes, so the overhead *may* be small - or it may not. If the engine ends up displaying the same sprite 1000 time at different locations, and they all share the same texture/color/shininess etc there will be little slowdown. Please can someone once and for all; explain surfaces to me A surface binds a vertex/triangle mesh (not a Blitz mesh - I regret that now - badly named!) to a brush. Internally, there is a surface 'class' that looks a bit like: class Surface{ Mesh *mesh; Brush *brush; }; Which is not quite optimal. These 2 should be separated, but to do so needs something like an immediate mode. I'm working on it. |
| ||
| Hello Mark, good to hear from you. Thanks for explaining all that, MasterBeaker as well. I always remember an explanation of why rocketboards was so fast was because there were only 8 surfaces per level. Sort of. The surface mechanism in Blitz automatically discards redundant renderstate changes, so the overhead *may* be small - or it may not. If the engine ends up displaying the same sprite 1000 time at different locations, and they all share the same texture/color/shininess etc there will be little slowdown. So do I create a mesh, set all its properties and use copymesh to reference it, or what? Thanks for all your help |
| ||
| Sort of. The surface mechanism in Blitz automatically discards redundant renderstate changes, so the overhead *may* be small - or it may not. If the engine ends up displaying the same sprite 1000 time at different locations, and they all share the same texture/color/shininess etc there will be little slowdown. Oh good. I assume this applies to all meshes no matter what order they were created in (i.e. it groups meshes by brush to render them).So this means I won't see that much speed up from combining my identical particle quads into one big mesh entity? |
| ||
| I suppose then that the speed difference between blitz sprites and s custom single surface partical system is the fact that the single surface system is not made up of so many entities seperate entities that blitz will have to cylce thruogh internally. |
| ||
| So this means I won't see that much speed up from combining my identical particle quads into one big mesh entity? Far be it from me to argue with the guy who created the language, but I think I'm going to argue with the guy who created the language. I wrote 2 demos a long time ago and posted them here for people to test. One created 500 identical sprites ( sharing the same, texture, colour, shininess, etc ) and one that created 500 identical quads, all attached to the same surface. If I recall, the speed increase ranged between 200% and 400% on average. With larger numbers of sprites, it was much more even. So, assuming what Mark says is true, the code which discards redundant renderstate changes is.. fallible. |
| ||
| These 2 should be separated, but to do so needs something like an immediate mode. I'm working on it. Awesome! Tracer |
| ||
| I wrote 2 demos a long time ago and posted them here for people to test. One created 500 identical sprites ( sharing the same, texture, colour, shininess, etc ) and one that created 500 identical quads, all attached to the same surface. If I recall, the speed increase ranged between 200% and 400% on average. I have not noticed any increase in speed using single surface compared to sprites, especially when you add all the vertex updating code to keep the single suface system pointing at the camera, but then you do say you did the demo a long time ago - Blitz may have changed internally since then. |
| ||
| I thought it was well established that single surface homemade particle systems were faster than doing it with Blitz Sprites. Who hasn't made one? |
| ||
| In my experience the sprites are just as fast as using a single surface system. BUT, when you go over abouut 100 particles using sprites, the system suffers big slowdown. I can go up to about 1800 single surface particles until i get that same sort of slowdown. So the way i see it is use single surface stuff if you intend to have alot of particles onscreen. Other wise i think they are just the same :) |
| ||
| Does multitexturing use one surface or one for each texture applied? |
| ||
| I never use Blitz sprites. I use my own quad meshes. I just want to know if creating all the quads in a single mesh is faster than creating a single quad mesh and CopyEntity()ing it a few hundred times. |
| ||
| RottBott: I never use Blitz sprites. I use my own quad meshes. I just want to know if creating all the quads in a single mesh is faster than creating a single quad mesh and CopyEntity()ing it a few hundred times. It's faster rottbott, the difference get's larger as you use a higher quantity of quads/other models, at 100 surfaces in quads you may not notice much of a difference, but try looking at a good 1500 quads in the distance (DISTANCE because fill rate will choke otherwise) and you will quickly notice that the single surface particles in the distance are far faster then the 1500 individual surfaces! MasterBeaker: I thought it was well established that single surface homemade particle systems were faster than doing it with Blitz Sprites. Who hasn't made one? Been using single surfaces for certain particles and many other things way before vertex alpha was even implemented. For high density graphics surface reduction is the way to achieve professional speed results. |
| ||
| RetroBooster - I know cos you've been using FONText for a long time. :P |
| ||
| I have not noticed any increase in speed using single surface compared to sprites, especially when you add all the vertex updating code to keep the single suface system pointing at the camera, but then you do say you did the demo a long time ago - Blitz may have changed internally since then. Imagine how much faster it would be if Blitz did this internally and you didn't HAVE to do all the vertex manipulation by hand. I've just run the demo again and the speed difference on my machine is 400%. I use Sin and Cos tables to get a slight speed increase and I actually found that recreating the surface and adding all the quads to it each frame was faster than manipulating them where they are. Though the latter is still around 300% faster. Bear in mind that this is only if you're updating every particle every frame. If you use a clever little rotation system where only 1/5 of the sprites is being moved each frame, sprites won't get any faster but single surface quads will. So you could easily end up with a speed increase of around 2000% over sprites. And that's with 500 particles. Not an inordinate amount. The more sprites, the bigger the increase. |
| ||
| Single surface is far faster. Not all single surface routines are born equal however. You don't need to use clearsurface each frame either if you rely on dx to clip tri's well out of range. |
| ||
| Rob.. OK. So when you delete a particle you mark it for deletion and move it away to some way-out location where it cannot been seen, or set the vertices alpha to 0. Then every now and then (50 frames?) you ClearSurface and get rid of the quads marked for deletion. That right? |
| ||
| MasterBeaker: RetroBooster - I know cos you've been using FONText for a long time. :P Yeah masterbeaker, great tool, though I was reffering to even long before that. RottBott: Depends on what your system is setup for... I have some setups that never need to use clearsurface, some which use it periodicaly and some of those add new particles (not just quads but whole objects if needed) in a distributed manner (over multiple game loops, sometimes even seconds). |
| ||
| Rob - I tested this good and proper before deciding how to implement my 2d-in-3d system, and if every particle is going to be moving, then it takes pretty much exactly the same time to clear the surface and rebuild all the quads as it does to move all the existing vertexes. Plus when you rebuild, you can re-sort the drawing order at the same time. |
| ||
| I knew I missed something. Can "reycle" particles. Saves using ClearSurface at all. How do you handle Z-order for alpha'd particles? |
   |