Texture size affecting game framerates?

[Karl]

so uh currently my mod uses like 47 files on average 1024x1024px scaling and it takes 41,4 mb in total they're all in PNG format.

And my question is if that would have large impact on game performance, because currently my workflow is that each unit gets 1024x1024 sized texture per default and sometimes smaller ones when the model is small such as projectiles where I would use 256x256 and lower

I looked also on the internet if there is much difference between DDS and PNG, so and from what I know that DDS + power of 2 scale gives a little bit more performance compared to textures that is not the case so to speak it got scale of 100x210 and is not a dds format.



I am sorry if this question has been asked before.

[FLOZi]

Use dds.

Most S44 textures are 512x512 and that is plenty if you are an efficient UV mapper.

[Anarchid]

An alternative approach is the BAR path where you use one huge texture for all units, and judging from the screenshots, it can be made to look amazing.

A possible downside is that you might sometimes get different texel density, but i guess there's some know-how in atlas creation that can solve that.

[Silentwings]

As far as I know the only downside of big textures is that there can be a tiny pause while they load, the first time the model is spawned. You can work around this: http://imolarpg.dyndns.org/trac/balates ... loader.lua

[Karl]

Use dds.

Most S44 textures are 512x512 and that is plenty if you are an efficient UV mapper.

hm right but I used different approach for texturing my models, I admit it is not the best one to use.

An alternative approach is the BAR path where you use one huge texture for all units, and judging from the screenshots, it can be made to look amazing.

A possible downside is that you might sometimes get different texel density, but i guess there's some know-how in atlas creation that can solve that.

Hm that one sounds the most interesting, the advance of that would be I could easily make that texture have in x different style, ie making everything for lets say different camo pattern, snow, damaged stage etc in practically 1 go, hmm yeah I could do that and use the BAR texture as a base.

As far as I know the only downside of big textures is that there can be a tiny pause while they load, the first time the model is spawned. You can work around this: http://imolarpg.dyndns.org/trac/balates ... loader.lua

so does this mean I could theoretically use for every unit 4096 texture scale and there would be no framerate impact apart from hiccups during the texture getting loaded?

Framerate impact as in the game runs slower when everything uses large textures compared to a smoother framerate when all models uses smaller texture.

So yeah thanks for your inputs.

[Forboding Angel]

Evo units use lego, which is a giant 2048x2048 atlas that is used across all the units. The cool part is, the more units you have, the more efficient it becomes.

I did the math one time and I think at about 21 units an atlas that size starts paying for itself.

I would caution going above 2048... at 4096 you will start having crappier gfx cards bombing out simply because they can't deal with the size of the texture.

[Silentwings]

so does this mean I could theoretically use for every unit 4096 texture scale and there would be no framerate impact apart from hiccups during the texture getting loaded?

Framerate impact as in the game runs slower when everything uses large textures compared to a smoother framerate when all models uses smaller texture.

Eventually you will hit a point where the textures no longer fit in memory, but up to that point I think this is correct. I don't think an individual 4096x4096 is big enough to cause a hiccup when it loads, but if it does just use the workaround above.

[Karl]

Evo units use lego, which is a giant 2048x2048 atlas that is used across all the units. The cool part is, the more units you have, the more efficient it becomes.

I did the math one time and I think at about 21 units an atlas that size starts paying for itself.

My game uses so far 50+ units, like you wrote it at that point it would be useful.

I would caution going above 2048... at 4096 you will start having crappier gfx cards bombing out simply because they can't deal with the size of the texture.

Yes I remember that from other game modding where some user would start reporting graphic glitches simple because the GPU refuses to load such a big texture due the game only supports an atlas for loading inventory item graphics.

Eventually you will hit a point where the textures no longer fit in memory, but up to that point I think this is correct. I don't think an individual 4096x4096 is big enough to cause a hiccup when it loads, but if it does just use the workaround above.

Alright, I have that already bookmarked and going to use the gadget as soon I use the atlas approach.



