But-AnyOldName3 wrote:No, we've now seen what happens when you're gone. You need to go away again.
Woo-hoo, distant terrain is in the master.
Re: Woo-hoo, distant terrain is in the master.
Re: Woo-hoo, distant terrain is in the master.
HAHAHAHA.lysol wrote:But-AnyOldName3 wrote:No, we've now seen what happens when you're gone. You need to go away again.
- ElderTroll
- Posts: 499
- Joined: 25 Jan 2012, 07:01
Re: Woo-hoo, distant terrain is in the master.
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.
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.
Re: Woo-hoo, distant terrain is in the master.
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.
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.
- ScarecrowDM
- Posts: 3
- Joined: 01 Nov 2015, 19:05
Re: Woo-hoo, distant terrain is in the master.
Wonderful ♥
Re: Woo-hoo, distant terrain is in the master.
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.
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.
Re: Woo-hoo, distant terrain is in the master.
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.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.
Re: Woo-hoo, distant terrain is in the master.
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.
Re: Woo-hoo, distant terrain is in the master.
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.wareya wrote:As far as I know, it already uses a logarithmic depth buffer.
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.