In my engine, I want to avoid having line, and separate triangle types. I want to draw the lines using a triangle where 2 verts are identical. But in opengl, this triangle wont be displayed because it has zero area, and therefore can't cover a pixel.
Internally, at the driver level, an opengl line is drawn using a degenerate triangle, and a different rasterization rule is used where it draws at least one pixel per scanline.
D3d had some option where you could set the rasterization to always draw the first pixel per scan line--effectively accomplishing what I want in d3d.
But how can I do this with opengl? I don't see any command that would allow you to change the rasterization rules.
Well I did this exact thing by, of the three vertices necessary, using the first two as the start point of the line and then using glPolygonMode(GL_FRONT_AND_BACK, GL_LINE) at the start of the line rendering object and glPolygonMode(GL_FRONT_AND_BACK, GL_FILL) at the end.
Combine that with the appropriate enabling and disabling of face culling, and you've got yourself a perfectly good line renderer that still uses the triangle set up.
Related
I'm able to draw a simple cube with modern opengl, but I would like to be able to draw a line cube from the same data I draw my current cube with (vertices):
currently I'm drawing a cube and using glPolygonMode to draw the lines, but I would like to get rid of the lines going though each quad face (essentially just drawing the edges of the cube)
I wasn't able to get any further than this, I don't know how to tackle this topic (shaders, or some other opengl method)
how can I draw a cube in such a way?
Easiest way is to still use glPolygonMOde(...) while rendering QUADS instead of TRIANGLES. This however requires change in your data ...
In case your meshes will be always composed from QUADS and triangulated so the 2 consequent triangles always form a QUAD but you are unwilling to switch to QUADS then you can write a Geometry shader taking in 6 Vertexes and outputting 4 lines which will be still more or less "fast" however note that Geometry shaders where not very reliable in past...
If those are not an option you can modify this:
Silhouette-Outlined shader
To render fragments near sharp normal changes. However this will hide back sides so in order to have them too you have to do this in 2 passes one with glFrontFace(GL_CW); and the other with glFrontFace(GL_CCW); combining their outputs. This also allows you to set different color to the hidden edges ...
So I see it like this:
glFrontFace(GL_CW);
render_mesh_to_trexture(); // using normal instead of color
render_siluete_from_texture(); // using texture from previous line
glFrontFace(GL_CCW);
render_mesh_to_trexture(); // using normal instead of color
render_siluete_from_texture(); // using texture from previous line
However this will be a lot slower and requires consistent winding rule...
Another option is to just compile list of edges from your mesh on CPU side and remove all that have duplicates. Its simple and fast however will create new VBO/VAO data and no longer complies with your requirement to use the same data (however the new VBO might be just integer indices so 2 ints per edge).
I have created a regular grid which originates from a 2D image, i.e. each pixels has a vertex. There are two triangles per four pixels so that I have a triangle in the top right and in the bottom left. I use vertex and index buffers for that.
Now I dynamically remove triangles / faces at the border of two different kinds of vertices (according to my application) because else there would be distortions. I wrote a geometry shader which takes a triangle and outputs the triangle or nothing (see first picture). The shader recognizes if a triangle is "faulty" (has orange edges) and omits it.
Now this works fine, but I may lose some details because of my vertex geometry. I can add complementary triangles to the mesh (see second picture, new triangles with dashed orange line).
How do I accomplish this in OpenGL?
My first idea is to create one quad instead of two triangles, check for the four possible triangles cases and create those triangles dynamically in the geometry shader. But this might be slow; GL_QUADs are deprecated and alternatives might be slow too. What do you have in mind?
Here's my idea:
Put the whole grid in a buffer/texture.
Build four triangles for each four pixels. They cross each other, yes.
In the geometry shader you can tell if a triangle is "faulty" because it connects two wrong regions. Or, sampling form the texture, because the crossing triangle is valid, so this new one can be discarded.
EDIT: Another approach
Use the texture. Draw instanced with GL_POINTS. With some order and the help of the instanceID the shader knows where the point is.
For this point test the four possible triangles. If you instance top to down and left to right, only a point to the right and the two below are used for the four triangles. And you avoid repeating tests.
Emit only those you choose.
I need to draw a wireframe around a cube,I have everything made but I have some problem with the alpha testing, whatever I do the GL_LINES keep either overlapping the GL_TRIANGLES when they dont have to(they are behind them) or the GL_TRIANGLES keep overlapping the GL_LINES (when the lines should be visible).
Gdx.gl.glBlendFunc(GL20.GL_SRC_ALPHA, GL20.GL_ONE_MINUS_SRC_ALPHA);
Gdx.gl.glEnable(GL20.GL_DEPTH_TEST);
SquareMap.get().shader.getShader().begin();
SquareMap.get().shader.getShader().setUniformMatrix(u,camera.combined);
LineRenderer3D.get().render(SquareMap.get().shader,worldrenderer.getCamera());
TriangleRenderer3D.get().render(SquareMap.get().shader,worldrenderer.getCamera());
SquareMap.get().shader.getShader().end();
Also the wireframe is a little bigger than the cube.
The TriangleRenderer3D.get().render and LineRenderer3D().render just load the vertices and call gl_drawarrays
By enabling depth mask the cube GL_TRIANGLES overlap the lines
Do I need to enable something that I missing here?
It is worth mentioning that line primitives have different pixel coverage rules than triangles. A line must cross through a diamond-shaped pattern in the center of a pixel to be visible, where as a triangle needs to cover the top-left corner. This documentation is for Direct3D, but it does an infinitely better job describing these rules (which are the same in GL) than any OpenGL documentation I have come across.
As for fixing this problem, a small offset applied to all vertex positions in order to better align their centers is the most common approach. This is typically done by translating X and Y by 0.375 units.
Another Microsoft document explains this as well.
While some of the issues described in the first paragraph may be primitive coverage related, none are in the last paragraph.
The issue described in the final paragraphs can be addressed this way:
//
// Write wires wherever the line's depth is less than or equal to the triangles.
//
glDepthFunc (GL_LEQUAL);
TriangleRenderer3D.get().render(SquareMap.get().shader,worldrenderer.getCamera());
LineRenderer3D.get().render(SquareMap.get().shader,worldrenderer.getCamera());
By rendering the triangles first, and then only drawing the lines where they are either in front of or at the same depth as (default depth test discards this scenario) you should get the behavior you want. Leave depth writes enabled.
Since GL_LINE_SMOOTH is not hardware accelerated, nor supported on all GFX cards, how do you draw smooth lines in 2D mode, which would look as good as with GL_LINE_SMOOTH ?
Edit2: My current solution is to draw a line from 2 quads, which fade to zero transparency from edges and the colors in between those 2 quads would be the line color. it works good enough for basic smooth lines rendering and doesnt use texturing and thus is very fast to render.
So, you want smooth lines without:
line smoothing.
full-screen antialiasing.
shaders.
Alright.
Your best bet is to use Valve's Alpha-Tested Magnification technique. The basic idea, for your needs, is to create a texture that represents the distance from the line, with the center of the texture being a distance of 1.0. This could probably be a 1D texture.
Then using the techniques described in the paper (many of which work with fixed-function, including the antialiased version), draw a quad that represents your lines. Obviously you'll need alpha blending (and thus it isn't order-independent). You use your line width to control the distance at which it becomes the appropriate color, thus allowing you to make narrow or wide lines.
Doing this with shaders is virtually identical to the above, except without the texture. Instead of accessing a distance texture, the distance is passed and interpolated from the vertex shader. For the left-edge of the quad, the vertex shader passes 0. For the right edge, it passes 1. You multiply this by 2, subtract 1, and take the absolute value.
That's your distance from the line (the line being the center of the quad). Then just use that distance exactly as Valve's algorithm does.
Turning on full-screen anti-aliasing and using a quad would be my first choice.
Currently I am using 2 or 3 quads to do this, it is the simpliest way to do it.
If line thickness <= 1px, then you need only 2 quads.
If line thickness > 1px, then you need to add third quad in the middle.
The fading edge quads thickness must not change if the line thickness >= 1px.
In the image below you can see the quads with blue borders. White color means full opacity and black color means zero opacity (=fully transparent).
I wanted to see the wireframe of my triangle mesh, so rather than constructing a whole new VBO I'm trying to use glPolygonMode and draw it again with the exact same draw call. This is because I can't find a draw command that will let me make GL_LINE_LOOP primitives out of every 3 indices from my IBO.
But when I draw the wireframe, the insides of the triangles become black again. Is this because when a fragment is discarded, its color value is set to zero (black)? How could I set it so that a discarded fragment does not get written or blended? Are the fragments actually getting discarded?
I solved it. I set glPolygonMode(GL_FRONT_AND_BACK,GL_LINE) then neglected to set it back to GL_FILL, so all subsequent draws in my loop were wireframe. So it's obvious why the polygons ended up not filled.