Big performance loss for texture size of 256x256, maybe problem on our side

EDIT: for those with little time to read a long paragraph :



Summarizing, is there a performance limit for textures, so that in jme, for like a 500 -700 mhz machine, with 128mb ram, 16mb of 3d card,  is not advisable use textures of 256x256 (quake 2 and 3 usual ones) , or simply is not adviceable to use a load of textures(number of files), or… a total amount of texture pixels, globally?






Hello all. :slight_smile:



Well, is not surely a problem of the engine, but is a problem we have so I post here anyway… :wink:



We're having real problems  trying to avoid big fps loss when adding certain texture size or quantity of texture. Seems we're unsure on wether is the total amount of texture pixels, as a total, or just that 256x256 textures do kill performance…We notice the loss in good pentium 4 (not as good as some I read people have here ;)) , but the big problem is we aim to make the game go averagely smooth(not arcade, is a puzzle game) in PCs of the kind of a celeron 500, duron 500 - 700, like 128(ideally 64) mb of ram, 32 of 3d card(ideally 16).



we, after quite some coding effort(of my friend), were finally having nice fps, when the texture problem raised.



We have the luck to have those PCs available for testing. (I, the one who makes the graphics, also do those testings)



Is there a reason why the textures, if they are of certain number or size force such an fps loss? .For example, think of like 20 textures of 256x256, unique ones.  I mean with 'unique' that we trust heavily  jme's ode phisics for the gameplay, and a bunch load of meshes which use the same textures, and indeed, are identical. We plan for them to make use of shared mesh or maybe VBO specially if that would save us from the texture performance cost(dunno, seems like if it were related to memory, from what I hear from my friend programmer, maybe of the card, maybe of cpu. But seems the loss is noticed in a high cpu and pc, so, we're quite worried. It stays in a good fps, but loose a lot, so surely next tests on low machines will mean to high loss.)



We are unsure if it's for total amount of pixels in texture or something, or the maximum size of each(as an artist, in other engines this was related to 3d card memory:ie: unreal tournament 2003 needed a gf4ti4200 with128mb, but the mb were for the 1024x1024 textures…) , or the number of texture files.We're now more happy with geometry power, but having this texture issue.Very important for a low pol game.





As with a much heavier texture work that i have had in other engines, I could do the work with much more tiny textures of 64x64, but textures of that size do make uv mapping and texturing a load more complex, time consuming, and means usually a loss of quality at the end, quite important. Besides it becomes more of pixel art than anything, which I'd like to avoid personally :wink: . And that we even so would be unsure again if a certain number of them would kill the performance anyway.





True that we have made a first test with basic physics (not that we need something really complex, though.just use in a lot of identical objects), that we have surely put a lot of pieces, and surely each texture as a way to be called that maybe is not ideal,in code, I suppose, but i don't know. We're going for like 40 dynamic objects (which are equal, just having each physics applied to suffer physics independently) , and a polygon count of all what is not physics of like 2,000 tris as much. The 40 dynamic objects wont pass of 200 tris,(but for one or two, most of those 40 will be of like 6 to 10 tris. And each texture, will be of 64x64, but maybe we tested with 256x256 texture. (one applied to all , I think. I am not the coder.))



oh, many of you know already, but we're aiming to do(actually at it now) a casual game, comercial, with jme :slight_smile:



I guess we're touching some sort of bottle neck and we're just too new in JME engine to know it.



So in case someone is aware or can throw a light…as we're a bit stuck on this one. had solved other problems , though.



Oh, we don't use shadows, to lower performance lossing…we  will probably use some featherd bitmap, but surely not for the dynamic objects.



Add to all that an md5 character only, of like 700 to 1500 tris,not yet done,  polygon count depending on how well it all runs globally in one of those low machines. textured with ideally at least a 256x256 texture…



Thanks a zillion in advance…


There are two main things you have to account for when it comes to texturing, size that the textures take up, and fillrate.



A 256x256 texture is 16 times bigger than 64x64 one (not counting mipmaps), but more importantly, it used 16 times more bandwith to draw as well. Even if you manage to fit all your 256x256  textures in 16 MB (together with diplay lists or VBOs and the framebuffer), they're still 16 times more expensive to draw.  (of course, only if they're fully drawn, which is your typical situation, but you can see the point here)



When you don't have much geometry the card will not be limited by how much geometry you can calculate, it will be limited by how quickly it can draw your textures. So wether you have a slow old card or a fast new card, if that's the limiting factor in your scene and you 16 times more detail, things will get slower. SharedMesh does not help you here either, because every mesh drawn has to be textured seperatly.



This is why most games have a "texture detail" setting.

very interesting info, Llama, thank you very much.



I guess I have bad habits. I worked in a company where we used to do indoor levels, a room usually was having several 512x512 textures… I remember one of them having a whole 1024 (initially was 2048, and still could run) texture from which objects did took each its textured zone… one of the rooms was more than 100k tris, and with particles, and one 5,000+ tris character, it started to not be so smooth in an ati 9000 or the kind…(but still was playable)



Also was in mods for ut2k3…characters used to have one 1024 for body, one 1024 for head…



Lol, nice good old times.



But low machines is our target now.



I will keep very much in mind those numbers you mention. I guess then is preferrable  to work with many 64 or 128 when very necesary, than a few 256.( if many objects use the same texture, I guess then it's the cost of only one texture. )



Our last tests point that definitely our performance problems aren't with polygon counts. In geometry, I am reaching quite some detail with little loss of performance.






Did you use mipmapping woth your 256x256 textures? This takes more memory but speeds up drawing at a distance (because it effectivly lets you draw with a smaller texture). Maybe for your most important textures you could use a mipmapped 256x256 texture.



Like I said, in a real world situation, it's not a x16 difference. It's only (approx.) that if you draw a full 256x256 texture and a full 64x64 texture. If you draw a 256x256 mipmap textured object at a distance where it's 64x64 mipmap is used, it's about that same. Except if because of all the big textures used it has to be fetched from RAM of course… a 256x256 mipmapped texture with 3 detail levels (0, 1 and 2, to reach 64x64) is 16+4+1=21 times larger than a plain 64x64 texture.



And, of course if you use only a 64x64 section of a 1024x1024 texture it's way cheaper to draw than the whole texture. What's important for pixel fill rate is the number of pixels a sample is taken from, and the actual number of pixel drawn to the framebuffer. (what type of filtering is used determines this, but also affects computation time mostly on old cards which can be an indirect influence)


Did you use mipmapping woth your 256x256 textures?


Unsure...I think we had to use a command something like linear_linear or something, that allows removing the noise when tetxures seen at a distance... I used to call that allways mipmapping, but to be sincere, one just use to cares about outputting the art, as tends to be quite hard itself, and while I hear allways stuff bout it, never too clear... I guess it acted like an smoothing for textures at a distance...Does it really generate smaller textures, or do I have to provide them? (like a manual lod but for textures) better if is automatic, as also we so don't add extra download memory.


I am doing a lot of tests now with two old machines, a celeron and duron, very unstable, and very old. And in bad state. Gonna try all sort of combinations in my artwork pipeline....


Thanks a lot for your help, llama.


If you don't supply any mipmaps, jME generates them for you. And yes, they really are smaller versions of the same texture.

Then great! 8) I will tell this to my friend :)