Advise on 3D optimisation
Author
I am making a first person game using direct 3d 9.0. I have loaded a mesh of a city from a .x file which is quite basic and around 5,000 polys. However when I run the program I get about 4-5 fps at best. This is my first attempt at a 3d game and am not sure how to get round this problem. I assume the whole model is drawn every frame even if parts of it cannot be seen through the viewport. Are there any inbuilt functions in direct 3d that only draw what can be seen? or can you suggest any other way of making it run faster? any advise would be greatly received.
What you''re looking for is called frustrum culling. It culls (omits from rendering) anything outside your current view. I don''t think it''s built into DirectX (at least it wasn''t prior to 9). You''ll need to implement it on your own and there are dozens of different algorithms for doing it. One that I''m familiar with is implemented using what''s called a quadtree.
Google is your friend.
Incidentally, 5000 polygons is not that many. Unless your video card is relatively low-end, you may just need to optimize your code a tad. With a GeForce 2 ti, I am pulling about 60-70 fps on 4000 polys (and my code is not optimized very well).
-bpopp
Google is your friend.
Incidentally, 5000 polygons is not that many. Unless your video card is relatively low-end, you may just need to optimize your code a tad. With a GeForce 2 ti, I am pulling about 60-70 fps on 4000 polys (and my code is not optimized very well).
-bpopp
have you tried the Optimize function? (i think it is part of the ID3DXBaseMesh interface, you can find it in the SDK help to figure it out)
It sorts the vertices of the mesh so that internal render state changes and texture changes are minimized for rendering, which results in a significant performance gain (i tried it on a house model which was rendered at about 5 fps without and well over 50 fps with the Optimize call).
It sorts the vertices of the mesh so that internal render state changes and texture changes are minimized for rendering, which results in a significant performance gain (i tried it on a house model which was rendered at about 5 fps without and well over 50 fps with the Optimize call).
5000 polys is NOTHING on a geforce class card. The lowest end geforces can push 20-30 million polys per second, leaving you with half a million per frame. In practice lower than that of course, but you should be able to reach much higher framerates with that scene unless you are fill limited
5000 polygons is nothing on any hardware, you should be able to get 5000 polygons at a minimum of 60Hz even on a 1997 Matrox Mystique or S3 ViRGE - the fact that you''re getting 4-5 frames a second hints that there is something wrong somewhere.
1) Are you using the sample framework from the SDK for your application? - if so check it isn''t using the Reference Rasterizer? (if your application asks for something which your hardware can''t do, the sample framework uses the RefRast [RefRast is implemented entirely in software and favours accuracy over speed]). The performance you''re reporting hints that this is on RefRast...
2) What graphics card do you have? - does it have at least DirectX 7 drivers? (The sample framework will also fallback to RefRast if it doesn''t detect any D3D9 capable HAL - if you don''t have at least a DX7 gfx card, then you won''t have a DX9 capable HAL).
3) If your graphics card is something like a GeForce or Radeon, then run DXDIAG and perform all tests to ensure there isn''t anything wrong with your hardware.
4) If you''re creating the D3D device with HARDWARE_VERTEX_PROCESSING, then make sure that NONE of your vertex buffers have the SOFTWARE_VERTEX_PROCESSING flag specified on their creation calls.
5) And vice versa - if the device is created with SOFTWARE_VERTEX_PROCESSING (or mixed with SWVP enabled), ensure that the SOFTWARE_VERTEX_PROCESSING flag is set for ALL vertex and index buffers you create.
6) Increase the D3D debug output level in the control panel and
see if D3D has any warnings for you etc on the output window.
7) Just to confirm: You aren''t calling any D3D Create* style calls (CreateVertexBuffer etc) every frame? - if you are, don''t, they''re very slow due to all the work they do behind the scenes!
8) Do you have any complex blending or pixel shaders used by your city model ? (a city without culling is an invitation for fillrate fluctuations - though 4-5 fps is still more likely something else)
9) Try the SDK samples - do they exhibit the same problems? - In a few rare cases the rest of your machine configuration may be at fault:
a. Check that your motherboard drivers are up to date (very important for AGP performance amongst other things)
b. Install any CPU specific drivers - for example some CPUs have extra AGP miniport drivers and CPU patch drivers.
c. Make sure you have all current Windows Service Packs installed - Windows 2000 for example has a rare bug which causes performance problems for some D3D setups - it was fixed in SP3.
d. Check that the AGP aperture size is set sensibly in the BIOS (e.g. not 0, not using all physical RAM, no set too high...)
e. Try the safe defaults in the BIOS (particularly if you''ve been experimenting) - AGP fast writes etc don''t work properly on some very well known hardware.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
1) Are you using the sample framework from the SDK for your application? - if so check it isn''t using the Reference Rasterizer? (if your application asks for something which your hardware can''t do, the sample framework uses the RefRast [RefRast is implemented entirely in software and favours accuracy over speed]). The performance you''re reporting hints that this is on RefRast...
2) What graphics card do you have? - does it have at least DirectX 7 drivers? (The sample framework will also fallback to RefRast if it doesn''t detect any D3D9 capable HAL - if you don''t have at least a DX7 gfx card, then you won''t have a DX9 capable HAL).
3) If your graphics card is something like a GeForce or Radeon, then run DXDIAG and perform all tests to ensure there isn''t anything wrong with your hardware.
4) If you''re creating the D3D device with HARDWARE_VERTEX_PROCESSING, then make sure that NONE of your vertex buffers have the SOFTWARE_VERTEX_PROCESSING flag specified on their creation calls.
5) And vice versa - if the device is created with SOFTWARE_VERTEX_PROCESSING (or mixed with SWVP enabled), ensure that the SOFTWARE_VERTEX_PROCESSING flag is set for ALL vertex and index buffers you create.
6) Increase the D3D debug output level in the control panel and
see if D3D has any warnings for you etc on the output window.
7) Just to confirm: You aren''t calling any D3D Create* style calls (CreateVertexBuffer etc) every frame? - if you are, don''t, they''re very slow due to all the work they do behind the scenes!
8) Do you have any complex blending or pixel shaders used by your city model ? (a city without culling is an invitation for fillrate fluctuations - though 4-5 fps is still more likely something else)
9) Try the SDK samples - do they exhibit the same problems? - In a few rare cases the rest of your machine configuration may be at fault:
a. Check that your motherboard drivers are up to date (very important for AGP performance amongst other things)
b. Install any CPU specific drivers - for example some CPUs have extra AGP miniport drivers and CPU patch drivers.
c. Make sure you have all current Windows Service Packs installed - Windows 2000 for example has a rare bug which causes performance problems for some D3D setups - it was fixed in SP3.
d. Check that the AGP aperture size is set sensibly in the BIOS (e.g. not 0, not using all physical RAM, no set too high...)
e. Try the safe defaults in the BIOS (particularly if you''ve been experimenting) - AGP fast writes etc don''t work properly on some very well known hardware.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
