| Home | Making it fast is a matter of algorithms and 3D card speed mostly, not so much which CPU you're running on. |
|
|
|
OPTIMIZING GEOMETRY HITTING
One of the greatest speed-ups I've seen, next to selecting a faster 3D card, is caching the triangle that is underneath the wheel. Badly split tracks can hold up calculations because a lot of triangles have to be checked for intersections, of which many are missed.
On a 200Mhz SGI O2, I ran Racer at 1000Hz to test my triangle caching. Here are the results:
| Version | Percentage of work for the physics on a bad part of the track |
| First hack'n'slash triangle intersection calculations | 63% |
| Optimized vertex passing to intersection function | 54% |
| Culling of faces to avoid hitting backfacing polygons | 46% |
| Caching the last known triangle/geode | 17% |
| Turning off triangle intersections altogether | 15% |
As you can see, the last step paid off and things are not that far off from omitting triangle intersections altogether, so I've approached the limit for this algorithm.
OPTIMIZING GRAPHICS
I've noticed that using vertex arrays versus display lists didn't have an impact on rendering speed. Even more so, display lists cost more display memory, and there's still not a lot of it on most machines.
Also, perform culling on your geometry! I perform per-geode culling, so I cull away entire blobs of geometry, instead of testing each triangle, which is a tedious task and can quickly turn into too much work. Ofcourse, striking the balance is not trivial and is quite dependent on your system (i.e. where your bottleneck is).
(last updated November 13, 2012 )