3D graphics questions that do not deserve their own thread (OpenGL / Dx10)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 3D graphics questions that do not deserve their own thread (OpenGL / Dx10)

pianoSpleen: Jun 13, 2007; printf("Java is for programmers with no %socks", "c");

shodanjr_gr posted:

Id actually love a brief how-to on Multiple Render Targets in OGL since id like to build a basic deferred renderer at some point.

Deferred shading in OpenGL is a little annoying, but reasonably easy once you get the idea:

- Disable clamping so we can set colors outside the range of 0..1:

code:

	glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB,GL_FALSE);
	glClampColorARB(GL_CLAMP_FRAGMENT_COLOR_ARB,GL_FALSE);
	glClampColorARB(GL_CLAMP_READ_COLOR_ARB,GL_FALSE);

- Create a PBO and bind it:

code:

glGenFramebuffersEXT(1, &pbo1);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, pbo1);

- Create a depth texture and bind it:

code:

	glGenRenderbuffersEXT(1, &depthbuffer);
	glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
	glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT,	GL_DEPTH_COMPONENT24, screenwidth, screenheight);

- Create your MRTs

code:

 usual stuff to create a rectangle here, and something like
glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_FLOAT_RGBA32_NV, ss.x, ss.y, 0, GL_RGBA, GL_HALF_FLOAT_ARB, NULL);

We probably want at least two MRTs - one for fragment position, one for the normal. If you want to do (diffuse) texture mapping as well for example you'd create another MRT for that.
- Bind your MRTs

code:

//Bind the two MRTs
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_RECTANGLE_ARB, frametexture[0], 0);
	glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_RECTANGLE_ARB, frametexture[1], 0);
//Tell it to use two buffers
GLenum drawbuffers[16] = {GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT};
    glDrawBuffers(2, drawbuffers);

- Do the geometry pass:
In your pixel shader, instead of setting a gl_FragColor, you do something like this:

code:

//normal
gl_FragData[0] = vec4(outnormal,0.0);

//Position
gl_FragData[1] = vec4(frageyepos,0.0);

- Select your MRTs to be used as textures

code:

//Nothing fancy here, we just use it as a texture as normal. Remember that rectangle textures do NOT use normalised texture coordinates,
 and that it's probably a good idea to unbind this from the PBO before we try to read from it
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, frametexture[1]);

- Set to render to the screen
This time we read from the two textures, use them to calculate the pixel brightness, and spit that out on to the screen.

Hopefully that made sense :P feel free to ask if you have any questions.

# ¿ Sep 2, 2008 03:37

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 04:33

pianoSpleen: Jun 13, 2007; printf("Java is for programmers with no %socks", "c");

Mithaldu posted:

However when i take the begin and end out of the lists proper and put them in front and after the loop, it suddenly goes weird. The CPUs cores both go to 100%, all used by the Perl process and the framerate noticeably drops. It doesn't even matter whether the list calling loops is within begin/end or not. If it isn't it won't render, but the CPU will still freak out.

Any ideas?

As soon as you call glBegin(), you enter immediate mode and the display driver expects *nothing but* vertex data (glColor, glAttribute, glVertex etc). When you called a display list while in this mode, your display driver was probably nice enough to notice this and pass the display list that way (hence the slowdown). Same deal if you're creating a display list full of vertices but have no glBegin anywhere, inside or out of it - the driver has no idea what to do with them, anything could happen.

Basically the begin and end are meant to be in the display list definition, not when you call the display list, and Bad Things happen if you put them anywhere else :P.

As for the threading thing, it's not really that surprising. Just because your program is single-threaded, doesn't mean the display driver it's calling is. If you do something weird like this it's not entirely unexpected that the driver will balance the load between cores to increase performance.

Edit: Just to make it clear, display lists are slightly misnamed because they are NOT just copy-and-paste lists of GL commands. Each display list must have exactly one glBegin and glEnd, vertex/attribute data in between, and nothing else. <- just checked and this is completely wrong. I guess it does just prevent some optimisation.

pianoSpleen fucked around with this message at 07:34 on Sep 6, 2008

# ¿ Sep 6, 2008 04:46

pianoSpleen: Jun 13, 2007; printf("Java is for programmers with no %socks", "c");

brian posted:

Ok another question for you dapper fellas, how do I copy a texture from one handle to another in openGL without copying the pixels manually? I want to create a faux-motion blur effect by taking the previous frame and doing a simple fragment shader blend with the current one, I can get the current framebuffer using the framebuffer EXT and it's stored in an image handle but that handle is linked to the FBO so whenever the FBO is drawn to it's overwritten. I know I can detach the current image and attach a different one but that doesn't seem like a particularly good way to go about it but I could be wrong, would using an alternating color attachment each frame do the job? Any help would be fabbo.

Uh, you realise you can do that in about 4 lines using the accumulation buffer, right? (and it'll be faster than doing it manually, too)

Like this:

float q=0.7f;
glAccum(GL_MULT, q);
glAccum(GL_ACCUM, 1.0f-q);
glAccum(GL_RETURN, 1.0f);

Where q is the amount to blur, naturally.

# ¿ Oct 11, 2008 01:49

pianoSpleen: Jun 13, 2007; printf("Java is for programmers with no %socks", "c");

OneEightHundred posted:

Don't most consumer graphics cards do accumulation buffers in software, punching your framerate in the face?

Hrm, reading up it seems that support for it is indeed a little iffy. Maybe using FBOs would be a better idea overall... it's a neat trick when you need a quick blur though.

# ¿ Oct 11, 2008 09:48

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 3D graphics questions that do not deserve their own thread (OpenGL / Dx10)