Using Threads in a 3D Engine

Why would you want to use threads in your engine at all?

I saw an particle Engine that was using threads, one thread for drawing and the other one for physics.

That is NOT a very good approach to make the animation independent from the frame rate. use time-based animation instead. There is a flag to make D3D8 threadsafe if you want though

My general philosophy is to fear threads, and fear dynamic allocations/deletions.

I'm not saying that stuff is bad, not at all. I just try to avoid them unless doing so might be uglier than using them.

My game engine and entire game runs on the one main thread and does so just fine. I would argue that just about any game these days can get by with the one thread, or two threads if it is a multiplayer game. It's wise to use a separate thread to handle communication.

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy

[edited by - BS-er on August 11, 2002 5:08:47 PM]

On a single processor machine, I can gaurantee you won''t get any speed benefits at all from using threads. You might see benefits if you''re doing I/O intensive stuff like pre-loading textures or something, but that''s about it.

Plus, in my opinion, if you''ve got to ask, you don''t understand the topic enough to use them. Do some research separately if you like, but don''t use them for the first time in a game. You''ve got too much else to worry about, without the overhead of worrying about threads.

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

Exactly, threads is a catch word for some people... Threads can be VERY usefull, in for example server connection handling.
But drawing for your engine, is like suicide!

I use a thread in my 3d program, and I''ll explain why;

I have a landscape engine that displays 40 KM around the camera. However, the landscape is huge, 1000 KM. I could not load in all that data. The memory requirements would be too big... So, when the camera is moving around the landscape, I have to load in new chunks of data from the heightmap file, and unload the area that is now far away.

The loading/unloading can take some time. If I do this in the main thread, when you go over these magical boundaries, you get a slight "pause." I didn''t like that, I wanted nice fluid motion. So, I had to create a thread do all the loading.

Sounded easy and simple enough. However, the main rendering thread still choked the loading thread so it took forever to load in each section of the map. I had to put in a Sleep(2) in the main thread to give the secondary thread some room to breathe so it could load in a timely manner.

The performance penalty for adding a thread was Sleep(2) + thread overhead + checks to see when each section of the map was done loading in (so I could start rendering it)

So, you can see, I decreased the performance (not much) of my engine by adding a thread, but it eliminated the stutter.

----

My answer is: It all depends on your engine and the need for a thread. If you have no need for one, then no, don''t have one.

becareful with 3d api. threads make them slow. Direct3d suffers if the used with multithreading flag on.
opengl i am not sure is thread safe at all.

dont use threads for 3d rendering. other aspects of the engine its ok but not for 3d rendering.

Its my duty, to please that booty ! - John Shaft

The only time you want to use more than one thread per-processor is if the 2nd thread is blocked and waiting on some external event to complete.

A good example would be waiting for a disk i/o operation to finish, or a socket sitting in listen mode waiting for incoming data. In this case your main thread is jamming away and the background thread is sleeping.

It is not a good idea to have two threads working simultaneously on a single proc system for an application like a CPU intensive game. You have limited control over when the thread switch occurs. Sleep(1) can take much longer than 1 millisecond to complete. IIRC, the quantum on Windows is around 10 msecs.

Not to mention that mastering thread synchronization gives newbies the fits. You absolutely must test your multithreaded code on single proc and multiproc machines. The true simultaneous execution of your code on a multiproc machine can be a bear to debug.

Ok, thanks for your suggestions. After all I think I should leave multithreading out of my Engine and investigate the
time in the main routines.

Best Regards,
Tealc