45 degree field of view (FOV)

[Mythos_Ruler]

http://trac.wildfire...changeset/10548

http://trac.wildfire....com/ticket/941

This new patch changes the field of view (FOV) for the game from 20 degrees to a more standard "3D" FOV of 45 degrees. It really does make everything feel a lot more "3D" and changes the whole look and feel of the game.

The only problem I am finding is with the mouse cursor (in-game and in Atlas). The farther away from the center of the screen the more difficult it is to select an item. This is very easy to test and confirm. I am guessing there would only need to be a few tweaks and fixes to the cursor code to fix this, but I thought I'd mention it here.

Anyway, so, this new patch makes the game view go from this, which is nearly isometric:

To this:

In the game, moving the camera, the new FOV really does add a distinctive "3D" feel to the game and gives a sense of depth and distance that wasn't present before. It takes a while to get used to, but works fabulously.

You can see it a lot better by toggling back and forth between these two tabs:

http://i.imgur.com/bOwST.jpg

http://i.imgur.com/7y2C5.jpg

[hhyloc]

Cool! The screenshot really did show off the improvements. I'm glad that alpha 8 is coming up nicely :-)

[Enrique]

I really like it!

Looks more natural and it helps to the immersion feeling IMO

[feneur]

(About that image: http://trac.wildfiregames.com/ticket/1023 )

[Pureon]

(About that image: http://trac.wildfiregames.com/ticket/1023 )

That's happening because we had to fix the way 0AD was importing prop points. Mythos and I are slowly going through and fixing any prop points now incorrectly positioned within the models.

[Mythos_Ruler]

That's happening because we had to fix the way 0AD was importing prop points. Mythos and I are slowly going through and fixing any prop points now incorrectly positioned within the models.

Yeah, but I don't see that on my local copy.

[feneur]

Yeah, but I don't see that on my local copy.

Any local/non-committed changes?

[Pureon]

Yeah, but I don't see that on my local copy.

I do, on updated svn. I'll fix

(edit: fixed)

[historic_bruno]

The only problem I am finding is with the mouse cursor (in-game and in Atlas). The farther away from the center of the screen the more difficult it is to select an item. This is very easy to test and confirm. I am guessing there would only need to be a few tweaks and fixes to the cursor code to fix this, but I thought I'd mention it here.

Hmm, this might be lingering issues with our current bounding box selection code. Are you not able to select anything, or maybe you're accidentally selecting something whose bounding box is in front of the desired object (trees seem especially bad because they are often curved but their bounding box is a large cube)? Hopefully vts' patch in #914 will fix this, I will try it tonight.

[feneur]

Hmm, this might be lingering issues with our current bounding box selection code. Are you not able to select anything, or maybe you're accidentally selecting something whose bounding box is in front of the desired object (trees seem especially bad because they are often curved but their bounding box is a large cube)? Hopefully vts' patch in #914 will fix this, I will try it tonight.

I'm not sure whether it is just the bounding box issue or something more, but it seems like you sometimes needs to click somewhat beside an object to be able to select it. I would presume it's towards the center of the screen, but when I tested the cases I noticed (or rather remember =) ) were all where I had to click to the left of the object. Not sure if that part does make any difference though =)

[Mythos_Ruler]

Hmm, this might be lingering issues with our current bounding box selection code. Are you not able to select anything, or maybe you're accidentally selecting something whose bounding box is in front of the desired object (trees seem especially bad because they are often curved but their bounding box is a large cube)? Hopefully vts' patch in #914 will fix this, I will try it tonight.

It may be related, but it is not the same thing. This issue has only arisen since the new FOV implementation yesterday. The farther from the center of the screen, the more pronounced the issue (the more difficult it is to select the object or click onto it). Anyone can test this, so I urge you to do so to see exactly what I mean yourself. This also happens in Atlas. And this is only a horizontal issue, not vertical.

[historic_bruno]

Trying to place an object in Atlas shows it much more clearly, in the corners there is a significant difference between cursor position and object position (problem with translation from screen to game coordinates?). Set the FOV back to 20 degrees in default.cfg and the problem is not really noticeable.

[Mythos_Ruler]

Trying to place an object in Atlas shows it much more clearly, in the corners there is a significant difference between cursor position and object position (problem with translation from screen to game coordinates?). Set the FOV back to 20 degrees in default.cfg and the problem is not really noticeable.

Question: Why is view.near anything greater than 1.0? I find there is clipping when zooming in if the default is used. These are my custom settings:

view.zoom.min = 50.0

view.zoom.max = 250.0

view.zoom.default = 110.0

view.near = 1.0 ; Near plane distance

view.far = 4096.0 ; Far plane distance

view.fov = 40.0 ; Field of view (degrees), lower is narrow, higher is wide

EDIT: I just tried playing again at 20 FOV and it's funny how quickly I got used to 40-45 FOV. The 20 looked weird.

