I used to write small games with 'per pixel' drawing,
I mean with some SetPixel(x,y,color) function or such.
I am also interested in OpenGL but do not know it much.
Is it a good (fast) way to do a per pixel drawing in OpenGL ?
It would be good for example to use textured quads as a sprites,
or whole application background screen, with possibility to
set distinct pixel with some kind of my own SetPixel routine
i would write... or any other way - but it should be efficient
as much as it cans
(especialy im interested in basic fundamenta 1.0 version of OGL)
You can set a projection that will map vertex coordinates 1:1 to pixel coordinates:
glViewport(0, 0, window_width, window_height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0, window_width, 0, window_height, -1, 1);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
From here on, vertex X,Y coordinates are in pixels with the origin in the lower left corner. In theory you could use the immediate mode with GL_POINT primitives. But it's a much better idea to batch things up. Instead of sending each point indivisually create an array of all the points you want to draw:
struct Vertex
{
GLfloat x,y,red,green,blue;
};
std::vector<Vertex> vertices;
/* fill the vertices vector */
This you can OpenGL point to…
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
/* Those next two calls don't copy the data, they set a pointer, so vertices must not be deallocated, as long OpenGL points to it! */
glVertexPointer(2, GL_FLOAT, sizeof(Vertex), &vertices[0].x);
glColorPointer(3, GL_FLOAT, sizeof(Vertex), &vertices[0].red);
…and have it access and draw it all with a single call:
glDrawArrays(GL_POINTS, 0, vertices.size();
You really don't want to do this.
Is it a good (fast) way to do a per pixel drawing in OpenGL ?
There is no good or fast way to do this. It is highly discouraged due to the speed.
The proper way, although not easy (or in some cases possible) in OGL 1, is to use pixel shaders or blend modes. That is the only correct way, anything else is hacking around the entire system.
Depending on how the data needs modified, vertex colors and blend modes may be able to solve the some uses. It won't tint each pixel individually, but you can modify the texture must faster.
To do it, you can draw single-pixel quads (although care must be taken to offset them and handle filtering to prevent blurring) or you can get texture data and manipulate it later. Both will be unbelievably slow, but could function.
Working with the texture data is probably simpler and may be slightly faster.
Related
I need to implement an image reconstruction which involves drawing triangles in a buffer representing the pixels in an image. These triangles are assigned some floating point value to be filled with. If triangles are drawn such that they overlap, the values of the overlapping regions must be added together.
Is it possible to accomplish this with OpenGL? I would like to take advantage of the fact that rasterizing triangles is a basic graphics task that can be accelerated on the graphics card. I have a cpu-only implementation of this algorithm already but it is not fast enough for my purposes. This is due to the huge number of triangles that need to be drawn.
Specifically my questions are:
Can I draw triangles with a real value using openGL? (Or can I come up with a hack using color etc?)
Can OpenGL add the values where triangles overlap? (Once again I could deal with a hack, like color mixing)
Can I recover the real values for the pixels as an array of floats or similar to be further processed?
Do I have misconceptions about the idea that drawing in OpenGL -> using GPU to draw -> likely faster execution?
Additionally, I would like to run this code on a virtual machine so getting acceleration to work with OpenGL is more feasible than rolling my own implementation in something like Cuda as far as I understand. Is this true?
EDIT: Is an accumulation buffer an option here?
If 32-bit floats are sufficient then it looks like the answer is yes: http://www.opengl.org/wiki/Image_Format#Required_formats
Even under the old fixed pipeline you could use a blending mode with the function GL_FUNC_ADD, though I'm sure fragment shaders can do it more easily now.
glReadPixels() will get you the data back out of the buffer after drawing.
There are software implementations of OpenGL, but you get to choose when you set up the context. Using the GPU should be much faster than the CPU.
No idea. I've never used OpenGL or CUDA on a VM. I've never used CUDA at all.
I guess giving pieces of code as an answer wouldn't be appropriate here as your question is extremely broad. So I'll simply answer your questions individually with bits of hints.
Yes, drawing triangles with openGL is a piece of cake. You provide 3 vertice per triangle and with the proper shaders your can draw triangles, with filling or just edges, whatever you want. You seem to require a large set (bigger than [0, 255]) since a lot of triangles may overlap, and the value of each may be bigger than one. This is not a problem. You can fill a 32bit precision one channel frame buffer. In your case only one channel may suffice.
Yes, the blending exists since forever on openGL. So whatever the version of openGL you choose to use, there will be a way to add up the value of the trianlges overlapping.
Yes, depending on you implement it you may have to use glGetSubData() or glReadPixels or something else. However, depending on the size of the matrix you're filling, it may be a bit long to download the full buffer (2000x1000 pixels for a one channel at 32bit would be around 4-5ms). It may be more efficient to do all your processing on the GPU and extract only few valuable information instead of continuing the processing on the CPU.
The execution will be undoubtedly faster. However, the download of data from the GPU memory is often not optimized (upload is). So the time you will win on the processing may be lost on the download. I've never worked with openGL on VM so the additional loss of performance is unknown to me.
//Struct definition
struct Triangle {
float[2] position;
float intensity;
};
//Init
glGenBuffers(1, &m_buffer);
glBindBuffer(GL_ARRAY_BUFFER, 0, m_buffer);
glBufferData(GL_ARRAY_BUFFER,
triangleVector.data() * sizeof(Triangle),
triangleVector.size(),
GL_DYNAMIC_DRAW);
glBindBufferBase(GL_ARRAY_BUFFER, 0, 0);
glGenVertexArrays(1, &m_vao);
glBindVertexArray(m_vao);
glBindBuffer(GL_ARRAY_BUFFER, m_buffer);
glVertexAttribPointer(
POSITION,
2,
GL_FLOAT,
GL_FALSE,
sizeof(Triangle),
0);
glVertexAttribPointer(
INTENSITY,
1,
GL_FLOAT,
GL_FALSE,
sizeof(Triangle),
sizeof(float)*2);
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindVertexArray(0);
glGenTextures(1, &m_texture);
glBindTexture(GL_TEXTURE_2D, m_texture);
glTexImage2D(
GL_TEXTURE_2D,
0,
GL_R32F,
width,
height,
0,
GL_RED,
GL_FLOAT,
NULL);
glBindTexture(GL_FRAMEBUFFER, 0);
glGenFrameBuffers(1, &m_frameBuffer);
glBindFrameBuffer(GL_FRAMEBUFFER, m_frameBuffer);
glFramebufferTexture(
GL_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
m_texture,
0);
glBindFrameBuffer(GL_FRAMEBUFFER, 0);
After you just need to write your render function. A simple glDraw*() should be enough. Just remember to bind your buffers correctly. To enable the blending with the proper function. You might also want to disable the anti aliasing for your case. At first I'd say you need an ortho projection but I don't have all the element of your problem so it's up to you.
Long story short, if you never worked with openGL, the piece of code above will be relevant only after you read few documentation/tutorials on openGL/GLSL.
I have to support some legacy code which draws point clouds using the following code:
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, (float*)cloudGlobal.data());
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(GL_FLOAT, 0, (float*)normals.data());
glDrawArrays(GL_POINTS, 0, (int)cloudGlobal.size());
glFinish();
This code renders all vertices regardless of the angle between normal and the "line of sight". What I need is draw only vertices whose normals are directed towards us.
For faces this would be called "culling", but I don't know how to enable this option for mere vertices. Please suggest.
You could try to use the lighting system (unless you already need it for shading). Set ambient color alpha to zero, and then simply use alpha test to discard the points with zero alpha. You will probably need to set quite high alpha in diffuse color in order to avoid half-transparent points, in case alpha blending is required to antialiass the points (to render discs instead of squares).
This assumes that the vertices have normals (but since you are talking about "facing away", I assume they do).
EDIT:
As correctly pointed out by #derhass, this will not work.
If you have cube-map textures, perhaps you can copy normal to texcoord and perform lookup of alpha from a cube-map (also in combination with the texture matrix to take camera and point cloud transformations into account).
Actually in case your normals are normalized, you can scale them using the texture matrix to [-0.49, +0.49] and then use a simple 1D (or 2D) bar texture (half white, half black - incl. alpha). Note that counterintuitively, this requires texture wrap mode to be left as default GL_REPEAT (not clamp).
If your point clouds have shape of some closed objects, you can still get similar behavior even without cube-map textures by drawing a dummy mesh with glColorMask(0, 0, 0, 0) (will only write depth) that will "cover" the points that are facing away. You can generate this mesh also as a group of quads that are placed behind the points in the opposite direction of their normal, and are only visible from the other side than the points are supposed to be visible, thus covering them.
Note that this will only lead to visual improvement (it will look like the points are culled), not performance improvement.
Just out of curiosity - what's your application and why do you need to avoid shaders?
I'm looking for a way to improve my particle system performance, since it is very costly in terms of FPS.
This is because I call:
glDrawElements(GL_TRIANGLE_STRIP, mNumberOfIndices,
GL_UNSIGNED_SHORT, 0);
I call this method for every particle in my application (which could be between 1000 and 5000 particles). Note that when increasing to over 1000 particles my application starting to drop down in FPS. I'm using VBO:s, but the performance when calling this method is too costly.
Any ideas how I can make the particle system more efficient?
Edit: This is how my particle system draw things:
glBindTexture(GL_TEXTURE_2D, textureObject);
glBindBuffer(GL_ARRAY_BUFFER, vboVertexBuffer[0]);
glVertexPointer(3, GL_FLOAT, 0, 0);
glBindBuffer(GL_ARRAY_BUFFER, vboTextureBuffer[0]);
glTexCoordPointer(2, GL_FLOAT, 0, 0);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, vboIndexBuffer[0]);
Vector3f partPos;
for (int i = 0; i < m_numParticles; i++) {
partPos = m_particleList[i].m_pos;
glTranslatef(partPos.x, partPos.y, partPos.z);
glDrawElements(GL_TRIANGLE_STRIP, mNumberOfIndices,
GL_UNSIGNED_SHORT, 0);
gl.glTranslatef(-partPos.x, -partPos.y, -partPos.z);
}
The way you describe it, it sounds like you have a own VBO for each particle. This is not how it should be done. Put all particles into a single VBO and draw them all at once using a single glDrawElements or glDrawArrays call. Or even better, if available: Use instancing.
Expanding a bit on what datenwolf said, just pack all your particle indices into a single index buffer and draw all particles with a single glDrawElements call. This means you cannot use triangle strips anymore but a triangle set, but that shouldn't be too much of a problem.
Otherwise, if your hardware supports instanced rendering (or better, instanced arrays), you can do it by just rendering a single particle n times with the position and texCoord data taken from the respective arrays for each particle. You then still need to compute the four corner's position and texCoord data in the vertex shader (assuming you draw a quad for each particle), as with the instanced arrays you only get one attribute per instance (particle).
You might also use the geometry shader to create the particle's quad and just render a single point set, but I assume this might be slower than instancing, considering that SM4/GL3 hardware is quite likely to support instancing, too.
I have piece of code which are following:
glRotatef(triangle_info.struct_triangle.rot, 0, 0, 1.);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, trian_data_values);
glDrawArrays(GL_TRIANGLES, 0, 3);
I want to know each VERTEX position after each transformation. How will I do this?
There is no easy way to get to this data. OpenGL is mostly concerned with drawing, and you normally don't need that data, it will still draw fine. Applications that do need this data usually do the math themselves.
You will either have to do the transform manually, for each vertex. To do this, multiply each vertex with the modelview matrix. If you don't know the modelview matrix (a program needing to do this calculation would normally cache that value), you can query it with glGetFloatv(GL_MODELVIEW_MATRIX).
Alternatively, you can use transform feedback if either your OpenGL version is at least 3.0 or EXT_transform_feedback is supported. That will require you to create and bind a buffer, set the vertex positions as feedback varyings, and call begin/end transform feedback. Lastly, you have to map the buffer to get your data back.
Transform feedback is more setup, but spares you from doing the math yourself.
Context
I am doing swarm simulation using GPU programming (both OpenCL and CUDA,
but not at the same time of course) for scientific purpose.
I use OpenGL for display.
Goal
I would like to draw the same object —namely the swarming particle, can be a simple triangle in 2D— N times at different positions and with
different orientations in the most efficient way knowing that:
the object is always exactly the same
the positions and orientations are calculated on the GPU and thus stored in the GPU memory
the number of particles N can be large
Current solution
So far, to avoid sending back the data to the CPU, I store the position and
orientation arrays in a VBO and use:
glBindBuffer(GL_ARRAY_BUFFER, position_vbo);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, 0);
glBindBuffer(GL_ARRAY_BUFFER, velocity_vbo);
glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(4, GL_FLOAT, 0, 0);
glDrawArrays(GL_POINTS, 0, N);
glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, 0);
to draw a set of points with color-coded velocity without copying back the arrays to the CPU.
What I would like to do is something like drawing a full object instead of a simple point
using a similar way ie without copying back the VBO's to the CPU.
Basically I would like to store on the GPU the model of an object
(a Display List? a Vertex Array?) and to use the positions and orientations on the GPU
to draw the object N times without sending data back to the CPU.
Is it possible and how? Else, how should I do it?
PS: I like keeping the code clean so I would rather separate the display issues from the swarming kernel.
I believe you can do this with a geometry shader (available in OpenGL 3.2). See this tutorial for specific information.
In your case, you need to make the input type and output type of the geometry shader to GL_POINTS and GL_TRIANGLES respectively, and in your geometry shader, emit the 3 vertices of your triangle for each incoming point vertex.