I am going to draw a regular hexagon with one fill color. I can do it with a sequence of glVertex2*() calls. However, the glBegin() call is what I am asking about. Is there any benefit to using GL_POLYGON or GL_TRIANGLE_FAN? If it matters, drawing hexes will be the main work of the program. If you have another idea, I am all ears.
GL_POLYGON is deprecated in OpenGL 3.x. I think most drivers convert GL_POLYGON to a bunch of triangles, you can save the conversion by providing triangles in the first place.
Usually that are very very close but at that point it's going to be down to the hardware. Don't worry about such minor details and only revisit it once you are sure that you indeed have a bottleneck in that area.
Related
I am writing a code in OpenGL, in c++ on Linux, where i need to draw a several sphere in the 3D space, for drawing it I use the glutSolidSphere( GLdouble(radius), GLint(slices), GLint(stacks) ) method, everytime, in the draw function, the glutSolidSphere is called a lot of times and after the sphere is traslated in the right position.
But I have noticed that when the program draw several spheres there is a framerate problem, so i was thinking if there was a method that allow me to "store" the model of the sphere without recreate it everytime and just change position.
I am not an OpenGL expert, sorry if i have committed english language errors.
The answer of #datenwolf in this topic is perfect, he said :
In OpenGL you don't create objects, you just draw them. Once they are drawn, OpenGL no longer cares about what geometry you sent it.
glutSolidSphere is just sending drawing commands to OpenGL.
So if you have performance issues you will need to look for others ways to improve performance like multithreading or maybe look to implement your own sphere draw function (google or stackoverflow research).
I heard that GluSolidSphere call glBegin(…) / glEnd() and these can be slow so maybe draw all your spheres with a loop so you have only one call of glBegin(…) / glEnd()
I have to implement simple texturing in OpenGL using the inverse(or backwards) mapping approach. In theory, I know what it is and how it works, but I can't figure out how to implement it in OpenGL. Is there a way to specify how OpenGL handles textures in this regard?
I know, more or less, how to texture polygons, but this little side-note on the homework assignment is what bugs me:
Note: The texture mapping is implemented using the inverse mapping
approach (do not use OpenGL texture mapping function)
Does anyone have any idea what is meant by this? I'm drawing the polygon to be textured with glBegin and glEnd and using glEnable(GL_TEXTURE_2D) and glTexCoord2f to texture it. Is there another way of doing it, or am I reading too much into the assignment?
I'm using Visual Studio 2012, which came with OpenGL installed, and have an AMD Radeon HD 6850 graphics card. This is for a simple homework assignment, so the simplest solution will suffice.
To save time, yes, this is for a homework, no, I don't want anyone to do it for me, just an indication as to how I would go about doing it myself, and no, an extensive google search gave me no insight whatsoever as to how this would be implemented in code.
I would like to draw a simple 2D stickman on the screen. I also want it to be anti-aliased.
The problem is that I want to use a bones system, which will be written after I would know how to draw the stickman itself based on the joints positions. This means I can't use sprites - I want my stickman to be fully controlable in the code.
It would be great if it will be possible to draw curves too.
Drawing a 3D stickman using a model would also be great if not better. The camera will be positioned like it's 2D, but I would still have depth. The problem is that I only have experience in Maya, and exporting and vertex weighting of the model in OpenGL seems like a mess...
I tried to find libraries for 2D anti-aliased drawing or enable multi-sampling and draw normally, but I had no luck. I also tried to use OpenGL's native anti-aliasing but it seems deprecated and the line joins are bad...
I don't want it to be too complicated because, well, it shouldn't be - it's just the first part of my program, and it's drawing a stickman...
I hope you guys can help me, I'm sure you know better than me :)
You could enable GL_SMOOTH. To check if you device supports your required line width for smooth lines, you can use glGet(GL_SMOOTH_LINE_WIDTH_RANGE);
If you want your code to be generic, you can also use antialiased textures.
Take a look at this link
http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node62.html
The only way to get antialiasing is use GL library which knows how to get antialiased GL context, for example, SDL. As of stickman, you can draw him with colored polygons.
In OpenGL, how can one cut a triangle shaped hole from a square? making the hole transparent.
I'm also using SDL, maybe it can be achieved with an SDL surface?
While doing it on a texture is truly the easier way out, if you need it to be a real shape, you might try using the GLUtesselator from GLU toolkit. See a tutorial for it here.
General usage is that you create a tesselator object, create two contours (the outer and the inner in a reverse direction) and the tesselator translates that into pure OpenGL commands. Of course if it's efficiency you're seeking you should implement or find some higher order system that operates on vertex buffers.
You can use a texture and alpha blending: the texture would contain a transparent triangle. See this tutorial on blending.
EDIT: Of course alpha blending doesn't change the geometry. For that you need to perform treatments that are more complicated. See this tutorial on realtime CSG.
Reference: Constructive Solid Geometry
Now that my OpenGL application is getting larger and more complex, I am noticing that it's also getting a little slow on very low-end systems such as Netbooks. In Java, I am able to get around this by drawing to a BufferedImage then drawing that to the screen and updating the cached render every one in a while. How would I go about doing this in OpenGL with C++?
I found a few guides but they seem to only work on newer hardware/specific Nvidia cards. Since the cached rendering operations will only be updated every once in a while, i can sacrifice speed for compatability.
glBegin(GL_QUADS);
setColor(DARK_BLUE);
glVertex2f(0, 0); //TL
glVertex2f(appWidth, 0); //TR
setColor(LIGHT_BLUE);
glVertex2f(appWidth, appHeight); //BR
glVertex2f(0, appHeight); //BR
glEnd();
This is something that I am especially concerned about. A gradient that takes up the entire screen is being re-drawn many times per second. How can I cache it to a texture then just draw that texture to increase performance?
Also, a trick I use in Java is to render it to a 1 X height texture then scale that to width x height to increase the performance and lower memory usage. Is there such a trick with openGL?
If you don't want to use Framebuffer Objects for compatibility reasons (but they are pretty widely available), you don't want to use the legacy (and non portable) Pbuffers either. That leaves you with the simple possibility of reading the contents of the framebuffer with glReadPixels and creating a new texture with that data using glTexImage2D.
Let me add that I don't really think that in your case you are going to gain much. Drawing a texture onscreen requires at least texel access per pixel, that's not really a huge saving if the alternative is just interpolating a color as you are doing now!
I sincerely doubt drawing from a texture is less work than drawing a gradient.
In drawing a gradient:
Color is interpolated at every pixel
In drawing a texture:
Texture coordinate is interpolated at every pixel
Color is still interpolated at every pixel
Texture lookup for every pixel
Multiply lookup color with current color
Not that either of these are slow, but drawing untextured polygons is pretty much as fast as it gets.
Hey there, thought I'd give you some insight in to this.
There's essentially two ways to do it.
Frame Buffer Objects (FBOs) for more modern hardware, and the back buffer for a fall back.
The article from one of the previous posters is a good article to follow on it, and there's plent of tutorials on google for FBOs.
In my 2d Engine (Phoenix), we decided we would go with just the back buffer method. Our class was fairly simple and you can view the header and source here:
http://code.google.com/p/phoenixgl/source/browse/branches/0.3/libPhoenixGL/PhRenderTexture.h
http://code.google.com/p/phoenixgl/source/browse/branches/0.3/libPhoenixGL/PhRenderTexture.cpp
Hope that helps!
Consider using a display list rather than a texture. Texture reads (especially for large ones) are a good deal slower than 8 or 9 function calls.
Before doing any optimization you should make sure you fully understand the bottlenecks. You'll probably be surprised at the result.
Look into FBOs - framebuffer objects. It's an extension that lets you render to arbitrary rendertargets, including textures. This extension should be available on most recent hardware. This is a fairly good primer on FBOs: OpenGL Frame Buffer Object 101