I know that there are algorithms of drawing line, circle, ellipse pixel by pixel (e.g. Bresenham's algorithms):
http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
I wonder why these algorithms (and I am sure that there are algorithms for drawing ellipsoid, sphere, cylinder in 3D) and not being used in OpenGL to draw corresponding primitives. Isn't it more simple and effective in terms of performance (which is very important in OpenGL) to have such primitives too instead of drawing a circle with lines, and sphere with triangles?
Who said OpenGL can't draw these shapes? There is no direct implementation of Bresenham and friends in the GPU core for the reasons Nico already explained.
However, since a couple of years GPU are fully programmable and therefore you can render almost anything you like. Including circles, ellipses and related primitives. You just have to write a shader program to do so :-)
Here is a little tutorial which shows you how it's done: http://www.geeks3d.com/20130705/shader-library-circle-disc-fake-sphere-in-glsl-opengl-glslhacker/
Related
After looking at some programs for 2d modeling, I noticed that all primitives are drawn as segments (see attached picture).
For example, why is the circle drawn as a polygon? It seems to me that it is much easier to create a shader that will draw a circle, regardless of the magnification (scaling)?
It is also interesting, These segments are drawn each separately or as one draw-call with a special shader for each shape?
What is the main reason that the developers chose this path? What they are trying to achieve?
3D graphics API support only triangles, dots and line segments - there is no built-in rendering primitives for drawing a circle or something like this. Therefore, the first two reasons for drawing all type of curves as a polyline are uniformity (you can render ANY type of curve as a set of line segments) and performance (line segments is the only native type supported by GPU). Drawing primitives of the same type using the same universal GLSL program allows rendering of many curves at once and reducing overall number of draw calls in optimized engine.
Moreover, you don't actually need a special GLSL program to avoid rough tessellation - just split your curve into more segments to make it appear smooth on the screen. You will have to balance between performance and quality, though - ideally, tessellation level should change dynamically basing on a zoom level and applied only to figures visible on the screen. This is not something trivial to implement, but it is much more straightforward when applied to 2D drawings than to 3D.
GLSL programs allow implementing various tricks, but rendering a fixed-width curve would require using a Tessellation Shader (or at least Geometry Shader), which WebGL doesn't support, or applying some dirty tricks! So I wouldn't say that drawing a thin circle of reliable quality via GLSL program will be that simple.
It is possible, though, rendering simple shapes like filled circle using just a Fragment Shader by drawing a rectangle and discarding fragments outside of the circle computed by circle equation. But that would be just a circle, a single solid circle, while there are a lot of other figures and combinations of them! Hence, again - uniformity and simplicity.
Indeed, there are applications implementing special GLSL programs for a limited set of commonly used figures, but these require a lot of development.
I am starting openGL. Not able to understand why everything in graphics starts from triangles. Every article that I read says entire graphics rests on triangles.
What is the reason for choosing such a shape as a basic building block? I though square or circle would be much better and is logical because of the symmetry properties.
Great question. It's because triangles are the only polygons that can approximate other shapes while also being guaranteed to lie in a plane, which means they have well-defined and easy-to-compute surfaces.
I've been using OpenGL since some time now for making 3D applications, but I never really understood the use of the GL_POINT and GL_LINES primitive drawing types for 3D games in the production phase.
(Where) are point and line primitives in OpenGL still used in modern games?
You know, OpenGL is not just for games and there are other kind of programs than just games. Think CAD programs, or map editors, where wireframes are still very usefull.
GL_POINTS are used in games for point sprites (either via the pointsprite functionality or by generating a quad from a point in the geometry shader) both for "sparkle" effects and volumetric clouds.
They are also used in some special algorithms just when, well... when points are needed. Such as in building histograms in the geometry shader as by the chapter in one of the later GPU Gems books. Or, for GPU instance culling via transform feedback.
GL_LINES have little use in games (mostly useful for CAD or modelling apps). Besides not being needed often, if they are needed, you will normally want lines with a thickness greater than 1, which is not well supported (read as: fast) on all implementations.
In such a case, one usually draws thick lines with triangle strips.
Who ever said those primitives were used in modern games?
GL_LINES is critical for wireframe views in 3D modeling tools.
(Where) are point and line primitives in OpenGL still used in modern games?
Where do you want them to be used?
Under standard methods, points can be used to build point sprites, which are 2D flatcards that always face the camera and are of a particular size. They are always square in window-space. Sadly, the OpenGL specification makes using them somewhat dubious, as point sprites are clipped based on the center of the point, not the size of the two triangles that are used to render it.
Lines are perfectly reasonable for line drawing. Once upon a time, lines weren't available in consumer hardware, but they have been around for many years now. Of course, antialiased line rendering (GL_LINE_SMOOTH) is another matter.
More importantly is the interaction of these things with geometry shaders. You can convert points into a quad. Or a triangle. Or whatever you want, really. Each "point" is just an execution of the geometry shader. You can have points which contain the position and radius of a sphere, and the geometry shader can output a window-aligned quad that is the appropriate size for the fragment shader to do some raytracing logic on it.
GL_POINTS just means "one vertex per geometry shader". GL_LINES means "two vertices per geometry shader." How you use it is up to you.
I'd say for debugging purposes, but that is just from my own perspective.
Some primitives can be used in areas where you don't think they can be applied, such as a particle system.
I agree with Pompe de velo about lines being useful for debugging. They can be useful when debugging AI and collision detection algorithms so that you can visualize the data that is being used by the AI or collision detection. Some example uses for AI, the lines can be used to show AI paths or path meshes. Lines can be used to show steering data that the AI is using. Lines can be used to show what an AI is aiming at. The data that is shown can be displayed in text form but sometimes it is easier to see it in visual form.
In most cases particles are based on GL_POINT, considering that there can be a huge number of particles on the screen it would be very expensive to use 4 vertices per particle, so GL_POINT solves this problem
GL_LINES good for debugging purposes, wireframe mode can be used in various cases. As mentioned above - in CAD apps, but if you're interesed in gamedev use - it's good for a scene editor.
In terms of collision detection, they come in handy when you want to visualize bounding volumes(boxes,spheres,k-dops) and contact manifolds in wireframe mode. Setting the colour of these primitives based on the status of collisions as well is incredibly useful.
Circles are one of the basics geometric entities. Yet there is no primitives defined in OpenGL for this, like lines or polygons. Why so? It's a little annoying to include custom headers for this all the time!
Any specific reason to omit it?
While circles may be basic shapes they aren't as basic as points, lines or triangles when it comes to rasterisation. The first graphic cards with 3D acceleration were designed to do one thing very well, rasterise triangles (and lines and points because they were trivial to add). Adding any more complex shapes would have made the card a lot more expensive while adding only little functionality.
But there's another reason for not including circles/ellipses. They don't connect. You can't build a 3D model out of them and you can't connect triangles to them without adding gaps or overlapping parts. So for circles to be useful you also need other shapes like curves and other more advanced surfaces (e.g. NURBS). Circles alone are only useful as "big points" which can also be done with a quad and a circle shaped texture, or triangles.
If you are using "custom headers" for circles you should be aware that those probably create a triangle model that form your "circles".
Because historically, video cards have rendered points, lines, and triangles.
You calculate curves using short enough lines so the video card doesn't have to.
Because graphic cards operate on 3-dimensional points, lines and triangles. A circle requires curves or splines. It cannot be perfectly represented by a "normal" 3D primitive, only approximated as an N-gon (so it will look like a circle at a certain distance). If you want a circle, write the routine yourself (it isn't hard to do). Either draw it as an N-gon, or make a square (2 triangles) and cut a circle out of it it using fragment shader (you can get a perfect circle this way).
You could always use gluSphere (if a three-dimensional shape is what you're looking for).
If you want to draw a two-dimensional circle you're stuck with custom methods. I'd go with a triangle fan.
The primitives are called primitives for a reason :)
I want to draw many spheres (~100k) using OpenGL. So far, I'm doing something like
for (int i=0; i<pnum; i++){
glPushMatrix();
glTranslatef(bpos[i].x, bpos[i].y, bpos[i].z);
glCallList(DListSPHERE);
glPopMatrix();
}
Before using proper spheres, I used GL_POINTS. That allowed me to call glDrawArrays with an array containing all points which was very efficient. Is there a better way than the above code to draw many, identical objects?
Have a look at this page on instancing: it contains many references:
Some test made that shows when to use instancing and when not: http://www.ozone3d.net/blogs/lab/?p=87
An OpenGL implementation of a pseduo-instancing (recommended for old hardware).
glsl_pseudo_instancing.pdf
OpenGL instancing:
http://www.opengl.org/registry/specs/EXT/draw_instanced.txt
See also Geometry instancing on Wikipedia.
If you draw ~100k spheres, you might want to consider raycasting them instead of using polygon meshes to approximate them. The papers GPU-Based Ray-Casting of Quadratic Surfaces by Sigg et al. (2006) and Splatting Illuminated Ellipsoids with Depth Correction by Gumhold (2003) show how to do this. If you do this, you can reuse much of your fast point sprite code.
You could use point sprites and a fragment shader to duplicate the effect of a rendered sphere without the actual sphere geometry. I would try instancing first, however.