How to specify BMP texture coordinates for a textured Quadric object ?

[Jean-Christophe]

Hi all,

I use a single BMP file to embed several textures
in just one file. When I draw a textured square
I set the BMP coordinates before calling vertex,
like below, and it works pretty fine.

glTexCoord2f( a , b ); // set BMP coords
glVertex3f( x, y, z ); // 3D point

Now I'm drawing textured cylinders using

gluCylinder( pQuad, b, t, h, sl, st );

Which works well with its own one and only BMP texture,
but I would like to use a texture which is a part of
the previous BMP file (holding several other textures)
and I don't know how to specify to gluCylinder the
coordinates into the BMP file to specify its texture.
( and it is the same question about gluSphere )

Can you help me on this subject please ?

[Jean-Christophe]

I found a way to do this, if anyone's interrested, here it is :

glMatrixMode(GL_TEXTURE); // select texture matrix
glPushMatrix(); // save
glLoadIdentity(); // preset
glTranslatef( x, y, 0 ); // texture offset into BMP
glScalef( sx, sy, 0 ); // rescale texture to fill cylinder
fCylinder( 0.017f, 0.17f ); // draw
glPopMatrix(); // restore
glMatrixMode(GL_MODELVIEW); // back

And it works perfectly for gluSphere() too.
Still - is there another way do do this ?



----

"Jean-Christophe" :

[Andy V]

On Monday, April 1, 2013 5:01:17 AM UTC-4, Jean-Christophe wrote:
> I found a way to do this, if anyone's interrested, here it is :
>
>
>
> glMatrixMode(GL_TEXTURE); // select texture matrix
>
> glPushMatrix(); // save
>
> glLoadIdentity(); // preset
>
> glTranslatef( x, y, 0 ); // texture offset into BMP
>
> glScalef( sx, sy, 0 ); // rescale texture to fill cylinder
>
> fCylinder( 0.017f, 0.17f ); // draw
>
> glPopMatrix(); // restore
>
> glMatrixMode(GL_MODELVIEW); // back
>
>
>
> And it works perfectly for gluSphere() too.
>
> Still - is there another way do do this ?

Re-write gluSphere to have texture generation parameters.

The glu primitives are fairly simple.

--
Andy V

[Jean-Christophe]

>> Jean-Christophe :
>> (...) is there another way do do this ?

> Andy V

> Re-write gluSphere to have texture generation parameters.

Yep, but I guess that my code won't be as
efficient as gluSphere, gluCylinder, gluPartialDisk, ...

> The glu primitives are fairly simple.

Another question : is there any (reasonable) reason to avoid
the use of any of the glu* functions in an OpenGL software ?
Or are they all inside a subset of the standard OpenGL library ?
( ... and same question about aux* )

[Nobody]

On Wed, 03 Apr 2013 18:10:15 +0200, Jean-Christophe wrote:

> Another question : is there any (reasonable) reason to avoid
> the use of any of the glu* functions in an OpenGL software ?

As of OpenGL 3, GLU is deprecated. More significantly, it relies upon
deprecated OpenGL functions, so GLU functions won't work with a 3.x core
profile context.

> Or are they all inside a subset of the standard OpenGL library ?

GLU is invariably a separate library, although it was sort-of standard
prior to OpenGL 3. It isn't tied to specific graphic hardware, so you can
use a third-party GLU library if the target platform doesn't provide one
(so long as the compatibility profile is supported).

> ( ... and same question about aux* )

The "aux" library is ancient history; it was superseded by GLUT. Neither
of those were part of the OpenGL standard (or even semi-standard like
GLU).

They were created to allow the "red book" examples to be written without
needing platform-specific boilerplate code, but are too simplistic for
most "real" programs.

GUI programs would normally use either the platform's native windowing
libraries in conjunction with the glX/wgl/agl functions, or a "GL canvas"
widget in a cross-platform toolkit. Games tend to use SDL or SFML.

[Andy V]

On Wednesday, April 3, 2013 12:10:15 PM UTC-4, Jean-Christophe wrote:
> Yep, but I guess that my code won't be as
> efficient as gluSphere, gluCylinder, gluPartialDisk, ...

Why not? Start with the source code for the GLU library and
make just the minimal changes you need. GLU is not part of,
or at least isn't normally, an intrinsic part of the GL
implementation.

--
Andy V

[Andy V]

On Wednesday, April 3, 2013 2:31:46 PM UTC-4, Nobody wrote:

