Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


tseval

Member Since 18 Dec 2006
Offline Last Active Nov 20 2013 09:14 AM

Topics I've Started

Shadow mapping depth buffer resolution problem

16 October 2013 - 01:21 AM

Hi,

 

I'm implementing a line-of-sight calculation shader in which I have an observer which can be dragged about on a map, and the areas visible to the observer are visualized. This is done by traditional shadow mapping where I render the 3D terrain surface in 4 directions with 90 degree frustums to produce depth maps, and then render everything from above, using the four depth maps and frustums for lookup.

 

This works fairly well as long as there is some variation in the terrain. However, on flat surfaces, the depth map doesn't have enough precision to separate the z values as they get close to the horizon. I have tried to illustrate the problem in the following figure:

 

Attached File  DepthMapPrecision.png   9.11KB   4 downloads

 

This is one of the camera frustums as viewed from the side. When the camera, C gets close to the ground, the two depth values,  Z1 and Z2 will map to the same pixel in the depth map, and only the closest one is used, causing the surface beyond this point to be visualized as invisible.

 

I know that this method will have its limitations, and that the range can't be too far, but does anyone have any ideas about how I could reduce this problem and increase the useful range of this method?

 

I have tried increasing the number of frustums up to 8 frustums with 45 degree FOV, and it helps a little bit, but not very much.

 

Cheers


Simple water rendering from various altitudes

25 November 2009 - 02:18 AM

Hi, I'm implementing a simple water shader for a terrain model. The general idea is to use a noise function or noise texture to modify the normal vectors and do bump mapping on it. Currently I have a textured terrain where the water is tagged with a special alpha value in the terrain textures, and then I add a specular highlight for water in the terrain shader. Now, one challenge here is that the water should look nice from a large span of altitudes, ie. it should look nice from a fairly close distance (walking along the water shore) as well as when flying 10km above the water. Using a simple tiling noise texture may look good very close up, but when zooming out, the repeating tiling pattern will be noticable, as well as the high frequency of the noise gets very disturbing. Any ideas how to solve this in a GLSL shader? Cheers

NvTriStrip flips triangles

15 September 2009 - 03:36 AM

Hi, I know that this particular library has been discussed earlier, and it's known to be quite buggy... However, I thought I'd check if anyone else had seen this particular issue and had a fix for it. The library in question is NVIDIAs NvTriStrip library for generating post-T&L vertex cache friendly triangle strips: http://developer.nvidia.com/object/nvtristrip_library.html My problem is that NvTriStrip from time to time will return part of a strip with reverse triangle order, so that those triangles are flipped relative to the rest. Anyone seen this? Alternatively, if there are some other libraries that does the same I could use that instead. NvTriStrip is very slow, but I usually get good results (when I don't get those flipped triangles) and I like that it returns everything stitched into one big triangle strip. Cheers

Incomplete render buffer for depth texture

06 September 2009 - 09:04 PM

Hi folks, I have a little problem with a depth texture FBO. I want to render to a depth buffer (for shadow map rendering) and use the following code to initialize the FBO. glGenTextures(1, &depth_tex_); glBindTexture(GL_TEXTURE_2D, depth_tex_); glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT24, depth_size_*num_splits_, depth_size_, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, (GLvoid*)NULL); // Set up FBO with a depth texture array as target. glGenFramebuffersEXT(1, &depth_fb_); glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, depth_fb_); // Attach texture to framebuffer depth buffer glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, depth_tex_, 0); glDrawBuffer(GL_NONE); glReadBuffer(GL_NONE); GLuint status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); This code seems to work nicely, since I get my shadows and everything. However the glCheckFrameBufferStatusEXT returns GL_FRAMEBUFFER_UNSUPPORTED_EXT on my linux computers with NVIDIA 8700 and 7950 graphics cards. On a MacBook Pro with NVIDIA 9600 it returns GL_FRAMEBUFFER_COMPLETE_EXT. As I said, the code works, even if the status check returns an error condition on linux, but I would like to know what happens here... Can anyone see what I have done wrong here, or is this a driver problem or something? Cheers

Handling huge depth range spans

18 August 2009 - 11:14 PM

Hi folks, I'm working on an indie game where the players will be able to drive and fly vehicles from the ground and all the way into space. We have a global terrain model and the visual range will be all the way to the horizon. Now, when the player moves around by foot on ground, this is OK, the far clipping plane will generally not be that far out, but when the player enters a vehicle and flies high up, we need to have the near clipping plane close enough to not clip the cockpit geometry and far enough to reach the horizon, which can be very far if we're high enough. Needless to say, this is bad for z buffer precision.... Now, we've tried splitting the scene so that we render the far objects first, then clear the z buffer and render the near objects on top. This works most of the time, but we have some cases where objects from the "far" group will stretch into the near group, typically very large objects. Then we may have smaller objects from the "near" group that should have been behind parts of the large object, but still will be rendered in front of it. I just wondered if some of you had worked with similar problems before, and if you have some clever ideas to solve the problem of huge z distance spans. Cheers

PARTNERS