Why do people use texture atlases?  Why not just use separate textures?

Le 01/12/2011 18:51, bob a �crit :
> Why do people use texture atlases?  Why not just use separate textures?

several reasons :
- with your graphics card, switching textures is costly. On contrary, 
often you will try to pack textures of several meshes in a single image 
to avoid switching textures in memory.
- that makes the processing easier : one mesh = one texture
- you don't waste as much space, as your parametric space is unlikely to 
fill the whole space (it may, but with useless resolutions in some 
parts, or high distortion in other parts). So you can pack several 
charts in a single texture with less blank space.
- easier to maintain : instead of shipping a 3d model with 10 different 
texture files that the artist might want to edit, you only have one.

I guess there are many other reasons.

Cheers

On 2011-12-01, Nicolas Bonneel <nicolas.bonneel@wwwwwwwwanadoo.fr> wrote:
> Le 01/12/2011 18:51, bob a ?crit :
>> Why do people use texture atlases?  Why not just use separate textures?
>
> several reasons :
> - with your graphics card, switching textures is costly. On contrary, 
> often you will try to pack textures of several meshes in a single image 
> to avoid switching textures in memory.

Furthermore, not only does it help avoid texture switches, but also
helps minimize the drawing calls themselves. The artists might pack the
textures of multiple objects in one, and then merge the meshes
themselves, thus enabling the engine to draw them all with a single
glDrawElements or whatever call, after binding the single texture.


-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

On Dec 1, 11:13=A0am, Nicolas Bonneel
<nicolas.bonn...@wwwwwwwwanadoo.fr> wrote:
> Le 01/12/2011 18:51, bob a =E9crit :
>
> > Why do people use texture atlases? =A0Why not just use separate texture=
s?
>
> several reasons :
> - with your graphics card, switching textures is costly. On contrary,
> often you will try to pack textures of several meshes in a single image
> to avoid switching textures in memory.
> - that makes the processing easier : one mesh =3D one texture
> - you don't waste as much space, as your parametric space is unlikely to
> fill the whole space (it may, but with useless resolutions in some
> parts, or high distortion in other parts). So you can pack several
> charts in a single texture with less blank space.
> - easier to maintain : instead of shipping a 3d model with 10 different
> texture files that the artist might want to edit, you only have one.
>
> I guess there are many other reasons.
>
> Cheers

Can you show me anything that says switching textures is costly?  I
would think it's just a matter of modifying an offset in an equation
(sort of like how you can do page flipping by changing a single
pointer).

There can be a lot of reasons why texture switching is expensive. First, th=
e new texture might be in host memory (or perhaps even on disk as backing s=
tore). Next, you need to set up a bunch of registers on how to access the t=
extures -- or the set of textures for mipmapping. This should be simple and=
 fast, but it does depend on the hardware. Finally, all the parallel proces=
sors in a GPU may need to be synchronized before the change can happen.=20

--
Andy V

Le 05/12/2011 03:06, bob a �crit :
> On Dec 1, 11:13 am, Nicolas Bonneel
> <nicolas.bonn...@wwwwwwwwanadoo.fr>  wrote:
>> Le 01/12/2011 18:51, bob a �crit :
>>
>>> Why do people use texture atlases?  Why not just use separate textures?
>>
>> several reasons :
>> - with your graphics card, switching textures is costly. On contrary,
>> often you will try to pack textures of several meshes in a single image
>> to avoid switching textures in memory.
>> - that makes the processing easier : one mesh = one texture
>> - you don't waste as much space, as your parametric space is unlikely to
>> fill the whole space (it may, but with useless resolutions in some
>> parts, or high distortion in other parts). So you can pack several
>> charts in a single texture with less blank space.
>> - easier to maintain : instead of shipping a 3d model with 10 different
>> texture files that the artist might want to edit, you only have one.
>>
>> I guess there are many other reasons.
>>
>> Cheers
>
> Can you show me anything that says switching textures is costly?  I
> would think it's just a matter of modifying an offset in an equation
> (sort of like how you can do page flipping by changing a single
> pointer).

http://bit.ly/uTikSF

"Keep mind that switching textures is a fairly expensive operation. If a 
texture is not already resident in dedicated texture memory, switching 
to a non-resident texture requires that the texture be downloaded to the 
hardware before use. Even if the texture is already downloaded, caches 
that maximize texture performance may be invalidated when switching 
textures. The details of switching textures varies depending on your 
OpenGL implementation, but suffice it to say that OpenGL implementations 
are inevitably optimized to maximize texturing performance for whatever 
texture is currently bound so changing textures is something to 
minimize. Real-world applications often derive significant performance 
gains by sorting by texture the objects that they render to minimize the 
number of glBindTexture() commands required to render the scene. For 
example, if a scene uses three different tree textures to draw several 
dozen trees within a scene, it is a good idea to draw all the trees that 
share a single texture first before switching to a different tree texture."

On 12/05/2011 07:06 AM, Nicolas Bonneel wrote:
> Le 05/12/2011 03:06, bob a �crit :
>>
>> Can you show me anything that says switching textures is costly? I
>> would think it's just a matter of modifying an offset in an equation
>> (sort of like how you can do page flipping by changing a single
>> pointer).
>
> http://bit.ly/uTikSF
>
> "Keep mind that switching textures is a fairly expensive operation. If a

Looks like that is from
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node59.html
"David Blythe 1999-08-06"

Has anybody benchmarked it on modern hardware?

- Marsh

