I'm having trouble coming up with a way to generate a grid of quads. The idea is to later be able to remove a quad at will but didn't even come close to generate the grid.
I was thinking of using GL_TRIANGLE primitive but failed at setting up the buffer because of vertex order for a triangle.
I was having two for loops for width and height. So a grid of width x height (pseudo):
for y < height y++
for x < width x++
set vertex position (x,y,1)
That could work with GL_TRIANGLE_STRIP, but would that cause trouble later when trying to remove a quad (two triangles)?
I'm using opengl 3.3 and trying to use modern way of doing this. Also skipping indices.
I got a "basic" understanding of opengl, any help appreciated
Related
Step : Find 68 Landmarks on a 2D image (with dlib)
So i know all 68 Coordinates of each landmark!
Create a 3D mask of a generical face (with OpenGL) -> Result
I know all the 3d Coordinates of the face model as well!
Now i want to use this Tutorial to texture map all triangles from the 2d image to the 3D generic Facemodel
Does anyone know an answer of my problem ? If you need more information just give me a message and i will send you what you need. Thanks everybody!
EDIT: After finding this tutorial i changed the size of my picture to get a width and a height which is power of two.
And then a divide all my picture coords (landmarks)with the size:
landmark(x) / height and landmark(y) / width
Picture :
Result:
As bigger the width and the height is as better is the image definition!
What you're seeing looks like you passed all your vertices directly to glDrawArrays without any reuse. So each vertex is used for a single triangle in your result, rather than being used in 6 or more triangles in the original picture.
You need to use an element buffer to describe how all your triangles are made up of the vertices you have, and use glDrawElements to draw them.
Also note that some of your polygons on the original image are in fact not triangles. You'll probably want to insert additional triangles for those polygons (the inside of the eyes).
I am writing a small OpenGL tile map renderer in C# with OpenTK.
To render the tiles I first create a vertex array and then a vertex buffer.
At next I iterate over all tiles and dependent from the tile type I add two triangles to the vertex buffer with the corresponding vertices(texture coords, color, position).
To avoid texture expensive switching I use one big texture with all tile textures named texture atlas.
But I have a problem while working with a texture atlas.
The problem is that I get some artifacts at the edge of some tiles if I zooming out and moving the camera around.
The solutions I found on the internet were...
...to calculate texture coords with half pixel correction.
...to use a texture array
The first one I tried but it didn't worked how expected (More explained below).
The second one I don't know how to work with texture arrays and I couldn't find much about texture arrays on the internet.
I used the following texture filters:
GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMinFilter, (int)TextureMinFilter.Nearest);
GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter, (int)TextureMagFilter.Nearest);
Texture coords calculation with half pixel correction:
text_coord_x = (0.5f + pixel_x) / texture_width;
text_coord_y = (0.5f + pixel_x) / texture_height;
Texture coords calculation without half pixel correction:
text_coord_x = pixel_x / texture_width;
text_coord_y = pixel_y / texture_height;
One tile with half pixel correction:
One tile without half pixel correction:
Multiple tiles with half pixel correction:
Multiple tiles without half pixel correction:
For solve your problem with border at atlas you should left N pixel border around each sprite. This border should contain pixel information depends of tiling what you need. This border may be generated by lot 3d programs.
For example Blender can bake several textures into one with margin options:
Also N pixels width depends from mip levels of future atlas. So if you will add one pixel border then you can to use only single mip level (zero mip level). For two - you can use 0 mip and 1 mip level etc. Make sure that your use mip levels not more them border width was.
I'm currently working on a cylinder shaped terrain produced by a height map.
What happens in the program is simple, there is a texture for the colors of the terrain that has the alpha value of regions in with i want it to be invisible and another texture ARGB with the A being the gray scale for the heights and RGB is the normal for the light.
The texture is such that the A value goes from 1 to 255 and I'm reserving the 0 for the regions with holes, meaning i don't want then to exist.
So in theory no problem, I'm making those regions invisible based on the first texture but on practice what's happening is that the program is considering the 0 as the minimum height and, even with the texture on top, is creating some lines towards this regions of 0, like trying to make its triangle but not getting there because i cut the next vertex by making it invisible.
Notice the lines going to the center of the cylinder
This is how it gets when i stop making those vertex invisible
So, just to say, i used the function Clip() on the pixel shader to make it invisible.
Basically what i need of help:
Is it possible, the same way i use clip() on the pixel shader i do something like that on the vertex shader and get rid of the unwanted vertex?
Basically, is possible to just say to ignore value 0?
Any ideas to fix this? i thinking of making all the vertex that are 0 become the value of his neighbor, that way those lines wouldn't go to the center but to the same plane as the cylinder itself.
Another thing is that we can see that the program is interpolating the values from one vertex to the next, that is why i cuts on halfway through to the invisible vertex
I'm working with Directx11 API with C++ and the program uses Tessellation.
Thank you for your time and will be very glad with any input on this!
Well i did resolve a bit of this issue.
I made the texture with the height values pass through a modifier that created another texture with the zero values substituted by the side pixel with value different then zero or change for 128.0f.
with that it made the weird lines direction be more accurate not going to the center of the cylinder but along the line.
So I'm rendering this diagram each frame:
https://dl.dropbox.com/u/44766482/diagramm.png
Basically, each second it moves everything one pixel to the left and every frame it updates the rightmost pixel column with current data. So a lot of changes are made.
It is completely constructed from GL_LINES, always from bottom to top.
However those black missing columns are not intentional at all, it's just the rasterizer not picking them up.
I'm using integers for positions and bytes for colors, the projection matrix is exactly 1:1; translating by 1 means moving 1 pixel. Orthogonal.
So my problem is, how to get rid of the black lines? I suppose I could write the data to texture, but that seems expensive. Currently I use a VBO.
Render you columns as quads instead with a width of 1 pixel, the rasterization rules of OpenGL will make sure you have no holes this way.
Realize the question is already closed, but you can also get the effect you want by drawing your lines centered at 0.5. A pixel's CENTER is at 0.5, and drawing a line there will always be picked up by the rasterizer in the right place.
I've searched for a while and I've heard of different ways to do this, so I thought I'd come here and see what I should do,
From what I've gathered I should use.. glBitmap and 0s and 0xFF values in the array to make the terrain. Any input on this?
I tried switching it to quads, but I'm not sure that is efficient and the way its meant to be done.
I want the terrain to be able to have tunnels, such as worms. 2 Dimensional.
Here is what I've tried so far,
I've tried to make a glBitmap, so..
pixels = pow(2 * radius, 2);
ras = new GLubyte[pixels];
and then set them all to 0xFF, and drew it using glBitmap(x, y, 0, 0, ras);
This could be then checked for explosions and what not and whatever pixels could be set to zero. Is this a plausible approach? I'm not too good with opengl, can I put a texture on a glBitmap? From what I've seen it I don't think you can.
I would suggest you to use the stencil buffer. You mark destroyed parts of the terrain in the stencil buffer and then draw your terrain with stencil testing enabled with a simple quad without manually testing each pixel.
OK, this is a high-level overview, and I'm assuming you're familiar with OpenGL basics like buffer objects already. Let me know if something doesn't make sense or if you'd like more details.
The most common way to represent terrain in computer graphics is a heightfield: a grid of points that are spaced regularly on the X and Y axes, but whose Z (height) can vary. A heightfield can only have one Z value per (X,Y) grid point, so you can't have "overhangs" in the terrain, but it's usually sufficient anyway.
A simple way to draw a heightfield terrain is with a triangle strip (or quads, but they're deprecated). For simplicity, start in one corner and issue vertices in a zig-zag order down the column, then go back to the top and do the next column, and so on. There are optimizations that can be done for better performance, and more sophisticated ways of constructing the geometry for better appearance, but that'll get you started.
(I'm assuming a rectangular terrain here since that's how it's commonly done; if you really want a circle, you can substitute 𝑟 and 𝛩 for X and Y so you have a polar grid.)
The coordinates for each vertex will need to be stored in a buffer object, as usual. When you call glBufferData() to load the vertex data into the GPU, specify a usage parameter of either GL_STREAM_DRAW if the terrain will usually change from one frame to the next, or GL_DYNAMIC_DRAW if it will change often but not (close to) every frame. To change the terrain, call glBufferData() again to copy a different set of vertex data to the GPU.
For the vertex data itself, you can specify all three coordinates (X, Y, and Z) for each vertex; that's the simplest thing to do. Or, if you're using a recent enough GL version and you want to be sophisticated, you should be able to calculate the X and Y coordinates in the vertex shader using gl_VertexID and the dimensions of the grid (passed to the shader as a uniform value). That way, you only have to store the Z values in the buffer, which means less GPU memory and bandwidth consumed.