> GLU is invariably a separate library, although it was sort-of standard
> prior to OpenGL 3. It isn't tied to specific graphic hardware, so you can
> use a third-party GLU library if the target platform doesn't provide one
> (so long as the compatibility profile is supported).

Why "sort-of standard"? As far as I know, it was just as standard as the
OpenGL specification itself.

--
Andy V

[Nobody]

GLU was a separate standard. GLU requires OpenGL, but OpenGL doesn't
require GLU, nor is it mentioned in the OpenGL specification.

The existence of GLU alongside OpenGL was "sort-of standard". At one time,
it was reasonable to assume that any system which supported OpenGL would
also have GLU.

Nowadays, most Linux distributions package the two separately (there are
typically multiple alternative OpenGL implementations, but a single GLU
package). Windows still provides GLU as part of the OS (glu32.dll). Apple
still provides GLU but has started pushing the use of core profile
contexts, where GLU won't work.

[Jean-Christophe]

"Nobody" :

Thanks.
So I'll have to replace calls to glu*() functions by my own ones ?
I started with the useful gluLookAt() replaced by a few
calls to glRotatef() n' glTranslatef(), and it works correctly.

[Jean-Christophe]

"Andy V" :

>> Jean-Christophe wrote:
>> Yep, but I guess that my code won't be as
>> efficient as gluSphere, gluCylinder, gluPartialDisk, ...

> Why not? Start with the source code for the GLU
> library and make just the minimal changes you need.
> GLU is not part of, or at least isn't normally,
> an intrinsic part of the GL implementation.

Thanks, I just felt like kind of lazy ( now I feel better )

If I understand well, I will no more
' #include <gl\glu.h> '
and rewrite the glu*() functions I need.

[Nobody]

On Thu, 04 Apr 2013 18:34:47 +0200, Jean-Christophe wrote:

> So I'll have to replace calls to glu*() functions by my own ones ?

If you want to do without GLU, then yes.

> I started with the useful gluLookAt() replaced by a few calls to
> glRotatef() n' glTranslatef(), and it works correctly.

Note that you'll also need to replace those if you want your code to be
forward compatible with a 3.x core profile context. The standard matrices
(model-view, projection, texture, colour) are part of the fixed-function
pipeline, which is deprecated in 3.x and only available in the
compatibility profile.

With the core profile, you have to construct your own matrices and pass
them to the shader(s) as uniform variables. Programs which need to do more
than just render graphics typically needed to do this anyhow; constructing
matrices with the OpenGL functions then reading the constructed matrix
with glGet* is quite inefficient (glGet* typically causes a pipeline
stall, making it several orders of magnitude slower than other OpenGL
functions, particularly for remote GLX).

The online manual pages for 2.x contain the definitions of the matrices
constructed by the GL and GLU matrix functions.

http://www.opengl.org/sdk/docs/man2/

[Nobody]

On Thu, 04 Apr 2013 18:42:19 +0200, Jean-Christophe wrote:

> If I understand well, I will no more
> ' #include <gl\glu.h> '

That should be:

#include <GL/glu.h>

Windows doesn't care about case, or about slash versus backslash, but Unix
does.

Macs need <OpenGL/glu.h>, but that can be (and often is) fudged with a
symlink. So much code uses <GL/gl.h> etc (including the red book examples)
that the Mac's incompatibility is widely considered a bug in Apple's
implementation.

The standard itself is silent on the subject. It doesn't even specify
the C interface (technically, the "gl" prefix is part of the C interface,
not OpenGL itself).

[Jean-Christophe]

"Nobody" :

Thanks again for all this information.
I really hope that it will be possible to
keep using glRotatef() n' glTranslatef() etc ...
because I already wrote about 30 software,
each with ~ 10 souces files in C, and I'd be
disapointed if I have to re-write all the stuff !

I have GL v1.1 and compiler Visual C 6.0
I know this is old (and maybe even odd)
but I'm just having a LOT of fun writing
some 3D software for myself, there is no
professionnal nor distribution involved.

Chess on a 8x8x8 board:
http://powerdown.free.fr/io/e/

Molecule builder and viewer:
http://powerdown.free.fr/io/m/

One of these days I'll start an OpenGL
version for 3D view of electronic signals:
http://powerdown.free.fr/io/s/11.png

And (maybe) a schematics & PCB designer:
http://powerdown.free.fr/io/b/