Sign in to follow this  

Can the IK subsystem be described as a "Mover"?

Recommended Posts

In my design, every mover will carry at least one thread.
And also, every game object carries at least one thread too.

If the IK is *NOT* a mover, unlike other stuff like the pathfinder and physics,
which each of them has a least one thread, then IK will be handled by the game object thread.

when the game object is updating the IK, it will deal with the IK there.
Other stuff like pathfinding, when looping the game object, it will issue requests to pathfinder,
and the pathfinder thread will work on it and tell the game object it has finished the job and you can interpolate on the waypoints?
Thanks
Jack

Share this post


Link to post
Share on other sites
I'm not familiar with this "mover" vs "not mover" idea. Does anything stop working right if you arbitrarily put the IK in the "mover" category or the "not mover" category? If so, then that's the answer. Otherwise, pick either one.

What I'm worried about: Each thread has a separate thread stack in RAM. Start too many threads and you'll waste a LOT of RAM.

If you plan on using threads heavily, consider using a fixed number of threads (a thread pool) which poll for tasks (independent batches of data that need to be processed). Then you can make the tasks be anything you want.

Share this post


Link to post
Share on other sites

If I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider

should I open 14-15 threads including one main thread?

 

But I am still having doubts abou the one thread per object approach.

9 threads in game objects is a resource hog and also the main thread

has nothing to do at all!!

 

If not otherwise, should I throw the game objects into a loop, or should

I submit requests on regular basis?

Edited by lucky6969b

Share this post


Link to post
Share on other sites
Wherever you have a system which may use a lot of threads, consider creating a thread pool.

A thread pool basically manages allocation of and recycling of threads so that the load is split evenly between a set number of threads e.g. 8 or 16 (just an example) based upon what is optimal for the hardware rather than just letting the thread allocation run out of control.

This might solve a few problems if you really must thread pathfinders etc.

Personally I'd have one pathfinding thread, and queue requests in that thread, passing back responses to the requestor on completion. Only if the queue is getting unreasonably long during play might I consider multiple path finding queue threads but this would be set at compile time rather than runtime.

Just my own 3 cents (2 cents adjusted for inflation)...

Share this post


Link to post
Share on other sites

One thread per object is a terrible idea. One thread per system (or mover, or whatever you want to call them) is also a terrible idea.

The number of threads should match the capabilities of the hardware.

 

As Nypyren says, you should have a fixed number of threads in a thread pool, and then your objects and systems should generate tasks for that thread pool to execute.

This way you can keep the CPU as busy as possible, without wasting resources.

 

Having too many threads just means a bunch of them are sleeping and do nothing but waste resources and will make your program execute slower.

Share this post


Link to post
Share on other sites

There is not much point in having many more ready-to-run threads than you have CPU-cores.

 

Mostly a single CPU-core can work on one thread. This is not entirely true, eg hyperthreading does 2 threads, but at a reduced speed.

If you start 15 threads on a dual core machine, about 12 of the 15 threads are just blocked on not having a CPU-core to run on.

 

Edit: Ninja'd by Olaf Hedman

Edit2: Add "-core" to the CPU, to clarify.

Edited by Alberth

Share this post


Link to post
Share on other sites

I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider should I open 14-15 threads including one main thread?
No no no. No thread pools. No thread anything. You stop using threads right now. No idea where you got this "one thread per object" idea from.

 

Do a single game loop in the main thread for now.

Share this post


Link to post
Share on other sites

No idea where you got this "one thread per object" idea from.
 


Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.

However, I see where you're going with your recommendation to avoid threads. Threads are a nightmare for even an experienced developer and should be used with extreme caution.

If there really is no other way, this is when you use threads, for example pathfinding several thousand actors across a gigantic navmesh in realtime whilst doing other AI and physics etc. Most of the big game engines have separate threads for things like physics and pathfinding, but they are much more complex systems, perhaps the adage applies: Keep It Simple.

Share this post


Link to post
Share on other sites

Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.
I'm going to blame every little single thing any C++ programmer does on the language. Every single one of them.

Share this post


Link to post
Share on other sites
Posted (edited)

I agree using one thread is most often the right idea because most games arent really cpu bound but data bound or gpu bound. (And threads also increase the complexity a lot) But if you find you really are cpu bound, and your cpu has cores to spare, thread pools is the way to go.

I dont want to start any language wars but I've also noticed a tendency to overuse threads by java developers. I dont know why, but an example is just starting my android studio ide and notice it spawns 70+ threads...

Edited by Olof Hedman

Share this post


Link to post
Share on other sites

I agree using one thread is most often the right idea because most games arent really cpu bound but data bound or gpu bound. (And threads also increase the complexity a lot) But if you find you really are cpu bound, and your cpu has cores to spare, thread pools is the way to go.

I dont want to start any language wars but I've also noticed a tendency to overuse threads by java developers. I dont know why, but an example is just starting my android studio ide and notice it spawns 70+ threads...


It's not really a language war that makes me say that java encourages overuse of resources.

It's two things, firstly that when I attended university we were told that the java design is such that you just fire and forget resource allocation, and the garbage collector handles it for you. Needless to say this didn't sound smart to me.

Secondly this is borne out by the fact that most java programs seem to use massive amounts of ram and threads, Android apps not withstanding.

I don't want to stray off topic though, perhaps this is a dead discussion best left to rot, or discussed in another thread?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this