1
\$\begingroup\$

Which brings better performance at run-time: a cube imported from a mesh, or a cube made from hardcoded vertices?

Are there limitations to a certain method? Is one of them better architectural-wise?

\$\endgroup\$

4 Answers 4

18
\$\begingroup\$

Once it's in memory, verts are verts.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Once its in memory, variables are variables (this is a low level programming question at its crux) \$\endgroup\$
    – bobobobo
    Aug 20, 2011 at 0:02
  • 1
    \$\begingroup\$ Meshes are verts with indicies (and good ones at that). Still, it's still relevant - if you set up an index buffer etc. correctly it's just as good. \$\endgroup\$ Nov 22, 2011 at 12:27
4
\$\begingroup\$

If by hardcoded vertices, you mean glBegin ... glEnd (OpenGL), or Draw(Indexed)PrimitiveUP (Direct3D), these methods are inferior because they result in the vertices being transferred from system memory to the graphics card every time they're called.

If, however, you're putting your vertices into a vertex buffer like you should be, it really doesn't matter. If your cube is logically an art asset, like the Horadric Cube, or the Weighted Companion Cube, it should probably be stored as a model on disk. If your cube is, on the other hand, intended to be used for skybox rendering, and therefore immutable, hard-coding it is probably fine.

\$\endgroup\$
1
\$\begingroup\$

When it comes down to raw speed, a hard-coded set of vertices (and indices) embedded in the application's data region will be faster; this is because you avoid the cost of loading the mesh from disk. For simple applications, such as rendering a triangle or a cube on the screen, this approach is fine. In practice however, geometry and other resources such as textures are typically loaded from some resource file on disk into memory. This approach is beneficial for many reasons, but two major reasons are: loading and unloading resources at will and decoupling the application from its resources.

\$\endgroup\$
1
\$\begingroup\$

Depends. If we're talking something as simple as a cube, you're going to want to hardcode it. The loading time for all 8 vertices is not worth it. Same can be said for any simple geometric shape; just make a CreateSphereMesh, CreateCubeMesh, etc. set of functions.

However, have fun making an OVER 9000 vertex model by specifying the individual vertices. And tweaking. Oh, and animating. That's when it's much better to have it as a model format.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .