Texturing Performance
Blitz3D Forums/Blitz3D Programming/Texturing Performance
| ||
| Hello Friends, i have a question that i haven't found the answer (looking in the forums, google,etc...) I am texturing a big map b3d file. But sometimes the performance of the game drops suddenly (from 120 fps to 30-40). I think it is a texture problem, cause it happens when i stop looking at some places. (the number of polys is not the problem). So my questions are: - Are there any problem of using 30 or 40 different 256x256 maps not been tiled? - Are there any problem in the map format (jpg, bmp)? - Please can you give some advises on texturing big maps? (Use that sizes... do not repeat too much the textures..., put them all in one archive, etc etc).? Perhaps one link to game texturing tutorial or something. Really Thanks. KuRiX. |
| ||
| Well, as far as i know, each texture equals a surface. And it's usually the number of surfaces you have in blitz that kills the framerate. As to your point with the type of image used for the texture. All textures get converted to an uncompressed bitmap in Video Memory, so it doesn't make a difference :o) |
| ||
| Kurix, to get the best performance out of blitz3D with textures I mostly ignore occlusions and try combining all static meshes in the level that share the exact same brush, even if it means chopping up objects with multiple textures on. like brick wall, floor tile etc. If you do this as much as possible you should get a pretty hefty speed increase. Of course you probably want to do this towards the end when you are about done with the game. YOu can also determine seperate your use of textures into seperate areas of your levels which optimizes how many brushes are viewed at any one time as the slow down occurs the more seperate surfaces that have to be drawn in a frame. Also depends on your CPU, a P2 350 can struggle with 20 surfaces, where a 1,2ghz athlon can handle 80 before being crippled to the level of the Pentium 2. It's probably the one weakness in blitz3D's otherwise excellent performance. So you can probably do what you want, but will have to put a lot of thought into how blitz renders things, and optimize around those limitations. |
| ||
| Oh yeah, each seperate brush is a surface, and each seperate mesh even if it shares the same brush with others is a unique surface. so if you have a lanpost copied about your level with a single brush applied, each lampost becomes a surface. if the lamp post has 2 brushes, metal for the post and a lamp texture that becomes 2 surfaces and doubles your surface count. However if you combine all your lamposts into a single mesh with the one texture your back to 1 surface again. Of course your lammposts are strewn about your level, and if one lanpost is visible all lanposts in that mesh will be drawn. So you have to judge for yourself how to split this up for maximum efficiency. If you keep the surface count fairly low you may get away with 80'000 polys drawn per frame and not have to worry about occluding polys so much. you still have to juggle your collisions and linepicks though, as these are other CPU hogs that will reduce how many polys can be drawn if you don't design your engine intelligently. Usually low poly hidden collision is the best way to go and will give you a surprising ammount of flexibility if used right. |
| ||
| oops, back to textures, if you can get mure than one texture on a larger bitmap rather than many smaller textures you can get quite a big boost in performance. I often combine 2 horizontaly tiling 256x128 textures into a single 256x256 one, and combine smaller objects that are skinned into one larger 512x512 page. If you have a skin for a large object, and some small objects that don't need much pixel space, just fill in some empty spece in the larger objects texture. If you choose your shared texture combinations carefully you can get a big boost in performance, particularly if objects sharing these textures are combined into a single mesh saving surface count. Heh, hope that wasn't too confusing, just woke up ;) |
| ||
| Wow, thanks for all the replies. I am making the level as a big mesh in 3ds Max6. So i have textures that i apply over the buildings, objetcs, etc... Then i export to b3d with the onigirl pipeline. Any Advises about this way of work, Please? EDITED: And let's say i use a different texture map (256x256) for almost every object in the scene (except the ground)... so? |
| ||
| The Scene has no more than 4000 Faces. When i disable the textures the fps keeps at 120. Enabling the textures at some points it drops down to exactly the half (60). I have noticed this problem some times before. Any Help? |
| ||
| hmm, I've never really had a performance problem with under 11,000 faces, even on my Pentium 2 400. (what system do you have and what video card?) If you post a screenshot that might help. Also depends what else you are doing, collisions and linepicks are a killer if your doing it on a lot of polys. |
| ||
| The Scene has no more than 4000 Faces. When i disable the textures the fps keeps at 120. Enabling the textures at some points it drops down to exactly the half (60). I have noticed this problem some times before. Any Help? To me that sounds like a vsync problem... how do you flip, do you vsync on or off? |
| ||
| Well i use vsync on, so the fps without speed problems is the same as the monitor refresh (i have a fuji with 800x600x16 at 120Hz). The problem is that i get suddenly the half at some points. If i set the resolution to 1024x768x16 at 75Hz i get 75fps and in the locations problem i get 37. Thanks Anyway, i think it is a speed problem with the graphics rendering. |
| ||
| is it a maplet map? |
| ||
| How much graphics memory does your card have? Perhaps it's having to swap textures in and out when you bring others into view... ? |
| ||
| The problem is that i get suddenly the half at some points. Well this is exactly what happens if you have vsync on... if it can't draw everything in one refresh then it have to wait another. Experiment with Vsync OFF and you'll see much dramatic steps in fps although you might get little tearing. 0---------10--------20--------30 0--3_______--3_______--3 V-Sync prevents a new frame being rendered and copied into buffer B until the next refresh of the monitor is executed. Another example: 0---------10--------20--------30 0-------8__-------8__-------8 No problem. Now to the bad part (FPS < RR): 0---------10--------20--------30--------40 0------------13_______------------13_______ After 10 msecs buffer B doesn't have the latest frame since still more 3 msecs have to pass until it is being drawn in buffer A. for the 20 msecs timestamp it is available and then the process repeates itself. That means every 20 msecs a new frame is ready which is a drop to 50 fps of what you'll get! If rendering would take 21 msecs we'd be down to 33 fps. These fluctuations are the big disadvantage of V-Sync and the reason why most people don't use it. (Of course there are FPS fluctuations without it as well but not that dramatically). http://www.esreality.com/?a=longpost&id=522789&page=3 |
| ||
| Oh, this is then. Two last questions: - Vsync can be disabled from Blitz3D, or from graphic card panel in each computer? - How many 512x256 Maps can i use with 128Mb Video Memory without problem? Thanks very much people. Best Regards, KuRi |
| ||
| - Vsync can be disabled from Blitz3D, or from graphic card panel in each computer? Can be disabled/enabled with code: http://www.blitzbasic.co.nz/b3ddocs/command.php?name=Flip&ref=2d_a-z ...But you can always override this with driver settings, so there's no sure way to force it. You probably want to put in the readme.txt something about user checking if he has forced settings in his/her drivers. - How many 512x256 Maps can i use with 128Mb Video Memory without problem? Depends of course what's your bit-setting (16 or 32) and AA usage (beause it needs a buffer like front and back buffer does). Triple buffering needs one too and IMO you can force that in the some driver settings too. Geometry (vertices etc) takes up VRAM too, but that really hard to estimate, because it's so heavily poly-count dependable (per camera view at the point of rendering time). You can check my formulas here and calc VRAM usage yourself: http://www.blitzbasic.co.nz/Community/posts.php?topic=24157 (last post on that thread) Basically VRAM is managed by Blitz/DX so if it gets full it just swaps out stuff you don't need - but this of course can slow down things you have to do too much swapping. |
| ||
| you should probably avoid 512x256 maps, or combine 2 into 1 512x512 map )if they only tile in one direction) otherwise I think blitz will scale the map up to 512x512 anyway internaly, the scaling usually reduces the map quality by bluring, and probably has other overheads too. so allways try and use power of 2 square textures, and multiple textures on one page where possible. |
| ||
| IMO Blitz scales them up only if the HW can't use rectangular maps, but that's just a gut-feeling... and also how Blitz SHOULD work at least. |
| ||
| maybe something changed but thats what I was told by Jeremy when we were doing aerial antics menu's, and seemed to be what happened. Was a bit surprised myself. I guess it might have been something Jeremy was doing in code though since I didn't get to design the menu's and UI in that game. Probably ought to go and check but I don't have aerial antics on my computer. He did all the UI in code with sprites I think so that might explain it. OK decided to research it in the forums, looks like your only going to have that problem with TNT2 or older hardware. Still come across those even on relatively new hardware, allthough no reason I can see to go out of your way to support them. |
| ||
| Ok, Thanks again. Setting Flip Vfalse shows the problem better. When the game dropped to 60 now drops to 100, 105. Anyway i think that there are not too much complexity in the scene for that. Perhaps the problem is that my car models uses cube mapping, shininess, and some alpha for the cristals. :D |
| ||
| hmm, well 4,000 polys isn't much at all, unless you have a ton of colision polys and linepicks being calculated, or way too many textures and entities being drawn at once. in my xperience linepicks, collision, high number of entities, or too many surfaces cause the biggest hit. regular shinyness on your brushes do little, if your using dynamic cubemaps though, where it renders a cubemap in realtime per frame or every other frame that will have a pretty big hit on your game as if they were dynamic it would be like rendering your scene an extra 6 times per frame. Some brushed need more than 1 pass if they have complex multitexturing on. can't really say without seeing what your game looks like and what it's doing. |
| ||
| Well, all physics (collision and the rest) are controlled by ode, so the time for the physics and all the rest is very limited and controlled. A demo of my game: http://www.lcuriel.arrakis.es/CarDemoKuRi.rar The problem is looking at the gas station, but perhaps not in this demo, i have it pretty much advanced. For example, if i disable the cubic map (not dinamic of course), the problem is gone. So i think the problem is the sum of all the little effects. Thanks for all the answers. |
   |