texture packing and improvement in speed (semi-newbie)
A L
something like 500, with all the items, tiling, buttons, etc.. Using
OpenGL, the framerate was pretty shoddy (~9). The geometry isn't too
complex (since most of the details are in textures, there are just a
lot of boxes, barrels, that sort of thing,) and my test bed is pretty
fast (GF4 Ti 4400, Athlon 1800, 1 gig DDR, etc.) so I was wondering
what could be done perhaps to speed this up (just to make sure- a
large number of textures would cause slowdown, right?)
Something I've considered for quite some time is texture packing. Are
there any tools/utilities for doing this?
What should be the max texture size for these combo textures, 256x256?
Could I go as high as 2048x2048?
Most importantly, why would accessing the same data in one texture be
faster than accessing many smaller textures? Stupid question, I
imagine, but I'm pretty new at this stuff.
Thanks!
zed
packing smaller textures into larger textures usually helps.
also look at texturecompression (requires 1/4 the memory but at a loss
of quality sometimes bad sometimes not)
use a lower quality internal texture format.
use luminance textures instead of RGB etc
fungus
> I have a level I designed for an old game that has a LOT of textures-
> something like 500, with all the items, tiling, buttons, etc.. Using
> OpenGL, the framerate was pretty shoddy (~9). The geometry isn't too
> complex (since most of the details are in textures, there are just a
> lot of boxes, barrels, that sort of thing,) and my test bed is pretty
> fast (GF4 Ti 4400, Athlon 1800, 1 gig DDR, etc.) so I was wondering
> what could be done perhaps to speed this up (just to make sure- a
> large number of textures would cause slowdown, right?)
>
If you run out of texture RAM then it will start
paging.
1) Sort your polygons by texture to reduce thrashing.
2) Make the textures smaller so they fit in available
texture memory.
> Something I've considered for quite some time is texture packing. Are
> there any tools/utilities for doing this?
>
> What should be the max texture size for these combo textures, 256x256?
> Could I go as high as 2048x2048?
>
Maybe.
> Most importantly, why would accessing the same data in one texture be
> faster than accessing many smaller textures? Stupid question, I
> imagine, but I'm pretty new at this stuff.
>
It won't, unless you're going to reduce the overall
area of textures.
--
<\___/>
/ O O \
\_____/ FTB.
Andy V
> > Most importantly, why would accessing the same data in one texture be
> > faster than accessing many smaller textures? Stupid question, I
> > imagine, but I'm pretty new at this stuff.
> >
>
> It won't, unless you're going to reduce the overall
> area of textures.
I can't agree with you here, fungus, because there is often a fair
amount of overhead in binding textures -- even when they are on the
board. It may not be significant, but then again it might.
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown
ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different
Drum_.
Paul Martz's OpenGL FAQ:
http://www.opengl.org/developers/faqs/technical.html
zed
>> Most importantly, why would accessing the same data in one texture be
>> faster than accessing many smaller textures? Stupid question, I
>> imagine, but I'm pretty new at this stuff.
>>
>
> It won't, unless you're going to reduce the overall
> area of textures.
actually it will (less texture changes needed)
César Blecua Udías
>
[...]
>
> Something I've considered for quite some time is texture packing. Are
> there any tools/utilities for doing this?
>
> What should be the max texture size for these combo textures, 256x256?
> Could I go as high as 2048x2048?
And 4096x4096 in some newer hardware, but this is implementation
dependent, so don't assume anything... check support at run-time and let
your program decide based on the detected supported size.
If you finally go for packing smaller textures into large ones, don't
forget that you need to be careful with filtering: First, linear
interpolation (magnification or minification) will use neighbouring
texels in the border of each sub-texture, accessing texels of other
sub-textures. Second, MIPmaps are even more problematic, because they
can access all texels in the texture (the lowest MIPmap level is one
pixel that must represent all your sub-textures).
You can minimize the impact of these filtering problems by sorrounding
your sub-textures with areas of repeated pixels from the subtextures,
although there will always be a MIPmap level at which unwanted
interpolation happens.
There's another problem: GL_REPEAT wrapping mode won't work: it would
repeat the whole texture rather than each subtexture.
Anyway, despite of this, packing small textures into large textures is a
useful technique, and good for many situations.
César
cesar...@ono.com