Welcome to the MacNN Forums.

Apocalypse · Mar 1, 2001, 11:24 AM

I bet that I could find this information if I looked for long enough but my patience isn't up to it. Can someone list the shapes that can be drawn with the built-in Cocoa OpenGL API with examples of very basic implementations? I know how to use the triangle one and the polygon one but I was wondering if there are provisions for a sphere, torus, cylinders, and other odd round shapes in the API or if we have to find some way to fake it on our own.
Also, does anyone know how to set view angles, textures (and how to make/store the textures), and opacity? I know that these are alot of questions and I probably could solve them with an evening or too of heavy sifting of the API but I am not there right now and I have been a little busy lately.

Thanks in advance,
Jeff.

parallax · Mar 1, 2001, 02:11 PM

You could use quadratics to create a sphere.

Textures are a bit more complex, but I'll try to get some explanatory source up.

For now, try http://nehe.gamedev.net/opengl.asp
. Don't read the tutorials, just download the OS X ported stuff.

tie · Mar 1, 2001, 10:01 PM

Lol, I read the post and immediately thought "nehe." You beat me to the link, parallax.

00101001 · Mar 5, 2001, 11:50 AM

HOLY CRAP!!!
i just went to that site and downloaded some of the examples...
OPENGL KICKS ASS....

just wanted to point that out

Apocalypse · Mar 12, 2001, 07:52 AM

Can someone tell me what the difference is between the "gl" methods and the "glU" methods? From what I have seen the "glU" libraries have more options and act as a sort of extension but is there anything more that has to be set up to use this or is there some other distinguishing factor I should be aware of? I am interested in using some of the cylinder and texture operations it includes so I was wondering if anyone knows more about this.

Thanks,
Jeff.

parallax · Mar 12, 2001, 08:41 AM

GL = OpenGL
GLU = OpenGL utilities
GLUT = OpenGL utility toolkit

GLUT's purpose is to make OS-independent source code (however, it is also horrendously slow).

GLU is a utility set which will make things like perspective and quadratics easier.

Apocalypse · Mar 12, 2001, 09:51 AM

Thanks, that is very halpful.

What is the best way to create things like cylinders if I don't care about making the code portable yet I want it clean and fast? I found some GLU routines that can do this rather easily (but I don't understand what the point of "GLUNewQuadric" is). Are those routines fast? If not, is there a _simple_ way of creating cyliners (and other rounded shapes) using straight GL?

parallax · Mar 12, 2001, 10:43 AM

You'd need something like
GLUquadricObj *q;

...

q = gluNewQuadric;
gluQuadricNormals(q, GLU_SMOOTH);
gluQuadricTexture(q, GL_TRUE);

...

