Skip to main content
GameDev.net gamedev.net
🔒 Locked

Rendering Models in OpenGL

Started by zaambu Jul 12, 2004 at 4:17 PM 5 replies 1.3k views
Original Post
zaambu
zaambu
Hello. I'm trying to decide on a way to store and render my models for an OpenGL graphics engine, and I'd like some advice. Right now I'm storing my models as lists of vertices, triangles, meshes, and materials, with appropriate indices from one list into another (e.g. each triangle stores three indices into the vertex list, etc.). This representation makes it easy to deal with animated joints and such. It seems like a pretty standard method -- I see it used everywhere. However, I'm finding it difficult to render these models efficiently. Normally I'd use VAs or VBOs with glDrawElements, but since I have lists of triangles pointing at lists of vertices I don't think I can use this method. Since the whole point of storing models this way is to make it easy to apply joint movement or fancy shader effects, I can't use drawlists either. My question is: am I stuck using immediate-mode rendering for these kinds of models, or is there a standard way to draw these models quickly in OpenGL? Or, alternatively, is there a better way to store my models that solves this problem? Thanks
Monder
Monder
Just store the vertex data in a single interleaved buffer, e.g. for every vertex you may have a position, a normal, and two sets of tex coords (one for the base texture, another for something such as a normal map). Your interleaved array is then set up something like this:

vertexpos1
normal1
texcoord1
texcoord2
vertexpos1
normal1
texcoord1
texcoord2
...
vertexposn
normaln
texcoordn
texcoordn

Use the stride parameter of the appropiate OGL functions when setting up VAs before rendering so it doesn't use normal1 for vertexpos2 or whatever.

You then have a seperate index buffer with indexes each vertex. Then for animation use a vertex shader, if they're not available code a fallback software path that directly alters your interleaved buffer.

Of course this is not the only way to do it(or even the most efficient).

zaambu
zaambu
The main reason I moved away from that solution is the need to deal with hard edges. Having a single normal per vertex doesn't work very well if I'm rendering, say, a cube. To represent a model of a cube in the interleaved manner you described, I'd have to store at least 3 vertex objects for each "vertex" of the cube; one for each of the three faces it's adjacent to.

The method you described works, but it seems messy to me. If I want to modify a vertex location, I'd like to just modify a single object, instead of having to find all of the vertex objects that refer to a particular point in space.

Is this not actually a problem in practice?

Thanks
Monder
Monder
Quote:
I'd have to store at least 3 vertex objects for each "vertex" of the cube


No you don't that's where the index buffer comes in, you can refer to the same vertex multiple times, unless of course you want something about that vertex different when you refer to it (e.g. a texture coordinate) a second, third etc time. In this case you will need to create a new vertex with the differing attribute as you can't have an index buffer with seperate indicies for things like texture coordinates and verticies (AFAIK).
zaambu
zaambu
If I'm dealing with a hard edge, (like the edge of a cube), then the normals for the vertices will change depending on what face of the cube I'm rendering. That's why I'd need to list the vertices multiple times.

For example, this article describes a model renderer that mixes smooth normals and hard edges. Unfortunately, it does all of its rendering via display lists, so it can't use, say, a CG shader program.

What I'm looking for is an efficient way to render a complex model structure other than display lists. I'm starting to think that such a thing doesn't exist... :(
kburkhart84
kburkhart84
I honestly think that Immediate mode is fine for animated models and easier too. What usually eats up more polygons is scene detail such as trees and terrain. The characters that are animated usually aren't too many to worry about. The models could be culled at an object level as well so if they are behind you, they don't get drawn. I think that is enough optimisation along with back side culling to make a good FPS with animated models and immediate mode.


zedzeek
zedzeek
theres no real way around it u will have to repeat vertices.
eg a cube needs 24 verts even though there are only 8 diffenrt ones

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.