Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Aug 2011
Offline Last Active Jan 08 2016 08:15 PM

Topics I've Started

Banding artefacts (caused by attenuation?)

07 January 2016 - 09:40 PM

I am experiencing annoying banding artefacts on monochromic surfaces. I narrowed down the cause to the attenuation over distance to the light source. At least I think it's that, since all ambient, diffuse, specular and any other rendertarget, I made sure to be floating point, so I shouldn't loose precision. Playing around with my simple phong shading also had no effect on the banding artefacts...
This is how I calculate the attenuation, L is the not yet normalized light vector

  return 1 / (factor * max(dot(L, L), 0.0f) + 1) - g_LightCutoff;

I posted since I need some inspiration on where else to look for the possible causes, since I do want to have at least some sort of attenuation for god ol' physics sake (not that my attenuation calculation has anything to do with the physics I got tought at university smile.png)...

In a "real" scene with more interesting texturing, the banding is rather hard or even impossible to detect. It is more a conceptual matter of not having those artefacts.
Here are some images to show you what I mean. If you look closely you can see the banding on the floor and the green wall:
Attenuation and fall off from the spot light enabled
Attenuation enabled, but no fall off from the spot light
Only the phong shading

scene graph render order

02 January 2015 - 07:12 AM

Hi, like the topic states I am currently tweaking the rendering order of my scene graph.

After VFC and occlusion culling happened i'd sorted the rendering lists by the objects state changes like


1. Pipeline state (enabling/disabling depth test, blending etc)

2. gl program 

3. VBO

4. Material


I've never done a huge scene with lots and lots of different objects and I'm just wondering, if the priorities are set correctly. In this case similar materials might be sorted into seperate batches because their gl programs differ... however I thought the register cache will be flushed anyway when the gl program binding changes, won't it? I am kind of walking alone in the dark regarding what properties to cache first when rendering the objects.


Looking forward to your responses!

tree traversal of LBVH with and without stack

03 August 2014 - 05:37 AM


I have implemented a tilebased and clustered deferred shading pipeline and am currently profiling and optimizing.

I am constructing a LBVH for all the lightsources every frame from scratch.

I'm doing this like described here: http://devblogs.nvidia.com/parallelforall/thinking-parallel-part-iii-tree-construction-gpu/

In short:

(1) compute a conservative AABB for all lights

(2) calculate Morton codes for each light

(3) sort the lights along their corresponding Morton codes

(4) construct a LBVH using a sparse tree representation


This works pretty well and uses all together 1 - 1.5 ms for up to 100 000 lights.

On the other hand the traversal of the LBVH consumes lots of time, primarily because I have to do this 2 times. 1st time to calculate the number of lights in each cluster, and the 2nd time after I have partitioned my indices texture to put the actual light indices into.


I have several different implementations for the traversal...

traversal with stack: http://pastebin.com/GZnzGrPw

stackless traversal: http://pastebin.com/4NE5UqVG


there are more variants to the stackless traversal (with less texture memory access) but I think they are not relevant for the time being.


My question is now, why is the stackless traversal faster (2 times as fast!) than the one with stack, even if there are AL LOT more texture memory reads. I figured the order in which the nodes are traversed is the same.

My theory goes as follows:

GPUs utilize fast context switches to gain performance. The stack (the 32 field array) uses up a lots of registers and the context switch is actually pretty slow. Although this is pure guessing an I have no proof what so ever. 


I tried to squeeze in as much info without bloating the post, so thanks to all those who have read up to this line biggrin.png

I'm very interested in your explanations as well.


Edit: I should have told you how the tree is represented in memmory...

It's a sparse tree representation with a texture holding the 2 children for the node N at the position N

The same with the parents, the parent of Node N is found by accessing the texture at position N

glsl syntax highlight and auto completion

16 June 2014 - 01:22 PM

Yes that's right the never ending story...


I've gone through a lot now tested different editors, tools, plugins and there's always something not the way I wanted. I think most people here know what I mean.

So recently I began searching for another solution (again). I came across a pretty nice solution in a forum post from like ages.


The main idea is to let your c-compiler think that .glsl files are to be parsed as header files. Not overwhelmingly new so far. But then you can go ahead an write another include file that defines all the glsl names and symbols and you are basically done, fore the c-compiler does the rest.


I took a liking to it and spend a night long crawling the glsl reference pages copy pasting function definitions and so on. Ill gladly share the result with you: https://github.com/Wh0p/Wh0psGarbageDump

You are free to test and improve this yourself! (However, I am totally new to all this git stuff and might need some time to figure this out)


Just have a look at the example on the bottom, how it looks in Visual Studio...


Still there are some drawbacks, you have to write a preprocessor that resolves or stripps the "#include" directives from the .glsl file.

The syntax for uniform buffer is somewhat broke.


Sooo, tell me if you like/hate/ignore it, or even have a better solution to this. Personally I think I have found a solution I can be happy with (for the time being).









image1D as function parameter in glsl

14 June 2014 - 05:38 AM

Hi like the topic suggests I am trying to find a way to pass an image1D (2D or whatever) in a parameterlist of a glsl function like:

vec4 myImageLoad (in image1D tex, int pos) {...}

This is simply for convenience when i need to do some more calcularion on the texel value.


However i did not get my driver (AMD HD6950) to compile this, the error would be "missing or invalid layout qualifier"

when I use a layout qualifier like this:

vec4 myImageLoad (layout (rgba32f) in image1D paramtex, int light) {...}

The compiler suggests: "parse error on 'layout'".


Since the glwiki told me this would be possible, but didnt give a syntax example (http://www.opengl.org/wiki/Image_Load_Store#Image_variables), one of you guys might give me a hint.