This might seem stupid, but it bugs me. From what I understand, multitexturing is just using more than 1 texture per shader (usually to blend them somehow). So instead of creating 1 texture, I create 2 or more which is... pretty obvious!

Why is there a special term for that? Is there more to it than just "using more than 1 texture"? Am I missing something?

  • \$\begingroup\$ At one point especially in real-time 3d graphics, using one texture (diffuse map) was very common. Therefore the name was used to suggest that you are using more than one texture. I don't see the problem. Much like multi-threaded \$\endgroup\$
    – AturSams
    Commented Mar 2, 2014 at 13:02
  • \$\begingroup\$ But multithreading requires special API, completely different program design and so on. It does differ in many aspects. My question stems from the fact that multitexturing doesn't seem to have anything different but the texture count. And it's not a problem, just a question. \$\endgroup\$
    – NPS
    Commented Mar 2, 2014 at 13:09
  • \$\begingroup\$ It does not have to require a special API. That would depend on the implementation. I use some tools that treat multitexture the same way they would "unitexture" ;) \$\endgroup\$
    – AturSams
    Commented Mar 2, 2014 at 13:11
  • \$\begingroup\$ @concept Which part? The title? \$\endgroup\$
    – Anko
    Commented Mar 2, 2014 at 22:56

3 Answers 3


The special term has to do with the evolution of graphics cards and real time graphics APIs rather than being so special. For instance image processing and offline graphics rendering had this feature long before it was available in real time graphics APIs and consumer level hardware.

Since OpenGL 1.1 (fixed functionality) multitexturing was introduced as a new state to the API. Instead of only binding one texture, it gave you the ability to bind multiple textures; one for each texture units and then blend between them using one of the texture environment parameters, blend, modulate..etc1

Then texture combiners were introduced, it gave the ability combine a set of textures using more flexible operations, by giving you a way to pass parameters to a fixed set of operations (think of it as shaders but with fixed set of params), this was more flexible than the original "combiners".

With the introduction of shaders, the previous combiners became redundant until officially deprecated. Finally It became trivial (as hardware and accordingly APIs evolved) to pass a texture sampler to the shader and let the GPU execute arbitrary operations (your shader) on your textures as much more flexiblel to what was before.

The point here; even if it became trivial, the term survived as a generic term for any operation that describes sampling and convolution of multiple textures.

1 I am using my memory to recall OpenGL fixed functionality correct me if I missed sth.


The historical reason is that "multitexturing" was a marketing buzzword like "hardware TnL" once upon a time. Since it was a distinguishing feature of new cards, there needed to be a word for it to sell them.

The technical reason is that multitexturing is not just creating and using two textures instead of one. If you simply used two textures (or three, or any number), you could just as well only use one texture, since there is only one output fragment. That would make no difference (whatever the input is, the output can only be one or the other), so it wouldn't be anything special.

The difference is not that you can create several textures, but that you combine two or more textures. For example, you might blend them based on alpha or on some per-vertex interpolated blend factors, or you might add them, or something different.
The amount of configurability/programmability has greatly evolved over the last decade, but the one great difference remains that you can somehow combine two or more inputs into one output.


In the beginning there was light

OpenGL lighting, to be specific, which specified certain mathematical operations to be applied to a fragment, which were then combined with textures to derive a final colour.

And then there was Quake

Quake didn't use this kind of lighting for many of it's objects. Instead it used a second texture to represent lighting, which was multipled by (or "modulated with) the object texture to derive a final colour.

However, hardware of the time didn't support this in a single operation. So Quake needed to draw it's scene objects twice:

  • Draw everything once to lay down the base textures.
  • Set a modulate blend mode.
  • Draw everything a second time to apply the lighting textures.

This of course was slow; not only did all geometry need to be transformed and clipped twice (which in those days was a CPU operation), but every pixel on-screen ended up being touched twice during rendering.

Enter multitexture

Multitexture was the solution to this, and was originally exposed via the GL_SGIS_multitexture extension, which only existed on certain consumer 3DFX cards. Originally it only allowed blending two textures (and with a limited set of blend modes).

To quote from the original GLQuake readme:

Multitextures support allows certain hardware to render the world in one pass instead of two. GLQuake uses two passes, one for the world textures and the second for the lightmaps that are blended on the textures. On some hardware, with a GL_SIGS_multitexture supported OpenGL implementation, this can be done in one pass. On hardware that supports this, you will get a 60% to 100% increase in frame rate. Currently, only 3DFX dual TMU cards (such as the Obsidian 2220) support this extension, but other hardware will soon follow.

It's important to remember that at this time effects such as normal mapping, any other kind of per-pixel lighting, even shaders, and so on just didn't exist (well they did, but primarily just in academic papers and research projects, and weren't considered viable for use in real-time rendering).

And so to the present

From here it's pretty much as described in the other answers. Multitexturing became a standard feature over time, with more blend modes becoming available, eventually giving way to arbitrary shader code.

But what's important for the purposes of your question is this: in the beginning the standard functionality was just being able to use one texture at a time when rendering. Being able to use more than one was additional functionality that only high-end hardware supported, and so it needed a name. That name could have been "dual-texturing" (as the first implementations just supported two textures) but with one eye on the future the name "multitexture" was chosen.

Further reading on the history of all this is available here, and a good historical writeup (of the broader context, and the part multitexturing played in it) at this Programmers.SE answer.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .