# Is this code optimized?

## Recommended Posts

gyula    100
I am using a 'classy' ms3d animation code taken from http://openglgui.sourceforge.net/code.html and I am wondering if the code is unoptimized or the ms3d file is a bit of a mess. In the code (see excerpt) CMatrix& final = m_pJoints[m_pVertices[index].m_boneID].m_final; is applied to each vertex bound to a parent bone (see code) instead aplying it to group of meshes (bound to a bone) or at least a triangle bound to a bone. Turning the animation on and off for a set of 20 models decreases the frame rate by almost 50% with th animation on. My question is? Is demo code doing what is suposed to do transforming individual vertexes or not.
 for ( int k = 0; k < 3; k++ )
{
int index = pTri->m_vertexIndices[k];

// { NEW }
if ( m_pVertices[index].m_boneID == -1 )
{
// same as before
glTexCoord2f( pTri->m_s[k], pTri->m_t[k] );
glNormal3fv( pTri->m_vertexNormals[k] );
glVertex3fv( m_pVertices[index].m_Pos );
}
else
{
// rotate according to transformation matrix
CMatrix& final = m_pJoints[m_pVertices[index].m_boneID].m_final;

glTexCoord2f( pTri->m_s[k], pTri->m_t[k] );

CVector newNormal( pTri->m_vertexNormals[k][0], pTri->m_vertexNormals[k][1], pTri->m_vertexNormals[k][2], 1 );
newNormal.Transform3( &final );
newNormal.Normalize();
glNormal3fv( newNormal.m_pos);

CVector newVertex( m_pVertices[index].m_Pos[0], m_pVertices[index].m_Pos[1], m_pVertices[index].m_Pos[2] );
newVertex.Transform( &final );
glVertex3fv( newVertex.m_pos);
}
}


Thx for editing...

##### Share on other sites
Guy Perfect    122
At a cursory glance, not knowing the context of the code in the program it's a part of, I can see that minimal instructions are being given and I don't see a way to simplify them any further. I believe the code is optimized.

##### Share on other sites
Promit    13246
Optimized? It's using glVertex, for christ's sake. You'd have to maliciously add fluff to it to make it any slower.

##### Share on other sites
Dranith    504
As Promit said, IM code is the devil in terms of speed. I bet you would see a decent speedup just by converting that to use dynamic VBOs along with a single draw call.

##### Share on other sites
outRider    852
You're transforming the vertices in software, and normalizing the normals, which is why it's slower with animation on.

You can do all that in hardware, and you shouldn't need to normalize the normals unless you have some scaling going on.

##### Share on other sites
zedz    291
Quote:
 As Promit said, IM code is the devil in terms of speed. I bet you would see a decent speedup just by converting that to use dynamic VBOs along with a single draw call.

perhaps but as was mentioned
'Turning the animation on and off for a set of 20 models
decreases the frame rate by almost 50% with th animation on.'
i assume theres the same number of IM mode calls in both methods

why create another temporay here?
CVector newNormal( pTri->m_vertexNormals[k][0], pTri->m_vertexNormals[k][1], pTri->m_vertexNormals[k][2], 1 );
normal could also be normalized with gl (eith enable GL_NORMALIZE i think, or in a shader )

##### Share on other sites
oliii    2196
OpenGL immediate mode is sort of evil in that way. It's GREAT to prototype stuff quickly, and get some results with little work, but the performance will be poor. Use vertex and index buffers, like in DirectX. I'm not sure where display lists fit in, but if your mesh is dynamic (skinning), it's probably far from being optimum either. Skinning is best achieved using vertex shaders, but that's opening another can of worms.

## Create an account

Register a new account