Jump to content

  • Log In with Google      Sign In   
  • Create Account

johnchapman

Member Since 24 Nov 2009
Offline Last Active Oct 17 2014 03:01 AM

Topics I've Started

Screen Space 'Psuedo' Lens Flare

09 March 2012 - 03:56 PM

After posting in a recent topic on lens flare, I revisited my quicky implementation and made some improvements which I've outlined in a wee tutorial here. The technique is based on MJP's old blog post about Killzone 2, plus some inspiration from BF3. Here's a video of it in action:

http://www.youtube.com/watch?v=w164K5nuak8

The main issue is that the 'features' generated are just copies of the bright spots as sampled from the source image, not a function of the lens aperture as they should be. I'm interested in any cunning ideas for overcoming this problem; until then it's best kept as a subtle addition to sprite-based effects.

Deferred Rendering, Transparency & Alpha Blending

01 August 2011 - 04:55 AM

I've just posted up an overview of a technique I've been using to render transparent and alpha-blended materials in a deferred renderer. It has the slight flavour of a hack (like all deferred transparency methods, I suppose), but hopefully it'll be of some interest.

At any rate I'm keen to here your views and opinions, and to know if there are any glaringly obvious problems with the technique that I've not thought of (I have implemented it, and it does work!)

The post is here: http://www.john-chap...ntent.php?id=13

glsl vec4 attribute issue

28 June 2011 - 07:30 AM

I've been merilly rendering geometry from vertex buffers with GLSL shaders without a hitch. Recently I updated the maths code that supports my renderer; basically a vertex position (in client memory) is now 4 floats whereas it used to be 3.

I updated my shaders to expect a vec4 as vertex position input, I also updated the client-side code which calls glVertexAttribPointer() to tell OpenGL that there are 4 floats in the buffer. My most basic geometry vertex program looks like this:

#version 330 core

uniform mat4 MODELVIEWPROJ_MAT;

in vec4 _POSITION;

void main() {
	gl_Position = MODELVIEWPROJ_MAT * _POSITION;
}

This works fine. However for more complex vertex programs (with more attributes), I get either triangle soup or nothing. Here's one of the shaders in question:

#version 330 core
uniform mat4 MODELVIEW_MAT;
uniform mat4 MODELVIEWPROJ_MAT;

in vec4 _POSITION;
in vec2 _TEXCOORD;

smooth out vec3 POSITION_;
smooth out vec2 TEXCOORD_;

void main() {
	vec4 hp = _POSITION; // vec4(_POSITION.xyz, 1.0);
	POSITION_ = (MODELVIEW_MAT * hp).xyz;
	
	TEXCOORD_ = _TEXCOORD;	
	gl_Position = MODELVIEWPROJ_MAT * hp;
}

Note the first line of main(), if I use

vec4 hp = vec4(_POSITION.xyz, 1.0);

instead then the shader works! I initially suspected that the 'w' component of my vertex positions wasn't being initialized to 1, but (using gDEBugger) I peeked directly at the contents of the vertex buffer which the shader is accessing; the 'w' components were all 1s.

Now the strange part: every now and again when I run my test app, the shader works correctly - the geometry is rendered correctly. This happens without me changing anything. Very mysterious.

So to recap: when I explicitly set the 'w' vertex position I get consistent results - the geometry is rendered correctly. When I use the 'w' component straight out of the vertex buffer I get nonsense most of the time, but occasionally it works.

Has anyone seen anything remotely like this? Is there something I'm missing? I've combed over all of the client-side code which has anything to do with the creation and population of the vertex buffer and the sending of data to the shader program and all seems to be in order (after all, it DOES work sometimes). I'm thoroughly baffled.

I should perhaps mention that the vertex buffer creation, vertex data loading, shader loading & compiling all happens in a seperate thread/context to where the rendering occurs, although I can't fathom how that would cause a situation like this to arise.

PARTNERS