Strips are better.

Since most objects are modelled by hand, they might not be well striped. There are a several programs out there that will do the job for you, and I have one in source form. Unfortunately I have lost the URL for it, but if you mail me I will mail you the source (76kb zipped). On that theme I have several technical papers on generating strips in PDF format. If you want those I can mail you those too (521kb zipped). All the mentioned files were gained freely from around the ''net.



Stay Lucky, Graham "Mournblade" Reeds.

Since everyone is in such agreement, I thought I would throw in my 2cents.

I was taught about something called "Big Oh" notation. This is by far the most important thing to consider when designing applications for speed.

A simple example is a routine to do collision detection. Let''s say for example that you have 1000 objects and that each object
could possibly collide with any of the other 999 objects.

If you made a routine that was something like:

for( i=0;i<1000;i++ ) for( j=i+1; j<1000; j++ )
{
if( colliding( i,j ) ) hitroutine( i, j );
}

then more important than optimizing functions "colliding"
and hitroutine would be to figuring out a way to not have
to check 1000 objects against 1000 objects each. Because,
this causes the above loop to execute 1,000,000 times. This
explodes proportionally to n^^2 or "n squared" where n is the
number of objects.

There is a whole class of algorithms that are "n squared."
And there are some that are "n cubed." These are generally
problems when n gets big, and n doesn''t even have to be that
big for it to impact your system.

Things that only have to go through a list once are called "order n" or O(n). (Pronounced "Big Oh sub in").

So without writing a book about the topic, try to think more about how many times you have to go through a loop first.

Also, as a general suggestion, learn to use the timers on your system. Yes you will have to relearn them on each system. But do it. Then use those timer routines and store the results in some variables. Then take samples of the CPU clock in several places and look at them all. The amount of CPU time that elapses from one call to the timer routines to the next will tell you how long it took. You can then determine what functions are between those two calls, and find out where your time is being spent.

To start off, try to put two timers in your code. One at the top of your main loop, and one in the middle. Figure out which out of those two is the biggest, then keep working your way down to a single function. Then work backwards. In other words, you will compile the code once for each new timer function that is called.

Using this technique, you will recompile your code log2(n) times where n is the number of functions in your code. For example, if you have 8192 functions in your code, you will only have to recompile it 14 times. More likely you have more like 100 functions or less, in which case you''ll only have to recompile at most 7 times.

Depending on your amount of skill and knowledge of the system you are working on, you can save even more time over the long run by investing in an optimization tool like Vtune. There''s also profiling available for many compilers.

I hope this was useful information. If not, then you get what you pay for!

--
- Aaron

Hang on everybody. If he's programming OpenGL and doesn't have really really complex geometry then the time it takes OpenGL to render will be the slowest thing in his code.

What card are you using?

Take Ingenu's advice, group rendered objects by texture and material. View-frustum cull objects that aren't visible - use a BSP tree if your doing an indoor engine.

Also, use display list wherever possible.

Leave all the math optimisation until last. Look up tables can be slower in some intances, they can stall the CPUs pipeline (esp. big lookup tables)

Edited by - Pauly on October 11, 2000 9:32:04 AM