I've been given a struct for a 2D triangle with x and y coordinates, a rotation variable, and so on. From the point created by those x and y coordinates, I am supposed to draw a triangle around the point and rotate it appropriately using the rotation variable.
I'm familiar with drawing triangles in OpenGl with GL_TRIANGLES. My problem is somehow extracting the middle of a triangle and drawing the vertices around it.
edit: Yes, what I am looking for is the centroid.
There are different "types" of centers of a triangle. Details on: The Centers of a Triangle. A quick method for finding a center of a triangle is to average all your point's coordinates. For example:
GLfloat centerX = (tri[0].x + tri[1].x + tri[2].x) / 3;
GLfloat centerY = (tri[0].y + tri[1].y + tri[2].y) / 3;
When you find the center, you will need to rotate your triangle about the center. To do this, translate so that the center is now at (0, 0). Perform your rotation. Now reverse the translation you performed earlier.
I guess you mean the centroid of the triangle!?
This can be easily computed by 1/3(A + B + C) where A, B and C are the respective points of the triangle.
If you have your points, you can simply multiply them by your rotation matrix as usual. Hope i got you right.
There are several points in a triangle that can be considered to be its center (orthocenter, centroid, etc.). This section of the Wikipedia article on triangles has more information. Just look at the pictures to get a quick overview.
By "middle" do you mean "centroid", a.k.a. the center of gravity if it were a 3D object of constant thickness and density?
If so, then pick two points, and find the midpoint between them. Then take this midpoint and the third point, and find the point 1/3 of the way between them (closer to the midpoint). That's your centroid. I'm not doing the math for you.
Related
I'm currently trying to map this pool ball texture to a sphere I have created. My approach is as follows:
Generate the sphere vertices
For every sphere vertex, translate that vertexes coordinates from the openGL world to the texture coordinates.
I want the white circle with the '1' in it to appear at the top of the sphere (at z=1), so I am using the x and z coordinates of the sphere vertices.
The texture file I am using has multiple textures. The texture below is the one I am concerned with. In the texture file, the top left of this particular texture is at (0.01, 0.01) and the bottom right is at (0.24, 0.24). If my math is right, this makes the dead center at about (0.115, 0.115). Since I want the white circle to be on top of the ball (z=1), I've come up with the following two lines of code to map the points:
tex_coords[i].x = 0.125 + (verticies[i].x)*0.115;
tex_coords[i].y = 0.125 + (verticies[i].z)*0.115;
My logic is that if X or Z is 0, the respective coordinate is 0.115, which is right in the middle. Otherwise, X and Z range from -1 to 1 so the maximum value we can reach is 0.24 and the minimum value is 0.01.
As you can see in the bottom screenshot, something has gone wrong. If you look very closely you can see that one tiny part of the sphere is colored white.
There was a discrepancy between one of my shaders and my init function. I had a variable called "vTexCoord" in my shaders but was using "vTexCoords" in my init function.
In Cartesian coordinates I have a rectangle with a know height h, width w and 4 corners (x,y). If i have some value r that is the fixed radius of circles, how do I calculate the center points of the smallest number of circles that will totally cover the rectangle?
I think you should refer to existing approaches and choose one, you think is more suitable for you.
I recommend to start from this list of solutions for similar task - Circles Covering Squares
And, as you understand, because this optimization problem is more a mathematical than programmer, my second recommendation is to read related posts at mathematics forum
See, I'm not posting code because I need logic, math, algorithms. Well:
I'm trying to achieve a 3d-looking visual for a top-down tile map using layers and parallax scrolling. The thing is: At the moment I simply set different "speeds" for each layer. But that would only work with some very specific camera positions, also, it makes so that the blocks have virtually an infinite height (as they will "increase in height" until they are out of the camera's FOV).
Is there a better (should be) to achieve the effect? Oh, and I'm using C with Allegro 5.
I thought about limiting each layer's offset, but I have no idea how.
My current method:
That's my current code for the layer "speed" (it repeats for up, down, left and right, changing coordinates):
if (key[ALLEGRO_KEY_UP])
camera_y[0] -= 1;
camera_y[1] -= 2;
camera_y[2] -= 3;
Then I run a loop to draw the map with the tiles relative to the current layer's offset.
By the way, that's the desired effect (example with 3 layers):
For parallax scrolling, layers that scroll faster must be correspondingly larger:
You can use unscaled tiles stacked on top of each other, offset by a fixed fraction of the distance from the center of the tile to the center of the viewport,
but the tops will not be continuous (unless the bottoms overlap). If all layer tiles are hand-drawn or rendered images, this is not an issue.
If the walls are box-shaped, and you have images of the top and each of the four sides, you can draw them in almost 3D,
where at most two sides of each box wall is drawn, skewed.
In all cases:
If the center of the viewport is at world coordinates (xc, yc), point (x, y, z) maps to coordinates (x', y') relative to the center of the viewport:
x' = (x - xc) × (z + z0) / z0
y' = (y - yc) × (z + z0) / z0
where z0 is a constant that determines the "size" of the parallax or depth effect.
I think you're on the right lines, but the "infinite height" issue can be solved by simply giving the camera an "altitude" property, and adjust the "speed" of each layer by calculating ...
layer.speed = (layer.altitude / camera.altitude) * ZOOM_FACTOR; //gives a float value.
Can't really suggest anything more until you show us some of your math code.
Imagine a 3D rectangle at origin. It is first rotated along Y-axis. So good so far. Now, it is rotated around X-axis. However, OpenGL (API: glrotatef) interprets the X-axis to be the global X-axis. How can I ensure that the "axes move with the object"?
This is very much like an airplane. For example, if yaw (Y rotation) is applied first, and then pitch (X-rotation), a correct pitch would be X-rotation along the plane's local axes.
EDIT: I have seen this called gimbal lock problem, but I don't think it is though.
You cannot consistently describe an aeroplane's orientation as one x rotation and one y rotation. Not even if you also store and one z rotation. That's exactly the gimbal lock problem.
The crux of it is that you have to apply the rotations in some order. Say it's x then y then z for the sake of argument. Then what happens if the x rotation is by 90 degrees? That folds the y axis onto where the z axis was. Then say the y rotation is also by 90 degrees. That's now bent the z axis onto where the x axis was. So now what effect does any z rotation have?
That's just an easy to grasp example. It's not a special case. You can't wave your hands out of it by saying "oh, I'll detect when to do z rotations first" or "I'll do 90 degree rotations with a special pathway" or any other little hack. Trying to store and update orientations as three independent scalars doesn't work.
In classic OpenGL, a call to glRotatef means "... and then rotate the current matrix like this". It's not relative to world coordinates or to model coordinates or to any other space that you're thinking in.
I'm writing a 2D game using OpenGL. When I want to blit part of a texture as a sprite I use glTexCoord2f(u, v) to specify the UV co-ordinates, with u and v calculated like this:
GLfloat u = (GLfloat)xpos_in_texture/(GLfloat)width_of_texture;
GLfloat v = (GLfloat)ypos_in_texture/(GLfloat)height_of_texture;
This works perfectly most of the time, except when I use glScale to zoom the game in or out. Then floating point rounding errors cause some pixels to be drawn one to the right of or one below the intended rectangle within the texture.
What can be done about this? At the moment I'm subtracting an 'epsilon' value from the right and bottom edges of the rectangle, and it seems to work but this seems like a horrible kludge. Are there any better solutions?
Your issue is most likely not coming from rounding errors, but a misunderstanding on how OpenGL maps texels to pixels. If you notice off-by-one errors, it's probably because your UVs, your vertex positions or your projection matrix/viewport pair are not aligned to where they ought to be.
To simplify, I'll just talk about 1D, and be assuming you use a projection and a viewport that map X,Y coordinates to the equivalent pixel location (i.e. a glOrtho(0,width,0,height,zmin,zmax) and a glViewport(0,width,0,height).
Say you want to draw 5 texels (starting at 0 for simplicity) of your 64-wide texture showing on the 10 pixels (scale of 2) of your screen starting at pixel 20.
To get there, draw the triangle with X coordinates 20 and 30, and U (of the UV pair) of 10/64 and 15/64. The rasterization of OpenGL will generate 10 pixels to shade, with X coordinates 20.5, 21.5, ... 29.5. Note that the positions are not full integers. OpenGL rasterizes in the middle of the pixel.
Likewise, it will generate U coordinates of 10.25/64, 10.75/64, 11.25/64, 11.75/64 ... 14.25/64, 14.75/64. Note again that texel coordinates, brought back to texel positions in the texture space, are not full integers. OpenGL samples from the middle of texel locations, so this is fine.
How the samplers use these UVs to generate texel values depend on filtering modes, but be it nearest or linear, the pixels should be contained solely inside the texels of interest (0.25 with a size of 0.5 should only use color from 0 to 0.5, which is all inside the first texel).
In general, if you follow the general principles I laid out, you should never see artifacts.
Use Ortho and Viewport of exactly your frame buffer size
Use positions of X, X+width exactly
Use UVs that correspond to exactly the texels you want (if you want the 10 texels starting from the texel 0, use U=0 to U=10.
If you ever have a -1 somewhere in your math, it's likely not correct (for position or UVs).
To get back to your example, it's unclear how you link the uvs you compute to positions (since you don't show the position computation).
It's also unclear how you got xpos_in_texture (you should explain how you computed them for the corners of your sprite). My guess is that you computed that wrong.
A bit late, but for posterity I was having the same problem, with the pixels from adjacent regions of a texture atlas bleeding into sprites/tiles when scaling or zooming the view. I had my glOrtho, glViewport, etc dimensions all set correctly, then I realized the problem was I was scaling the view before translating the camera, which meant that even though I was snapping to integer pixels pre-zoom, after the zoom it would align to a fraction of a pixel and introduce the texel problem.
So if your code looks something like this, where camera.zoom is a non-integer (i.e. 0.75):
glScalef(camera.zoom, camera.zoom, 1.0f);
glTranslatef(camera.x, camera.y, 0.0f);
You'll want to make sure the result of the translation after scaling aligns to whole pixels on the screen, so you can do something like:
glScalef(camera.zoom, camera.zoom, 1.0f);
glTranslatef(
floor(camera.x * camera.zoom) / camera.zoom,
floor(camera.y * camera.zoom) / camera.zoom,
0.0f);
Do the division as a double, round the result down yourself to the desired level of precision, then cast it to GLFloat.
Your xpos/ypos must be based on 0 to (width or height) - 1 and then:
GLfloat u = (GLfloat)xpos_in_texture/(GLfloat)(width_of_texture - 1);
GLfloat v = (GLfloat)ypos_in_texture/(GLfloat)(height_of_texture - 1);