Woo-hoo, distant terrain is in the master.

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
lysol
Posts: 1401
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Woo-hoo, distant terrain is in the master.

Post by lysol » 16 Mar 2017, 07:51

AnyOldName3 wrote:No, we've now seen what happens when you're gone. You need to go away again.
But- :(
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
raevol
Posts: 3067
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Woo-hoo, distant terrain is in the master.

Post by raevol » 16 Mar 2017, 10:23

lysol wrote:
AnyOldName3 wrote:No, we've now seen what happens when you're gone. You need to go away again.
But- :(
HAHAHAHA. :lol:

User avatar
ElderTroll
Posts: 499
Joined: 25 Jan 2012, 07:01

Re: Woo-hoo, distant terrain is in the master.

Post by ElderTroll » 16 Mar 2017, 14:41

Listen, Lysol, none of us feel good about this, but with distant terrain enabled I can see 1.0 on the horizon.
Just spitballing here;
Sacrifice him to a volcano? Maybe the Volcano god is real and that'll just help propel the momentum...
Push him out on a block of ice into the arctic sea?
Get him addicted to a mmo?
Try scaring him off like a Scooby Doo villain? I'm sure it'll work for us where it failed for them.

Really awesome to see Scrawl crushing commits.
“A society grows great when old men plant trees whose shade they know they shall never sit in.”

Chris
Posts: 1574
Joined: 04 Sep 2011, 08:33

Re: Woo-hoo, distant terrain is in the master.

Post by Chris » 16 Mar 2017, 16:42

Cool to finally see this back. :) Here's hoping shadows are soon to follow.

Though I can't help but think if the distant terrain option is enabled, the viewing distance option should be ignored and instead just extend the view distance out as far as it can. Especially considering the viewing distance option is limited in the in-game UI, where accidentally touching it will revert it back to a smaller value, it serves no real purpose except to clip out the distant terrain.

User avatar
ScarecrowDM
Posts: 3
Joined: 01 Nov 2015, 19:05

Re: Woo-hoo, distant terrain is in the master.

Post by ScarecrowDM » 18 Mar 2017, 18:20

Very nice indeed.
Performance wise it is really not that bad for a beta feature.

While the water shader seems to be the real offender (ON and OFF), looks awesome.

I kind miss the fog though.
A thin fog across the horizon would be killer.

User avatar
ap0
Posts: 290
Joined: 11 Aug 2011, 18:47
Contact:

Re: Woo-hoo, distant terrain is in the master.

Post by ap0 » 18 Mar 2017, 22:52

Wonderful ♥

User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: Woo-hoo, distant terrain is in the master.

Post by wareya » 28 Mar 2017, 09:46

Playing with distant land, even set to low settings, makes the depth-based (as opposed to distance-based) fog much more obvious to me.

http://imgur.com/a/hZzai

And the default near clip of <whatever it is> makes the depth buffer have a really low granularity, causing visible zfighting between intersecting polygons on my system, I think it should be higher. This could cause problems rendering custom viewmodels, but it's a straight improvement for now. (viewmodels should be rendered with their own different near clip value in the future)

So a couple low-priority requests on the note of distant terrain:

1) Distance-based (rather than depth-based) fog, so objects don't come in/out of the fog when you rotate your view
2) Change the default near clip to 8 or something

Also, distant land alleviates this a little, but unless I can render the whole map at once it's going to be a problem; when objects come to viewing distance limit, they "pop" into existence with the fog color. I think that they should fade in from the skybox color instead, but it's not trivial to suggest that at all. This is another reason that distant static are important, so statics don't entirely pop into existence without fog at all.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

Chris
Posts: 1574
Joined: 04 Sep 2011, 08:33

Re: Woo-hoo, distant terrain is in the master.

Post by Chris » 29 Mar 2017, 01:03

wareya wrote:And the default near clip of <whatever it is> makes the depth buffer have a really low granularity, causing visible zfighting between intersecting polygons on my system, I think it should be higher.
I think switching to a logarithmic depth buffer would be more prudent. It's a little tricky to pull off in OpenGL, but using the clip control extension it is possible to use the simple "DirectX Reversed 32bit FP" trick by mapping the depth clip plane to zero-to-one instead of the default negative-one-to-one. Otherwise, there's a way to handle it using glDepthRangedNV from the NV_depth_buffer_float extension (which is apparently supported on AMD Catalyst 13.11 betav9.2 drivers too, so it's not nVidia-only). I don't know how such a thing would be handled through OSG, though.

User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: Woo-hoo, distant terrain is in the master.

Post by wareya » 29 Mar 2017, 12:43

As far as I know, it already uses a logarithmic depth buffer. The only way I can imagine this happening is if it's using a logarithmic depth buffer with a floating point format, which would make it twice logarithmic, or if it were using too low-resolution of a depth buffer, like 16-bit.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

Chris
Posts: 1574
Joined: 04 Sep 2011, 08:33

Re: Woo-hoo, distant terrain is in the master.

Post by Chris » 29 Mar 2017, 15:42

wareya wrote:As far as I know, it already uses a logarithmic depth buffer.
The depth calculation isn't very good, as the graphs on that page show. The OpenGL FAQ even notes that with a 16-bit depth buffer (which stores 65536 different values), and a near plane of 0.01 with a far plane of 1000, the closest 1/3rd of the view frustum utilizes 65534 of those values, leaving 1 bit of precision for 2/3rds of the scene depth. Using near=10 and far=1000000 is the same. Increasing the bit depth can help, but not linearly. You're just pushing the problem back by throwing more bits at it, rather than being smarter about the bits you have.

Generally speaking, you do want more precision for closer areas, so the idea of having less precision in the distance isn't bad, but the default calculation doesn't lend well to having a deep view frustum. Too much precision is packed in close to the camera if you want to have a distant view.

Post Reply