my first try with the cremuss/BAR texture, its a metal extractor

[smoth]

Not trying to come off like I am being mean, but what about your work justifies a 1024 texture for most units? I don't understand. If you cannot do it in 512 x 512, you may be wasting a majority of uv space. Also do you mean average or MEAN size?

[Karl]

Not trying to come off like I am being mean, but what about your work justifies a 1024 texture for most units? I don't understand. If you cannot do it in 512 x 512, you may be wasting a majority of uv space. Also do you mean average or MEAN size?

meh, I wasted anyway alot of UV spaces just alone for using smart unwrap, and I made it the texture that big so the unit doesn't look way to blurry

on the second question, well let me list it:
60x 1024x1024
3x 1536x1536
4x 512x512
10x 256x256
1x 128x128
so in total it would be 70784x70784 and 47,6 MB


http://www31.zippyshare.com/v/27216457/file.html
heres the blend file which you can see how I texture my units

http://i.imgur.com/0faWo6m.jpg
hm it doesnt seem to be really that noticeable, as it is mostly made up of noisy texture

[smoth]

Well, part of your flow NEEDS to be doing a well planned texture UVmap. Lazy uv maps waste a lot of space, when you are worried about performance you need to spend the time to really craft all your UV maps.


In before blurry..

Here are some of my older gundam models







If you are interested I could post some of my textures as examples if you would like.

here is a more recent example as well:

which easily became:

512x512

[Forboding Angel]

my first try with the cremuss/BAR texture, its a metal extractor

Actually, that's really good. My only real complaint would be that the geometry of your model is not complicated enough, but lesbihonest, when viewed from 50 meters in the air, it's plenty detailed.

Suffice it to say, I like.

I would, however, caution you with this... Don't use a 2048 or whatever just for the sake of it.

In evo, I use that size because the texture is extremely detailed and I want units to look really good up close.

However, if I were to retex the lego parts (actually I have done it to some extent, I just keep losing motivation), my end result texture would probably be a 512, because I would not be using the same level of detail on it. Make sense?

In other words, use what you need to, but don't waste anything if/when you don't need it.

Crappy explanation, but hopefully you understand what I mean.

[smoth]

my atlas is like 2048 and I have not even used 40% of the thing yet, maybe 30ish...

Also this was using mostly the tank atlas...



so yeah.

[Karl]

Well, part of your flow NEEDS to be doing a well planned texture UVmap. Lazy uv maps waste a lot of space, when you are worried about performance you need to spend the time to really craft all your UV maps.

In before blurry..

Those are nice screenshot, ok I get it now - when all units should get a individual texture it should be 512x512 and needs manual UV mapping, unless I use a atlas one which should be bigger like around 2048-4096 then it doesn't matter much.

Actually, that's really good. My only real complaint would be that the geometry of your model is not complicated enough, but lesbihonest, when viewed from 50 meters in the air, it's plenty detailed.

Suffice it to say, I like.

Well I made that low detailed because I wanted to look how well it will look like when using a atlas
and it looks kinda alright.

I would, however, caution you with this... Don't use a 2048 or whatever just for the sake of it.

However, if I were to retex the lego parts (actually I have done it to some extent, I just keep losing motivation), my end result texture would probably be a 512, because I would not be using the same level of detail on it. Make sense?

a 512x512 sized atlas texture isn't that a little bit small?



tl;dr I am going to use Atlas from now on. that way I can also add/remove mesh part all the time.

[smoth]

I think a 512x512 is sill but he can do what he wants.

2048 is safe, in a few years 4096 will be safe if it isn't already. You can go smaller.

As far as unit textures,

these 2 aircraft from grts, they had 256x256 and panel line details because aircraft are closer to the camera..

click for image larger

512x512 is justified if the model is reasonably large or complex...

click for image larger

Also you need to learn how to mirror and reuse parts that look exactly the same, which is why all my previews have 1 arm and 1 leg

P.S. I am not trying to thread jack or berate you, best I can do to give you tips is post examples. I wish I had more I could help you as far as tips and tuts. I did once record a video of my texturing if that is of any help.

