I have two simple cube-shaped primitives that are pushed together. Where the polygons connect, there is a razor-thin seam where the polygon edges match up (see pic, red arrow).
Each face owns its own vertices, they are not shared with indicia. I have confirmed with debugging that the coordinates of the vertices at each end of the seam that should be occupying the same position ARE occupying the same position/normal/uv. The winding of the faces that join together are the same. I have even adjusted the code to MANUALLY COPY the positions, normals, and UV of the vertices in question just in case there was some floating point error that was too small to be display.
Can anyone explain what's going on here? Is there a way to fix it without literally joining those vertices into a single vertex and indexing it?
I've included a wireframe pic in the screenshot as well. I can tell from the wireframe that the two lines, though overlapping, are a bit off. But with all coordinates at the same value, what is it??
Related
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 have this polygon with a hole when rendered in translucent color in openGL, it shows some sort of artifacts along seams of tessellated triangles (by GLUtesselator). This is a bit of strange because the same polygon would not have such artifacts if it's drawn in opaque color.
Artifacts seen as doted line extended from inner circle to outer boundary of polygon:
More artifacts seen in interior of the polygon:
It appears like bleeding from alpha blending of color between two adjacent triangles' edges. But I have no idea of how to mitigate the problem.
Has anyone seen this problem before? or can someone point out what the problem might be and a possible solution for me?
OpenGL guarantees that drawing two triangles that share an edge will produce each covered fragment exactly once, thus you could render artifact-free translucent polygons.
However, this guarantee holds only if both vertices of that edge are identical between the two triangles. Also it won't hold if you anti-alias your polygons with GL_SMOOTH_POLYGON.
It's hard to tell what's the case here without seeing the relevant code, but I would definitely check the coordinates of the vertices of the shared edges to see if they are the same.
I've got a model that I've loaded from a JSON file (stored as each tile /w lots of bools for height, slope, smooth, etc.). I've then computed face normals for all of it's faces and copied them to each of their verticies. What I now want to do (have been trying for days) is to smooth the vertex normals, in the simplest way possible. What I'm trying to do is set each vertex normal to a normalized sum of it's surrounding face normals. Now, my problem is this:
The two circled vertices should end up with perfectly mirrored normals. However, the one on the left has 2 light faces and 4 dark faces. The one on the right has 1 light face and 6 dark faces. As such, they both end up with completely different normals.
What I can't work out is how to do this properly. What faces should I be summing up? Or perhaps there is a completely different method I should be using? All of my attempts so far have come up with junk and / or consisted of hundreds of (almost certainly pointless) special cases.
Thanks for any advice, James
Edit: Actually, I just had a thought about what to try next. Would only adding a percentage of each triangle based on it's angle work (if that makes sense). I mean, for the left, clockwise: x1/8, x1/8, x1/4, x1/8, x1/8, x1/4 ???
And then not normalize it?
That solution worked wonderfully. Final result:
Based on the image it looks like you might want to take the average of all unique normals of all adjacent faces. This avoids double counting faces with the same normal.
I have two quads for which I need to find the normal.The co-ordinates are as follows
for quad 1:
(-2,1.25,-1)
(-2,2.2,0)
(1,2.2,0)
(2,1.25,-1)
I have got the normal as (0,.73,-.69)
for quad 2:
(-2,2.2,0)
(2,2.2,0)
(2,1.25,1)
(-2,1.25,1)
normal:(0,.73,.69)
I have already calculated the normals.Can someone please confirm whether these normals are correct?
Also I read about normal pointing inwards and outwards..would someone explain that concept to me?
Your normals basically look correct. For the first quad, I get:
(0.0, 0.725, -0.689)
For the second one:
(0.0, -0.725, -0.689)
As you can see, I got the opposite sign for the second normal. Which leads directly to the second part of your question.
The term "outwards" does not really make sense for a isolated quad. It is mostly applied to closed shapes, where it should make intuitive sense. Picture a sphere, with a normal vector drawn starting at a point on the sphere. The normal pointing "outwards" means that it points away from the center of the cube, which means that it points to the outside. "inwards" is then of course the opposite, where the normal points towards the center of the sphere, or to the inside of the shape.
There's another way of looking at it, since normals are mostly used for lighting calculations. The normals need to point to the side of the surface that you want to see lighted. Most often, you look at shapes from the outside, so you want the outside lighted. Which means that you mostly want the normals pointing outwards. If you have open surfaces that need to be lighted when viewed from either side, there are slightly more complex lighting calculations that can handle that, which are typically found under "two-sided lighting".
There's a related concept that is also important here, which is the "winding order". It defines if the vertices are arranged clockwise or counter-clockwise when viewing them from a certain direction. OpenGL uses the winding order to decide if a triangle faces the viewer. Again, you care about having the desired winding order when looking at the surface from the outside, or more generally from the side you want to see when you display the surface. OpenGL uses counter-clockwise winding by default, so you want counter-clockwise winding when looking at a surface from the side you want to be visible, which for closed shapes is mostly from the outside. You can often get away with the winding order being "wrong" if you don't eliminate backwards facing triangles, which is done with glEnable(GL_CULL_FACE). But in any case, you can save yourself from running into problems later if you always use a consisting winding order for your primitives.
This leads us back to the normal calculation. Since only the sign ended up different, none of our calculations are technically wrong. I assumed that the quads used counter-clockwise winding, which means that I see the "outside" of the quad from the direction where the vertices appear in counter-clockwise order. Since I also want the normals pointing towards the outside, I calculated the normals that way. In other words, with the normal I calculated, if you move away from the quad in direction of the normal, and then look back at the quad, the vertices would be in counter-clockwise order.
http://img136.imageshack.us/img136/3508/texturefailz.png
This is my current program. I know it's terribly ugly, I found two random textures online ('lava' and 'paper') which don't even seem to tile. That's not the problem at the moment.
I'm trying to figure out the first steps of an RPG. This is a top-down screenshot of a 10x10 heightmap (currently set to all 0s, so it's just a plane), and I texture it by making one pass per texture per quad, and each vertex has alpha values for each texture so that they blend with OpenGL.
The problem is that, notice how the textures trend along diagonals, and even though I'm drawing with GL_QUAD, this is presumably because the quads are turned into sets of two triangles and then the alpha values at the corners have more weight along the hypotenuses... But I wasn't expecting that to matter at all. By drawing quads, I was hoping that even though they were split into triangles at some low level, the vertex alphas would cause the texture to radiate in a circular outward gradient from the vertices.
How can I fix this to make it look better? Do I need to scrap this and try a whole different approach? IS there a different approach for something like this? I'd love to hear alternatives as well.
Feel free to ask questions and I'll be here refreshing until I get a valid answer, so I'll comment as fast as I can.
Thanks!!
EDIT:
Here is the kind of thing I'd like to achieve. No I'm obviously not one of the billions of noobs out there "trying to make a MMORPG", I'm using it as an example because it's very much like what I want:
http://img300.imageshack.us/img300/5725/runescapehowdotheytile.png
How do you think this is done? Part of it must be vertex alphas like I'm doing because of the smooth gradients... But maybe they have a list of different triangle configurations within a tile, and each tile stores which configuration it uses? So for example, configuration 1 is a triangle in the topleft and one in the bottomright, 2 is the topright and bottomleft, 3 is a quad on the top and a quad on the bottom, etc? Can you think of any other way I'm missing, or if you've got it all figured out then please share how they do it!
The diagonal artefacts are caused by having all of your quads split into triangles along the same diagonal. You define points [0,1,2,3] for your quad. Each quad is split into triangles [0,1,2] and [1,2,3]. Try drawing with GL_TRIANGLES and alternating your choice of diagonal. There are probably more efficient ways of doing this using GL_TRIANGLE_STRIP or GL_QUAD_STRIP.
i think you are doing it right, but you should increase the resolution of your heightmap a lot to get finer tesselation!
for example look at this heightmap renderer:
mdterrain
it shows the same artifacts at low resolution but gets better if you increase the iterations
I've never done this myself, but I've read several guides (which I can't find right now) and it seems pretty straight-forward and can even be optimized by using shaders.
Create a master texture to control the mixing of 4 sub-textures. Use the r,g,b,a components of the master texture as a percentage mix of each subtextures ( lava, paper, etc, etc). You can easily paint a master texture using paint.net, photostop, gimp and just paint into each color channel. You can compute the resulting texture before hand using all 5 textures OR you can calculate the result on the fly with a fragment shader. I don't have a good example of either, but I think you can figure it out given how far you've come.
The end result will be "pixel" pefect blending (depends on the textures resolution and filtering) and will avoid the vertex blending issues.