Getting Geometry Shaders working

[Elliot Saba]

So I've got a fork up on github that is trying to add support for Geometry shaders, which I need for a project I'm working on.  Polycode seemed like a pretty neat way to get at what I want to do for my project, so I figured I'd just add in the bits that I need. I'm running into some problems though, so I thought I'd ask the wizards that built this thing in the first place to see if they've got any bright ideas as to why these problems are occurring.  

First, here's what I did:

* Pretty much anywhere a fragment or vertex program is created, built, or destroyed, I've added in extra variables and logic to do the same to a geometry program.  This seems to work well enough, my shaders get compiled and linked together no problem.  This does mean that just as a fragment and vertex program are required, so is a geometry program, but I can live with that for now.

* I had to modify the pixel format being asked for on OSX, because if you don't specify the Core profile, which enables 3.3 and above, (see this chart for what's supported; looks like assuming 3.3+ is a safe bet) you get Legacy mode, which is opengl version 2.1, and glsl version 1.2, which is too old for my purposes.

With these modifications, I've been trying to just create the basic "passthrough" versions of shaders and get stuff to render, but I'm running into a couple different problems.  The first is that no geometry gets drawn to the screen, period.  My guess is because when moving to OpenGL 3.0+, since the automatic matrix stack is deprecated, things like gl_modelViewProjectionMatrix are gone, and have to be manually passed to the shader.  I've tried doing this by getting the matrices from the current renderer, but my MVP matrix seems to be zero.  I'm doing the following:

Material * mat = shadedMesh->getMaterial();
ShaderBinding * sb = mat->getShaderBinding(0);
Renderer * r = CoreServices::getInstance()->getRenderer();
Matrix4 MVP = r->getModelviewMatrix() * r->getProjectionMatrix();
sb->addParam(ProgramParam::PARAM_MATRIX, "MVP")->setMatrix4(MVP);

Where "shadedMesh" is just some geometry I've created that I want to apply my vert/geom/frag shader to.  The MVP matrix is zero when I run these commands, is there some kind of setup I need to run in order to get these matrices to be setup properly?  Excuse my ignorance, I'm a little new to this kind of programming. :)

-E

[Devin Stone]

This is great news! I have been wanting to use geometry shaders for my project as well. Thanks for working on it. I would help if I wasn't so busy :/

_Devin

[Elliot Saba]

I think I've figured out what's going on.  Since Polycode currently assumes we've got a legacy OpenGL pipeline around, it uses things such as glPushMatrix(), glMatrixMode(), etc...  All this stuff is gone when using the OpenGL core 3.2 profile, which I am using so that I have access to geometry shaders.

I'd like to modify Polycode to store matrices as uniforms for use by the shaders, but there are a few things I need to know first:

1) If I don't apply any shaders to anything, what are the defaults?  With Polycode as it is now, using the legacy opengl mode, I can just push some vertices onto the GPU, call them triangles and opengl will shade them according to the color passed in via the color buffer.  With 3.2, I'm assuming this has changed, since there is no way to automatically give it the model, view and projection matrices.  It assumes that we will have shaders to do the work for us.  Is OpenGL 3.2+ setup in such a way that it just doesn't do anything without shader programs loaded in?

2) How should I be uploading these matrices?  I suppose Polycode could offer automatic uniforms to shaders, (Although we can't use "gl_" prefixed names) so I could just have Polycode automatically upload "modelViewProjection" uniforms, etc...  Is this the right way to do this?

3) I notice that we've got functions such as setProjectionFromFOV() and friends in PolyGLRenderer.cpp, where these matrices are being changed.  I suppose I would just find instances of glPushMatrix() and glMatrixMode() and store the matrices being edited/changed as instance variables instead of calling those functions.  Then in BeginRender(), I would upload them to the GPU, so that shaders can take advantage of them?

4) If this work eventually gets merged back into mainline, I'm assuming you'd want options on all of this.  Things like a flag to request a core 3.2 profile instead of a legacy profile on OSX, which then creates a PolyGLCoreRenderer instead of a PolyGLRenderer.  Am I right?

Thanks for your help!

-E

[Ivan Safrin]

Hey, sorry I haven't replied sooner. Was traveling for like 3 days.

So a fairly important goal of mine for Polycode in the neat future is to port it to iOS/Android, which means writing an OpenGL ES renderer, which also uses uniforms for everything. I think that that should be the standard in Polycode and all renderers should use some sort of standard uniform pipeline. I would even argue for GLES being the main renderer even on desktop for consistency sake, but things like geometry shaders and other non-ES features that I know people use make me think that there should me multiple renderers no matter what.

As far as I know, there is no reason not to use uniforms for everything in OpenGL < 3.2 and the only reason I'm not right now was convenience and my own un-familiarity with all the various ways of doing things. So, I would agree that writing a standardized uniform pipeline in Renderer that would easily provide uniforms for its implementations.

