Ok, please please could somone explain this?

I just dont understand how i can do this?

I have a box, made from 6 quads. Its in a calllist so i can call it at anytime. The texturecoords are set in the calllist, and at 0,0 / 0,1 ETC.

All i want to be able to do is scale the object at runtime to what ever i want and the texture DONT stretch? Instead just stay the same size and repeat, i know the functions to do so.

Its the getting them to all stay the same whilst rescaling is the problem??


What about scaling the texture matrix ?

Thats what ive tried doing., But this is problem i am finding.

Calllist is 6 quads making a cube. So i call the cubelist in my draw loop and then when i scale the cube, i then change into texturematrix, scale the matrix to the new object scale and then go back to model matrix. Problem is, doing it that way, when you scale along say the X axis it also changes other texture scales along Z axis. Because this is trying to scale all textures the same even thought the object scale values might be different. For instance the front side of the cube might be 5 x 7 say, and the right side might be 5 x 10 so a rectangle. so now, the 2 scales values are different and so it all looks wrong.

Do you understand what i mean?

Im trying to make it so, if i scale my cube along just the Y, then it scales all the SIDES correctly. Then if i scale my cube along the Z then it only needs to scale the 2 sides, top and bottom correctly.




and see if that gives you the results you’re looking for.

thats a nice affect, and i can see how it might work, but maybe its where i am apply them actions?

Ive put them in the draw loop just after i bind a texture?

But then when i move my camera? (or the matrix) them textures move with it?? Looks kinda cool though :slight_smile: But obviously not what im after, but like i said it might be me doing it wrong?


Yes, it will move with the camera.
If that doesn’t work for you, you can scale your texture coordinates.

For example, the front of your cube lies on the X,Y plane. So, you would scale your texture coordinates by the scaling values you’ve done along the X & Y axis.

assuming your front face has the following texture coordinates (going counter-clock wise starting at the bottom left):


You would then change those texture coordinates to:


This assumes that your texture coordinates are either 0 or 1. If you are using fractional texture coordinates multiply that value by scaleX or scaleY.
Here, scaleX and scaleY are the values that you’ve used in glScalef for the x & y component respectively.

This would avoid you having to render the cube in pieces by modifying the texture matrix for each face.

I haven’t tested any of this of course, but in my head it seems like it should work.

Good luck.

Hi, thanks, this was my first attempt. But the texture coords are stored in the calllist which is crated at the start?

And i belive you cannot change the values stored in the callist? Without having to keep recreating the list? Which would be everytime i scale the object?


Since display list can contain other display lists, you could put the texture coordinates into sub-lists, and then redefine only the sub-lists. This works well for settings with a large effect (like enabling/disabling texturing, or changing global colors). But if you are changing per-vertex data, that makes for a lot of extra work for the display list dispatches (and it’s a pain to redefine so many display lists.

Instead, I suggest looking into vertex and attribute arrays (and the derivative vertex buffer objects).

See glDrawArrays.

But just for completeness, here’s an sketch of what I meant by the sublist approach.

    glVertex*() // first fixed vertex here
    glCallList(a) // this list holds the first vertex texcoord.
    glCallList(b) // this list holds tex coord for the second 
    // etc...

Scale the texture coordinates by 1/model_scale, and you may have to translate too depending on your goals and the cube origin.

P.S. I suspect what you actually need to permit free scaling and translation on all axes is texgen in eye_linear space (as suggested) with the inverse viewing matrix on the texture stack.

Thsi will give you what you need, if you are unable to formulate it with suitabel translates after the 1/scale, it’s simple really but if you struggle the texhen is a nobrainer. (you can also pre or post multiply (dunno which) a translation on the texture stack to get your initial alignment for the identity texgen on the base cube, if a vertex does not lie on the origin.