Tag Info

New answers tagged

2

The camera analogy is a lie because there is no camera. Instead all that happens is a transformation of points in 3D space to points on a 2D screen, and the matrices define how that transformation happens. Modelview and projection are conceptually different although mathematically the same (it's all just matrix multiplication). Modelview just moves points ...


8

The graphics pipeline (typically) involves transformation from model space to world space, from world space to view space, and from view space to clip space. There is a transformation matrix associated with each of these (the world, view and projection transformations, respectively). There are of course stages of the pipeline after geometry reaches clip ...


0

You answered your question well. This is exactly how it should be done for a 3D scene at least in OpenGL (not used other graphics APIs). You create your projection matrix using your FOV, aspect ratio, near and far planes and use it to render your entities, by multiplying it against each entities own model matrix. You should only need to set your projection ...


0

This is fairly easily solved with a bit of vector math. You're interested in the vector from the cannon to the event point, but you have the cannons position and the event point from origo. Adding the cannons position to the vector pointing from the cannon to the event would equal the event from origo vector. Or in other words: OrigoToEvent = ...


2

The trick here is conversion between world space and screen space. World space is the coordinate system you use for your game logic - calculations of pathing, movement, formations, etc. Your original formation code is correct for world space. Screen space is the coordinate system in which items are displayed. Because you're using an axonometric projection ...


0

How big or small are your objects? Maybe the problem is with float precision? This would explain that the problem does not occur when you are not using PPM



Top 50 recent answers are included