Sign in to follow this  
gyula

Is this code optimized?

Recommended Posts

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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this