"Marsh Ray" <marsh@extendedsubset.com> wrote in message 
news:4EDD1272.3040802@extendedsubset.com...
> On 12/05/2011 07:06 AM, Nicolas Bonneel wrote:
>> Le 05/12/2011 03:06, bob a �crit :
>>>
>>> Can you show me anything that says switching textures is costly? I
>>> would think it's just a matter of modifying an offset in an equation
>>> (sort of like how you can do page flipping by changing a single
>>> pointer).
>>
>> http://bit.ly/uTikSF
>>
>> "Keep mind that switching textures is a fairly expensive operation. If a
>
> Looks like that is from
> http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node59.html
> "David Blythe 1999-08-06"
>
> Has anybody benchmarked it on modern hardware?
>
> - Marsh

I expect that, if all textures are resident, it's a negligible cost to 
switch these days. But I could be proven wrong.

Having said that, one advantage with an atlas is that you know it's resident 
for "virtual texture" 2..N, and,
you can have memory savings due to power-of-two size waste being avoided for 
lots of small textures. Downside can be that texture compression can cause 
"bleed" from one "virtual tetxure" to the next.

jbw 

On Dec 5, 4:06=A0am, bob <b...@coolgroups.com> wrote:
> On Dec 1, 11:13=A0am, Nicolas Bonneel
>
>
>
>
>
>
>
>
>
> <nicolas.bonn...@wwwwwwwwanadoo.fr> wrote:
> > Le 01/12/2011 18:51, bob a =E9crit :
>
> > > Why do people use texture atlases? =A0Why not just use separate textu=
res?
>
> > several reasons :
> > - with your graphics card, switching textures is costly. On contrary,
> > often you will try to pack textures of several meshes in a single image
> > to avoid switching textures in memory.
> > - that makes the processing easier : one mesh =3D one texture
> > - you don't waste as much space, as your parametric space is unlikely t=
o
> > fill the whole space (it may, but with useless resolutions in some
> > parts, or high distortion in other parts). So you can pack several
> > charts in a single texture with less blank space.
> > - easier to maintain : instead of shipping a 3d model with 10 different
> > texture files that the artist might want to edit, you only have one.
>
> > I guess there are many other reasons.
>
> > Cheers
>
> Can you show me anything that says switching textures is costly? =A0I
> would think it's just a matter of modifying an offset in an equation
> (sort of like how you can do page flipping by changing a single
> pointer).

Binding a texture object will at least generate PM4 packets to the
command stream the CP has to execute. The more commands you have to
process the slower your program will be. The command stream also has
to be generated by the CPU so it will cost CPU time, bandwidth and CP
time.

When you bind a texture object, you must also map the handle to
address of the texture object. A hash is pretty fast but unfortunately
many vendors use linked-list to handle the collisions which isn't very
nice when you have a lot of hash collisions. A binary tree would be
nice but then it has higher average cost for trivial cases, a hybrid
of those might be a nice tradeoff. The point is this trivial operation
might have some stupid CPU cost associated with it.

Then, the additional draw calls will introduce more work for the
driver. In optimum case everything is asynchronous but when you page
out textures you can't do it until the texture is fully consumed (eg.
all draw commands pending execution have finished). To intelligently
page out stuff you would need to keep track what is still being
processed, or will is pending processing otherwise you would have to
soon page stuff back in and that would be a very bad performance
choice.

Every draw calls incurs overhead as it makes sense to use lazy
evaluation to update the state; this would allow the driver to cache
the state changes locally, and when idiotic application (there are so
many out there you wouldn't believe) writes to same state multiple
times before committing a draw command only the latest state change
would be written into the command stream. Also, it makes a lot of
sense to optimize the # of register writes so it's advantageous to see
more of the state before creating command stream.

Loosely translated above means that it makes sense to burn CPU time to
reduce the workload to the GPU, if you have a driver which just
idiotically passes everything down to the hardware you can in typical
scenario have 2x more work for the GPU to do and so have significantly
reduced performance. Such driver is much simpler in structure but
performs pretty poorly with badly written applications. It could be
possible to leave a lot of this work to the application developers but
history has shown that it is not a very wise decision, the driver
people know much better what kind of command stream is better for any
given hardware they are optimizing drivers for than the application
developers.

But there are still guidelines which allow applications perform better
in most hardware and driver combination. Reducing number of state
changes is one optimization that applications can always do and most
of the time benefit from, when it i relevant, that is. One or two
rotating cubes won't see much improvement from super-duper optimized
way to draw them.

Texture change is one of the more expensive state changes there are.
When you change a texture object, you are not just "changing a
pointer", you are actually activating a new surface as sampler. In
OpenGL this means you also have to change the sampler state for that
texture stage; more register writes, more work. Textures carry quite a
bit of state with them that needs to be updated. :(

It gets even worse with OpenGL 2.x and later, in case the texture type
affects the sampler. For example, it is possible that hardware has
different output format from RGB, RGBA, INTENSITY texture formats.
This difference affects the generated shader microcode. So, when the
draw call comes in.. and texture object binding has changed from, say,
LUMINANCE to RGB, the shader microcode has to be re-generated, which
will be a HUGE hit in performance. Okay, so why the compiler won't
emit all combinations at once and change the one that is used when
sampler internal format changes? Because if you got for example 8
samplers and 4 different combinations to choose from for each, the #
of generated microcode is 65536 variations, oh shit.

There are other issues as well but this is just scratching the
surface. The short version: "texture change is expensive"