I am loading models from obj, colladae files where individual faces of the mesh are not triangulated if all the faces are perfect quads when exporting to save memory.
Now I know this won't work for most models but for some meshes say a cube where some amount of duplication can be avoided along each face I want to make it work.
I have 2 options using triangle strips or gl_quads.
The problem with triangle strips is that neighbouring faces are connected so it is impossible to have some gap between them,even for a simple cube the output looks correct on the outside but when I go inside the cube even with back face culling enabled I see some stray triangles connecting the front and back of the cube and basically it's a whole jumbled mess.
But with gl_quads everything works correctly but the docs say that quads is deprecated in 3.1 [even though I can still use it gl 4.0] so my question is
Can I continue using gl_quads for loading meshes from files without running into problems in the future or how can I replace it with triangle strips without the whole connectivity issue?.
One solution I found was to issue a draw call for every 4 vertices in a for loop but this is terrible for performance for an huge mesh.
Any suggestions?
Can we still use GL_QUADS?
Yes, if using a compatibility profile OpenGL context.
Can I continue using gl_quads for loading meshes from files without running into problems in the future...?
Platforms may choose not to implement the compatibility profile. Most desktop platforms do and have done so since forever. Would surprise me if existing implementations decided to drop it.
...or how can I replace it with triangle strips without the whole connectivity issue?
One way to render disconnected quads (or triangle strips in general) is to draw two vertices in the same point and then move to where the next strip should continue, see this question.
The simpler way is to generate a sequence of indices like [1 2 3, 1 3 4, 5 6 7, 5 7 8, ...] and render the mesh of quads using those indices.
Related
Today, I started to implement a wavefront obj loader and the thing is that I don't know why there are so many obj files on the internet containing 4 vertices despite the fact that OpenGL no longer supports GL_QUADS and deprecates its use.
Is there any workaround on this? I mean, everytime I try to draw a face containing 4 vertices using GL_TRIANGLE_FAN or GL_TRIANGLE_STRIP, it shows tragic result. So in the end I have no option but to issue draw command on each face and as you know, it shows bad performance. I want to draw it issuing only one command on each group or smoothing group.
Any ideas?
Because OBJ is a file format that is completely unrelated to OpenGL.
Face statements in OBJ files can contain any number of vertices, not only 3 or 4. And it's not unusual for them to contain more than 4. So if you want to be able to read a reasonable variety of OBJ files, you need to be prepared to read any number of vertices per face.
This really does not add much difficulty. Unless you use an algorithm to analyze connectivity, and build meshes, you get a separate triangle per face statement anyway, even for files with only 3 vertices per face. So in that case, you create one triangle per face, and draw them with primitive type GL_TRIANGLES.
So all that changes with more than 3 vertices per face is that you generate multiple triangles per face. You will need n - 2 triangles for a face with n vertices. My answer to this question explains in more detail how this is done: Converting quadriladerals in an OBJ file into triangles?.
Another option is that you treat each face as a triangle fan, and render them with the GL_TRIANGLE_FAN primitive type. A convex polygon (and all of this would break down if faces in the file are non-convex polygons) can always be drawn as a triangle fan, while keeping the vertices exactly in their original order. To treat each face as a separate triangle fan, you can use the primitive restart feature that has been available since OpenGL 3.1, using calls like:
glEnable(GL_PRIMITIVE_RESTART);
glPrimitiveRestartIndex(...);
It's easy to tell that OBJ is not targeting OpenGL rendering. The much more cumbersome aspect is that OBJ uses separate indices for positions, normals, and texture coordinates, while OpenGL only supports a single set of indices which are used for all vertex attributes. This tends to cause much more difficulties for people writing parsers. See for example here: OpenGL - Index buffers difficulties.
If you have a modelling program that can open/export objs like Maya or Blender, I'd recommend opening the model there, triangulating it using the appropriate menu option, and then re-exporting it.
If you don't have access to any of those, it should be relatively simple to write a program that reads in the obj data, triangulates it, and writes it to a file. You'll need a bit of a deeper understanding of the obj format, but it won't require any additional software.
I am drawing transparent cubes,which share vertices, in a grid(Windows 7 VC++ VS 2012). Problem is when i rotate the picture i see strange visual effect in planes where cubes touch each other. Is this effect because of that reason only and i need to remove the shared faces? Or there is some other trick to it?
Does it have anything to do with face/orientation of the cube surface? btw i have tried a lot of these already but cant make it work perfectly.
If you assure a consistent process when defining triangle vertex numbering this issue can be avoided. Typically you number vertices counter-clockwise 0, 1, 2 Doing this tells the OpenGL state machine which side is up. Depending on your needs there is a GL flag you can set to color in or not front and/or back of such triangles ... let us know how you get on
So basicly I am creating a 2D game. I am using VBOs and GLSL Shaders. Now what I do is that every texture I load, I create a VBO for it, so every drawable object that uses that texture it's elements will be inserted into that VBO. So a while ago I was trying to create a grid like object by creating a lot of small boxes and positioning them next to each other. They were all in the same VBO because they all had the same texture to create the grid like object. Once they got like over 10 or so, they started having weird artifacts.
So I by-passed this by creating one big drawable and repeating the texture over it multiple times. The artifacts were gone. Now I started doing text mapping (Each letter is an instance but they share the same texture, text map) and I have noticed when I go over 6 letters artifacts start to appear. I have no idea why this is happening I dont have even a lead.
So I was wondering if anyone has a clue to what might be causing this problem..
Note: I noticed also that in my lighting system (same texture but different RGB values) that if I put two lights too close to each other, that they intersect after like 3 the artifacts start. This might be the caus, because the text actually intersects due to padding.. How can I fix 2 textures that intersect and use the same texture that caus artifacts?
Edit: ^^^ Never mind that I removed the padding and the artifacts were still there..
Solved. The problem was that in glDrawElements 2nd argument I was passing in a number that was larger than the actual amount of indexes I had, so OpenGL was trying to render extra triangles.
I'm making a voxel engine in C++ and OpenGL (à la Minecraft) and can't get decent fps on my 3GHz with ATI X1600... I'm all out of ideas.
When I have about 12000 cubes on the screen it falls to under 20fps - pathetic.
So far the optimizations I have are: frustum culling, back face culling (via OpenGL's glEnable(GL_CULL_FACE)), the engine draws only the visible faces (except the culled ones of course) and they're in an octree.
I've tried VBO's, I don't like them and they do not significantly increase the fps.
How can Minecraft's engine be so fast... I struggle with a 10000 cubes, whereas Minecraft can easily draw much more at higher fps.
Any ideas?
#genpfault: I analyze the connectivity and just generate faces for the outer, visible surface. The VBO had a single cube that I glTranslate()d
I'm not an expert at OpenGL, but as far as I understand this is going to save very little time because you still have to send every cube to the card.
Instead what you should do is generate faces for all of the outer visible surface, put that in a VBO, and send it to the card and continue to render that VBO until the geometry changes. This saves you a lot of the time your card is actually waiting on your processor to send it the geometry information.
You should profile your code to find out if the bottleneck in your application is on the CPU or GPU. For instance it might be that your culling/octtree algorithms are slow and in that case it is not an OpenGL-problem at all.
I would also keep count of the number of cubes you draw on each frame and display that on screen. Just so you know your culling routines work as expected.
Finally you don't mention if your cubes are textured. Try using smaller textures or disable textures and see how much the framerate increases.
gDEBugger is a great tool that will help you find bottlenecks with OpenGL.
I don't know if it's ok here to "bump" an old question but a few things came up my mind:
If your voxels are static you can speed up the whole rendering process by using an octree for frustum culling, etc. Furthermore you can also compile a static scene into a potential-visibility-set in the octree. The main principle of PVS is to precompute for evere node in the tree which other nodes are potential visible from it and store pointers to them in a vector. When it comes to rendering you first check in which node the camera is placed and then run frustum culling against all nodes in the PVS-vector of the node.(Carmack used something like that in the Quake engines, but with Binary Space Partitioning trees)
If the shading of your voxels is kindalike complex it is also fast to do a pre-Depth-Only-Pass, without writing into the colorbuffer,just to fill the Depthbuffer. After that you render a 2nd pass: disable writing to the Depthbuffer and render only to the Colorbuffer while checking the Depthbuffer. So you avoid expensive shader-computations which are later overwritten by a new fragment which is closer to the viewer.(Carmack used that in Quake3)
Another thing which will definitely speed up things is the use of Instancing. You store only the position of each voxel and, if nescessary, its scale and other parameters into a texturebufferobject. In the vertexshader you can then read the positions of the voxels to be spawned and create an instance of the voxel(i.e. a cube which is given to the shader in a vertexbufferobject). So you send the 8 Vertices + 8 Normals (3 *sizeof(float) *8 +3 *sizeof(float) *8 + floats for color/texture etc...) only once to the card in the VBO and then only the positions of the instances of the Cube(3*sizeof(float)*number of voxels) in the TBO.
Maybe it is possibile to parallelize things between GPU and CPU by combining all 3 steps in 2 threads, in the CPU-thread you check the octrees pvs and update a TBO for instancing in the next frame, the GPU-thread does meanwhile render the 2 passes while using an TBO for instancing which was created by the CPU thread in the previous step. After that you switch TBOs. If the Camera has not moved you don't even have to do the CPU-calculations again.
Another kind of tree you me be interested in is the so called k-d-tree, which is more general than octrees.
PS: sorry for my english, it's not the clearest....
There are 3rd-party libraries you could use to make the rendering more efficient. For example the C++ PolyVox library can take a volume and generate the mesh for you in an efficient way. It has built-in methods for reducing triangle count and helping to generate things like ambient occlusion. It's got a good community around it so getting support on the forum should be easy.
Have you used a common display list for all your cubes ?
Do you skip calling drawing code of cubes which are not visible to the user ?
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.