I'm learning about OpenGL graphics and the demonstrator has given us glut; however, it doesn't satisfy the needs of the project.
So, I want to move on to glfw3 but am having an issue with the primitives like, GL_TRIANGLES, GL_TRIANGLE_FAN, GL_LINE_LOOP, etc.
How can I use the primitives to draw polygons and lines using glfw3?
Related
I'm trying to write code to draw shapes on my JOGL canvas. I have the canvas on screen, but I can't figure out how to draw shapes. In GL2 examples, I see examples like:
gl.glBegin( GL2.GL_LINES );
gl.glVertex3f( 0.0f,0.75f,0 );
gl.glVertex3f( -0.75f,0f,0 );
gl.glEnd();
However, this doesn't work for me when gl is an instance of GL4 (gl is an instance of GL2 in this example).
OpenGL 3.x Core Profile has deprecated immediate mode statements.
Use vertex arrays or vertex buffers.
I cannot offer an example in JOGL, but in other languages, one of related calls is glDrawArrays(). You'll need to enable and set up the data source arrays before calling glDrawArrays(); if memory serves well, you'll be interested in glEnableClientState(), glVertexPointer() et al.
I have a transparent OpenGL texture which has some simple shapes drawn on it by OpenGL:
circles, polygons, lines. They are drawn without anti-aliasing, multi-sampling, etc. Therefore, they have jaggy borders.
I don't have access to process of texture creation so I cannot enable multi-sampling
.
Is there a way to make those smooth AFTER drawing is done?
There are image-based anti-aliasing filters such as FXAA and MLAA that will work in this situation. I hesitate to call them anti-aliasing because they do not really avoid aliasing, they just hide it after the fact. They are more akin to intelligent blur filters.
I know from your other question that you do not want to use FBOs, so that leads me to believe you are using an OpenGL 2.1 or older codebase. FXAA can be implemented in GLSL 1.20, but it works better in 1.30 (GL 3.0). The one thing I do not know about is using FXAA on an image that includes transparency, it expects luminance to be encoded in the alpha channel (or sRGB, which is not a GL 2.1 feature).
You will probably not want to apply FXAA to your texture directly, rather you would need to draw into a PBuffer and apply FXAA after you blend your input texture.
I assume that SDL 2 uses OpenGL rendering in the background (or perhaps DirectX if on Windows) and this decision is made by SDl itself.
I have seen tutorials which show the use of OpenGL directly in SDL and wondered what benefit, if any would you get from using OpenGL direct? Are there things which SDL would not be able to achieve natively?
If you completely rely on SDL functionality for graphic purposes, you only have access to simple image and buffer functions.
Accelerated 2D render API:
Supports easy rotation, scaling and alpha blending,
all accelerated using modern 3D APIs
But what SDL also does is providing an OpenGL context. This means you also have full access to OpenGL functionality including 3D objects, shaders, etc.
You can use SDL simply to create your context and provide you with sound, input, and file i/o, and use OpenGL to bring color to the screen, or use the SDL video API to draw sprites and images.
http://wiki.libsdl.org/MigrationGuide
Simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, or
software rendering behind the scenes
SDL2 just give you easy start with 2D graphics (and other matters) but you can't do "real 3D" only with SDL. (or i don't know about something?)
I don't know what SDL do "behind the scenes" but if you use directly OpenGL (or other API like Direct3D)
you have full control over the code and rendering process and you aren't limited to SDL graphics API.
I use SDL only for creating window, graphics context and using input devices like mouse.
NURBS chapter in RedBook is denoted deprecated, including utility library: "Even though
some of this functionality is part of the GLU library, it relies on
functionality that has been removed from the core OpenGL library."
Does it mean OpenGL 4.2 actually lacks C++ toolkit for manipulating NURBS curves and surfaces? There are some commercial 3rd party toolkits, but they're not crossplatform ( windows, mainly )
...?
In OpenGL-3 and later you've got geometry, and vertex shaders at your disposal, OpenGL-4 even provides tesselation shaders. They offer everything to implement GPU accelerated NURBS and Bezier splines and surfaces. The evaluators of OpenGL-1.1 never were GPU accelerated on most hardware. So actually you're better off without them.
Just implement NURBS or Bezier evaluators in the shaders and send in vertices as surface sampling points.
With respect to your question regarding the Red Book, the GLU library wasn't officially deprecated by the OpenGL ARB, rather just ignored. However, GLU used features that were deprecated in OpenGL 3.0, and removed in OpenGL 3.1: immediate-mode rendering, display lists, matrix stacks, to name a few. Specific to NURBS, they used several of those features (assuming the GLU library associated with your OpenGL implementation was based on the SGI version of GLU, which most were), and so features just won't work in a core context. It's not the lack of the C++-based GLU library, as much as GLU used features removed from modern OpenGL.
#datenwolf - not quite. The GLU NURBS library supported trimming curves, which are challenging to implement in all cases using the OpenGL vertex shader pipeline (i.e., vertex, tessellation, and geometry shading only). Specifically, support for winding rules and correct trimming while respecting trim-curve crossings is pretty darned tough (it may be possible with a combination of compute shaders and fancy work in a fragment shader). You could hack trimming using an alpha texture, but you'd suffer aliasing results, but it's a quick fix.
Does version OpenGL 3+ only uses "GL_TRIANGLES" ?
That's what I read, but in the documentation for OpenGL 3.3, http://www.opengl.org/sdk/docs/man3/, "glDrawArrays()" takes the following parameters:
GL_POINTS,
GL_LINE_STRIP,
GL_LINE_LOOP,
GL_LINES,
GL_LINE_STRIP_ADJACENCY,
GL_LINES_ADJACENCY,
GL_TRIANGLE_STRIP,
GL_TRIANGLE_FAN,
GL_TRIANGLES,
GL_TRIANGLE_STRIP_ADJACENCY,
GL_TRIANGLES_ADJACENCY
Does version OpenGL 3+ only uses "GL_TRIANGLES"
You mean "instead of also offering GL_QUADS and GL_POLYGON"?
Yes indeed. Quads and Polygons have been removed altogether. Most polygons needed to be tesselated into triangles anyway, since OpenGL can deal with convex polygons only (convex also imples planar!). Similar holds for quads.
Lines and points remain to be supported of course.
Does version OpenGL 3+ only uses "GL_TRIANGLES" ?? That's what I read
Where? Please provide a link.
There is a difference between "GL_TRIANGLES" and "triangles".
GL_TRIANGLES is a specific primitive type. It has a specific interpretation. It's base primitive type is "triangles" (as in, it generates triangles), but there's more to it than that.
"triangles" are exactly that: assemblages of 3 vertices that represent a planar area. GL_TRIANGLES, GL_TRIANGLE_STRIP, and GL_TRIANGLE_FAN produce triangles.
OpenGL 3.1+ core does not allow the use of the specific primitive types GL_QUADS, GL_QUAD_STRIP (ie: all "quad" types), and GL_POLYGON. Everything else is fair game.
According to section 2.6.1 of the specification commands like glDrawArrays() accept the primitives you posted. So, no, OpenGL 3.3 doesn't accept just GL_TRIANGLES.
What you read was probably meant to explain that OpenGL doesn't support primitives like GL_QUADS and GL_POLYGON anymore.
Quad and polygon primitives have been removed according to appendix E.2.2 of the specification (since version 3.1, prior versions still support them, although they're deprecated from version 3.0).
You can find the specification here.