[Karl]

I think a 512x512 is sill but he can do what he wants.

2048 is safe, in a few years 4096 will be safe if it isn't already. You can go smaller.

As far as unit textures,

these 2 aircraft from grts, they had 256x256 and panel line details because aircraft are closer to the camera..

Of course he can do what he wants with his project its his and not mine, I was just wondering a bit that he chosed such a small resolution for a atlas but thats his choice.

I am going to use the KaiserJ texture instead, as it is a bit smaller than cremuss and bit better organized, using cremuss one lags my blender which sucks when I have to drag the UV maps.

And I already made myself familiar with the unwrapping tool with blender and wings 3D, I prefer blender ones as it has more tools and the like. Thanks for the example it will be useful when I try to texture something in a traditional way.

As for Mirroring goes: http://wiki.blender.org/index.php/Exten ... stribution this plugin seems to be good or atleast according to the video, I couldnt try it at the moment as I need a account on blender for downloading this plugin, what a bullshit in my opinion it is like maybe a few KB big and I dont lurk on blender forum much at all, oh well.

P.S. I am not trying to thread jack or berate you, best I can do to give you tips is post examples. I wish I had more I could help you as far as tips and tuts. I did once record a video of my texturing if that is of any help.

well all my question is already answered, so I dont mind about it but thanks anyway.

[smoth]

IIRC he felt he had a framerate increase with it. I don't know if there is a real reason to use a 512x512. JK could better answer that as he understands the underpinnings of it all better than I do.

I dunno, grts had a comparitively HUGE textured model count and it ran as slow as all the other *a spring games at the time -10 to -20 fps due to all the extra actual visuals, gui and economy + other lua. Which meant GRTS ran about the same as CA and BA. The bigger issue was piece count for gundam units.

I don't think atlasing really increases performance persay I am doing it to save time on units

[Karl]

IIRC he felt he had a framerate increase with it. I don't know if there is a real reason to use a 512x512. JK could better answer that as he understands the underpinnings of it all better than I do.

I dunno, grts had a comparitively HUGE textured model count and it ran as slow as all the other *a spring games at the time -10 to -20 fps due to all the extra actual visuals, gui and economy + other lua. Which meant GRTS ran about the same as CA and BA. The bigger issue was piece count for gundam units.

I don't think atlasing really increases performance persay I am doing it to save time on units

Alright I wait for his answer then, it kind of sucks to read that the game lags when a unit got alot of piece count, about the other part I cannot say much as I dint play tested my game enough with other players and dint so for a while.


well I decided to use the atlasing approach as I can make easily sure it looks consistent, easily just modify it for different visuals such as damaged, snow, dirt etc on 1 go. And like I previously wrote for peformance reason because I wondered using like 1024 scale for every unit individually was a bit overkill
and it dint looked that detailed anyway.

So far my PC doesnt lag when I use /cheat giveall apart from the temporary hiccup with like 74 units total

[smoth]

The piececount thing jk explained to me once years ago, essentially the higher up a tree something is, the more expensive it's rotations are because it walks the tree..

so like a model that has this heirarchy..

chest
- shoulder
-- arm
--- forearm
---- gun

moving the gun is expensive as it has to account for all the other prior parts and moving the shoulder is the same

so like:

base
pole
flag
pole
flag

is cheaper than:

base
- pole
-- flag
- pole
-- flag

[8611]

Never trust anything that begins with "Someone once told me many years ago that.."
Applies to RL and internet more so. Instead
a) find the original source, threads like http://springrts.com/phpbb/viewtopic.ph ... 8&p=538006 ,
http://springrts.com/phpbb/viewtopic.ph ... 13#p424713 is interessting too but with so old posts must be careful sometimes in internet.
b) Test yourself. Resize all your textures to superlarge or small - and see what happens.
Use some graphics batch-conversation/resize program (like irfanview for images or DDS Converter for .dds) and you can resize all files at once.