It always amuses me when people who have no idea what they’re talking about talk about how easy something is.Look if one single person can do this: https://www.youtube.com/watch?v=1XlriRF5ogA
Adding a slider for FOV is easy. Altering the camera matrix for the math is easy. DOOM can do it just fine in the idTech 6 engine, which is specifically designed for PC (then ported.)
I’d love to hear how someone who said it’d be easy would address alter the dynamic occlusion map. Are you going to rebake it for a higher FOV and mess with everyone else’s performance (higher draw calls?). Or are you suggesting write something that does all that math in real time? That’s not a minor piece of code, that’s a lot of really heavy math, which is why it’s baked. Or just bake it as it loads and increase the load time tenfold?
you already we see objects pop in and out of view sometimes at the edge of the screen in the Halo Ce campaign. That’s the occlusion map not expecting an HD aspect ratio.
I hope Microsoft and 343 can do the same or better.
This is not even close to the same thing. A multiplayer map is easy because it's small, performance doesn't get dragged down if occlusion isn't handled well. All this guy did was make a way to manipulate the 4x4 matrix which defines how geometry is projected in the frustum. I would also imagine that the Halo 5 engine has very complex on-the-fly dynamic binary space partitions, which all of the guns and dynamic objects will be in, so you'll never even see issues with dynamic occlusion.
Here is the problem, and it comes down to an understanding of exactly what a level is. Every engine does things differently and there are lots of special things each engines do, but the major components are the same. The level creator creates the mesh, which is the physics object. And an artists overlays some textures and places lights. Then the engine does a LOT of work on it. I'd bet about 90% of the "load time" of any given map is lighting, which obviously is all precalculated, and takes up a lot of space because it's a combination of textures and octree voxels (often called Probes.). One of the other major jobs of the engine is to break the mesh up so that it can make physics calculations easier, for this is uses a binary space partition. Another binary space partition is created for the camera, and this is the one that causes the problem.
For various positions along the way, the engine basically does some math and figures out what might be visible from certain angles and what will absolutely never be visible. This allows the real time engine to then not have to waste so much time filtering out stuff that isn't going to be drawn. The FOV of the camera, is taken into account here, so in order to have a flexible FOV, you'd have to remove limitations inflicted by the camera and always have to do way more filtering out in real time (or have multiple levels of FOV all providing different occlusion maps.)
For a real demonstration of the occlusion system, take a look at what happens when you go outside of where you were supposed to. Once you clip through the wall, the sector the camera is in doesn't change, so you can see just how limited drawing really is, and how much more, you'd have to do in order to have a wider FOV.
*Some people call this the "culling" system, but that can be ambiguous since there are lots of types of culling.