Recap: Texturing in OpenGL can be achieved in two separate ways, using different API’s and hardware features. The preferred, modern approach – procedural texturing – uses nothing more than a Fragment shader (this is really what Fragment shaders were created for: Texturing).<\/p>\n
Part 5 (Textures: 1 of 3)<\/a> covered that in detail – but there’s another option: Texture-Mapping (also known as “UV Mapping”, it’s identical). Procedural Texturing (from the previous post) requires a lot of processing power on-board the GPU. OpenGL launched in 1992 – 5 years before GPU’s even existed for the PC. Texturing was mostly useful as a hack to make up for the poor raw power of hardware. Texture-Mapping in OpenGL comes out of that mindset – and it works a lot differently from the “simple, obvious” texturing we have today.<\/p>\n \nTexture-Mapping requires almost zero processing power, instead it sacrifices huge amounts of RAM. But the API is much lower-level than it needs to be.\n<\/p><\/blockquote>\n Everything in texture-mapping comes out of this quest for performance at low cost. Texture-mapping is theoretically a subset of procedural texturing – but even modern GPU’s still contain custom hardware dedicated to texture-mapping<\/strong>. This has three main effects:<\/p>\n Texturing has been added to OpenGL in fits and starts. I will try to consistently use these terms:<\/p>\n \nTexturing<\/strong>: the general concept of putting pixel-level detail – from any source! – onto geometry.<\/p>\n Texture-Mapping<\/strong>: a specific kind of Texturing that uses a source image usually but not always 2D<\/em> and maps it to a 3D geometry<\/p>\n Texture(s)<\/strong>: the “image” part of Texture-Mapping (on CPU: an image file; on GPU: an OpenGL TextureObject)\n<\/p><\/blockquote>\n Google for more info, but the essence is:<\/p>\n Texture-mapping often creates distortion of the original 2D image, unless you deliberately choose your cookie-cutter to prevent it.<\/p>\n Note that only the final step (the stretch\/squish) uses processing-power on the GPU. For the rest of it, the GPU can “cut out” the shape from the 2D image when the app starts running, and keep “stamping” it onto the triangle in each frame.<\/p>\n Also, if you zoom-in on the triangle … the texture will get more and more blocky, because the 2D image has fixed resolution.<\/p>\n This process of stretching and squashing the image until the corners match-up is mathematically known as a “map”, because each x,y co-ordinate in the image is “mapped” to a different x,y co-ordinate in the 3D-projected pixels.<\/p>\n There are two x’s and two y’s, which gets confusing. So, traditionally, the x and y co-ords in the source image<\/em> are renamed “u” and “v” – so that in code and in docs you always know which x is which. Hence the other name for Texture Mapping: “UV Mapping”.<\/p>\n Before the invention of Shaders, you had almost no influence of the mapping function – it directly mapped u\/v to x\/y according to the corner-co-ordinates you attached to the 3D geometry. With Shaders, of course … the Fragment Shader “replaces” the mapping function, and lets you do any kind of weird and funky *even animated* ‘map function’ you want.<\/p>\n There’s more to texture-mapping than meets the eye. Some of the hardware features of TextureMapping mean that you can achieve certain special effects and high performance boosts by storing 3D geometry inside special textures<\/strong>.<\/p>\n GL ES 2 supports Vertex Textures for this (textures you can access inside the Vertex Shader), but allows vendors to say “number supported = 0”. Apple used this to disable Vertex Textures on all iPhone\/iPod\/iPad’s – even though the hardware supported it. They “accidentally” enabled it for one version of iOS only (4.3), and then quickly killed it again.<\/p>\n Until now. iOS7 not only adds GL ES 3 support (for the iPhone 5 only :( ), but also “re-unlocks” Vertex Textures on all devices.<\/p>\n First, make sure you fully understand the previous post on Procedural Texturing<\/a>, since TextureMapping is a special-case of that.<\/p>\n Then there are several stages to Texture-Mapping:<\/p>\n From reading that list you may already have guessed at what we’ll use to implement this technically – it’s similar but not the same as ordinary Procedural Texturing. We’ll need:<\/p>\n Items 3 and 4 above require us to attach some data to the ShaderProgram – but we don’t want to duplicate this for every Vertex (huge waste of VRAM!). So we need a way of storing some variable data on the ShaderProgram itself…<\/p>\n Uniforms are a special-case of Attribute. Where an Attribute has a separate value for every Vertex, a Uniform has the same value for every Vertex – they hold “global” data that affects the entire Draw call.<\/p>\n \nA Uniform is constant but only while executing a single Draw call<\/strong>. Each successive Draw call – even within the current Frame – can change the constant’s value.\n<\/p><\/blockquote>\n I’ll come back to this in a later post, but the typical use of Uniforms (apart from Texture Mapping) is to efficiently re-use geometry and source code. It simplifies your source (less copy\/paste code), and reduces memory usage (e.g. you can use one “copy” of a Monster on the GPU, but draw it in many different places with small changes between them (e.g. arms and legs at different positions)).<\/p>\n For now, we’re going to skim the topic lightly. A future blog post will cover them in more detail.<\/p>\n Uniforms are very similar to Attributes; just as we had to “store” all the Attributes when we linked our ShaderProgram, we must do the same with Uniforms. The code is identical, except that the method names and Constants use the text “Uniform” or “UNIFORM” instead of “Attribute\/ATTRIBUTE”.<\/p>\n I won’t go into it here, look in the GitHub source if interested. The net result is a new method on GLK2ShaderProgram:<\/p>\n GLK2ShaderProgram.h<\/em>: GLK2Uniform itself is modelled on our existing GLK2Attribute class:<\/p>\n GLK2Uniform.h<\/em>: +(GLK2Uniform*) uniformNamed:(NSString*) nameOfUniform GLType:(GLenum) openGLType GLLocation:(GLint) openGLLocation numElementsInArray:(GLint) numElements;<\/p>\n \/** The name of the variable inside the shader source file(s) *\/ @property(nonatomic) GLint glLocation; @property(nonatomic,readonly) BOOL isInteger, isFloat, isVector, isMatrix;<\/p>\n -(int) matrixWidth; @end Please note:<\/p>\n \nI have implemented NSCopying on GLK2Uniform – this is very, very useful (allows you to use them as Keys in an NSDictionary) – but easy to get wrong if you’ve not done it before in Objective-C. See the source of GLK2Uniform.m for details of the three methods<\/strong> Apple requires you to override.\n<\/p><\/blockquote>\n With Attributes, the amount of data scales up with complexity of the 3D object, and quickly becomes measured in megabytes for complex 3D levels and characters\/objects. It’s so rare to send small amounts that OpenGL only provided methods for “sending a whole load at once” – this gave us all the complexity of BufferObjects \/ VBO’s.<\/p>\n In contrast, the number of Uniforms is low – typically only a few tens per Draw call. So GL lets you set individual Uniforms with a single call:<\/p>\n \nglUniform1\/2\/3\/4\/i\/f\/v: sets a Uniform for the currently-selected ShaderProgram\n<\/p><\/blockquote>\n GL knows what the uniform is, but you still have to (over-)specify it. For Texture-Mapping, only one of those methods is used – glUniform1i – because we’re only using it to set a single “tag” (magic number) at a time.<\/p>\n \nTexture-Mapping is old<\/em>. It pre-dates VBOs, VAOs, etc – otherwise it would probably<\/em> have re-used those features. Instead, it reproduces them, with subtle differences<\/em>\n<\/p><\/blockquote>\n Today most software uses JPG, PNG, etc – but GPU’s save money by using simple hardware that doesn’t support these. So … Uploading textures to the GPU requires you to handle every low-level detail of parsing the image format and converting it into a “raw bytes” format that GL understands.<\/p>\n Lots of GL ES tutorials have you write a texture-loader that will convert e.g. PNG or UIImage into raw bytes, using arcane invocations of CALayer \/ CoreAnimation.<\/p>\n But … Apple’s already done it for you. Check out GLKit’s GLKTextureLoader<\/a> class. As Apple put it: “The GLKTextureLoader class simplifies the effort required to load your texture data.”<\/p>\n I hate texture-units. Ideally you would say to GL:<\/p>\n \n“For this Draw call, use this Texture” (I wish!<\/strong>)\n<\/p><\/blockquote>\n Unfortunately, they didn’t invent the GPU-side “Texture” object until OpenGL 1.1. OpenGL launched with a much crappier system: the TextureUnit.<\/p>\n Instead, you have to say:<\/p>\n \n“For this Draw call, take a Texture, put it in a TextureUnit. But only while rendering. When not rendering, don’t. Take a number – that is not the TextureUnit’s name, but “implies” the TextureUnit, and put it in a Shader-Uniform. In the Shader, use the Uniform in a magical way as if it’s a function (not a variable!). (I HATE TEXTURE UNITS<\/strong>)\n<\/p><\/blockquote>\n TL;DR: We need a way to assign a magic-number to the ShaderProgram, that OpenGL understands to mean a specific TextureUnit. We also have to “load” that TextureUnit with the right Texture … and repeat this before every Draw call<\/strong><\/p>\n Now we flee from the evils of TextureUnits, and zoom forwards in time by 10 years, to the advent of Shaders. Shaders do texture-mapping in a sensible and easy way.<\/p>\n Previously, to access an attribute, you simply read its value:<\/p>\n [c] On the CPU, Uniforms and Sampler2D’s are identical, and are “set” the same way: A Sampler2D is defined as a 1-dimensional integer Uniform.<\/p>\n On the GPU, “uniform” and “sampler2D” variables are again the same – except that sampler2D variables can be passed to the Shader function “texture2D(…)”, allowing it to “find and read from” the correct Texture on the GPU.<\/p>\n Shaders assume:<\/p>\n All of that is represented in Shader source code by:<\/p>\n [c] Simples.<\/p>\n First, create a new Draw call, setup 6 vertices (for 2 triangles), and setup X,Y values for our Varying (all as per last time):<\/p>\n ViewController.m<\/em>: \tdrawTexturedQuad.VAO = [[GLK2VertexArrayObject new] autorelease]; \tGLK2Attribute* attXY = [drawTexturedQuad.shaderProgram attributeNamed:@"a_virtualXY"]; Unlike OpenGL, Apple supports PNG and JPG. Grab any image file you like, and add it to your Xcode project. Then send it to the GPU. In this case, I’ve named my file “textureFile.png”:<\/p>\n \nGOTCHA: Apple hasn’t documented the formats they support. I filed a bug and got confirmation that PNG and JPG are supported – others might too, but be careful.\n<\/p><\/blockquote>\n ViewController.m<\/em>: \tNSError* error; \tNSAssert( appleTextureMetadata != nil, @"Error loading texture: %@", error); \nNB: textures can and do fail to load – and when they do, you’ll waste hours trying to trace the wrong bugs in your app. Much, much safer to put this nil check at load time, and Assert immediately if a texture failed for any reason.\n<\/p><\/blockquote>\n Done! You don’t even need to “convert” the image from the incoming file-format – Apple does all this automagically. When it works, GLKTextureLoader is a wonderful utility.<\/p>\n Apple’s texture-loader creates Textures on the GPU, but the things it returns are GLKTextureInfo<\/strong> objects. These are not “textures” themselves, but a handle that lets you access the GPU-side texture later on. This is great – but for some reason they decided to make the TextureInfo class private and non-extensible.<\/p>\n This is tragic. Every GL app needs to “create” TextureInfo objects – Apple has only implemented one out of the 5 or more different ways to upload GL texture data. I don’t mind them failing to implement those – but blocking us from implementing them in a compatible way? That’s bad.<\/p>\n So, we have to create a class that reproduces the features of GLKTextureInfo – I’ve called it GLK2Texture (which says more about how we’ll end up using it, than it does about how we use it today). For this post, we’ll simply wrap the GLKTextureInfo object, but later on we’ll use it to create our own texture-loading:<\/p>\n GLK2Texture.h<\/em>: +(GLK2Texture*) texturePreLoadedByApplesGLKit:(GLKTextureInfo*) appleMetadata;<\/p>\n \/** OpenGL uses integers as "names" instead of Strings, because Strings in C are a pain to work with, and slower *\/ \/** Creates a new, blank, OpenGL texture on the GPU.<\/p>\n If you already created a texture from some other source, use the initWithName: method instead \/** If a texture was loaded by an external source – e.g. Apple’s GLKit – you’ll already have a name for it, and can @end …so you can modify the ViewController code above, too:<\/p>\n ViewController.m<\/em>: You can’t use a texture directly, but you do have to create and manage them. TextureUnits also have to be managed, on a Draw-call-by-Draw-call basis. I went for the “least possible coding” approach – but it’s still got a lot of boilerplate code here.<\/p>\n GLK2DrawCall.m<\/em>: The number of TextureUnits is fixed and small – on most iOS devices, it’s 8. This is how many textures can be used during a single Draw call<\/strong>. You can have thousands of textures on-screen – they just have to be rendered by different Draw calls. Note that there is a significant performance cost to “switching” textures in and out of TextureUnits (this is partly why they exist – so you can optimize your switching).<\/p>\n So … we pre-create an array with exactly that many slots. Each slot “represents” a TextureUnit.<\/p>\n We also create a dictionary mapping “Uniform from Shader”<\/em> to “the Texture that the Uniform is connected to”<\/em>. For reasons we’ll come onto later, Uniforms used by TextureMapping have a different type in Shader source: “sampler2D”. So we use the term “samplers” from here on in.<\/p>\n GLK2DrawCall.m<\/em>: \t\tGLint sizeOfTextureUnitSlotsArray; \/\/ MUST be fixed size, and have an entry for every index! Next comes a big, fat, ugly chunk of boilerplate code…<\/p>\n What this will do is take a pair of “Uniform (Sampler2d)” and “Texture”, and save references to both of them in this Draw call.<\/p>\n It will also iterate across our “slots” (one per TextureUnit) until it finds one that is “empty” (i.e. not being used for a Texture on this Draw call already). If it can’t find one – you’ve tried to use too many textures, and we Assert.<\/p>\n \nNB:<\/strong> GL ridiculously uses two different incompatible ways of referencing TextureUnits – be very careful if you re-write this code manually. Pay close attention to TextureUnit name vs. TextureUnit index\n<\/p><\/blockquote>\n GLK2DrawCall.m<\/em>: \tif( texture != nil ) \t\t\tif( (id)samplerInUnitSlot != [NSNull null] && [samplerInUnitSlot isEqual:sampler]) \t\t\/** store the texture locally *\/ \t\t\/** choose a textureunit slot, if not already assigned for that sampler *\/ \t\t\t\tif( (id)samplerInUnitSlot == [NSNull null]) \t\t\t\t\t\/** Inform the embedded shader program that this slot is the new source for this sampler *\/ \t\t\t\t\tNSAssert( self.shaderProgram != nil, @"Cannot set textures on a drawcall until you’ve given it a shader program (it’s possible, but not implemented here)"); \t\t\t\t\t\/** Set the program, set the Uniform, then restore the program *\/ \t\t\tNSAssert( indexOfStoredSampler >= 0, @"Ran out of texture-units; you cannot assign this many texture samplers to a single ShaderProgram on your hardware" ); \t\treturn indexOfStoredSampler; \t\tint i=-1; \t\t\tif( (id)samplerInUnitSlot != [NSNull null] && [samplerInUnitSlot isEqual:sampler]) \t\treturn -1; -(GLint)textureUnitOffsetForSampler:(GLK2Uniform *)sampler \t\tif( (id)samplerInUnitSlot != [NSNull null] && [samplerInUnitSlot isEqual:sampler]) \treturn -1; Now we can use this method to “add” a texture to our Draw call:<\/p>\n ViewController.m<\/em>: \t\/** … store the sampler and texture in the Draw call, and configure it to use them *\/ First, we need a Varying (just as with Procedural Texturing).<\/p>\n Unlike Procedural Texturing … the values of this Varying are special, and you have to use numbers pre-ordained by the GL spec:<\/p>\n For the Vertex Shader, we’ll re-use our existing … except:<\/strong> we have to change the range of Varying values back to the original 0..1:<\/p>\n VertexTextureMappingUnprojected.vsh<\/em>: varying mediump vec2 v_virtualXY;<\/p>\n void main() The Fragment Shader needs only one line changing, we’ll make a new Shader:<\/p>\n FragmentTextureMapOnly.fsh<\/em> void main() …and use the new Shader pair in our app:<\/p>\n ViewController.m<\/em>: ViewController.m<\/em>: \t\tglActiveTexture( GL_TEXTURE0 + [drawCall textureUnitOffsetForSampler:sampler] ); \t\/** Finally: kick-off the draw-call, telling GL how to interpret the data we’ve given it (triangles, lines, points – or a variation of one of those) *\/ …which is where all that boilerplate code in GLK2DrawCall saves our butts: the “management” of the texture\/texture-unit stuff is all happening there, and our Render call remains nice and simple (as it should be).<\/p>\n iOS’s implementation of OpenGL really messes with the concept of “up”. You can Google for “OpenGL image upside down” and find many hits that explain the basic problem (OpenGL draws from y=0 at BOTTOM of screen, UIKit draws with y=0 at TOP of screen).<\/p>\n …but then you discover that UIKit *sometimes* automatically does the switch for you.<\/p>\n …and that CALayer (which UIKit uses internally) uses the OpenGL version of “up” (because it’s implemented on top of OpenGL, in fact).<\/p>\n The very very short answer is this: change the U,V numbers you attached as vertex attributes, to “flip” your texture upside down. i.e. wherever the second value is “1.0” replace it with “-1.0”.<\/p>\n If you’re finding these OpenGL ES tutorials useful, enter your email, and I’ll let you know the next time I post one. I’ll also send you some info about my current personal-project, a 3D game\/app which uses these techniques:<\/p>\n In case you hadn’t noticed, I’ve converted this series of blog posts into a complete, standalone, library and hosted it on GitHub<\/a>.<\/p>\n
\n<\/p>\nCheaper ways to texture an object<\/h2>\n
\n
What is texture-mapping?<\/h2>\n
\n
\n
…Mapping?<\/h3>\n
Vertex Textures and GL ES 2<\/h3>\n
How do you TextureMap in OpenGL?<\/h2>\n
\n
\n
\n
\n
Shader Variables: Uniforms<\/h2>\n
Compiling\/Linking Shaders: Store the Uniforms<\/h3>\n
\n[objc]
\n…
\n-(GLK2Uniform*) uniformNamed:(NSString*) name;
\n…
\n[\/objc]<\/p>\n
\n[objc]
\n@interface GLK2Uniform : NSObject <NSCopying> \/** Apple’s design of NSDictionary forces us to ‘copy’ keys, instead of mapping them *\/<\/p>\n
\n@property(nonatomic, retain) NSString* nameInSourceFile;<\/p>\n
\n@property(nonatomic) GLenum glType;
\n@property(nonatomic) GLint arrayLength;<\/p>\n
\n-(int) vectorWidth;<\/p>\n
\n[\/objc]<\/p>\nSetting the Uniform with GL calls<\/h3>\n
Creating and uploading Textures<\/h2>\n
Texture Units and … kill me now<\/h2>\n
Access a texture-map inside a Shader<\/h2>\n
\nmediump vec4 attribute positionAttribute;
\n…
\n{
\ngl_Position = positionAttribute;
\n}
\n[\/c]<\/p>\n\n
\ntexture2D( samplerForMyTexture, vec2( x, y ) ); \/\/ returns a Colour at position (x,y) inside the Texture
\n[\/c]<\/p>\nPutting it together: A TextureMap instead of a Procedural Texture<\/h2>\n
\n[objc]
\n-(NSMutableArray*) createAllDrawCalls
\n{
\n…
\n\t\/* draw a TEXTURED pair of 2 triangles onto the screen, arranged into a square ("quad")
\n\t *\/
\n\tGLK2DrawCall* drawTexturedQuad = [[GLK2DrawCall new] autorelease];
\n\tdrawTexturedQuad.numVerticesToDraw = 6;
\n…
\n\t…NB: must create ShaderProgram here, and call glUseProgram, as in previous posts
\n…
\n\tGLKVector3 cpuBufferQuad[6] =
\n\t{
\n\t\tGLKVector3Make(-0.5,-0.5, z),
\n\t\tGLKVector3Make(-0.5, 0.5, z),
\n\t\tGLKVector3Make( 0.5, 0.5, z),
\n\t\tGLKVector3Make(-0.5,-0.5, z),
\n\t\tGLKVector3Make( 0.5, 0.5, z),
\n\t\tGLKVector3Make( 0.5,-0.5, z)
\n\t};
\n\tGLKVector2 attributesVirtualXY [6] =
\n\t{
\n\t\tGLKVector2Make( 0, 0 ), \/\/ note: we vary the virtual x and y as if they were x,y co-ords on a right-angle triangle
\n\t\tGLKVector2Make( 0, 1 ),
\n\t\tGLKVector2Make( 1, 1 ),
\n\t\tGLKVector2Make( 0, 0 ), \/\/ note: we vary the virtual x and y as if they were x,y co-ords on a right-angle triangle
\n\t\tGLKVector2Make( 1, 1 ),
\n\t\tGLKVector2Make( 1, 0 )
\n\t};<\/p>\n
\n…
\n\tGLK2Attribute* attributePosition = [drawTexturedQuad.shaderProgram attributeNamed:@"position"];
\n\t[drawTexturedQuad.VAO addVBOForAttribute:attributePosition filledWithData:cpuBufferQuad bytesPerArrayElement:sizeof(GLKVector3) arrayLength:drawTexturedQuad.numVerticesToDraw];<\/p>\n
\n\t[drawTexturedQuad.VAO addVBOForAttribute:attXY filledWithData:attributesVirtualXY bytesPerArrayElement:sizeof(GLKVector2) arrayLength:drawTexturedQuad.numVerticesToDraw];
\n…
\n}
\n[\/objc]<\/p>\nPart 1: Upload a texture using GLKit<\/h3>\n
\n[objc]
\n-(NSMutableArray*) createAllDrawCalls
\n{
\n…
\n\t[drawTexturedQuad.VAO addVBOForAttribute:attXY filledWithData:attributesVirtualXY bytesPerArrayElement:sizeof(GLKVector3) arrayLength:drawTexturedQuad.numVerticesToDraw];
\n…<\/p>\n
\n\tGLKTextureInfo* appleTextureMetadata = [GLKTextureLoader textureWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"textureFile" ofType:@"png"] options:nil error:&error];<\/p>\n
\n…
\n}
\n[\/objc]<\/p>\nApple Engineering: Hmm…<\/h3>\n
\n[objc]
\n@interface GLK2Texture : NSObject<\/p>\n
\n@property(nonatomic, readonly) GLuint glName;<\/p>\n
\n *\/
\n– (id)init;<\/p>\n
\n use this method
\n *\/
\n– (id)initWithName:(GLuint) name;<\/p>\n
\n[\/objc]<\/p>\n
\n[objc]
\n…
\n\tNSAssert( appleTextureMetadata != nil, @"Error loading texture: %@", error);
\n\tGLK2Texture* texture = [[GLK2Texture texturePreLoadedByApplesGLKit:appleTextureMetadata] retain];
\n…
\n[\/objc]<\/p>\nPart 2: Modify the DrawCall to track Textures and TextureUnits<\/h2>\n
\n[objc]
\n@interface GLK2DrawCall()
\n@property(nonatomic,retain) NSMutableArray* textureUnitSlots;
\n@property(nonatomic,retain) NSMutableDictionary* texturesFromSamplers;
\n[\/objc]<\/p>\n
\n[objc]
\n…
\n-(void)dealloc
\n{
\n\tself.texturesFromSamplers = nil;
\n\tself.textureUnitSlots = nil;
\n…
\n}
\n…
\n– (id)init
\n{
\n\tself = [super init];
\n\tif (self) {
\n…
\n\t\tself.texturesFromSamplers = [NSMutableDictionary dictionary];<\/p>\n
\n\t\tglGetIntegerv( GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, &sizeOfTextureUnitSlotsArray );
\n\t\tself.textureUnitSlots = [NSMutableArray arrayWithCapacity:sizeOfTextureUnitSlotsArray];
\n\t\tfor( int i=0; i<sizeOfTextureUnitSlotsArray; i++ )
\n\t\t\t[self.textureUnitSlots addObject:[NSNull null]]; \/\/ marks this slto as "currently empty"
\n…
\n}
\n[\/objc]<\/p>\n
\n[objc]
\n…
\n-(GLuint)setTexture:(GLK2Texture *)texture forSampler:(GLK2Uniform *)sampler
\n{
\n\tNSAssert( sampler != nil, @"Cannot set a texture for non-existent sampler = nil");<\/p>\n
\n\t{
\n\t\t\/** do we already have this sampler stored? *\/
\n\t\tint indexOfStoredSampler = -1;
\n\t\tint i=-1;
\n\t\tfor( GLK2Uniform* samplerInUnitSlot in self.textureUnitSlots )
\n\t\t{
\n\t\t\ti++;<\/p>\n
\n\t\t\t{
\n\t\t\t\tindexOfStoredSampler = i;
\n\t\t\t\tbreak;
\n\t\t\t}
\n\t\t}<\/p>\n
\n\t\t[self.texturesFromSamplers setObject:texture forKey:sampler];<\/p>\n
\n\t\tif( indexOfStoredSampler < 0 )
\n\t\t{
\n\t\t\ti = -1;
\n\t\t\tfor( GLK2Uniform* samplerInUnitSlot in self.textureUnitSlots )
\n\t\t\t{
\n\t\t\t\ti++;<\/p>\n
\n\t\t\t\t{
\n\t\t\t\t\t[self.textureUnitSlots replaceObjectAtIndex:i withObject:sampler];
\n\t\t\t\t\tindexOfStoredSampler = i;<\/p>\n
\n\t\t\t\t\t\/\/ save the current program, since GL requires this magicness…
\n\t\t\t\t\tGLint currentProgram;
\n\t\t\t\t\tglGetIntegerv( GL_CURRENT_PROGRAM, ¤tProgram);<\/p>\n
\n\t\t\t\t\tGLint textureUnitOffsetOpenGLMakesThisHard = [self textureUnitOffsetForSampler:sampler];<\/p>\n
\n\t\t\t\t\tglUseProgram(self.shaderProgram.glName);
\n\t\t\t\t\tglUniform1i( sampler.glLocation, textureUnitOffsetOpenGLMakesThisHard );
\n\t\t\t\t\tglUseProgram(currentProgram);
\n\t\t\t\t\tbreak;
\n\t\t\t\t}
\n\t\t\t}<\/p>\n
\n\t\t}<\/p>\n
\n\t}
\n\telse
\n\t{
\n\t\t[self.texturesFromSamplers removeObjectForKey:sampler];<\/p>\n
\n\t\tfor( GLK2Uniform* samplerInUnitSlot in self.textureUnitSlots )
\n\t\t{
\n\t\t\ti++;<\/p>\n
\n\t\t\t{
\n\t\t\t\t[self.textureUnitSlots replaceObjectAtIndex:i withObject:[NSNull null]];
\n\t\t\t\tbreak;
\n\t\t\t}
\n\t\t}<\/p>\n
\n\t}
\n}<\/p>\n
\n{
\n\tint i=-1;
\n\tfor( GLK2Uniform* samplerInUnitSlot in self.textureUnitSlots )
\n\t{
\n\t\ti++;<\/p>\n
\n\t\t{
\n\t\t\treturn i; \/\/ NB: sometimes you need i, sometimes you need GL_TEXTURE0 + i. OpenGL API is evil. Don’t mix them up!
\n\t\t}
\n\t}<\/p>\n
\n}
\n[\/objc]<\/p>\n
\n[objc]
\n-(NSMutableArray*) createAllDrawCalls
\n{
\n…
\n\tGLK2Uniform* uniformTextureSampler = [drawTexturedQuad.shaderProgram uniformNamed:@"s_texture"];<\/p>\n
\n\t[drawTexturedQuad setTexture:texture forSampler:uniformTextureSampler];
\n…
\n}
\n[\/objc]<\/p>\nPart 3 + 4: Use the texture inside the Fragment Shader<\/h2>\n
\n
\n[c]
\nattribute vec4 position;
\nattribute vec2 a_virtualXY;<\/p>\n
\n{
\n\tv_virtualXY = a_virtualXY;
\n\tgl_Position = position;
\n}
\n[\/c]<\/p>\n
\n[c]
\nuniform sampler2D s_texture; \/\/ this name MUST match the one used for "uniformNamed:" above
\nvarying mediump vec2 v_virtualXY; \/\/ MUST match the one in Vertex Shader<\/p>\n
\n{
\n\tgl_FragColor = texture2D( s_texture, v_virtualXY );
\n}
\n[\/c]<\/p>\n
\n[objc]
\n…
\n-(NSMutableArray*) createAllDrawCalls
\n{
\n\t…this gets inserted just after we create the GLK2DrawCall itself,
\n\t…so that we have the ShaderProgram active before we try to read
\n\t…Uniforms, Samplers, etc out of it…
\n…
\n\tdrawTexturedQuad.shaderProgram = [GLK2ShaderProgram shaderProgramFromVertexFilename:@"VertexTextureMappingUnprojected" fragmentFilename:@"FragmentTextureMapOnly"];
\n\tglUseProgram( drawTexturedQuad.shaderProgram.glName );
\n…
\n}
\n[\/objc]<\/p>\nFinally: update the RenderFrame method to use Texture Mapping<\/h2>\n
\n[objc]
\n…
\n-(void) renderSingleDrawCall:(GLK2DrawCall*) drawCall
\n{
\n…
\n\tfor( GLK2Uniform* sampler in drawCall.texturesFromSamplers )
\n\t{
\n\t\tGLK2Texture* texture = [drawCall.texturesFromSamplers objectForKey:sampler];
\n\t\tNSLog(@"RENDER: Binding and enabling texture sampler ‘%@’, putting texture: %i into texture unit: %i", sampler.nameInSourceFile, texture.glName, GL_TEXTURE0 + [drawCall textureUnitOffsetForSampler:sampler] );<\/p>\n
\n\t\tglBindTexture( GL_TEXTURE_2D, texture.glName);
\n\t}<\/p>\n
\n\tglDrawArrays( GL_TRIANGLES, 0, drawCall.numVerticesToDraw );
\n}
\n[\/objc]<\/p>\nBut, but! … my texture is upside-down!<\/h3>\n
Did this post help you?<\/h3>\n
Source code…<\/h2>\n