#Problem with understanding transformations in modernOpenGL

41 messages · Page 1 of 1 (latest)

south ridge
#

Hello guys the following link contains code for drawing some shape and applying transformations: https://paste.ofcode.org/hGLdU8WTph43eY3rf7qy5c . This one is vertex shader: https://paste.ofcode.org/uXASEWxyrbvnBGKDYYcZYA . I don't understand how is result of this code: object that is being translated once 0.5 in x and -0.5 in y but being rotated constantly (I understand it is rotating over time). Shouldn't it be translated (0.5 x current_frame_number, -0.5 x current_frame_number, 0) and not just (0.5, -0.5, 0) since it is being translated every frame for that amount? Also why is it rotating perfectly? Shouldn't it have some problems rotating since we aren't rotating it in the origin of the world coordinate system? Wouldn't right order be translate_to_origin => rotate => translate_to_wanted_position? I am also wondering if data in VBO is getting changed when we multiply coordinates of it's vertices like this or are data that we have stored in it when defining unchanged? Are changes temporary and do they last only that single frame?

image.png
karmic cobalt
#

For the first part:
Would you expect to get a different result in every iteration of the following loop:

while(true) {
  int x = 1;
  x = x + 1;
}
```?
#

For the second part: the rotation is around the origin of the cube.

#

Nothing of this has anything to do with OpenGL, it's all about linear algebra.

#

There are no changes done to the VBO at all. You just read it from the shaders, and pass the transformed values further down the pipeline (where they will reach the rasterizer)

rocky yarrow
#

I am also wondering if data in VBO is getting changed when we multiply coordinates of it's vertices like this or are data that we have stored in it when defining unchanged? Are changes temporary and do they last only that single frame?

The VBO is const.

Every frame, a copy is made, and the transformation is applied to the copy in the shader, which then appears on screen.

south ridge
# karmic cobalt For the second part: the rotation _is_ around the origin of the cube.

Tnx that's what I was assuming was happening since it was always being translated at the same position but I still had my doubts which youve cleared nown:) . For the rotation part: we are directly modifying vertices by multiplying them with transformation matrix and thats why changes happen in local space is that what you are trying to say?

south ridge
#

I assume not since they wouldn't make something that isn't optimized, but it sounds pretty costy (espeecially if you have high poly model)

#

And also I was wondering if everytime we wanted to render object to the screen a copy was made with original vertices positions, how could I make object move in the certain direction? Would I have to have variable "distance" which is vec3 that is getting updated in every frame

south ridge
karmic cobalt
#

The cube center is already at the origin in the object space data

#

glTranslate and glRotate would work exactly the same - which shouldn't come as a surprise since they do the exact same matrix multiplication under the hood

south ridge
#

So all of the transforms are happening on object in it's local space? We have to explicitly convert those values if we wanted to move object in world space?

#

I thought that we should always translate object back to world origin in order to avoid this situation (if we rotate object away from world origin, it also gets different position since it is being rotated over origin)

#

I thought that was defualt point of rotation

#

Center of object doesn't even matter, does it? Since we are multiplying all of the vertices with transformation matrix, we don't even have to know where is object's center in world?

karmic cobalt
#

The transformations itself are just matrix multiplications. They work in whatever space you choose to apply them.

south ridge
#

So whenever I apply transformation over vertices, I am working in local space right?

karmic cobalt
#

The pivot point for standard rotation matrices is origin. So if we want to rotate the cube around its center, we need to care about where the center is.

karmic cobalt
#

Coordinate spaces are something you make up as you need them

south ridge
south ridge
karmic cobalt
#

Of course it is in the vertex data

south ridge
south ridge
karmic cobalt
#

Please note that each transformation you apply is a transformation of the object in the space it currently is an, as well as a transformation to a new coordinate space - both at the same time.

#

So you can just choose which of the two views is more convenient for the particular situation

karmic cobalt
south ridge
south ridge
south ridge
south ridge
#

So I've come to the conclusion that for most of the time (but not always) I would like to rotate object in it's local (object) space and then translate it to the world space rotated like that. Is that accomplished by just rotating it wanted amount (since by default VBO is in local space) and then multiplying it with model view matrix to translate it to the world space? Also do I have to store data about it's position and orientation in world space since every frame a copy of VBO is made

rocky yarrow
#

i think you have the right idea

#

keep in mind that camera view space is separate from world space

#

Also do I have to store data about it's position and orientation in world space since every frame a copy of VBO is made

Yes. Imagine you want to draw two objects that share the same geometry (VBO), but at different positions in the world.

You would store separate data about each object's world position, which would be used in each object's world matrix.

However, once both copies of the VBO's are transformed into world space by their respective world matrixes, you can then use the same view matrix to transform them into camera space.

south ridge
south ridge