The purpose of the glRotate is so that I am not looking straight down the Z axis.
The glTranslate command should result in the second set of nine points moving in relation to the first. This is not happening.
Modifying the variable "something" appears to be ineffectual.

My objective is to rotate the entire model about the center of the second VBO.
I am running Debian oldstable

KDE reports OpenGL version 2.1 Mesa 7.7.1, and GLX version 1.4 Mesa. I understand that Debian "squeeze" (most recent stable OS) has later versions, but I am having motherboard issues with squeeze. The GPU is a GeForce GT630 (Nvidia), which the vendor says supports OpenGL 4.2
From your results, it appears that I am having version problems.

Originally Posted by Steven Katic

The code you have will not achieve the description of your aim.
can you describe what you are making? what are you trying to do? whats its purpose?

Do you just want the 2 objects to be "something" units apart, and then pitch and roll your viewing of them?

It appears that youd would be using OpenGL2.1 on your system and calling fixed pipeline functions(its a much older deprecated version) but should still work with your graphics card. The fact that your graphics card supports 4.2 doesn't exclude the use of the older 2.1.

More info could help.
(1) what do you currently see when you run your program? And what can you do: pitch, roll an object?

(2)which variables are you changing: pitch and roll?
(3)Is the rotation you want like the earth rotates around the sun(orbit), or like the way your arm rotates around your shoulder(robot)
or are you using updated pitch and roll variables to give the effect of the viewer(you/your camera) rotating around? If you can tell me, I can show you how to modify you code to get the effect you desire.

(3) whats the purpose of your application? Are you just using it to learn test graphics programs concepts? (not that important, but helps)

I am writing an open source version of NASTRAN. Think of it as a CAD model undergoing computer analysis. My test file is from a real life project that has 10,000 points. My current objective is to view the model from any direction. Once in the desired orientation, the model is modified by the operator. Since it was taking two seconds to generate the model, it was suggested to me that I copy the model to a VBO, and rotate the VBO. I can then rotate the model as desired with a mouse drag. Happiness is. I can do that in real time. The code presented in this thread appears within a move() subroutine. The only problem was that the model was rotating about Z = 0 instead of the center of the model. Pan X and pan Y are working just fine, but pan Z is ineffectual.

I can get the effect that I want by subtracting center_z from each Z coordinate as I write the model to the VBO. That will work until I can get my version issues straightened out.

Thank you for your help. Now that my problem is identified, I can deal with it.

Originally Posted by Steven Katic

It appears that youd would be using OpenGL2.1 on your system and calling fixed pipeline functions(its a much older deprecated version) but should still work with your graphics card. The fact that your graphics card supports 4.2 doesn't exclude the use of the older 2.1.

More info could help.
(1) what do you currently see when you run your program? And what can you do: pitch, roll an object?

(2)which variables are you changing: pitch and roll?
(3)Is the rotation you want like the earth rotates around the sun(orbit), or like the way your arm rotates around your shoulder(robot)
or are you using updated pitch and roll variables to give the effect of the viewer(you/your camera) rotating around? If you can tell me, I can show you how to modify you code to get the effect you desire.

(3) whats the purpose of your application? Are you just using it to learn test graphics programs concepts? (not that important, but helps)

