• Create Account

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a \$50 Amazon gift card. Click here to get started!

# _Slin_

Member Since 11 Feb 2013
Offline Last Active Dec 16 2014 06:56 PM

### Frustum Culling

13 May 2013 - 03:09 AM

I want to do some basic view frustum culling, using bounding spheres for my objects.

The spheres are positioned in world space and I am constructing planes for my frustum.

I then calculate the distance between my spheres centers and each plane and if it is bigger than the radius and on the wrong side, the object is culled. This can be optimized by first culling with a sphere around the frustum and maybe some caching for the plane that culled an object in the previous frame and generally works great. Something like this can be found easily online and is most probably good enough for most cases.

A problematic case looks like this:

where "View" is the visible area, "PL" the left plane, "PB" the bottom plane and "P" the center of the sphere to cull.

It is obviously inside the top and right plane (where ever those are) and while the point is clearly on the wrong side of PL and PB, the distance to each minus the radius is inside the both planes, but still the sphere would not be visible.

This usually shouldn´t be a problem, but I am using it to cull lights for tiled shading, so I´ve got many small frustums and many in comparison big spheres, so this is a big issue.

The solution I came up with is simple, all I do is (additional to the culling above) storing the distances to the planes and using pythagoras to get the squared distance to the frustums corner which means for example for the case above: distToPL*distToPL+distToPB*distToPB

For visibility, the result can be compared to the squared radius.

Now I am wondering if this makes sense (I am not completely sure if maybe the perspective frustum breaks it? From my understanding it shuldn´t, but that doesn´t have to mean much...) and if there is any better alternative?

### improving dynamic branching performance

12 February 2013 - 06:07 PM

I am trying to realize tiled lighting (http://www.cse.chalmers.se/~olaolss/papers/tiled_shading_preprint.pdf), my problem is that my fragment shader is extremely slow due to dynamic branching.

The fragment shader looks like this:

```#version 150
precision highp float;

uniform sampler2D mTexture0;

uniform isamplerBuffer lightListOffset;
uniform vec4 lightTileSize;

in vec2 outTexcoord;
out vec4 fragColor0;

void main()
{
fragColor0 = texture(mTexture0, outTexcoord);
vec3 light = vec3(0.1);
int tileindex = int(int(gl_FragCoord.y/lightTileSize.y)*lightTileSize.z+int(gl_FragCoord.x/lightTileSize.x));
ivec2 listoffset = texelFetch(lightListOffset, tileindex).xy;
for(int i = 0; i < listoffset.y; i++)
{
light += 0.1;
}

fragColor0.rgb *= light;
}
```

The problem is the loop which is even extremely slow if there is only one or even no iteration at all.

So my question is: What is the optimal way to provide the information for the dynamic branching to be as fast as possible?

Should the tileindex be calculated in another way? Is it a bad idea to provide the lightListOffset as a buffer texture?

I tried a couple of variations and actually this works great on my NVIDIA GeForce GT 650M, but not on the AMD Radeon HD 6770M we are also testing it on. With slow I am talking about 15fps compared to 60fps on the nvidia card, just by the existence of the loop with the dependency on the texelFetch.

Just to show what I am talking about (just very basic diffuse point lights):