I have a problem, I need to draw a 3D object in such a way that I can move it along the screen plane and rotate so that the angle of view is as if I always looked at it fixedly from one point.
I use the GLM library for working with matrices. I tried to use glm::ortho, but I can not operate with the z coordinate, respectively, the model does not rotate. if i use glm::perspective, then the model looks like i need only in the center of the screen. I mean, for example, the character model is depicted in the window of a game. How would you not move the window at any point on the screen, you look at the model directly, and not as if looking out of the corner.
I apologize, I do not know how to explain it in normal language, I hope it is understandable.
Related
My goal is to create an intuitive 3D manipulator to handle rotations of meshes displayed in my 3D editor, made with Qt / QML.
To do that, when the user clicks on an entity, 3 tori are spawned around the mesh, representing the euler angles the user can act on. If the user then clicks on one torus, I want him to be able to rotate the mesh by dragging the mouse. The natural way users seem to do that is by dragging the mouse around the torus in the direction they want the mesh to rotate.
I therefore need a way to know how the user is rotating his mouse. I thought of a way: when the user clicks on the torus, I retrieve the position of the center of the torus. Then, I translate this world position to its screen position. Then, I monitor the angle between the cursor of the mouse and the center of the torus. The evolution of this angle should tell me everything I need: if the angle increases clockwise, the mesh should rotate clockwise and vice versa. This solution should yield a result good enough for my application, since it won't depend on the angle of the camera, or only very minimally.
However, I can't find a way to translate a world position to its screen position with Qt. I found the function QVector3D::project(const QMatrix4x4 &modelView, const QMatrix4x4 &projection, const QRect &viewport), but its documentation is very scarce and I couldn't find anyone using it... I might have found what to feed in for the projection argument (the projectionMatrix property from QCamera, here https://doc.qt.io/qt-5/qml-qt3d-render-camera.html), but that's it. What is the modelView ? And viewport ? Is it simply QRect(0, 0, 1920, 1080) ?
If anyone have any kind of lead, it would be amazing, I can't find anything anywhere and I'm kind of losing hope now. Or maybe another, simpler, solution to my problem ? Please note that the user can also freely move the camera around the mesh, which adds in complexity.
Thanks a lot for your time, and have a nice day !
Yes, you should be able to translate from world position to screen position using the mentioned function. You are correct about the projection argument. As for the modelView argument, you should use viewMatrix property from QCamera, which is missing from the official documentation, but it works for me. The viewport parameter represents the dimensions of the part of the screen, you are projecting on. You could use QRect(0, 0, 1920, 1080) if you use full screen Full HD projection, otherwise use something like QRect(QPoint(0, 0), view->size()), where view is the wigdet or window with your 3D image. Be careful, that the resulting screen position will have y = 0 being down and positive values being above, which the opposite to usual screen coordinates.
I plan on making a game, and I want to create some background animations for said game. One of these animations is a rotating rectangle. I've looked all over, and I cannot find any form of math or logic that allows me to rotate a rectangle (SDL_Rect to be specific, but you might have already known that).
I can't figure out the math for myself, I really don't have any working code for this, so I can't show anything.
Essentially I'm looking for some type of logic that I can apply the rectangle's coordinates so that whenever the main game loop loops, it will rotate the rectangle some amount of degrees.
You can't rotate an SDL_Rect. If you look at its definition, it's made of coordinates for the top-left corner, the width and the height. There's no way to represent a rectangle with sides that aren't parallel to the coordinate system's axes.
SDL_RenderCopyEx supports drawing rotated textures, though.
I am trying to implement an overlay for a particular screen saver that I inject my application into.
This screen saver uses 3d objects and a dynamic camera.
I have camera position and direction and the 3d object positions, and the fov value, and I'd like to create an audio based overlay that adds icons to the objects.
I have the 2d overlay in place, and can successfully iterate the objects, however I can't figure how to calculate a frustum with the data I have.
Basically: how can one create a frustrum from the camera direction? Is a world to screen matrix required to create the frustum? I don't have the w2s matrix, so would that make the problem impossible to solve?
There is an excellent resource at http://web.archive.org/web/20120531231005/http://crazyjoke.free.fr/doc/3D/plane%20extraction.pdf which should explain everything you need and outlines how to extract the view frustum using the view and model matrices.
In regards to the world to screen (W2S) matrix you can calculate it on the fly by utilising a variant of the following:
ScreenPosition = (ProjectionMatrix* (ViewMatrix * WorldPosition))
Thast way you can calculate it on the fly as required.
There is also a frustum tutorial at Lighthouse aimed at frustum culling, but explaining the implementation quite nicely.
I have trouble in opengl. I want to rotate my vehicle while moving forward/backward. Here's a picture which shows exactly my problem. Effects of current code are in blue - after moving the car rotates over the starting location and not the current one. I want to have situation in red - in which my vehicle will rotate over current position and later move forward/backward correctly.
My current code:
lxr=sin(angle);
lzr=cos(angle);
xr+=speed*lxr;
zr+=speed*lzr;
totalangle+=angle
glRotatef(totalangle,0.0,1.0,0.0);
glTranslatef(0.0,0.0,xr);
drawVehicle();
You can try to call translate before rotate. glRotatef rotate view matrix and it affects on current view and also matrix glTranslatef.
From the image, I thought you are translating and then rotating, but looking at the code, I see it is not true.
So, it is obvious that you are in the drawVehicle(); function not rendering your object in the center (0,0). You need to render it in the center, rotate and then translate.
Also, your translation is bogus. You are just translating in z direction, not in y :
glTranslatef(0.0,0.0,xr);
You need to do something like this :
glRotatef(totalangle,0.0,1.0,0.0);
glTranslatef(0.0,yOffset,0.0);
drawVehicle(); // render around [0,0]
you have to move the origin of the coordinate system too, in order to rotate your car as you wish.
I have a rectangle on my window and I am trying to make this rectangle click-able by defining the area of the rectangle.
If the mouse click is inside this area, then it's a click else not.
For eg: On the window, let's assume the vertex of the rectangle is:
x = 40, y = 50; width = 200, height = 100;
So, a click will be counted when
(mouseXPos > getX()) && (mousxPos < (getX()+width)) && (mouseYPos > getY()) && (mouseYPos > getY()+height)
Now, I am doing lookAt transformation to the object by inheriting a class which has lookAt functions. Also, I am using a camera to check the different faces of the object (camera rotation). So, when the object rotates along various axes and shows different faces when the camera is used.
However, when the object moves, I would have thought the vertices of the rectangle would change. The vertices of the rectangle should also have changed on doing gluLookAt function but looks like they do not and my click-area always remains stationary at those points although the object is not there. How do I tackle this problem? How do I make my object clickable and add some mouse events on it?
If you're trying to click on 3D shapes, and you are moving the camera, I wouldn't check this in screen coordinates.
Instead, you can project the point where the user has clicked into a line in 3D space, and intersect that against the objects which can be clicked on.
GL has a function for this: gluUnproject()
If you give that function the details of your view, along with the screen point being clicked on, it can tell you where in 3D space the user has clicked. If you check a point at both the near and far planes, the line between these points can be checked against your object.
The other alternative, is some kind of ID buffer, where you render the scene off-screen, but instead of outputting shaded pixels, you output ID values for each object. The hit-test is then just a matter of reading a pixel from that buffer.
Seeing that nobody else is answering, I will give it a try. :)
Though not very experienced with opengl this seems like the expected behavior to me, and it seems like you are mixing up world coordinates with on screen coordinates.
Think of it this way, if you take a picture of a table in your living room from two different angles it will look differently, but will in both images occupy the same space in that room. The same can be said about entities when working with opengl, even though you move the camera the coordinates for the entity does not change, just the perception of it.
Now, if I'm not mistaken you can translate your world coordinates into on-screen coordinates by applying the same transformations as applied by opengl. I would suggest taking a look at this: OpenGL: projecting mouse click onto geometry
Thumbs up for the ID buffer alternative. I used it several times and it was really the right thing to do : no expensive geometry picking and a hardly-total disconnection with the underlying geometry.
Still, you can only pick the closest geometry (that is the one "visible" on the screen) and not the models that could be hidden behind. The same problem appears when dealing with translucent materials too.
One solution could be to do some ID-peeling by rendering four objects in a RGBA ID texture (I have a feeling it could be non-optimal but it's worth a shot).