gluCylinder(q,<bottom radius>,<top radius>,<height>,<subd ivisions (30 is good)>,<subdivisions (30 is good)&gt

;

Check http://nehe.gamedev.net/tutorials/lesson18.asp for more info.

------------------

http://gilgalad.dyndns.org/

Apocalypse · Mar 13, 2001, 02:55 PM

Damn forum being down! Went down just after I finished composing my post earlier so now that it is back up I have to retype it (this kind of thing just annoys me, that's all).

Since I really don't like using too much mixing of code (even C with Obj-C) in one app and I am big on speed efficiency I am not going to use GLUT. As it turns out, so far everything that I needed is included in GLU. You mentioned something about GLU having functions to make perspectives easier. Can you tell me what these functions are so I can research how to use them. I was planning on translating and rotating everything in the view by some set figure before drawing to get them all in the perspective that I wanted but if there is an actual function (or set thereof) that do this it would be alot easier (not to mention cleaner). Thank you for the help so far, Parallax, it has been exceptionally helpful. Now if only I can write my program by Friday and try to get it on MacAddict...

Jeff.

tie · Mar 16, 2001, 12:40 AM

Try using gluPerspective. It's easier than the gl alternatives (arghh, can't tell what they are because the Redbook is no longer online; maybe I'll have to buy a copy).

If speed of development is an issue, then I myself would use GLUT. It is very very easy to get things working, and you can use the same code for different platforms (this was useful for me because I could test my program on other hardware with better graphics cards, before everything was optimized). For instance, when I was learning OpenGL I ported a few of the tutorials on the nehe site because I thought it would be a good learning experience. But it wasn't; all I had to do was delete the Windows-specific code and it worked (once I had the libraries set up).

--

So basically what gluPerspective does is set up the camera, pointing along the z axis from the origin. gluLookat changes the position of the camera. But whichever you use, you should only need to use it once (or again when the window is resized). The functions for moving objects around are glTranslate, glRotate, and so on.

[This message has been edited by tie (edited 03-16-2001).]

Apocalypse · Mar 16, 2001, 08:00 AM

Thanks, I will play with some of their tutorials to see if I can use those to change the perspective. Other things I am more concerned with, however, are how easily GLUT can be integrated with a standard NIB. I was also wondering why the OpenGL view seems to be -1 to 1 in both X and Y directions and why making a Z value more negative doesn't cause it to appear further away. On top of that, I have been wondering about run-time. Parallax claims that GLUT is slower than the existing OpenGL routines in cocoa. Is this true? More importantly, is it noticeable. The only things that I need to learn how to do in standard GLU that I am looking into using are perspectives (and their easy manipulation), light sources (eventually with shadows), and quadratic object textures. I guess I will figure it out eventually.

Thanks for your help,
Jeff.

parallax · Mar 16, 2001, 09:25 AM

why making a Z value more negative doesn't cause it to appear further away.

Hmm?

On top of that, I have been wondering about run-time. Parallax claims that GLUT is slower than the existing OpenGL routines in cocoa. Is this true? More importantly, is it noticeable.

Just drawing, this will be unnoticeable. Using functions like glKeyboardFunc( <function> ) is undesirable for any type of game. It slows down the loop considerably.

Apocalypse · Mar 16, 2001, 09:52 AM

What do you mean about slowing down the loop? Is this a drawing/rendering loop or the actual program loop? My game is event-driven so the concept of the loop works a bit differently (but is obviously there under everything I write, but is handled by the NIB, I guess). I just need it to be able to perform fast renders of the shapes (I will be storing them in a list and just setting texture colours as I extract them from the list - like one of the nehe tutorials). I can easily fake the perspective by writing a method to perform:
glLoadIdentity();
glRotatef(/*some constant amount*/);
glTranslatef(/*some constant amount*/);
before every screen draw. The only problem that I see with this is that their will be no accurate depth perception. This problem is caused by the issue I found of Z translation not actually looking any different. Perhaps I was doing something wrong (I hope) or perhaps I am suffering from bad OpenGL hardware (Rage 128) but I doubt that. Ah well, I will poke around with more of those tutorials once I get a chance. I should be able to find out why I am having this problem with the Z. If I can't, this will be very difficult to create a realistic appearance.

Jeff.

parallax · Mar 16, 2001, 10:19 AM

Try using a mouse down, or mouse moved function that GLUT implements.
The main loop will slow down considerably.

Apocalypse · Mar 29, 2001, 09:55 AM

You've been a great help, Parallax, and I ended up fixing pretty much all of these problems so I figured that I would post a bit of a response to some of my own questions if anyone else is interested.

I was able to get the Z translation to make objects appear further away, the sensitivity for it is a little strange, that is all. Also, I found from playing with some of the NeHe tutorials that enabling the depth buffer is able to correct many layering problems itself (so drawing from back to front isn't too big a deal). For an example of this, try the crate tutorial (7, I think) without enabling the depth buffer and watch as one side is always in front, very confusing.

Also, I will use NSView Event implementation to catch mouseUp events over my view. I can use the x and y locations of the events divided by NSMaxX() to get local floating point coordinates to accurately respond to clicks. Since I have based so much of my implementation on what I learned from NeHe there is no totally escaping GLUT as I had hoped but I will offload all but a few of the initialization routines to GLU, GL, or NSView (as with the events) to speed most operations up.

Thanks for your help,
Jeff.