I am working on a 3D renderer, and as I was loading various test models, I noticed that everything looked OK, except for the fact the the textures were all flipped on the x-axis.
This is actually previewed as I'm blitting my GBuffer to the screen, so it can't be a FBO-rendering problem.
After I load each .obj file, I prepare its VBOs. Here's the snippet setting up the texture coordinates:
for(Face f : master.faces) {
for(int i = pointsPerFace - 1; i >= 0; i--) {
uv[0] = f.texCoords[i].x;
uv[1] = f.texCoords[i].y;
texcoords.append(uv);
}
}
Things like replacing a coordinate with 1 - coordinate don't really work, since that would flip the whole bitmap, not just the current triangle.
What could cause everything to be rendering x-flipped?
except for the fact the the textures were all flipped on the x-axis.
I think what's actually happening is, that the model's geometry is flipped on the Z axis. The usual transformation setup used with OpenGL uses a right handed coordinate system. If the object has been designed saved for left handed, one axis is swapped and this also affects the texture application of course.
Things like replacing a coordinate with 1 - coordinate don't really work
Yes it would, because…
since that would flip the whole bitmap, not just the current triangle.
… that's exactly what you'd require, if doing it this way. But first I'd check if the model geometry is loaded correctly, i.e. with the right handedness. If not, I'd simply flip the Z axis of the geometry.
Related
As a simple demonstration of my problem, I am trying to render a large but simple mesh to a texture to be used later, but strangely enough, the further-away-from-the-camera parts of this mesh are displayed in front of the closer-to-the-camera parts, when viewed from a specific angle. Despite the undeniable fact that I do beyond all doubt use depth testing:
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LESS);
As an example, I am trying to render a subdivided grid (on the xz plane) centered on the origin, with a smooth "hill" in the middle of the grid.
When rendered to the screen no errors occur and the mesh looks like this (rendered using orthographic projection, and with the greyscale color representing depth, no error will furthermore occur even if the mesh is viewed from any side):
Rendering to the screen is of course done by making sure the framebuffer is set to 0 (glBindFramebuffer(GL_FRAMEBUFFER, 0);), but i need to render this scene to another framebuffer which is not my screen, in order to use this render as a texture.
So i have set up another framebuffer, and an output texture, and now i am redering this scene to the framebuffer (with absolutely nothing changed, except the framebuffer and the viewport size, which is set to match the output texture). For the purpose of demonstrating the error, which I am experiancing, I am then then rendering this rendered texture, onto a plane which is then displayed on the screen.
When the mesh is rotated seen from the positive x axis, and rotated around the y axis, centered on its origin between -0.5 π rad and 0.5 π rad, the rendered texture looks exactly identical to the result when rendering to the screen, as seen on the image above.
However when rotation around the y axis is greater than 0.5 π rad or less than -0.5 π rad the closer-to-the-camera hill is rendered behind the further-away-from-the-camera plane (the fact that the hill is closer to the camera can be proven by looking at the color, which represents debth):
(whoops got the title wrong on the window, ignore that)
In the borderregions with a rotation around the y axis of close to 0.5 π rad or -0.5 π rad the scene looks like this.
(whoops got the title wrong on the window again, ignore that again)
To recap. This error with the depth sorting happens only when rendering to a texture using a framebuffer, and only when the object is viewed from a specific angle. When the object is rendered directly to the screen, no error occurs. My question is therefor: why does this happen, and how (if at all) can I avoid avoid it.
If this problem only happens when you're rendering to the texture framebuffer, you probably don't have a depth attachment properly linked to it.
Make sure that during FBO init you are linking it to a depth texture as well.
There's a good example of how to do this here.
Also, check all of the matrices you're using to render -- I've had several cases in the past where improper matrices have thrown off depth calculations.
I've got a very specific problem. I have an OpenGL application that is used to render video onto 3D meshes. As it turns out, I can make my video sources send me rectangular portions of the image, reducing memory usage. These portions are specified as a Rectangle2D(int x, int y, int width, int height) with 0 <= x <= w <= sourceVideoWidth and 0 <= y <= h <= sourceVideoHeight.
With that said, I want to find out, for each frame, and for each mesh the following:
Whether the mesh is visible
If so, what portion of image should I request
The benefit is reducint the texture upload to GPU, this operation is often the bottleneck in my application.
In order to simplify the problem let's make the assumption that all meshes are 3D rectangles arbitrarily positioned. A 3D rectangle is defined by four points:
class Rectangle3D
{
public:
Vec3 topLeft;
Vec3 topRight;
Vec3 botLeft;
Vec3 botRight;
}
Possible solutions:
A) Split the mesh into a point grid of points with known texture coordinates, and run frustum culling for each point, then, from the visible points find the top left and bottom right texture coordinates that we must request. This is rather inefficient, and the number of points to test multiplies when we add another mesh to the scene. Solutions that use just the four corners of the rectangle might be preferable.
B) Using the frustum defining planes (see frustum culling). For further simplicity, using only the four planes that correspond to the screen sides. Finding out whether the mesh is visible is rather simple. Finding the visible texture coordinates would need several cases:
- One or more frustum sides intersect with the mesh
- No frustum sides intersect with the mesh
- Either the mesh is fully visible
- Or the mesh is surrounding the screen sides
In any case I need several plane-plane and plane-line segment intersections. Which are not necessarily efficient.
C) Make a 2D projection of the Rectangle3D lines, resulting into a four side polygon, then using line segment intersection between the screen sides and the polygon sides. Also accounting for cases where we have no intersection and the mesh is still visible.
D) Using OpenGL occlusion query objects, this way a render pass could generate information about the visible mesh portion.
Is there any other solution that best solves this problem? If not which one would you use and why?
Just one more thought on to your solutions,
Why don't you incorporate one rendering pass for occlusion queries. Split your mesh into imaginary rectangles which tells you about the visible parts of the mesh. Like
Left part of the image is with imaginary sub-rectangles, right part of the image shows sub-rectangles visible within the screen area (red rectangle in this case). Based on this pass result, you will get the co-ordinates of mesh which are visible.
UPDATE:
This is a sample view that explains my point. This can be done by using opengl query objects.
r is result of GL_SAMPLES_PASSED
Since you will know which rectangles are visible through the result of the query objects , you will come to know which co-ordinates are visible.Google for opengl occlusion queries you will get detailed info. Hope this helps.
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.
So Im trying to figure out the best way to render a 3D model in OpenGL when some of the textures applied to it have alpha channels.
When I have the depth buffer enabled, and start drawing all the triangles in a 3D model, if it draws a triangle that is in front of another triangle in the model, it will simply not render the back triangle when it gets to it. The problem is when the front triangle has alpha transparency, and should be able to be seen through to the triangle behind it, but the triangle behind is still not rendered.
Disabling the depth buffer eliminates that problem, but creates the obvious issue that if the triangle IS opaque, then it will still render triangles behind it on top if rendered after.
For example, I am trying to render a pine tree that is basically some cones stacked on top of each other that have a transparent base. The following picture shows the problem that arises when the depth buffer is enabled:
You can see how you can still see the outline of the transparent triangles.
The next picture shows what it looks like when the depth buffer is disabled.
Here you can see how some of the triangles on the back of the tree are being rendered in front of the rest of the tree.
Any ideas how to address this issue, and render the pine tree properly?
P.S. I am using shaders to render everything.
If you're not using any partial transparency (everything is either 0 or 255), you can glEnable(GL_ALPHA_TEST) and that should help you. The problem is that if you render the top cone first, it deposits the whole quad into the z-buffer (even the transparent parts), so the lower branches underneath get z-rejected when its their time to be drawn. Enabling alpha testing doesn't write pixels to the z buffer if they fail the alpha test (set with glAlphaFunc).
If you want to use partial transparency, you'll need to sort the order of rendering objects from back to front, or bottom to top in your case.
You'll need to leave z-buffer enabled as well.
[edit] Whoops I realized that those functions I don't believe work when you're using shaders. In the shader case you want to use the discard function in the fragment shader if the alpha value is close to zero.
if(color.a < 0.01) {
discard;
} else {
outcolor = color;
}
You needs to implement a two-pass algorithm.
The first pass render only the back faces, while the second pass render only the front faces.
In this way you don't need to order the triangles, but some artifacts may occour depending whether your geometry is convex or not.
I may be wrong, but this is because when you render in 3d you do no render the backside of triangles using Directx's default settings, when the Z is removed - it draws them in order, with the Z on it doesnt draw the back side of the triangles anymore.
It is possible to show both sides of the triangle, even with Z enabled, however I'm thinking there might be a reason its normally enabled.. such as speed..
Device->SetRenderState(D3DRS_CULLMODE, Value);
value can equal
D3DCULL_NONE - Shows both sides of triangle
D3DCULL_CW - Culls Front side of triangle
D3DCULL_CCW - Default state
Short Version
How can I draw short text labels in an OpenGL mapping application without having to manually recompute coordinates as the user zooms in and out?
Long Version
I have an OpenGL-based mapping application where I need to be able to draw data sets with up to about 250k points. Each point can have a short text label, usally about 4 or 5 characters long.
Currently, I do this using a single textue containing all the characters. For each point, I define a quad for each character in its label. So a point with the label "Fred" would have four quads associated with it, and each quad uses texture coordinates into that single texture to draw its corresponding character.
When I draw the map, I draw the map points themselves in map coordinates (e.g., longitude/latitude). Then I compute the position of each point in screen coordinates and update the four corner points for each of that point's label quads, again in screen coordinates. (For instance, if I determine the point is drawn at screen point 100, 150, I could set the quad for the first character in the point's label to be the rectangle starting with left-top point of 105, 155 and having a width of 6 pixels and a height of 12 pixels, as appropriate for the particular character. Then the second character might start at 120, 155, and so on.) Then once all these label character quads are positioned correctly, I draw them using an orthogonal screen projection.
The problem is that the process of updating all of those character quad coordinates is slow, taking about half a second for a particular test data set with 150k points (meaning that, since each label is about four characters long, there are about 150k * [ 4 characters per point] * [ 4 coordinate pairs per character] coordinate pairs that need to be set on each update.
If the map application didn't involve zooming, I would not need to recompute all these coordinates on each refresh. I could just compute the label coordinates once and then simply shift my viewing rectangle to show the right area. But with zooming, I can't see how to make it work without doing coordniate computation, because otherwise the characters will grow huge as you zoom in and tiny as you zoom out.
What I want (and what I understand OpenGL doesn't provide) is a way to tell OpenGL that a quad should be drawn in a fixed screen-coordinate rectangle, but that the top-left position of that rectangle should be a fixed distance from a given point in map coordinate space. So I want both a primitive hierarchy (a given map point is that parent of its label character quads) and the ability to mix two different coordinate systems within this hierarchy.
I'm trying to understand whether there is some magic transformation matrix I can set that will do all this form me, but I can't see how to do it.
The other alternative I've considered is using a shader on each point to handle computing the label character quad coordinates for that point. I haven't worked with shaders before, and I'm just trying to understand (a) if it's possible to use shaders to do this, and (b) whether computing all those points in shader code actually buys me anything over computing them myself. (By the way, I have confirmed that the big bottleneck is computing the quad coordinates, not in uploading the updated coordinates to the GPU. The latter takes a bit of time, but it's the computation, the sheer number of coordinates being updated, that takes up the bulk of that half second.)
(Of course, the other other alternative is to be smarter about which labels need to be drawn in a given view in the first place. But for now I'd like to concentrate on the solution assuming all labels need to be drawn.)
So the basic problem ("because otherwise the characters will grow huge as you zoom in and tiny as you zoom out") is that you are doing calculations in map coordinates rather than screen coordinates? And if you did it in screen coords, this would require more computations? Obviously, any rendering needs to translate from map coordinates to screen coordinates. The problem seems to be that you are translating from map to screen too late. Therefore, rather than doing a single map-to-screen for each point, and then working in screen coords, you are working mostly in map coords, and then translating per-character to screen coords at the very end. And the slow part is that you are working in screen coords, then having to manually translate back to map coords just to tell OpenGL the map coords, and it will convert those back to screen coords! Is that a fair assessment of your problem?
The solution therefore is to push that transformation earlier in your pipeline. However, I can see why it is tricky, because at first glance, OpenGL seems want to do everything in "world coordinates" (for you, map coords), but not in screen coords.
Firstly, I am wondering why you are doing separate coordinate calculations for each character. What font rendering system are you using? Something like FreeType will automatically generate a bitmap image of an entire string, and doesn't require you to work per-character [edit: this isn't quite true; see comments]. You definitely shouldn't need to calculate the map coordinate (or even screen coordinate) for every character. Calculate the screen coordinate for the top-left corner of the label, and have your font rendering system produce the bitmap of the entire label in one go. That should speed things up about fourfold (since you assume 4 characters per label).
Now as for working in screen coords, it may be helpful to learn a bit about shaders. The more you learn about OpenGL, the more you learn that really it isn't a 3D rendering engine at all. It's just a 2D graphics library with some very fast matrix primitives built-in. OpenGL actually works, at the lowest level, in screen coordinates (not pixel coordinates -- it works in normalized screen space, I think from memory from -1 to 1 in both the X and Y axis). The only reason it "feels" like you're working in world coordinates is because of these matrices you have set up.
So I think the reason why you are working in map coords all the way until the end is because it's easiest: OpenGL naturally does the map-to-screen transform for you (using the matrices). You have to change that, because you want to work in screen coords yourself, and therefore you need to make the transformation a long time before OpenGL gets its hands on your data. So when you go to draw a label, you should manually apply the map-to-screen transformation matrix on each point, as follows:
You have a particular point (which needs a label drawn) in map coords.
Apply the map-to-screen matrix to convert the point to screen coords. This probably means multiplying the point by the MODELVIEW and PROJECTION matrices, using the same algorithm that OpenGL does when it's rendering a vertex. So you could either glGet the GL_MODELVIEW_MATRIX and GL_PROJECTION_MATRIX to extract OpenGL's current matrices, or you could manually keep around a copy of the matrix yourself.
Now you have the map label in screen coords, compute the position of the label's text. This is simply adding 5 pixels in the X and Y axis, as you said above. However, remember that you aren't in pixel space, but normalised screen space, so you are working in percentages (add 0.05 units, would add 5% of the screen space, for example). It's probably better not to think in pixels, because then your application will scale to match the resolution. But if you really want to think in pixels, you will have to calculate the pixels-to-units based on the resolution.
Use glPushMatrix to save the current matrix, then glLoadIdentity to set the current matrix to the identity -- tell OpenGL not to transform your vertices. (I think you will have to do this for both the PROJECTION and MODELVIEW matrices.)
Draw your label, in screen coordinates.
So you don't really need to write a shader. You could certainly do this in a shader, and it would certainly make step 2 faster (no need to write your own software matrix multiply code; multiplying matrices on the GPU is extremely fast). But that would be a later optimisation, and a lot of work. I think the above steps will help you work in screen coordinates and avoid having to waste a lot of time just to give OpenGL map coordinates.
Side comment on:
"""
generate a bitmap image of an entire string, and doesn't require you to work per-character
...
Calculate the screen coordinate for the top-left corner of the label, and have your font rendering system produce the bitmap of the entire label in one go. That should speed things up about fourfold (since you assume 4 characters per label).
"""
Freetype or no, you could certainly compute a bitmap image for each label, rather than each character, but that would require one of:
storing thousands of different textures, one for each label
It seems like a bad idea to store that many textures, but maybe it's not.
or
rendering each label, for each point, at each screen update.
this would certainly be too slow.
Just to follow up on the resolution:
I didn't really solve this problem, but I ended up being smarter about when I draw labels in the first place. I was able to quickly determine whether I was about to draw too many characters (i.e., so many characters that on a typical screen with a typical density of points the labels would be too close together to read in a useful way) and then I simply don't label at all. With drawing up to about 5000 characters at a time there isn't a noticeable slowdown recomputing the character coordinates as described above.