Framerate drops
Blitz3D Forums/Blitz3D Programming/Framerate drops
| ||
| Hi, I have a large terrain and two player objects. It runs smoothly at around 50fps. But then I added some trees (+-250, each has about 50 polygons), there's usally 5-6 onscreen at the same time, and the framerate drops to +-28. I use camerarange. The models use transparant png's. Anything I can do to make it run faster? (commenting out all my code so it just has to render doesn't make it faster so it's not my code that's running slow). Thanks. |
| ||
here's a screenshot :  |
| ||
| It will be your transparency textures on your trees...do a test and replace the trees with objects with the same poly count but no transparency textures and you'll probably see no frame rate drop. |
| ||
| Actually the problem is most probably the number of individual objetcs. Blitz doesn't handle this very well. The more individual objects, the more individual surfaces, anf blitz doesn't like that. To handle well numerous objetcs, you might want to try to merge your objects: take several trees, and for each surface with the same properties (same texture, same color, etc) you can merge both surfaces into a single one. Do a search in the forum, you should find some intersesting threads on the subject. Sweet graphics by theway. |
| ||
| "It will be your transparency textures on your trees...do a test and replace the trees with objects with the same poly count but no transparency textures and you'll probably see no frame rate drop. " OK, I'll try removing the texturefilter option that makes them transparant and see if it's an improvement. "Actually the problem is most probably the number of individual objetcs. Blitz doesn't handle this very well. The more individual objects, the more individual surfaces, anf blitz doesn't like that. " Do you mean the number of total objects, or the number of objects on screen at one time? "To handle well numerous objetcs, you might want to try to merge your objects: take several trees, and for each surface with the same properties (same texture, same color, etc) you can merge both surfaces into a single one." I don't really understand what you mean. I tried searching for "merge surfaces" but didn't find anything. Could you explain, or point me in the right direction? "Sweet graphics by theway. " That's motivating. Thanks! |
| ||
| Do you mean the number of total objects, or the number of objects on screen at one time? The second one, as objects entirely out of the viewport are not rendered.These systems are often called "single surface system" When you search on the forum, don't use the built-in search facility, it is too limited. Instead use google and restrict the search to this site, like: site:blitzbasic.com surface merge "single-surface" By doing that I have found some threads from which you could get some useful information. In particular there is a code archive here: http://www.blitzbasic.com/codearcs/codearcs.php?code=389 An additional note: don't merge all the objects into a single one big object, because as soon as an object is even partly visible on screen, it is rendered. If your forest is only one big object then it will always be entirely rendered, and even if it is rendered faster thanks to the smaller number of surfaces, you will on the other hand have more polygons rendered. So the idea is to try to take a middle solution: create chunks of several trees. You"ll have to make some tests to find the best balance (that is, how many trees to group into a single object). |
| ||
| 250 objects will not cause this much slowdown ive had literally thousands of things on screen at max frame rate.  That would run at 60fps (but it was vsynced, so i have no idea how fast it could run) without ever slowing down.. also remember that theres around 2-3 times that many ships but theyre all off screen. im not doing anything special either. |
| ||
| It obviously depends heavily on your hardware, as well as the number of surfaces per object. Though it's quite possible indeed that the slowdown has nothing to do with the number of objects. |
| ||
| I agree with the surfaces per object. The above code has run fine on the last 4 machines (i use newer versions of it it as a benchmark, y'see) theyve all been 2ghz+ but of mixed hardware. I did however come across a problem where alpha/masked textures caused program death though.. dont know :) |
| ||
| Koriolis, I've read the code in that link and I understand how it works (adding the meshes from child-entities to the same mesh). But I'm still not entirely sure how this would make it faster. Basically, I don't know what you mean with surfaces (the code in that link sais "Merge your high entity count into one entity matching surfaces " - but I don't get how the matching is done, I only see "addmesh")- is this the same as a "face" or a polygon? And placing them in the same mesh would be faster than when they're in a different mesh? Am I right? Thanks. |
| ||
| What is called "surface" in blitz is just a bunch of polygons that are rendered the same way. So basically I'd say your trees have 2 surfaces: one for the trunk, and one for the leaves. The thing is surfaces are per object: even though all your trees are the same, they all have these 2 separate surfaces. When blitz renders such a bunch of polygons, it performs a rendering state switch (simply put, it sets the rendering pipeline in the state that is appropriate : setting the current texture(s) and so on). These state switches are costly, so trying to mimimize them is a good idea. And to minimize them the simplest is to minimize the number of surfaces. In all honestly a good 3d engine should be able to minimize the number of state changes automatically (by rendering in one shot all the polygons that share the same rendering properties), but blitz doesn't do that and you have to take that into account. but I don't get how the matching is done, I only see "addmesh" It's precisely this function that does the job. It will merge 2 objects by merging - when possible - the surfaces that make up the objects. |
| ||
| So basically, adding a bunch of trees (the amount I'll have to experiment on) to one mesh with AddMesh will make sure there will be a lot less surface switches which would make it run faster? edit : oh, I didn't see the last paragraph in your last post, thanks. And yeah my hardware probably has a lot to do with it. I have a fairly good pc (don't remember the specs :s) but there's something wrong with it (most 3D games don't run very well, and scrolling in windows makes my sound skip, and most blitz programs that use an interface run very badly (the mouse doens't follow very well and I have to click a few times). Still I want it to run smoothly here, because that way it'll run good everywhere. |
| ||
| Okay, I spent till 4am last night trying to get this implemented in my tree-population code (which, based on soms images, creates the forrest). It works, I believe it's a bit faster now (not sure though), but I found out that now sometimes I can see trees entirely trough other trees that are in front of it. It's like the drawing order within my bigger meshes isn't correct. Is there anything I can do about this? |
| ||
| That'll be to do with the transparency. When a single surface has trasparency, it loses the z-order, and there are drawn in the order they were created in. I don't think the amount of object should make that much of a difference, because blitz automatically doesn't draw any entities which aren't in view. It maybe very well be the collisions. You should maybe split up the forest part into sectors. When the player moves into a sector, hide the trees in all the other sectors, and show the ones in the sector the character is in. Hiding an entity disables collisions for it, until it is shown again. Also, have you tried disabling the v-snyc option? It sometimes leaves some tearing when rendering, but makes sure the game renders as quick as it can. |
| ||
| I just reversed the order in which my trees are created (the camera is never rotated in my game so I could do this) but the problem remains. How do I turn off vsync? |
| ||
| Flip false http://www.blitzbasic.com/b3ddocs/command.php?name=Flip&ref=goto |
| ||
| Thanks. But it doesn' work :( Any ideas are welcome. |
| ||
| I decided this is just not worth it. I tried a lot of things, and I could still see some trees trough other ones, even when I disabled the transparancy of my trees. So I turned off this mesh merging, and the framerate difference isn't that big and at least it all works the way it should. To compensate for the framerate drop, I made all my movements so they're relative to the time between frames - I just let my main loop run as fast as possible, and the slower the game runs, the more units I move everything. That way it'll run always run equally fast, just not as smoothly. Thanks to everybody who tried helping me out. |
| ||
| There are probably non-Blitz-specific speed optimization tips out there on a site like "GameDev" or "CCN." |
   |