Hot answers tagged perspective
17
Generally it is true, depending on your view point and in which direction it has moved, as well as the viewing angle.
Note how in the first camera view, as the Red block is perpendicular to the camera view, the object seems to be twice as large in a perfect 1:2 ratio (Note the arrow pointing that it hits the edge of the view after being moved twice as ...
14
I believe your intuition was correct, just not your formula.
atan(4 / 3) = 53.1301024 degrees
This ratio can be useful because it forms a Pythagorean triangle, meaning that the length of the diagonal is an exact integer value.
12
One of my favorite classic arcade games also happened to do fake 3D: Space Harrier
In that video you can see a few tricks they used, but one of the most effective visual effects is so seamless that you might not even notice it happening: when the player (or importantly the camera) moves, they use parallax to give objects in the scene a feeling of depth.
...
8
If you're going to ask the user to aim up and down, you need the player to be able to judge those up and down distances. With a static top-down camera, that is virtually impossible, and grossly unfair of you to demand of the player, no matter how you map it to controls.
If you're set on using a top-down camera, then your player character should handle ...
6
Actually that's pretty much true (if you move an object twice as far away it looks half as big) but it obscures how the visual size of objects should change as the viewers moves. Specifically, objects appear to get bigger faster the closer they are. That's because the viewer covers half the distance a lot faster when the object is close, compared to when the ...
6
An object twice as close does appear twice as big. It is a consequence of Thales's Theorem and it is true in the real world.
One could argue that Thales's Theorem is the core mathematical tool behind perspective projection and what's known in the graphics pipeline (OpenGL or DirectX) as perspective division. It a theorem you should definitely know, and ...
5
Most of these games use the famous "Mode 7" tricks. It is just a rotozoom. This operation was done by coprocessor on console so it was very fast on these hardwares. Real 3d operations were too costly. But with actual hardware, it is easier to simulate with real 3D.
A rotozoom is a rotation and a zoom on a sprite. Look this explanation or this SDL ...
4
You haven't done the division by w. Also, the [-1, 1] range after projection needs to be linearly remapped to [0, 1], not clipped. Try this:
vec4 vPosition= MVP * vec4(vVertex, 1);
vec3 vPositionDivided = vPosition.xyz / vPosition.w;
float z = vPositionDivided.z * 0.5 + 0.5;
vSmoothColor = vec4(z, z, z, 1);
gl_Position = vPosition;
Finally, Z is not ...
4
I found a fantastic review of these techniques, with examples and explanations, several years back. Your question prompted me to search for it again: Lou's Pseudo 3d Page. He used to have a working Outrun engine but removed it for some reason (the Wayback Machine if your friend here)
To further answer your question, here is a list of the games from his ...
4
All 3d games are fake 3d :P I'm joking, I know what you mean by 'fake 3d'..
Well, the 8/16bit has several examples of a very common technique of presenting the background in layers moving with different velocities, to mimic parallax. It was also very common to see.. actually, it's easier to just look at any racing game made for those consoles than ...
4
Remember one thing: Perspective projection ==== division by distance from camera. Let's say, that camera is at 0, so distance is Z coordinate of your object.
So your ball has X and Y coordinates equal to zero, it only changes the Z coordinate and you want to compute the size depending on Z. Let's say, your object is sliding between Z=100 and Z=10. First, ...
4
I think having a FoV of 90deg is what feels natural when you try to mimick 'looking through human eyes'. Your calculations would be correct if you would use the screen to simulate a window into a virtual world, not a first person perspective. Image you would have to see the world trough a 20" frame 80cm away from your head ...
3
You can't multiply the angle by the aspect ratio directly; the aspect ratio is the ratio of pixels horizontally vs. vertically, not the ratio of the angles.
To demonstrate the problem: Assume we have a window that's 100 pixels tall, and 1000 pixels wide. That's a 10:1 aspect ratio. If we have a 90 degree vertical field of view, then naively ...
3
Unless I'm misunderstanding you, this sounds like the presentation that Dwarf Fortress gives, at least from a top down perspective. Or, if you're looking for isometric, people have created visualizers for Dwarf Fortress that give that effect.
For example:
As you can see the image shows multiple layers. The user is then able to "slice" down into the land. ...
3
I think you can tell the difference from whether you have 1 or -1 in the Z line (or column depending on the matrix orientation). In particular:
Left handed: 1
Right handed: -1
For a comparison, see both of these links - D3DXMatrixPerspectiveLH and D3DXMatrixPerspectiveRH. Since DirectX is left handed, you'd normally use the left handed version which has ...
3
You are talking about doing manually something which is already done for you automatically by 3D APIs. One of the most basic functions of any 3D engine is to handle the transition from a bunch of objects in 3D space and a camera (naturally you must always have a camera) to a 2D picture (technically a projection) on the screen.
In your case, doubtless an ...
3
You do not mention a view matrix which is usually used for camera position & rotation while the projection matrix is used for zoom(FOV) & frustum params.
Although these two get combined in the end into a final "camera" matrix to render the object, I've not seen an engine where you have to maneuver the combined result... You always maneuver the view ...
2
The question is not how to implement vector graphics with modern 3D APIs like OpenGL and DirectX, since doing it is quite easy and does not require to build a vector/matrix system from scratch like those games did.
Vectors are literally just a list of numbers. Matrices are just a grid of numbers. The interesting part is the mathematics you use on them, ...
2
You are looking for vertex based 3D supporting arbitrary (unrestricted) geometries in 3D space. Raytracing in the original sense is real 3D in that it may support unlimited degrees of freedom (DoF). Raycasting (in the game development sense rather than original sense which is similar to raytracing except for the direction of rays), however, restricts degrees ...
2
The easiest way to do that is to use an orthogonal projection when rendering, but do your own perspective divide on the origin of the objects.
If you want to use a perspective project when rendering, you'll need to reverse the effects of the assumed original perspective projection used when editing, and apply the new perspective projection for the current ...
2
The camera angle used by most "isometric" games is actually 30 degrees (a true isometric view where the x, y, and z axis have the same length is 35.264 degrees). The reason for this angle is so that the width of the tile ends up being twice its height. This way you can get an even 2:1 ratio when drawing the diagonals so the tiles line up neatly without any ...
2
Use storyboards and blocked out animations to preview game play changes, both are easy to create and cheap to modify until you arrive at a solution. Movie studios call this "prefiz" and use it to save money and effort.
You can animate several new viewpoints in a day and save a week of coding.
2
One easy way - which would work for inverting any axis - is to apply the inversion function in your vertex shader, like so:
// in this example we flip the Z axis
gl_Position = (matrix * position) * vec4 (1.0, 1.0, -1.0, 1.0);
The inversion vec4 could be made a shader uniform if you want finer control.
1
I am making an assumption that you are viewing this ball from above for answering this question. Essentially, the size of the ball at a specific height depends on the viewing frustrum of your projection, and camera height relative to the ground(assuming once again that your view is pointing straight down the axis that you are using for 'vertical'). Using a ...
1
well there is ofc if you go into 3D calculations; but it sounds too me that try and error is enough. just set 2 different scales for 2 different height and interpolate. (eg. height: 0 = scale 64px; height 100 = scale 128) in case "kinda 3D" is isometric you don't need to scale it actually (but a shadow scaling on the ground might help)
1
Those formulas look crazy. Perspective projection just means dividing each object's XY position and size by its Z distance from the camera. Then you scale the resulting values to get the desired field of view. This is assuming the camera is located at the origin and the Z axis points into the screen, so do this after any camera rotation/translation has ...
1
I believe the difference between the two stems from considering the post-projective (NDC) z range to be [-1, 1] (in your first formula) and [0, 1] (in your second). OpenGL uses the former while D3D uses the latter. It's strictly a matter of convention - in OpenGL, of course, the depth buffer range eventually ends up being [0, 1] as well, but the NDC space ...
1
This might help you...
You'll need to change the camera's projection view. Normally, I don't think you use pixel values with a 3D view- unless I'm mistaken. But you can do it fairly easily in 2D:
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
glOrtho (0, XSize, YSize, 0, 0, 1);
glMatrixMode (GL_MODELVIEW);
where XSize and YSize are the screen ...
1
I wouldn't bother with heavy maths to get that ellipse's equation. Here's what I recommend:
Discretize your wireframe sphere (the usual way, using lattitude/longitude, or with a geodesic grid, or fancier). This gives you a list of 3D vertices;
Transform them to screen space with the usual model-view-projection matrix;
Then just render line segments between ...
1
Based on your camera's position and orientation, the object appearing smaller and farther away has to have a Z component value in the pre-transformed state that is less than the Z value of the closer object. Since both objects are the same height above the road, their Y component values in the pre-transformed state should be equal.
Where you convert your ...
Only top voted, non community-wiki answers of a minimum length are eligible
