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);
}
}
Is this code optimized?
Author
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.
Thx for editing...
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.
Optimized? It's using glVertex, for christ's sake. You'd have to maliciously add fluff to it to make it any slower.
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.
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.
You can do all that in hardware, and you shouldn't need to normalize the normals unless you have some scaling going on.
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 )
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
