Surface count dilemma
Blitz3D Forums/Blitz3D Programming/Surface count dilemma
| ||
| Hi! I'm working on a game where 4 blocks and one border form an island. Now the graphics designers sent me their blocks and the game chokes on them. The blocks contain objects like trees and so on. But...I can hide objects that are not in my cameraview. This is the benefit of having seperate objects. On the other hand, combining objects seem to reduce surfacecount. IS the TOTAL surface count important, or surfacecount per MESH? Sswift told me about what surfaces are, but I don't know if the game chokes on mesh surfacecount, or total surface count. If it's per mesh, I can chop them. Trisrendered says (max) 60000 polygons which is quite high too. But this is the "combined" mesh. The mesh uses 110 surfaces now, but one plant layer used 54 surfaces all by itself! It's not such a complex looking layer! 54 x 4 blocks = 216 surfaces, excluding trees and so on. |
| ||
| 110 surfaces? Blame yourself then... or your artists! :) You can have 50.000 polygons on screen easily if your surface count is low, like 1-2. But 110... no way! Number of objects is not that important (if it even few hundred), but should be kept at minimum too. But if you group too many (big) objects as one object, you choke to death Blitz3Ds culling because it only works per object... so if your 50.000 polygons are just one object it has to draw every polygon on every surface even if it is behind the camera. So: -Use sensible sized polygon / object chunks -Minimize the amount of surfaces per object (combine textures to bigger texture chunks and UV-map stuff accordingly if needed) |
| ||
| I find that surface count can add a up to 15 FPS using about 150,000 polygons. I think mainly though if your game is choking you need to be careful with collision. In Aerial Antics we had one level with around 40,000 polygons but then we used invisible low polygon collision which was 9,000 polygons. We didn't really optimize the surface count as we needed many separate objects for culling purposes with the shadow system. It is my experience that while surface count can a good optimization to a point, that it is far more important to watch collisions and culling. We actually did some experients with reducing the surfaces, the game ran better overall with a higher surface count but more culling. |
| ||
| Yup, it's all about "balancing"... and there is no ready-made formula for that. And like BAN300 said, hi-poly meshes and collisions can be problematic [slow], preferred and better way is to use optimized invisible low-poly collision hull. |
| ||
| Hi Mustang, Thanks for your explanation. I see Blitz does do culling even when it's one object, but ofcourse it isn't that optimised as it would have been with seperate objects. However, combining the "main" mesh, does decrease the surface count, and I guess here the combining does work. However, count is still high. |
| ||
| Is 23 surfaces ok? Say 18 surfaces with 2000 polys per surface? |
| ||
| Ross: is there a guideline for that? It's hard to tell. Well, I decided this: Combine the ground to one mesh (blocks+border). Keep the entities on the ground mesh as seperate objects and use show/hide entity when not in cameraview. Now it's up to bringing bad news to the modellers... |
| ||
| Hehe, that's the problem sometimes. Modellers have to work a certain way :) Mind and don't hide meshes that are involved with collisions, if they are off screen :) |
| ||
 is this true? Right half of picture would be the "mesh", left part are the textures. |
| ||
| Yes, 5 surfaces are needed for the top part since it is made from 5 different textures, this is the bad way of doing it. Only 1 surface is needed for the lower part since it uses a single texture. this is the good way since it means both lower poly count and lower surface count. |
| ||
| Every separate piece of texture creates new surface, and every new object (and it's textures) does this too. Since objects need to be separate for culling and game purposes (like characters, props, level parts) they should be textured like that, meaning that character should have it's own texturemap and gun it's own. You could combine even those, but since they are separate objetcs there's no point really to do that. And so on... |
| ||
| The number of meshes does not matter, only the total number of surfaces in all meshes visible at once, and the total number of polygons visible in all meshes at once. Try disabling collisions just for kicks. I had some problems with collisions and terrains a long time ago but I forget if it was a slowdown or a glitch. As a guideline how many surfaces you can have total, I have a mid-range video card, and I can push around 400 surfaces befor my framerate drops from 60 to 30 in a particle system test. My card is roughly equivalent to a Geforce 2. But each card will be different in how it handles state changes, which is what a surface causes. A state change causes a "stall" on the card. They happen when the card is told to draw with a different texture or other surface property. "is this true? Right half of picture would be the "mesh", left part are the textures." Yes. In the top image you have many textures, and each one of those will require a different surface, but the bottom image combines several textures into one and so only requires one surface. Note also that the bottom version requires one fifth the number of polygons, and that is just for a SINGLE window. Imagine a while wall on a building filled with these windows, and the bottom version will not only have only one surface as opposed to 5, but there'll only be two polygons on that building as opposed to hundreds. Note I still said 5 surfaces on the building. Just because that one window needs five surfaces that doesn't mean you need 5 more surfaces for every window. You can just stick all the polygons that use those five textures in the five surfaces that you created to hold those polygons. Ie, if you have 500 trees each with a trunk texture and a texture of leaves, then you still only need two surfaces total. Unless of course you want to be able to remove some of those trees from the scene for polygon culling. In that case I reccomend combining large numbers of trees into "clumps" and hiding clumps of trees when nercessary instead of individual trees. That will save you a lot of surfaces and the few extra polygons rendered will have little effect on the speed. |
| ||
| Another factor to consider for speed btw, is OVERDRAW. How many times is a pixel covered by different polygons? And are those pixels transparent? Overdraw can be expensive, and transparent overdraw even more so because you definitely have to draw two layers of pixels if you cansee a solid object behind a transparent one, whereas with opaque stuff you have a good chance of not having to draw extra pixels. But there's still a lot of zbuffer checks. |
| ||
| I typically find if you have entities that are similar that using CopyMesh() significantly speeds the program up (with about 100 entities). Is this because it then uses the same surface? I find it's interesting that you can add so much speed by copying the initial mesh instead of using loadmesh() you still have the same number of entities and you can manipulate them the same (perhaps texture changes are the exception). There are a lot of ways to increase the speed of programs. It'd be useful to know the methods and the ideology behind Blitz and why certain things really speed a game up. I've learned quite a bit about this with the various games I've made but still learn something new every few weeks. |
| ||
| @ Sswift: Thank you very much, you summed up all answers to my questions. I find the last tip worth to be trying to (overdraw). Your answer should be put in a blitz "user FAQ"...it's very important to know this :) # Ban300: I use a similair system: answer = ifEntityIsInLibray(whichEntityFileName$) if answer = true m\mesh=loadMesh(whichEntityFilename$) else m\mesh = copyEntityFunction(whichEntityFileName$) Basicly I use a "library" and I copy the entity (pointer) to the meshEntity\entity type. |
| ||
| Sswift: should I use hideEntity when an entity is not on screen, and showEntity when an entity IS on screen, or leave it up to Blitz' "flustrum culling"? |
| ||
| I doubt that hiding an entity will in any way speed things up when it is off the screen. Also, hiding an entity disables collision checking on it, which would affect gameplay. Also, I wrote an octree entity hiding system a long time ago, and it was actually much faster to just use EntityAutoFade to hide thousands of trees than it was to try to hide them manually with hidentity. Of couse neither ran at a good framerate. It was just a test. This difference in speed though has likely been dramatically reduced because Mark changed the way Blitz handles hiding entities so that is near instantaneous. It was not when I did my earlier tests. In summary, don't bother with frustrum culling. Just hide stuff based on distance, and occlusion if possible. (Ie, trees behind a hill can be hidden and that will speed things up.) |
   |