Also, since OpenGL ES doesn't have its own matrix stack, it has to be implemented in the renderer, so it's a good idea to just have Renderer handle that and provide a way for it to pass the current matrix as uniforms to the shader pipeline.

Anyway, I'm at GDC this week and trying to make a Polycode release while I'm here. After this week, screenrewrite will become master and there will probably be a version release. After that, I would love to move on improving the renderer pipeline and any thoughts and ideas on that are totally welcome. 

Elliot, feel free to send me pull requests or emails with ideas around this.

[Matthew Bell]

Yeah, I've been looking into ideas for upgrading the renderer while working on the Particles.  Essentially I'd rather hold off on moving them to the gpu until we're got a good plan for the renderer.

Obviously any improvement will require moving away from a lot of the legacy gl* stuff like the matrix stack but, I'd also like to look into improving certain aspects of the pipeline.  The easiest way to do this would be to abstract pipelines.  There are certain aspects of rendering that all pipelines generally follow.

Sort + Culling Geometry based on opacity and position.  Essentially drawing opaque front to back and transparent back to front.

Light assignment is the other step I'd like to look at.  I'd love to implement clusterred forward rendering and being able to change the light assignment process is definitely a part of that.  Currently we're using glLight which has to go anyways.  Abstracting this will also allow for other current ( tiled ) and future ( who knows ) light assignment schemes.

So basically I'd imagine a rendering pipeline that would go something like this:

Sort/Cull + Light Assignment concurrently

Sort/Cull will create an array of renderables along with indices for Opaque ( 0 ), AlphaTest and alpha blend

After Sort/Cull depth pass will be done on Opaque

After DepthPass + Light Assignement are done the rendering pass will be kicked off

Regardless first steps would be to get uniform support up and running and perhaps a more robust shader systems ( pre processors and what not ).  Changing out glLights can be done in a more straightforward manner for now ( than doing clustered ) if you want.  After that it's a matter of rewriting the examples, really.  

[Elliot Saba]

Thanks for the replies, Ivan, Matthew.

I'm going to go through the renderer code in Polycode to try and understand it, and see where I can start upgrading things.  I'll start with the problems I know about, and then ask for help when I have something that works, or don't know what else to change.  Right now that's the matrix stack for projection and whatnot, but I'm sure there's other things I'll need to change.

Note that I'm really only doing this on OSX, so any infrastructure upgrades that need to happen (e.g. I'm explicitly asking for an OpenGL 3 context on OSX now) will need to come from someone else.

I'm really not qualified to start dealing with the light assignment changes that you're talking about, Matthew.  Although I'd love to learn.  :)

-E

[Matthew Bell]

The main thing would be to allow it to be abstracted ( light assignment that is ).  I can definitely handle that part, though.  For now we should figure out how to implement uniforms in an easy and reusable manner.  Then you can handle the matrices and I'll look into the lights.

We may also need to look at how the vertices and vertex attributes are being handled.

[Ivan Safrin]

In screenrewrite, the lights are sorted (distance + importance) for each entity by the Renderer and then assigned to shaders via glLight, so it would be just a matter of replacing the glLight/gl_ stuff with uniforms. I will look into creating a custom matrix stack after screenrewrite merge.

[Elliot Saba]

Alright.  I guess I'll wait for you to muck around with the matrix stack stuff, and then I will continue on my geometry shaders adventures.

-E

[Matthew Bell]

Just so you guys are aware I've begun working on a Uniform Buffer Object implementation.  After I'm done I'll use it to implement the lights.

[Elliot Saba]

Hey Matthew, I'm getting the polycode itch again, so I thought I might step in and see how your efforts are coming.  I'd be game for taking a small chunk of work off your plate and submitting a PR to your branch in the next couple weeks or so.  Looking at your changes, it seems like you've gotten a good foundation for these uniforms, but have a few things left yet to do such as vertex colors/textures, etc...  I'd be interested in helping out, as well as doing OSX or Linux-specific code that you need to get GL3.x or 4.x contexts, etc...

Just from a quick glance, it looks like you're asking for OpenGL 4.3.  Is that rather ambitious?  How are we going to deal with having multiple possible subsets of functionality?  Will we perform this upgrade once every so often and just support a base set of features with "the one true renderer" that polycode supports, leaving newer features to the user to implement, or will Polycode support multiple renderers from which a user can choose which one they want to use?

-E

[Matthew Bell]

I really have to get back to that.  It's potentially in a state to pull from.  Vertex information needs to be updated, old system is deprecated.  I've been crunching on this project for the longest time but I'll try and get some hours in soon.

4.3 is when the debugging extensions were made core and they're very useful.  I'm hoping to target a minimum of 3.0 I think but for now it's very useful for finding deprecated features