Hi all! first post in a while. Nice to be back. Anyway, I'll get right down to it. I'm making what (for the purpose of this post) can be considered a model viewing program, and I'm trying to make translation work right with arcball rotation. I went through NeHe lesson 48 for arcball, and I implemented it in my own Delphi program with great success. Beautiful control style. I'd really like to avoid sounding stupid, but... What I'm trying to do is to make the entire scene translate left/right/up/down, while at the same time the center of the arcball rotation stays in the center of the screen. An example of this can be seen in the modeling program, Blender. The entire scene is rotated from the center of the screen regardless of how it has been translated. the entire scene can also be translated left/right/up/down relative to the edges of the 2d screen regardless of the angle the arcball is rotated at. This sounds like it should be VERY simple to me, but I think I'm missing something because I just can't get it to work the way I want it to. I've tried about a gazillion combinations of calls to glrotate and gltranslate...all that did was to not work right and make it look like the source code puked on the screen. BTW, since I followed the NeHe example, I never actually call glrotate...I call glMultMatrix(@RotationMatrix). I think I'm just making it more complicated than it needs to be, but my main handicap in all this is that I am insanely uncomfortable with 3d math. I have an aching suspicion that I will have to do something like projecting the mouse coordinates into the 3d scene, and doing some math to make the 2d mouse motion translate over to whatever orientation the model is in, but, uh, I can't do that because I'm not good enough at 3d math yet. I've been going through some online math refreshers, but it's obviously slow going. What I've got right now is about as simple as it can be.

gluLookAt(CamX, CamY, CamZ,
  SubjectX, SubjectY, SubjectZ,
  0, 1, 0);

glPushMatrix;

  glMultMatrix(@RotationMatrix);
  glMultMatrix(@TranslationMatrix);

  DrawScene;

glPopMatrix;

The above code actually works just fine, even for what I need to do. The problem is that it requires the user to manually input translation factors for X, Y, and Z. The mouse unfortunately can only input X and Y. I've tried searching around for a while, but to little avail. if I'm approaching this stupidly go ahead and say so, but please tell me why! thanks for lending an ear! -Langecrew-

Hi BluntMan!
Ah, I see. Thank you very much! After reading a bunch of stuff over the past couple days, that is kind-of what I was thinking I'd have to do.

I greatly appreciate your offer to post some helpful source, I'll let you know if I get stuck, Heaven forbid. Can you tell me though, when you say to project the screen coordinates, do you refer to the use of the glProject/UnProject? Or is there another way I should do it?

I've seen several examples of how to properly use the built in project/unproject functions, but I read something that bugged me. The examples I've seen hinge upon the usage of GLGetIntegerV or GLGetDoubleV to return the states of the model, viewport, and projection matricies. I remember reading once that the GLGet*V calls are a sort of "bottleneck" in the GL rendering pipeline...calls which stop rendering until the appropriate information can be returned. Do you know if this is true, or is memory just not serving me here? Furthermore, if that is true, how much of a performance hit could I really expect in the real world...I'd expect that it would probably be difficult to notice unless I render large amounts of stuff?

Also, still on the subject of GLGet calls, if what I remember is actually true, is there any good way to work around that?


Thanks a bunch, have a great day!
-Langecrew-

Quote:Original post by Langecrew
I remember reading once that the GLGet*V calls are a sort of "bottleneck" in the GL rendering pipeline...calls which stop rendering until the appropriate information can be returned. Do you know if this is true, or is memory just not serving me here?

That's almost true. It's anything that transfers data from the card to system memory that can stall the pipeline* (for example, glReadPixels and glGetTexImage). glGet* returns simple state variables which the driver will almost certainly store so it shouldn't read anything from the card itself. In an actual application you will probably have the projection/modelview matrices and viewport stored away somewhere anyway so you won't even need to call glGet*.

* The GL_ARB_pixel_buffer_object (PBO) extension can help to alleviate this stall.