Threads for the purpose of accurate physics
Author
Hi, I''m new around here, but not to programming.
I really appreciate it and admire you if you read all the way through this post. Some is a little irrelevant, but it might be interesting to read.
I am writing a "game engine" based around Genesis3D. Genesis3D is great and all for graphics (free is good too), but I''m having to do all my own physics, input, networking, etc. and I have a problem with physics right now. The problem I have is mostly theoretical but somewhat practical.
When doing collision detection and movement of objects around in space, I have to use a time variable to scale all the movement by for the next frame update. The way I currently approach the calculations is to do them all right before I actually draw the frame. Due to variances in framerate, this can cause the physics to go quite awry when I get a framerate spike and I''m not using "perfect" equations and methods of calculation.
So I thought that threads might be able to solve this problem. By using a client/server thread mechanism, I believe that I could get the server to do all the calculations at a fairly constant rate and the client can do all the input/output work of the program. This would mostly eliminate the problem of mistiming things, even though some erros would still occur. My main query arises from the thread volatility issue. The variables and objects in my game will have to be shared between client and server on the same machine for the sake of efficiency in both memory and speed. So I''ll end up getting the info out of the calculations before the calculations on all the objects are complete. This could lead to an interesting effect: Objects being hit by other things after the frame draw could appear to bounce around in unusual fashions.
So how can I solve the thread volatility problem? Should I just maintain a "usable" position value in each object and only use that, and update it at the end of each calculation cycle while denying the client access to the data (make the thread wait...)? That seems to be the most logical solution to me, but there might be other methods that I''m overlooking. Also, if you have any hints on avoiding strange collision errors in the low end of time resolution (i.e. things going through each other in strange manners...the result of one object moving, and then another moving, even though they really had conflicting paths...) I''d definitely like to hear solutions for that kind of problem.
Thanks to all
Assassin
anthalaris.8k.com
First off, I just want to let you know that I am by no means a programming or physics guru, I''m just another coder who has a little experience. Now, with that out of the way...
From my exeperiences with physics updates and varying framerates, I have found that for my application, it is best to avoid separate threads altogether for similar reasons as those you mentioned. Without setting some sort of global flags to say when it''s cool for the other thread to access certain info, there will inevitably be synchronization problems between the server and client. How I got around this is by putting my update/evolve functions and input on a set timer (30 a second, or whatever) but keep the display functions running at the highest speed as they can. By doing this, your framerate can vary quite widely without affecting the physics updates at all. It will also avoid the side-effect of your physics running twice as fast on a 1GHz machine versus a 500MHz one, while still allowing the guy on the fast machine to see the 75 frames per second that he wants to get out of his expensive computer and you to get an admirable 30-40; I''m not sure if this helped you much but I hope it was at least a little bit informative to hear how I''ve tried to deal with it. It''s all about the scalability, baby!
Good Luck!
From my exeperiences with physics updates and varying framerates, I have found that for my application, it is best to avoid separate threads altogether for similar reasons as those you mentioned. Without setting some sort of global flags to say when it''s cool for the other thread to access certain info, there will inevitably be synchronization problems between the server and client. How I got around this is by putting my update/evolve functions and input on a set timer (30 a second, or whatever) but keep the display functions running at the highest speed as they can. By doing this, your framerate can vary quite widely without affecting the physics updates at all. It will also avoid the side-effect of your physics running twice as fast on a 1GHz machine versus a 500MHz one, while still allowing the guy on the fast machine to see the 75 frames per second that he wants to get out of his expensive computer and you to get an admirable 30-40; I''m not sure if this helped you much but I hope it was at least a little bit informative to hear how I''ve tried to deal with it. It''s all about the scalability, baby!
Good Luck!
Author
I understand that concept. Right now i'm using a similar method, but with variable timing. I have everything in one big loop and the physics calculations are done before each frame draw. However, I don't have access to super-fast computers so that physics calculation doesn't happen 30 times a second. 30-40 is the high end of my framerate counter... (I run on a voodoo1 and k6 200) and I quite often delve into the single-digit framerates. At that level, the physics go quite bad, and so I figured that using a separate thread to maintain correct values (at a specified frequency of updates) would be a much better solution. It would also allow the server thread to synchronize with a central server and have the client thread just get the latest values.
So my proposition: Let each object have 2 sets of members. One set is for the actual calculations and the other is just "vital information" that the client can use. The server thread goes throught doing all its calculations and when it gets done with an "update frame" it stops the client thread from grabbing the vital values and goes throught updating them. Then it lets the client get the vital values. While the client renders, the server cannot access the data. This seeems like a good approach until you realize that a massive list of objects would reduce the framerate to a crawl. I guess I could let the client retrieve any value that isn't being actively modified, as it is only a visual display.
Any more suggestions before I start modifying my program for this method?
Edited by - Assassin on 4/6/00 5:21:38 PM
So my proposition: Let each object have 2 sets of members. One set is for the actual calculations and the other is just "vital information" that the client can use. The server thread goes throught doing all its calculations and when it gets done with an "update frame" it stops the client thread from grabbing the vital values and goes throught updating them. Then it lets the client get the vital values. While the client renders, the server cannot access the data. This seeems like a good approach until you realize that a massive list of objects would reduce the framerate to a crawl. I guess I could let the client retrieve any value that isn't being actively modified, as it is only a visual display.
Any more suggestions before I start modifying my program for this method?
Edited by - Assassin on 4/6/00 5:21:38 PM
Don''t write a multithreaded engine. I made the experience that you only lose time because of the thread-switching if you have no multi-processor system. You should put the input/output into a main loop and put the physics to a TimerProc.
Visit our homepage: www.rarebyte.de.st
GA
Visit our homepage: www.rarebyte.de.st
GA
Hey there Assassin,
I was thinking exactly what GA was thinking... ie, you''ll probably take a bit of a hit with switching threads anyway.
I''ve found it adequate to do what he says, and perform physics after a known (or as close as possible) amount of time rather than every frame, because, as you say, it can be a bit expensive.
my game loops look sort of like this:
while (not time to exit)
currentTime = timeGetTime()
if (currentTime - prevCheckTime >= someThreshold)
DoPhysics //NOTE:use actual time interval in calculations rather than the expected one, in case it went a little over
prevCheckTime = timeGetTime()
end if
DrawFrame()
....
....
end while
This seems to give a decent trade-off between performance and accuracy that you can tweak by shortening/lengthening the time threshold/interval that you wait between physics updates.
Hope that helped a bit
-------------
squirrels are a remarkable source of protein...
I was thinking exactly what GA was thinking... ie, you''ll probably take a bit of a hit with switching threads anyway.
I''ve found it adequate to do what he says, and perform physics after a known (or as close as possible) amount of time rather than every frame, because, as you say, it can be a bit expensive.
my game loops look sort of like this:
while (not time to exit)
currentTime = timeGetTime()
if (currentTime - prevCheckTime >= someThreshold)
DoPhysics //NOTE:use actual time interval in calculations rather than the expected one, in case it went a little over
prevCheckTime = timeGetTime()
end if
DrawFrame()
....
....
end while
This seems to give a decent trade-off between performance and accuracy that you can tweak by shortening/lengthening the time threshold/interval that you wait between physics updates.
Hope that helped a bit
-------------
squirrels are a remarkable source of protein...
Author
I get where you''re coming from. But I don''t see where the hit in perrformance from switching threads would come from; Windows System Monitor reports that I currently have 102 threads running, and I''m not seeing massive slowdowns. I''m not playing a game though...
Basically, my idea was to separate the client and server modules because if I don''t and I have a bad framerate, then the stuff goes to hell. The "actual time" will be WAY over the threshold and collisions go crazy and all sorts of bad suff happens. It''s quite useless testing for time elapsed over a threshold when a simple frame update takes tons of time to process. I was planning to implement a method much like the one you listed in the server code, updating only once in a while to avoid chewing up massive cycles. It can sleep() between updates to free up cycles to the client thread (if that''s possible).
I just don''t really see a problem with doing multithreaded applications. There are only a few cases I have to avoid to keep from having synch errors, and apart from that it seems to be a very good solution.
As I finish this up, I''m now running 107 threads. And my processor usage is at a very low 20%.
Basically, my idea was to separate the client and server modules because if I don''t and I have a bad framerate, then the stuff goes to hell. The "actual time" will be WAY over the threshold and collisions go crazy and all sorts of bad suff happens. It''s quite useless testing for time elapsed over a threshold when a simple frame update takes tons of time to process. I was planning to implement a method much like the one you listed in the server code, updating only once in a while to avoid chewing up massive cycles. It can sleep() between updates to free up cycles to the client thread (if that''s possible).
I just don''t really see a problem with doing multithreaded applications. There are only a few cases I have to avoid to keep from having synch errors, and apart from that it seems to be a very good solution.
As I finish this up, I''m now running 107 threads. And my processor usage is at a very low 20%.
Actually, if you could somehow relinquish time slices from the physics thread to the main game thread, I suppose it wouldn''t be so bad after all... I thought you meant you would just switch threads and compute the physics every frame (which struck me as a bit pointless), however the rust has now flaked off my useless brain (I''m at work, therefore no need to think 
), and I see what you mean.
Your problem will indeed be maintaining consistent data and managing access between the threads (I''ve never really done much multithreading, but it seems to be a pain in the arse). I''d be interested to see how you can solve it. Is that what you use a mutex or a semaphore for? (sorry, I really suck when it comes to multithreading/multitasking )
thankyoubye
-------------
squirrels are a remarkable source of protein...
), and I see what you mean.Your problem will indeed be maintaining consistent data and managing access between the threads (I''ve never really done much multithreading, but it seems to be a pain in the arse). I''d be interested to see how you can solve it. Is that what you use a mutex or a semaphore for? (sorry, I really suck when it comes to multithreading/multitasking
)thankyoubye
-------------
squirrels are a remarkable source of protein...
What sort of physics calculations are we talking here?
Projectile Motion is my guess.
Projectile motion SHOULD NOT be a huge hit on performance.
Projectile Motion is relatively simple:
First before we do anything we add a time_since_last_update variable into each object that we are calculating:
then we can practically (for most purposes) forget about off screen objects. However, if your game can sometimes involve a great number of objects, that are off-screen we should be calculating them once every say 5 to 10 frames. This should reduce the load on the CPU. Now the only problem with this is that if you are in a "big battle", say a RTS. You can miss a off-screen unit because the physics engine isn''t updating enough.
Here are the basic physic "straight line" formulas:
s=ut+.5at^2
s=vt-.5at^2
v=u+at
v^2 = u^2 + 2as
s = .5(u+v)t
where s is displacement (Change in position
where v is current velocity
where u is initial velocity
where a is acceleration
where t is time
Now if you were working in 3d you would have a straight line function for each dimension. Which if you had a lot
of object could indeed slow the crap out of an engine.
However you could do quite a bit to optimize this.
-Big Al
Projectile Motion is my guess.
Projectile motion SHOULD NOT be a huge hit on performance.
Projectile Motion is relatively simple:
First before we do anything we add a time_since_last_update variable into each object that we are calculating:
then we can practically (for most purposes) forget about off screen objects. However, if your game can sometimes involve a great number of objects, that are off-screen we should be calculating them once every say 5 to 10 frames. This should reduce the load on the CPU. Now the only problem with this is that if you are in a "big battle", say a RTS. You can miss a off-screen unit because the physics engine isn''t updating enough.
Here are the basic physic "straight line" formulas:
s=ut+.5at^2
s=vt-.5at^2
v=u+at
v^2 = u^2 + 2as
s = .5(u+v)t
where s is displacement (Change in position
where v is current velocity
where u is initial velocity
where a is acceleration
where t is time
Now if you were working in 3d you would have a straight line function for each dimension. Which if you had a lot
of object could indeed slow the crap out of an engine.
However you could do quite a bit to optimize this.
-Big Al
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