If your OS is reporting GL2.1 then you don't have your drivers properly installed. You're likely getting software-emulated GL too, which will be substantially lower-performing (and I don't mean 50% or even 25% of the performance - I mean a drop to 1 frame per second). You should fix that first.

In your code, you have a number of things that indicate you don't actually know what you're doing. Sorry to be blunt, but that's the way it is. Like the fact that you're undoing your transforms before each glPopMatrix call - that has absolutely no effect whatsoever, and shouldn't be there. I'd suggest that you need to go back and learn more about how this stuff actually works before proceeding any further with your current project.

Wow. I am mostly self taught, and my background is as a structural engineer (PE), and incidentally as a computer programmer. I have the Red Book; I should probably get a copy of the Blue Book rather than Googling individual commands.
I will take your suggestions to heart. The Red Book tells how to make something work. I can do that but, as you say, I am still on the steep part of the learning curve. Can you recommend a text that goes beyond the Red Book in terms of style?

Originally Posted by mhagain

If your OS is reporting GL2.1 then you don't have your drivers properly installed. You're likely getting software-emulated GL too, which will be substantially lower-performing (and I don't mean 50% or even 25% of the performance - I mean a drop to 1 frame per second). You should fix that first.

In your code, you have a number of things that indicate you don't actually know what you're doing. Sorry to be blunt, but that's the way it is. Like the fact that you're undoing your transforms before each glPopMatrix call - that has absolutely no effect whatsoever, and shouldn't be there. I'd suggest that you need to go back and learn more about how this stuff actually works before proceeding any further with your current project.

I am not familiar with Debian 6.0 "squeeze", Im on windows mostly (with visual studio and eclipse). But I am of the impression updating drivers is typically straight forward (on windows at least):
e.g. have you tried this: https://wiki.debian.org/NvidiaGraphi...sion_195.36.31

RE: your code.

Your first post talked about 2 widgets, with a second set of nine points, then in a later you only mention the one 10,000 point model. Hence the description of your viewing and transformation problems and aims are still not clear to me. I am used to thinking in terms of models in a 3d space(and their transformtions) and a camera/cameras for viewing(and their transformations).

RE: Redbook

I've always thought of the Redbook as the best starting point for the basic fundamentals of understanding the use of the fixed pipeline api(I used it many many moons ago). It contains clear simpe examples with clear simple explanations. In fact it was the redbook I was alluding to when I asked you whether you want the transformations to be more like an orbit or robot or a camera manipulation. For example see this section: http://www.glprogramming.com/red/chapter03.html#name8
You could/should learn how to drop the code examples from this section into your app to see them in action to reinforce understanding of the use of the api calls (Experimenting is key to learning for me [but that's my bias]).

RE:The code presented in this thread appears within a move() subroutine.

Doesn't sound good. I assumed it was your main renderScene() function (since that is fundamentally what the code actually does and especially because you are swapping the buffers at the end). I also assumed that you had an some sort of updatemovement() function as your glutKeyboardFunc() and/or glutMouseFunc where the variables roll, pitch and 'something' might be updated via user input.(suffice to say making assumptions is not good). But I don't know, you didn't answer my other questions, so you haven't helped me to help you much. That's OK. You can scan through all of chapter 3 for the viewing/camera concepts. You have to become familiar with fundamental concepts of the api calls here in order to troubleshoot the problems in your current code.

RE:Can you recommend a text that goes beyond the Red Book in terms of style?

What is your style?
There really is an enormous amount of info available on the net in countless styles. You should look at and try out as many examples as possible and do whatever else it takes that accomodates your style in order to write the few lines of code that will solve your problem. For example, I could refer you to this: http://www.lighthouse3d.com/tutorial...und-the-world/ as a different style. It gets you thinking about a camera (viewing) and handing the transformations of various models/parts.This is a good site worth looking at.The whole glut tut is here: http://www.lighthouse3d.com/tutorials/glut-tutorial/

RE: steep learning curve

If you think about, its not that steep with regard to the specific code you presented. There is only hand full of api calls you need to make to get what you want. And all you need to do is pass in the right parameters to the right functions and call the right functions in the right sequence to achieve you goal. The hardest part is clearly understanding how the results of that sequence will render out. The section of the redbook I referenced does a great job of explaining what some useful api sequences do.

But if you don't like the redbook, or the lighthouse3d stuff, I guess you will/can google for a style you prefer.

So, as long as you persist, just do what it takes, and you will achieve success.

Back to basics, I have recently learned that my push, transform and pops affect the transformation matrix, not the contents of the framebuffer. You say, "well, duh?"

Google NASTRAN for what I am attempting to accomplish. I am calling my project GNUtran. I am shooting for peer review in a year. In the mean time, all help is most appreciated.

One of my past models was all structure in the aft 105 feet of a ship. The model that I am using for testing purposes is (only) the deckhouse of a ship with the main mast and all appurtenances on the mast. X = 0.0 is the forwardmost frame that I am modeling; Y = 0.0 is the centerline of the ship; Z = 0.0 is typically the keel of the ship. The data presently resides in a three linked lists: one for vertices, one for members (lines, triangles and quadrilaterals) and one general purpose for everything else. Depending on operator preferences, the lines (structural beams) may become extruded texels. The static display is built within model(). However, periodically, the operator needs to rotate, pan, zoom to a new orientation. I stuck that within the move() routine. If the operator has a space puck, then that transformation can be achieved simultaneously. Otherwise, click on a rotate, pan or zoom icon to effect mouse action. Requiring a few seconds to regenerate the static display is no big deal. Being able to transform that model in real time with a mouse drag is really nice. Thus, during static display refresh, I am copying the vertices to a VBO, and rotating the VBO within the move() routine. If satisfying my version problems will give me at least a 4X speedup, I'll make VBOs of some of the other stuff also.
Typically, the model is constructed of elements that are members of groups and layers, and only a few groups or layers are on display at any given time. However, periodically you do have to zoom out to the entire model, reorientate, and zoom back in.

The GUI for constructing the model will end up being several thousand lines of C code.

Originally Posted by Steven Katic

Hi wmelgaard,

How you going with the opengl drivers?

I am not familiar with Debian 6.0 "squeeze", Im on windows mostly (with visual studio and eclipse). But I am of the impression updating drivers is typically straight forward (on windows at least):
e.g. have you tried this: https://wiki.debian.org/NvidiaGraphi...sion_195.36.31

RE: your code.

Your first post talked about 2 widgets, with a second set of nine points, then in a later you only mention the one 10,000 point model. Hence the description of your viewing and transformation problems and aims are still not clear to me. I am used to thinking in terms of models in a 3d space(and their transformtions) and a camera/cameras for viewing(and their transformations).

RE: Redbook

I've always thought of the Redbook as the best starting point for the basic fundamentals of understanding the use of the fixed pipeline api(I used it many many moons ago). It contains clear simpe examples with clear simple explanations. In fact it was the redbook I was alluding to when I asked you whether you want the transformations to be more like an orbit or robot or a camera manipulation. For example see this section: http://www.glprogramming.com/red/chapter03.html#name8
You could/should learn how to drop the code examples from this section into your app to see them in action to reinforce understanding of the use of the api calls (Experimenting is key to learning for me [but that's my bias]).

RE:The code presented in this thread appears within a move() subroutine.

Doesn't sound good. I assumed it was your main renderScene() function (since that is fundamentally what the code actually does and especially because you are swapping the buffers at the end). I also assumed that you had an some sort of updatemovement() function as your glutKeyboardFunc() and/or glutMouseFunc where the variables roll, pitch and 'something' might be updated via user input.(suffice to say making assumptions is not good). But I don't know, you didn't answer my other questions, so you haven't helped me to help you much. That's OK. You can scan through all of chapter 3 for the viewing/camera concepts. You have to become familiar with fundamental concepts of the api calls here in order to troubleshoot the problems in your current code.

RE:Can you recommend a text that goes beyond the Red Book in terms of style?

What is your style?
There really is an enormous amount of info available on the net in countless styles. You should look at and try out as many examples as possible and do whatever else it takes that accomodates your style in order to write the few lines of code that will solve your problem. For example, I could refer you to this: http://www.lighthouse3d.com/tutorial...und-the-world/ as a different style. It gets you thinking about a camera (viewing) and handing the transformations of various models/parts.This is a good site worth looking at.The whole glut tut is here: http://www.lighthouse3d.com/tutorials/glut-tutorial/

RE: steep learning curve

If you think about, its not that steep with regard to the specific code you presented. There is only hand full of api calls you need to make to get what you want. And all you need to do is pass in the right parameters to the right functions and call the right functions in the right sequence to achieve you goal. The hardest part is clearly understanding how the results of that sequence will render out. The section of the redbook I referenced does a great job of explaining what some useful api sequences do.

But if you don't like the redbook, or the lighthouse3d stuff, I guess you will/can google for a style you prefer.

So, as long as you persist, just do what it takes, and you will achieve success.