I'm trying to actually learn OpenGL after having experimented with it for a while, and so I'm trying to build a rudimentary rendering engine (not a game engine) to lead me through it. I've come to a conceptual obstacle however: I don't know exactly what a model really is. I mean obviously, it is composed of one of more meshes and textures, and other important data. But how much data? Should shaders be associated with models directly, with each one holding some sort of reference to the shader they require? Or should that be handled in another layer?

I think it makes sense to incorporate the shader program and the necessary parameters along with the meshes and textures as part of a model, but I wanted a more experienced opinion.


A model often refers to it's geometric data such as vertices (aka mesh data) and it's rendering properties commonly refered to as materials to give you the actual rendered object.

A single model can reference multiple materials where a material describes the blending algorithm, texture data, and shader references that combined together yield what finally gets rendered for a particular subsection of a model and other various rendering artifacts.

It's important that your shaders are kept separated like this because you likely will reuse a shader on multiple models or objects in your scene. For example, I have a shader that fades an object in and out of a scene based on opacity. Such a shader is useful for transitions as objects come into view or leave view for various reasons.

  • \$\begingroup\$ I guess my idea is weird, but I was thinking of having mesh data in its own class, and model data would just be an aggregation of mesh data, textures, and a shader program it uses, and any of those things could be "hot-swapped". I know about shader re-use, I meant each "model" would hold, say, a pointer to a shader object that would be initialized ahead of time. Does this make any sense? \$\endgroup\$ – chbaker0 Oct 27 '14 at 19:57
  • 1
    \$\begingroup\$ Yep, sounds very similar to OGRE3D's Entity class where it contains multiple SubEntities for each sub-mesh that has a particular material with it's own set of shaders and parameters. \$\endgroup\$ – Naros Oct 27 '14 at 20:53
  • 1
    \$\begingroup\$ usually models are split into their regions that uses different materials. also, when serialized, "Pointers" can be named IDs. like "black hair material". The mesh (submesh) holds the UV in the vertices structure, but the material holds the textures and "pointers"(or ids) to its shaders. \$\endgroup\$ – v.oddou Oct 28 '14 at 3:10

There is no absolute answer. Generally a "model" is some representation of something interesting in your computer program.

In CG it often means the geometry, and a typical model format might be something like:

  • List of vertices (maybe with graphical attributes like color)
  • List of polygons which reference vertex list with attributes like Material ref or Texture ref (and maybe overriding vertex attributes)
  • A list of material definitions and texture content
  • Maybe higher level groupings, like List of objects, each pointing to a list of polys
  • Lists of instances of these objects, like a fleet of cars, with overrides for their particular position, rotation, maybe even color...

Or it could be very flat, like a raw OpenGL vertex triangle list.

Or it could be very high level, with parameterized instantiations of procedurally generated geometry invocations, like

  • Gear(position,diameter, thickiness, number of teeth)
  • CityBuilding(location, style, number of stories, footprint polygon)

The "model" is expressed at some level of abstraction, and that level depends on how it needs to be used.

That all said, if you take a look at the Collada format, you'll see a pretty common, useful, and relatively straightforward interchange format for rendering and geometry.




A model is a logical container that contains - among other things - mesh data. Depending on the format it can also reference external assets such textures and shaders. With FBX, for instance, you can even export cameras and lights from whatever DCC was used to create it, so your model can contain that data. At that point, you can even think of the model as a complex scene. OBJ on the other hand is pretty much vertices/indices/texture cords/materials only, so your model would have to be simplified down to that.

You could technically create your own "model" format/definition in your own engine and it could reference the things you mentioned (necessary/custom parameters).


Your Answer

