Qt-interest Archive, March 2007
OpenGL Widget Newbie problem
Message 1 in thread
Dear all,
I have an application where I had set up an QGLWidget to display a number of
3D Points.
The points range in XY direction from +500 to -500 and in Z-Direction from
10 to 25mm
I am totally new to OpenGL and therefore just jused the code of a tutorial
where I printed a pyramid inside an opengl widget.
I was able to print the pyramid very well but not my 3D Points. I can only
see the points when i do a division on their value by 10 and set the
glTranslatef(0.0, 0.0, -16.0);
Can someone of you give me a hint on how i have to adapt my opengl settings
that my whole points are printed into my screen without having to bother
about the actual coordinate values?
Another thing I found is the fact, that I dont need to call updateGL to draw
my points. I thought that this is necessary everytime I want to draw
something new to the screen.
I have seen in debug mode that an event is triggered inside qt to redraw the
scene after i load in my list of points. Is this true. And why do i need an
updateGL then
Thank you very much in advance for your help.
Best regards,
Joachim
Message 2 in thread
Joachim Zettler wrote:
> Dear all,
> ...
> Can someone of you give me a hint on how i have to adapt my opengl
> settings that my whole points are printed into my screen without having
> to bother about the actual coordinate values?
Well, there is no easy way "without bothering about the actual
coordinates" - OpenGL (and any other 3D framework) is all about
coordinates, transformations, view frustums... that's the very basic
stuff of "3D math", so there's no (easy) way around to avoid it ;)
First off, some basic "viewing settings" stuff is described here (how to
move the camera, how to "zoom" etc.)
http://www.opengl.org/resources/faq/technical/viewing.htm
Think of a normal holiday day with your 20 person italian family which
you try to get all on one photo picture for the family album: everyone
is running around (glTranslate, glRotate, ...), people look into the
wrong direction (glNormal, glRotate, ...), you need to turn on your
flash (glEnable(GL_LIGHTING), glEnable(GL_LIGTH0), ...), their fancy
sport caps colour does not match the sunset colour (glColor, ...). All
normal conditions for a photographer (OpenGL programmer) ;)
So you either need
- to move the people close enough to each other (glTranslate, ...) or
- move your camera position far enough away so everyone is on the
picture (glMatrixMode(GL_MODELVIEW), glMultMatrix, gluLookAt, ....) or
- zoom away (enlarge your "view frustum", glFrustum, gluPerspective, ...)
What you basically need is a "Fit to window" approach, given a scene
(with bounding box or sphere). This is not as easy as it sounds in the
general case: you basically need to render the scene from the current
camera position as to know where everybody of your italian family is
standing *in screen coordinates*, remember the minimum and maximum x, y
screen coordinates (minX, minY, maxX, maxY) and then calculate a new
camera position, given a view frustum, so that everyone (minX, maxX,
minY, maxY) falls into this view port (or enlarge the view frustum,
that is "zoom away or in").
You could probably also solve this problem in world coordinates, given
the camera position, view frustum and 3d coordinates of each object.
That's basically some basic algebra stuff ;) (But don't ask me...!)
For an orthographic projection there's a tutorial posted in the above
link under point 8.070 which answers your exact question.
http://www.opengl.org/resources/faq/technical/viewing.htm
But remember: this is for an orthographic projection (glOrtho()), that
is all lines are parallel (well, sort of). For the more natural
perspective projection (gluPerspective()) you need another approach as
described above.
> I have seen in debug mode that an event is triggered inside qt to redraw
> the scene after i load in my list of points. Is this true. And why do i
> need an updateGL then
In your MyQGLWidget::paintGL(), you don't need to call this updateGL()
method, if this was your question. The protected method paintGL() is
automatically called by Qt whenever your widget needs to be repainted.
For example when someone else has called updateGL().
If on the other hand you have modified your *model* (or scene), for
example you added news points, moved the camera or other 3D objects then
you also need to update your *view* (or your 3D rendering, the
QGLWidget). In short: whenever you need to update the rendering, then
you call myQGLWidget->updateGL() (or have it called itself in a slot as
shown below).
// each loaded point is appended to the scene
// (better off course: pass an entire array)
MyScene::addPoint (MyPoint &point)
{
m_points->append (point);
emit sceneChanged();
}
// slot, connected to MyScene::sceneChanged()
MyQGLWidget::handleSceneChanged()
{
// the model (scene) has changed, update this view
this->updateGL();
}
Qt finally calls your MyQGLWidget::updateGL() method where you have
implemented your basic OpenGL commands which draw the points in the
"MyScene".
Hope that helps a bit. I also suggest a good book about OpenGL, "OpenGL
Programming Guide - The Official Guide to Learning OpenGL" is a
must-have if you are serious about GL programming ;)
Good luck, Oliver
--
[ signature omitted ]
Message 3 in thread
nicely said :-)
by the way, you can also read the OpenGL Redbook online:
http://www.opengl.org/documentation/red_book/
and for OpenGL online tutorials, I would recommend NeHe:
http://nehe.gamedev.net/
manu
Till Oliver Knoll wrote:
> Joachim Zettler wrote:
>> Dear all,
>> ...
>> Can someone of you give me a hint on how i have to adapt my opengl
>> settings that my whole points are printed into my screen without
>> having to bother about the actual coordinate values?
>
> Well, there is no easy way "without bothering about the actual
> coordinates" - OpenGL (and any other 3D framework) is all about
> coordinates, transformations, view frustums... that's the very basic
> stuff of "3D math", so there's no (easy) way around to avoid it ;)
>
> First off, some basic "viewing settings" stuff is described here (how to
> move the camera, how to "zoom" etc.)
>
> http://www.opengl.org/resources/faq/technical/viewing.htm
>
> Think of a normal holiday day with your 20 person italian family which
> you try to get all on one photo picture for the family album: everyone
> is running around (glTranslate, glRotate, ...), people look into the
> wrong direction (glNormal, glRotate, ...), you need to turn on your
> flash (glEnable(GL_LIGHTING), glEnable(GL_LIGTH0), ...), their fancy
> sport caps colour does not match the sunset colour (glColor, ...). All
> normal conditions for a photographer (OpenGL programmer) ;)
>
> So you either need
>
> - to move the people close enough to each other (glTranslate, ...) or
> - move your camera position far enough away so everyone is on the
> picture (glMatrixMode(GL_MODELVIEW), glMultMatrix, gluLookAt, ....) or
> - zoom away (enlarge your "view frustum", glFrustum, gluPerspective, ...)
>
> What you basically need is a "Fit to window" approach, given a scene
> (with bounding box or sphere). This is not as easy as it sounds in the
> general case: you basically need to render the scene from the current
> camera position as to know where everybody of your italian family is
> standing *in screen coordinates*, remember the minimum and maximum x, y
> screen coordinates (minX, minY, maxX, maxY) and then calculate a new
> camera position, given a view frustum, so that everyone (minX, maxX,
> minY, maxY) falls into this view port (or enlarge the view frustum,
> that is "zoom away or in").
>
> You could probably also solve this problem in world coordinates, given
> the camera position, view frustum and 3d coordinates of each object.
> That's basically some basic algebra stuff ;) (But don't ask me...!)
>
> For an orthographic projection there's a tutorial posted in the above
> link under point 8.070 which answers your exact question.
>
> http://www.opengl.org/resources/faq/technical/viewing.htm
>
> But remember: this is for an orthographic projection (glOrtho()), that
> is all lines are parallel (well, sort of). For the more natural
> perspective projection (gluPerspective()) you need another approach as
> described above.
>
>> I have seen in debug mode that an event is triggered inside qt to
>> redraw the scene after i load in my list of points. Is this true. And
>> why do i need an updateGL then
>
> In your MyQGLWidget::paintGL(), you don't need to call this updateGL()
> method, if this was your question. The protected method paintGL() is
> automatically called by Qt whenever your widget needs to be repainted.
> For example when someone else has called updateGL().
>
> If on the other hand you have modified your *model* (or scene), for
> example you added news points, moved the camera or other 3D objects then
> you also need to update your *view* (or your 3D rendering, the
> QGLWidget). In short: whenever you need to update the rendering, then
> you call myQGLWidget->updateGL() (or have it called itself in a slot as
> shown below).
>
> // each loaded point is appended to the scene
> // (better off course: pass an entire array)
> MyScene::addPoint (MyPoint &point)
> {
> m_points->append (point);
> emit sceneChanged();
> }
>
> // slot, connected to MyScene::sceneChanged()
> MyQGLWidget::handleSceneChanged()
> {
> // the model (scene) has changed, update this view
> this->updateGL();
> }
>
> Qt finally calls your MyQGLWidget::updateGL() method where you have
> implemented your basic OpenGL commands which draw the points in the
> "MyScene".
>
> Hope that helps a bit. I also suggest a good book about OpenGL, "OpenGL
> Programming Guide - The Official Guide to Learning OpenGL" is a
> must-have if you are serious about GL programming ;)
>
> Good luck, Oliver
>
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 4 in thread
Hi to Till and Manuela,
first of all thank you Till for your excellent description of my problems (I
yet dislike the Italien family a little bit but maybe this will change with
more knowledge on opengl :))
I will have a look at the tutorials and also the red book.
Thanks for your help.
Best regards,
Joachim
2007/3/14, Manuela Hutter <manuela.hutter@xxxxxx>:
>
> nicely said :-)
>
> by the way, you can also read the OpenGL Redbook online:
> http://www.opengl.org/documentation/red_book/
>
> and for OpenGL online tutorials, I would recommend NeHe:
> http://nehe.gamedev.net/
>
>
> manu
>
>
>
> Till Oliver Knoll wrote:
> > Joachim Zettler wrote:
> >> Dear all,
> >> ...
> >> Can someone of you give me a hint on how i have to adapt my opengl
> >> settings that my whole points are printed into my screen without
> >> having to bother about the actual coordinate values?
> >
> > Well, there is no easy way "without bothering about the actual
> > coordinates" - OpenGL (and any other 3D framework) is all about
> > coordinates, transformations, view frustums... that's the very basic
> > stuff of "3D math", so there's no (easy) way around to avoid it ;)
> >
> > First off, some basic "viewing settings" stuff is described here (how to
> > move the camera, how to "zoom" etc.)
> >
> > http://www.opengl.org/resources/faq/technical/viewing.htm
> >
> > Think of a normal holiday day with your 20 person italian family which
> > you try to get all on one photo picture for the family album: everyone
> > is running around (glTranslate, glRotate, ...), people look into the
> > wrong direction (glNormal, glRotate, ...), you need to turn on your
> > flash (glEnable(GL_LIGHTING), glEnable(GL_LIGTH0), ...), their fancy
> > sport caps colour does not match the sunset colour (glColor, ...). All
> > normal conditions for a photographer (OpenGL programmer) ;)
> >
> > So you either need
> >
> > - to move the people close enough to each other (glTranslate, ...) or
> > - move your camera position far enough away so everyone is on the
> > picture (glMatrixMode(GL_MODELVIEW), glMultMatrix, gluLookAt, ....) or
> > - zoom away (enlarge your "view frustum", glFrustum, gluPerspective,
> ...)
> >
> > What you basically need is a "Fit to window" approach, given a scene
> > (with bounding box or sphere). This is not as easy as it sounds in the
> > general case: you basically need to render the scene from the current
> > camera position as to know where everybody of your italian family is
> > standing *in screen coordinates*, remember the minimum and maximum x, y
> > screen coordinates (minX, minY, maxX, maxY) and then calculate a new
> > camera position, given a view frustum, so that everyone (minX, maxX,
> > minY, maxY) falls into this view port (or enlarge the view frustum,
> > that is "zoom away or in").
> >
> > You could probably also solve this problem in world coordinates, given
> > the camera position, view frustum and 3d coordinates of each object.
> > That's basically some basic algebra stuff ;) (But don't ask me...!)
> >
> > For an orthographic projection there's a tutorial posted in the above
> > link under point 8.070 which answers your exact question.
> >
> > http://www.opengl.org/resources/faq/technical/viewing.htm
> >
> > But remember: this is for an orthographic projection (glOrtho()), that
> > is all lines are parallel (well, sort of). For the more natural
> > perspective projection (gluPerspective()) you need another approach as
> > described above.
> >
> >> I have seen in debug mode that an event is triggered inside qt to
> >> redraw the scene after i load in my list of points. Is this true. And
> >> why do i need an updateGL then
> >
> > In your MyQGLWidget::paintGL(), you don't need to call this updateGL()
> > method, if this was your question. The protected method paintGL() is
> > automatically called by Qt whenever your widget needs to be repainted.
> > For example when someone else has called updateGL().
> >
> > If on the other hand you have modified your *model* (or scene), for
> > example you added news points, moved the camera or other 3D objects then
> > you also need to update your *view* (or your 3D rendering, the
> > QGLWidget). In short: whenever you need to update the rendering, then
> > you call myQGLWidget->updateGL() (or have it called itself in a slot as
> > shown below).
> >
> > // each loaded point is appended to the scene
> > // (better off course: pass an entire array)
> > MyScene::addPoint (MyPoint &point)
> > {
> > m_points->append (point);
> > emit sceneChanged();
> > }
> >
> > // slot, connected to MyScene::sceneChanged()
> > MyQGLWidget::handleSceneChanged()
> > {
> > // the model (scene) has changed, update this view
> > this->updateGL();
> > }
> >
> > Qt finally calls your MyQGLWidget::updateGL() method where you have
> > implemented your basic OpenGL commands which draw the points in the
> > "MyScene".
> >
> > Hope that helps a bit. I also suggest a good book about OpenGL, "OpenGL
> > Programming Guide - The Official Guide to Learning OpenGL" is a
> > must-have if you are serious about GL programming ;)
> >
> > Good luck, Oliver
> >
> >
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 5 in thread
Joachim Zettler wrote:
> Hi to Till and Manuela,
>
> first of all thank you Till for your excellent description of my
> problems (I yet dislike the Italien family a little bit but maybe this
> will change with more knowledge on opengl :))
Well you will love them! The Itali...err.. OpenGL might seem to be
complex (and in fact, 3D programming needs a bit more "space
imagination" and a little bit more of math understanding than other
typical programming task) at first, but once you get used to those funny
3f, 3d, 4i etc. suffixes you will realise that the API is held very
simple (given the task it implements)!
And don't be afraid of the "black void with no light with the camera
facing the wrong direction" - that's the typical "Hello 3D-World" scene
which *every* OpenGL programmer has seen at one timer or another ;)
("advanced beginners" will see a "black void with no light with the
camera facing the wrong direction, the normals turned inside and the GL
display lists uninitialised" ;)
And also note that John McClurkin is actually right, you should normally
not call updateGL() directly, but the usual update() method (which is
common to any QWidget) instead.
Like this the update of the widget is synchronised with the Qt event
queue (in fact, you can call update() multiple times in your application
logic since it merely raises a flag "needs an update", but the actual
update (rendering) is only done once, as soon as the program execution
returns to the Qt event loop).
If on the other hand you really need a forced rendering, for example
when you are in a loop and render a series of images (usually offscreen)
for an animation, then you can call updateGL() directly, which will
immediatelly render the scene. I think this is safe to do in such a case...
Cheers, Oliver
--
[ signature omitted ]
Message 6 in thread
Hi Till,
yes in fact I begin to love them :)
I have finally managed to draw my points and I can even see them.
I have now created a bounding box myself and used the data for the min and
max values to do a translation like this:
glTranslatef(-(minX+((maxX-minX)/2)),-(minY+((maxY-minY)/2)), -500);
Now I can see the Ponts directly in the middle of the screen. I wonder a
little bit why it is like this because I thought the origin is in the left
lower corner...so normally with this kind of translation i have done i
should only see the half of the points in x,y direction.
Now I want to rotate around the center of all my points (the points form a
cup more or less). As you work for autoform a "deep drawing" cup represents
it a little bit better :)
I implemented a function to rotate around with the left mouse button clicked
but unfortunately i can only rotate around the origin 0,0,0 and not around
the center of my points at minX+((maxX-minX)/2)),minY+((maxY-minY)/2)
Is there another gl function necessary to set up a new origin?
Best regards from munich,
Joachim
2007/3/14, Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx>:
>
> Joachim Zettler wrote:
> > Hi to Till and Manuela,
> >
> > first of all thank you Till for your excellent description of my
> > problems (I yet dislike the Italien family a little bit but maybe this
> > will change with more knowledge on opengl :))
>
> Well you will love them! The Itali...err.. OpenGL might seem to be
> complex (and in fact, 3D programming needs a bit more "space
> imagination" and a little bit more of math understanding than other
> typical programming task) at first, but once you get used to those funny
> 3f, 3d, 4i etc. suffixes you will realise that the API is held very
> simple (given the task it implements)!
>
> And don't be afraid of the "black void with no light with the camera
> facing the wrong direction" - that's the typical "Hello 3D-World" scene
> which *every* OpenGL programmer has seen at one timer or another ;)
> ("advanced beginners" will see a "black void with no light with the
> camera facing the wrong direction, the normals turned inside and the GL
> display lists uninitialised" ;)
>
>
> And also note that John McClurkin is actually right, you should normally
> not call updateGL() directly, but the usual update() method (which is
> common to any QWidget) instead.
>
> Like this the update of the widget is synchronised with the Qt event
> queue (in fact, you can call update() multiple times in your application
> logic since it merely raises a flag "needs an update", but the actual
> update (rendering) is only done once, as soon as the program execution
> returns to the Qt event loop).
>
> If on the other hand you really need a forced rendering, for example
> when you are in a loop and render a series of images (usually offscreen)
> for an animation, then you can call updateGL() directly, which will
> immediatelly render the scene. I think this is safe to do in such a
> case...
>
> Cheers, Oliver
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 7 in thread
Joachim Zettler wrote:
> Hi Till,
> ...
> glTranslatef(-(minX+((maxX-minX)/2)),-(minY+((maxY-minY)/2)), -500);
>
> Now I can see the Ponts directly in the middle of the screen. I wonder a
> little bit why it is like this because I thought the origin is in the
> left lower corner...so normally with this kind of translation i have
> done i should only see the half of the points in x,y direction.
Remember: OpenGL deals with different coordinate systems: don't confuse
the *screen* (or viewport) coordinate system aka Windows coordinates
(with origin in the left lower corner, as correctly stated), and the
*world* (aka model view) coordinate system, which in OpenGL is by
default a "right-handed" coordinate system IIRC (means: the z-axis
points "out of" the screen; objects with bigger z-coordinate are behind
you, and you look down the "negative z-Axis" initially).
Keeping this in mind there's another issue: are you
- moving the camera (gluLookAt)?
- or are you moving the objects (glTranslate, glRotate)?
for example when you have a unity matrix loaded on the MODEL_VIEW stack
and you do a
glTranslatef (0.0, 0.0, -5.0);
this moves the objects -5 (minus) units along the z-axis ("OpenGL
programming guide", 3rd ed., p. 117). But you could also think of the
same operation of moving the *camera* +5 (plus) units along the z-axis.
For example the following has the *same* effect (note the +5.0 (plus):
gluLookAt (0.0, 0.0, 5.0, // camera position
0.0, 0.0, 0.0, // "look at" point
0.0, 1.0, 0.0); // up-vector
But usually you should "mentally stick to one idiom": move the camera or
move the scene".
In this call:
glTranslatef(-a,-b, -500);
above I think of it as "moving the scene 'a' units to the left (in
negative x-axis direction), moving it 'b' units down (in negative y-axis
direction) and 500 units away from the camera.
Getting headache already? ;) Try some tutorials as suggested in another
post and play around with gluLookAt, glTranslate, glRotate.
I think gluLookAt is pretty intuitive to use. Mathematically it amounts
to the same work to be done whether you move the camera or the entire
scene. It's just a question of what is more natural in your specific
application.
>
> Now I want to rotate around the center of all my points (the points form
> a cup more or less). As you work for autoform a "deep drawing" cup
> represents it a little bit better :)
>
> I implemented a function to rotate around with the left mouse button
> clicked but unfortunately i can only rotate around the origin 0,0,0 and
> not around the center of my points at
> minX+((maxX-minX)/2)),minY+((maxY-minY)/2)
>
> Is there another gl function necessary to set up a new origin?
Well, gluLookAt() could be useful here: You could calculate the correct
"camera orbit" coordinate X, given the center C of the object around
which you want to rotate and the rotation radius r, do some sin/cos
calculations and place your camera there at X with gluLookAt and "look
at" point C.
"Visually the same" would also be, for example, when you would move the
scene into the origin (glTranslate) and still circle the camera around
the origin (glTranslate, glRotate).
Take a piece of paper and a pencil (most important tools for a 3D
programmer), make a few sketches and you'll get into it ;)
Cheers, Oliver
--
[ signature omitted ]
Message 8 in thread
Hi,
ok I can follow your explanation. The thing with right handed was new, now
everything concerning gltranslate is more clear to me :)
"Visually the same" would also be, for example, when you would move the
> scene into the origin (glTranslate) and still circle the camera around
> the origin (glTranslate, glRotate).
Hmm...I have problems with this way. I think for my application this would
be the easiest way (I only want to rotate around with the mouse a few times,
this is all)
So if I take my example: The points form a square and the middle is at
500,500,0. The width and height of the square is 300mm.
So I have done a gltranslate now to get the scene origin to the middle of
the square. therefore I used gltranslate(-500,-500,0)
Now it should be in the center but I can still not rotate around the middle
of the square....
Or do I now need to use the gluLookAt?
Take a piece of paper and a pencil (most important tools for a 3D
> programmer), make a few sketches and you'll get into it ;)
Yes, in fact I have done this now :) Thank you for the tips.
Best regards,
Joachim
Message 9 in thread
Joachim Zettler wrote:
> Hi,
> ...
> So I have done a gltranslate now to get the scene origin to the middle
> of the square. therefore I used gltranslate(-500,-500,0)
> Now it should be in the center but I can still not rotate around the
> middle of the square....
Off course the order of rotation/translation is imporant, as you might
remember from Algebra (M = R * T is not the same as N = T * R etc. ;)
But this is leading a bit far now for me to explain, especially it has
become very off-topic.
Read the links others and I have posted (the Nehe's tutorial is
excellent), try some basic OpenGL code and play around to get the
feeling for translations and rotations in cyberspace ;) A good book
about transformations is also always a good friend...
Cheers, Oliver
--
[ signature omitted ]
Message 10 in thread
Ok,
thank you Till.
Once again, thx for your help,
Hopefully the next time I can tell you that I made a successful picture of
the Italian family.
Best regards,
Joachim
2007/3/14, Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx>:
>
> Joachim Zettler wrote:
> > Hi,
> > ...
> > So I have done a gltranslate now to get the scene origin to the middle
> > of the square. therefore I used gltranslate(-500,-500,0)
> > Now it should be in the center but I can still not rotate around the
> > middle of the square....
>
> Off course the order of rotation/translation is imporant, as you might
> remember from Algebra (M = R * T is not the same as N = T * R etc. ;)
> But this is leading a bit far now for me to explain, especially it has
> become very off-topic.
>
> Read the links others and I have posted (the Nehe's tutorial is
> excellent), try some basic OpenGL code and play around to get the
> feeling for translations and rotations in cyberspace ;) A good book
> about transformations is also always a good friend...
>
> Cheers, Oliver
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 11 in thread
On Wed, 14 Mar 2007 15:58:22 +0100
"Joachim Zettler" <joachim.zettler@xxxxxxxxxxxxxx> wrote:
> I implemented a function to rotate around with the left mouse button
> clicked but unfortunately i can only rotate around the origin 0,0,0
> and not around the center of my points at
> minX+((maxX-minX)/2)),minY+((maxY-minY)/2)
A rotation around a point (x,y,z) can be performed by simply translate
it to the origin (-T), rotate (R) and translate it again into (x,y,z):
P' = T * R * inv(T) * P
Hope that helps!
Federico Fuga
--
[ signature omitted ]
Message 12 in thread
Hi Federico,
thank you for this information. This is exactly what I wanted to know.
Have a good time.
Best regards,
Joachim
2007/3/15, ing. Federico Fuga <fuga@xxxxxxxxxxxxxx>:
>
> On Wed, 14 Mar 2007 15:58:22 +0100
> "Joachim Zettler" <joachim.zettler@xxxxxxxxxxxxxx> wrote:
>
> > I implemented a function to rotate around with the left mouse button
> > clicked but unfortunately i can only rotate around the origin 0,0,0
> > and not around the center of my points at
> > minX+((maxX-minX)/2)),minY+((maxY-minY)/2)
>
> A rotation around a point (x,y,z) can be performed by simply translate
> it to the origin (-T), rotate (R) and translate it again into (x,y,z):
>
> P' = T * R * inv(T) * P
>
> Hope that helps!
>
> Federico Fuga
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 13 in thread
Joachim Zettler wrote:
> Dear all,
>
> I have an application where I had set up an QGLWidget to display a
> number of 3D Points.
>
> The points range in XY direction from +500 to -500 and in Z-Direction
> from 10 to 25mm
>
> I am totally new to OpenGL and therefore just jused the code of a
> tutorial where I printed a pyramid inside an opengl widget.
>
> I was able to print the pyramid very well but not my 3D Points. I can
> only see the points when i do a division on their value by 10 and set the
>
> glTranslatef(0.0, 0.0, -16.0);
The visibility of your points will depend on the positions of the near
and far clipping planes of your viewing volume and on the "camera" or
viewing position. Point that are not in the viewing volume or that are
behind the camera will not be displayed.
The default camera position is at x = 0, y = 0, and z = 0 and looks down
the negative Z axis. Thus, positive Z values will be behind the camera.
That you had to divide the Z values by 10 suggests that the original Z
values were beyond the near and/or far clipping planes.
>
> Can someone of you give me a hint on how i have to adapt my opengl
> settings that my whole points are printed into my screen without having
> to bother about the actual coordinate values?
>
> Another thing I found is the fact, that I dont need to call updateGL to
> draw my points. I thought that this is necessary everytime I want to
> draw something new to the screen.
Any time your widget needs to be updated, say from expose or resize
events, your paintGL function will be called automatically.
>
> I have seen in debug mode that an event is triggered inside qt to redraw
> the scene after i load in my list of points. Is this true. And why do i
> need an updateGL then
Don't call updateGL() function directly. Call the update() function
instead so that redraws are put into the event loop. You only need to do
this if your program makes changes to your scene after the widget is
displayed.
>
>
> Thank you very much in advance for your help.
>
> Best regards,
>
> Joachim
--
[ signature omitted ]
