Jump to content
  • Advertisement

C++ OpenGL, Translating a Sphere

Recommended Posts

45 minutes ago, Josheir said:

So, the view for the ball is determined and used for the previous terrain model too?

If you're asking whether you'd use the same view transform for both the terrain and the ball, the answer is probably yes.

In a simple environment, typically there will be a single projection transform and a single view transform. Sometimes you can have multiple projection/view transforms, e.g. for picture-in-picture effects, UI elements, specialized first-person elements like a player's hands or held items, etc. But in a typical simple scene you'd have one projection transform, one view transform, and N world transforms, for some arbitrary value N. (I think this has all been touched on in various forms by others previously.)

I don't know if this'll help, but here's an attempt at a graph showing what we're talking about:

                projection transform
                   view transform
      |                   |                  |
world transform     world transform   world transform
(e.g. terrain)        (e.g. ball)          (etc.)

In practice the world transforms can be arbitrary hierarchies, but we're just keeping it simple here.

Your focus in this thread seems to be on how to come up with an appropriate view transform, and there have been various suggestions made about that.

As has been pointed out, a view transform is typically the inverse of a world transform. It's the inverse because its purpose is not to transform geometry from local to world space, but rather to transform geometry from world to local space (that is, to camera space). So-called 'look at' functions hide these details from you in that they build a world-to-local transform for you given (usually) a position, a target, and reference up vector.

I would say that using a 'look at' function would probably be the easiest way for you to build an appropriate view transform. You know what the world up vector is, and you know what the target is (the ball position). That leaves only the camera position that you need to compute. (This isn't the only way to go about it, but I think it's a fairly straightforward way.)

I can't tell you exactly how to compute the camera position because at this point I'm still not entirely clear on what behavior you want. There have been various suggestions though, so I suspect the answer is somewhere in this thread. In any case, whatever behavior you're after, computing the camera position should only require a little vector math and/or trig (for the basic behavior at least).

Share this post

Link to post
Share on other sites
1 hour ago, Green_Baron said:

2. calculate (in world coords) a camera position, view direction and up vector. The camera can perform any gymnastics one likes, using trigonometry, inverse matrices, offsets, or simply put into place. After the calculation of the camera position, view and up vectors, calculate the view matrix (glm::lookat()).

It's one or the other. You can use either glm::lookat() to calculate your view matrix or in case you already have a world matrix for your camera object you can obtain a view matrix by inversing the world matrix.

@Josheir Have a look at the picture below. It is a visual representation of a world matrix and above you see the mathematical representation. The location is in the 4th column of the matrix. You can see colored axes (X=R, Y=G, Z=B). These can be found in the columns 1 to 3. As stated already by @Zakwayda the world matrix can be used to transform objects from model (a.k.a. object space) to world space. On the right side you see the cube in object space. Please note that the cube isn't rotated and centered at 0,0,0. By calculating the inverse of the above matrix you can convert from world to object space which is exactly what the view matrix does. The view matrix is related to your camera and nothing else so there is no view matrix for your cube. However you can still calculate the inverse matrix only that it is not called view matrix but object matrix.


Share this post

Link to post
Share on other sites

Soerensen3, your view with inversion did the trick!  Lots to learn too, thanks everyone!


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!