Still puzzled on translated projection

in Projection-matrix doesn’t work

@GameGuru sets up a 120 fov projection-matrix and then translates it (0,0,-1).
The use of the matrix strongly distorts or mis-represents some of 4 cubes on the screen. I’ll try to rearrange the appearantly faul order of the two matrixes to see if it’s the same transform as a
projection * LookAt( (0,0,0) , (0,0,1) )
A matrix as a pose as a direction + a position suggests the LookAt() to be a simple translation from (0,0,0)->(0,0,1), looking down -z … the inverse operation of the translation used on the projection.
translate * projection ==? invers_translate * projection
From faint recollection, this is probably true.

I then looked at the numbers he uses for the data. The ‘eye’ is 1 away from a 0.4 high cube. That’s fair to expect to be drawn properly, and it is.
The upper, most distal cube has a corner a radial distance 2 away, and an eye-angle slightly under 60 deg (from forward), which makes it just pass into the projection-pyramid. The distal cube has same /size/ as the others in proper accordance with the division happens on the z that they share. Had a lense been used, it would probably has had the proper size of half of the closest since it’s radially twice as far away.

So, what’s the ‘take home’?
If it had been a ‘real’ situation, the viewer would only catch a vague impression of what’s 60 degrees off the focus-direction, and it would pass largly undetected. If the viewer swings the head 60 degrees, it will conform properly, shrink in size and have oblique edges since it’s further away.
I don’t know why the visual representation manages to appear as miniatures on the screen. There is no info. For us to experience the setup, the cubes will have to be considerably larger to be 0.4 high with our noses 1 away … as I sit here, the cube should be 20 cm high, more or less matching the hight of the screen. That would have to put the distal cube well off the screen.
This not to say that it must be sat up this way, only that there may be a limit on your abillity to fool your brain … you do not, in your mind, position yourself as an ant in the screen as needed in @GameGuru’s visualisation. If you did there wouldn’t be a problem.

It would. 120° is an extremely wide-angle projection. But it’s probably much worse than that. glm::perspective follows gluPerspective, so the specified angle is for the vertical direction; the horizontal angle is usually wider. E.g. for a 16:9 aspect ratio (1920×1080), a Y FoV angle of 120° corresponds to an X FoV angle of 144°.

For comparison, a 35 mm camera with a 50 mm lens has a horizontal angle of view of around 40°, i.e. 80° X FoV. And 50 mm is considered “wide angle”.

FoV angles much over 90° are rare simply because of how distorted everything looks at the edge of the screen (most people are sitting such that their distance from the monitor is more than half the width of the monitor, meaning the actual FoV is less than 90°).

For an axis-aligned cube, the ratio of the screen-space width (difference in X) of the side face to the width of the front face is equal to the tangent of the angle between the edge (between the front and side faces) and the forward direction. For a FoV less than 90° (i.e. ±45°), this will always be less than 1. At 60°, it’s ~1.73, i.e. the side face will look almost twice as wide as the front face, and at 72° it’s over 3.

Even a 90° FoV looks pretty weird if you actually focus on the geometry near the edges of the screen (normally, you try to keep whatever you’re actually looking at roughly centred), but is often necessary to avoid “blinkering” the user. Try making a ±45° cone of card/paper and attaching it to your face; you’ll find the lack of peripheral vision quite problematic (ensure any hazards have been removed from the room first).

The only example I can recall of a >90° FoV in a game are for the alien in the Alien Versus Predator series, and that’s meant to look weird. Typically it’s between 60° and 90°; 60° looks nicer (less distortion, and also allows for higher detail because the proportion of the scene inside the view frustum is less) but is annoying if you have to track moving objects (e.g. enemies) which can get up close.

darn, the danish eqvivalent of Holloween just passed … I missed my chance.

I had to look in my books for a better estimate of

ups, I made a faul equation

translate * projection ==? invers_translate * projection
should be
( @GameGuru setup ==? traditional setup)
translate * projection ==? projection * invers_translate

the closest thing I can find is, for matrices A,B,C
A * B == B * C
is true if B is invertible and C is a diagonal-Matrix. B as the projection is not obviously invertible as rotates or translates are, and C is not a diagonal-matrix. So, in itself the setup of the matrix could well be gibberish. I should add: I don’t blame @GameGuru for his way of thinking in translating the projection.