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.
[QUOTE=Steven Katic;1258318]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/NvidiaGraphicsDrivers#Version_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).
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:
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/tutorials/glut-tutorial/keyboard-example-moving-around-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.[/QUOTE]