[historic_bruno]

Question: Why is view.near anything greater than 1.0? I find there is clipping when zooming in if the default is used.

Not sure, 16 is the previous hard-coded value. You can change them if you find defaults that look better

[historic_bruno]

I believe I found the problem with selections. It was an intermediate calculation when converting screen coordinates to world coordinates (in order to do ray tracing from the cursor to find a point on the terrain). This error has always existed, but it was not noticeable with narrower FOV (about 1.7% error at 20 degrees FOV, compared with 10% error at 45 degrees, it gets worse the wider you go). Only the horizontal (x) coordinate was affected and you would notice it especially in the far corners of the game view. This particular calculation only depends on the game view's aspect ratio, far plane distance, and FOV, which are all fixed so moving the camera would make no difference.

The good news is we found the bug and selections will be more accurate because of it (would have only made a few pixels difference before). I'll commit a fix shortly

[Mythos_Ruler]

The good news is we found the bug and selections will be more accurate because of it (would have only made a few pixels difference before). I'll commit a fix shortly

Awesome news, man! Thanks for jumping on that!

[k776]

Now all we need is someone to figure out the bounding box bug. I'll be clicking grass, but the bounding box will be around it for a building a good 1cm away from the cursor.

Edit: Looks like the ticket mentioned earlier. http://trac.wildfiregames.com/ticket/914 (exactly like this: http://i.imgur.com/Ggl6d.jpg). It kills the game for me when I have buildings close together.

[Mythos_Ruler]

Now all we need is someone to figure out the bounding box bug. I'll be clicking grass, but the bounding box will be around it for a building a good 1cm away from the cursor.

Edit: Looks like the ticket mentioned earlier. http://trac.wildfire....com/ticket/914 (exactly like this: http://i.imgur.com/Ggl6d.jpg). It kills the game for me when I have buildings close together.

Yep. That's one of those little things that is very important.

[Ykkrosh]

Why is view.near anything greater than 1.0?

If you double view.far or reduce view.near by half, the depth buffer resolution (i.e. smallest detectable difference between distances) is reduced by half. That can cause z-fighting problems (e.g. a building's floor flickering behind the terrain since the GPU thinks they're at the same distance), especially when zoomed out, especially for users with 16-bit depth buffers (I think most (but not all) default to 24-bit instead). So view.near should be as large as possible (and view.far as small as possible) to minimise those problems, though they probably need to be changed to avoid obvious clipping.

(If it's really a problem, I suppose we could dynamically adjust the near plane so it goes further out when the camera zooms further out, to get a better balance between resolution and non-clipping, but probably better just to stick with the static settings for now.)

I believe I found the problem with selections. It was an intermediate calculation when converting screen coordinates to world coordinates (in order to do ray tracing from the cursor to find a point on the terrain).

Hmm, I thought I'd fixed a bug like that for Atlas, but it looks like it was this which wasn't the same. Thanks for finding this

[Pureon]

Should we not restrict the camera more now that the FOV has increased? On full zoom out much more of the map is visible on the horizon

[feneur]

Sweet Nice work Ben!

Now all we need is someone to figure out the bounding box bug. I'll be clicking grass, but the bounding box will be around it for a building a good 1cm away from the cursor.

Edit: Looks like the ticket mentioned earlier. http://trac.wildfiregames.com/ticket/914 (exactly like this: http://i.imgur.com/Ggl6d.jpg). It kills the game for me when I have buildings close together.

Yeah, as soon as Philip is able to review that patch and its finalized and committed selections should be a lot more accurate Alpha 8 will be great

[Mythos_Ruler]

Should we not restrict the camera more now that the FOV has increased? On full zoom out much more of the map is visible on the horizon

I've committed some tweaked camera zooms. See how those work out for you.

If you double view.far or reduce view.near by half, the depth buffer resolution (i.e. smallest detectable difference between distances) is reduced by half. That can cause z-fighting problems (e.g. a building's floor flickering behind the terrain since the GPU thinks they're at the same distance), especially when zoomed out, especially for users with 16-bit depth buffers (I think most (but not all) default to 24-bit instead). So view.near should be as large as possible (and view.far as small as possible) to minimise those problems, though they probably need to be changed to avoid obvious clipping.

The only time I had z-fighting was when I tested view.near at 0.0. I've set it at 2.0 instead of 1.0 though just in case.

[vts]

This error has always existed, but it was not noticeable with narrower FOV (about 1.7% error at 20 degrees FOV, compared with 10% error at 45 degrees, it gets worse the wider you go). Only the horizontal (x) coordinate was affected and you would notice it especially in the far corners of the game view.

Happy to hear it got fixed Inspecting the solution gave me a chuckle -- these kinds of bugs are so easy to write yet so hard to find, going back as far as ticket 99. Good thing you found it!