Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

b00ny

Ideas for optimisation?

This topic is 6187 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I'm currently writing a game and am developing my 3D engine as I go using the "First get it working, then make it fast" approach. Well, I've got it working but now I want to make it faster. Basically, I have a class to manage the "world" - CWorld, and I have a class to manage objects - CObject. The CWorld class has a list of CObject representing the objects that are to be rendered. The CObject class has an internal D3DXMesh and loads the information from an .X file. To render the world, I do the following:
  
for (int i=0; i<m_iNumObjects; i++)
{
    // Clear down all textures in between rendering objects

    for (int j=0; j<8; j++)
    {
        m_pd3dDevice->SetTexture( j,NULL );
    }

    m_pObj[i]->SetWorldTransform();
    m_pObj[i]->Render();
}
  
Each call in above loop to an objects Render() method results in :
  
for (DWORD i=0; i<m_dwNumMaterials; i++)
{
    // Set the material and texture for this subset

    m_pd3dDevice->SetMaterial( &m_pMeshMaterials[i] );
    m_pd3dDevice->SetTexture( 0, m_pMeshTextures[i] );

    // Draw the mesh subset

    m_pMesh->DrawSubset( i );
}
  
To me, this seems like it's going to be horribly in-efficient? This is the main rendering code - so I want this to be as fast as possible. Is there a better way to render this list of objects in terms of reducing the number of SetMaterial / SetTexture calls. I know I should have some code in there so that only the objects that will be visible on screen get rendered - but currently all objects are visible all of the time and I'm still not happy with the framerate. I'd appreciate any comments or ideas you might have. Thanks for taking the time to read. Boony. Edited by - b00ny on September 9, 2001 5:46:32 PM Edited by - b00ny on September 9, 2001 7:16:36 PM

Share this post


Link to post
Share on other sites
Advertisement
I don''t quite know how to respond to the code. I''m
not sure what you are trying to do. But I will make
observances:

1) Your nested loop to clear all textures to NULL.
Pretty expensive. In your render code bit, I see
you are setting texture index 0 only. Why are
you clearing the others ? Maybe you don''t have to
clear any texture. I''m not quite sure though.
You could try remming that out and see what happens.

2) In your render loop, you set the material, texture
for every object rendered. Do any of the objects
share a material or a texture ? If so, you can
batch the objects together with similar char-
acteristics. If they all share the same material,
you can set the material outside the loop.

< There are strange things done in the midnight sun by
men who moil for gold. > Robert W. Service

Share this post


Link to post
Share on other sites
Thanks for posting Guy. I''ll take your points on board... But...

Do you (or anyone reading) know if the SetTexture calls are *that* expensive?

I just did a quick hack - eliminating the set textures alltogether - resulting in everything being rendered with the skybox texture - and it didn''t really make any difference to the speed.

At the moment, I''m getting getting 45 fps in 1024x768 rendering 1800 polygons. That''s on a PIII 500 Mhz with Matrox G400 card. Seems way too slow to me... Am I right?

It seems like the biggest impact on performance is the size of the textures... if I reduce the main texture from 128x128x256 to 64x64x256 - the fps reaches the 60fps maximum (it''s VSync''d with the monitor refresh). Should that make *so much* difference or am I doing something silly?

Thanks again...

Share this post


Link to post
Share on other sites
You are right, a SetTexture probably does not chew up
frame rates too much. I just like taking as much stuff
out of nested loops as I can.

Changing the texture size was a very good idea for
increasing frame rate. As long as you like the result.
If you don''t like the result, you might consider
mip mapping the textures. In this way, the textures
are sized automatically according to distance. Smaller
textures are used for objects far away that don''t need
detail, and near objects use large textures for full
detail. I consider 60 fps a good target. I believe the
human brain can only take pictures at about this rate,
so that makes things very fluid.

Right now I have a frame rate of about 45 fps. It looks
OK to me but I''m trying to increase the frame rate as much
as I can. I know it''s going to drop as I add more objects
to the program.

Share this post


Link to post
Share on other sites
Actually, changing the texture is one of the most expensive operations (next to changing the vertexbuffer). I believe that using X-files is also a major bogdown, but you''ll have to figure that out for yourself. I suggest that you check out the nVidia developers site (www.nvidia.com), it has some great documents on speed optimizations. In a nuttshell it comes to this:


1) use indexed trianglestrips whenever you can. Don''t use trianglefans

2) limit yourself to one vertexbuffer. If you make it dynamic, make sure you use the right flags!

3) order your primitives by texture, and then maybe by other states so the amount of statechanging is minimal

4) locking a buffer means stalling the system. Try to limit the amount of locks you have to do. I read somewhere that if you have to lock a buffer during rendering, you''re doing something wrong.

After all the documents I''ve read on the subject, I believe these are the most important optimizations.

Share this post


Link to post
Share on other sites
Thanks for the comments guys, I''ll try to implement them soon and see if I can speed things up.

I''ve got another idea too - I''m gonna do some experiments and see if it makes a difference... I''ll let you know how I get on.

Thanks again.

Boony.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!