I made a new page to host some simple OpenGL samples that I have been working on, You can access it from the menu on the right under “Projects” or from here.
I tried moving a VS2010 solution from one location to another only to be met with the cryptic message “The project file ” has been renamed or is no longer in the solution” upon trying to Build/Execute/Clean the solution. This Message is far from useful, especially since VS2010 had managed to load all the required projects.
This link gives a slight hint at what the problem is though I was not sure how to fix it based on the answers within. Looking through the project and solution files helped me find out what was wrong. Most of the projects in my solution were dependant on the same 2 projects “utils” and “glew_static”, judging from the .sln file only some of the projects had them listed explicitly as a dependency others did not, this seemed to be the cause of the error, as removing those that did not list them explicitly let me build the project as before.
And the solution to getting them to be listed explicitly as dependencies in the .sln file is this: Step 1. manually create the dependency via [solution]->properties->Project Dependencies, Step 2. (optional) then if you also need them linked as libraries do what you need from [project]->properties->Common Properties->Framework and References
The order is important here! If you do Step 2 first VS2010 automatically created the dependency in Step 1, and for some reason when it is made automatically the dependency won’t appear explicitly in the .sln file.
Just to clear some stuff up for myself…
//in the shader if we had...
layout(location = 0) out vec4 mainColor[4];
//and in the callling program we had
GLenum bufs[] = {GL_COLOR_ATTACHMENT1, GL_COLOR_ATTACHMENT5, GL_NONE, GL_COLOR_ATTACHMENT0};
glDrawBuffers(4,bufs);
//then
//mainColor[0] at (location = 0) maps to GL_COLOR_ATTACHMENT1
//mainColor[1] at (location = 1) maps to GL_COLOR_ATTACHMENT5
//mainColor[2] at (location = 2) ouput to this is disguarded
//mainColor[3] at (location = 3) maps to GL_COLOR_ATTACHMENT0
Guaranteed at least 8 color attachments in GL4.2
see
http://www.opengl.org/sdk/docs/man4/xhtml/glDrawBuffers.xml
http://www.opengl.org/wiki/Framebuffer_Object#Multiple_Render_Targets
also, when calling glBlitFramebuffer between two MRT FBOs you seem to be limited to copying from between GL_COLOR_ATTACHMENT0 and GL_COLOR_ATTACHMENT0 on both sides (when blitting GL_COLOR_BUFFER_BIT)
Yesterday I briefly tried out Philip Rideout’s very nice Shader Wrangler (click the link for full details). I tried to make a couple of changes to allow combining of shaders using several effect keys like this
“shaders.Shared+shaders.Vertex”
which will combine “Shared” and “Vertex” both from within the file named “shaders” (they don’t have to be from the same file)
I’ve added two methods for doing this, not sure which one is best yet. glswGetShaders returns the final combined string.glswGetShadersAlt is passed a char** and a maximum size for the array and returns the number of effects that matched.
“shaders.Shared+shaders.Vertex”
which will combine “Shared” and “Vertex” both from within the file named “shaders” (they don’t have to be from the same file)
I’ve added two methods for doing this, not sure which one is best yet. glswGetShaders returns the final combined string.glswGetShadersAlt is passed a char** and a maximum size for the array and returns the number of effects that matched.
const char* pStr[2] = {0,0};
int got = glswGetShadersAlt("shaders.Shared+shaders.Vertex", pStr, 2);
const char* pV2 = glswGetShaders("shaders.Shared+shaders.Vertex2");
The first method is appealing as it is the most simple, but results is some wasted data internal to glsw.c. The second method doesn’t have any wasted data and the char** and the returned number of matching effect files can be passed to glShaderSource as they are.
Of course it’s not too difficult to do this outside of the default shader wrangler, but if you like here are the modified glsw.c and glsw.h.
First attempt, still a little rigid.
A little code sample showing how to make Win32 like OpenGL 3.x and 4.x rendering contexts which can be attached to panels within a CLR Windows Form Application. Mixing Native C/C++ with C++/CLI can be pretty useful for making quick tools with shared code bases.
The basic code is in gl_canvas.h. The download contains a sample which makes 3 OpenGL canvases, two of which share a rendering context. It also uses a Timer to update the drawing of the panels. See the comments for more details.
Updated! 2012.04.02:
The sample now uses GLEW, also made it more flexible to create different context 4.1, 3.2 etc, and make it support the creation of multisampled pixel formats.
The sample now uses GLEW, also made it more flexible to create different context 4.1, 3.2 etc, and make it support the creation of multisampled pixel formats.
In my current project I am using the Prefix Sum to help me pack data processed on the GPU into an OpenGL buffer that is to be used as a position input for instanced drawing. I am doing this because it allows me to pack all the data I will use at the start of the buffer and render only the valid, on screen instances of data.
The basics of Prefix sum are covered in the link above, and a simple example of how to implement one in parallel can be found here. A more complex GPU efficient explanation can be found on the NVIDIA site. The NVIDIA link uses CUDA but if, like me, you are using OpenCL a version of it can be found in the OpenCL Code Examples in the NVidia GPU Computing SDK, under “Scan”.
Packing of the data is covered here Though I think the explanation is a little unclear “if P[i]==P[i+1]” should be “if P[i]!=P[i+1]” shouldn’t it? In fact I think there are some mistakes in link from the same site written above too, but it covers the basics in an easy to understand manner.
After processing the data on the GPU, counting the number of valid entries, and packing the data the number of instances I need to render must be passed to OpenGL. Currently I read back the number to the CPU and then pass it to OpenGL via glDrawElementsInstanced though it seem the need to read back the data is removed by glDrawElementsIndirect in GL4 or the GL_ARB_draw_indirect extension in GL3.1
which I will try out later (along with moving my instanced data from a Texture Buffer to a Vertex one see: GL_ARB_instanced_arrays
and Finally i read this interesting article on a newer extension to drawing using data on the GPU today : http://rastergrid.com/blog/2011/06/multi-draw-indirect-is-here/